01:27 librasteve_ left
lizmat m: use nqp; my $a = 42; my $b = 7; my $c := nqp::mod_I($a,$b,Int) for ^10000000; say now - ENTER now 13:36
camelia P6opaque: get_boxed_ref could not unbox for the representation 'P6bigint' of type Scalar
in block <unit> at <tmp> line 1
lizmat m: use nqp; my $a := 42; my $b := 7; my $c := nqp::mod_I($a,$b,Int) for ^10000000; say now - ENTER now
camelia 4.461088037
lizmat m: use nqp; my $a := 42; my $b := 7; my $c := $a - ($a div $b) * $b for ^10000000; say now - ENTER now 13:37
camelia 0.825001458
lizmat so why is the nqp op basically 6x as slow as the HLL module calculation ?
[Coke] the optimizer is working? 14:39
Is the HLL smart enough to see you're doing the same thing with raku code a million times, but not smart enough to see it when calling "out" to nqp? 14:40
lizmat not sure 14:42
seems to be like that for a long time, and the reason that currently Int mod Int doesn't use nqp::mod_I apparently
patrickb It seems 20:38
yes, yes it does.🤦🏻 20:39
Second try. It seems that the moar debugger api hangs when being suspended and then requesting to add another breakpoint. I'll investigate a bit more. But just a quick sanity check, am I supposed to do this in some very specific way? 20:41
(I'll paste a full api log in a moment.) 20:42
lizmat not sure: something effectively makes nqp::mod_I a lot slower than the equivalent in Raku...
patrickb paste.sr.ht/~patrickb/418e9e096367...389dd0019b 20:51
lizmat not sure what I'm looking at there 20:53
patrickb That's a log of all the data flowing through the moar debugger api 21:13
the last line is the second request to add a breakpoint. That request doesn't receive an answer. 21:14
line 9 is the first breakpoint request. Line 10 is the confirmation. Line 11 is the breakpoint being hit. 21:15
lizmat ah, ok.. I thought was in relation to mod_i 21:16
perhaps timo has an idea
patrickb I just noticed there is an also unanswered thread list request in between. Probably that's to blame... 21:22