|
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 | |||