Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
00:02 reportable6 left 00:03 reportable6 joined 00:21 CaCode_ joined 00:23 CaCode- left 00:24 CaCode joined 00:25 CaCode- joined, CaCode_ left 00:28 CaCode left 00:59 CaCode- left 01:57 discord-raku-bot joined 02:36 frost joined 03:36 releasable6 left, evalable6 left, linkable6 left 03:37 releasable6 joined 04:04 squashable6 left 05:04 quotable6 left, shareable6 left, bisectable6 left, nativecallable6 left, greppable6 left, releasable6 left, tellable6 left, unicodable6 left, reportable6 left, statisfiable6 left, sourceable6 left, bloatable6 left, notable6 left, committable6 left, coverable6 left, benchable6 left 05:05 bloatable6 joined 05:06 benchable6 joined, nativecallable6 joined, statisfiable6 joined 05:07 tellable6 joined, coverable6 joined, greppable6 joined 05:56 frost left 06:00 frost joined 06:05 unicodable6 joined, squashable6 joined, shareable6 joined, committable6 joined 06:06 sourceable6 joined 06:39 evalable6 joined 07:04 reportable6 joined 07:05 bisectable6 joined 07:07 quotable6 joined 07:38 linkable6 joined 08:07 releasable6 joined, notable6 joined 08:13 CaCode joined 08:23 frost left, CaCode left 09:20 MasterDuke joined 09:36 Colt left
MasterDuke perf says 53% of the time is spent in `__memmove_avx_unaligned_erms` for `my $str; $str ~= "$_\n" for 0..300000` ?!?! 09:40
Nicholas if true, that seems LTA 09:54
good *, *
10:36 linkable6 left, evalable6 left
Geth MoarVM/remove_callsite_flat_named_flag: 2c776f530e | (Stefan Seifert)++ | 3 files
Treat MVM_CALLSITE_ARG_(FLAT | NAMED) like FLAT_NAMED

If both the FLAT and NAMED flags are set, this means exactly the same as the FLAT_NAMED flag, so we treat them the same. Later on we can free up the FLAT_NAMED flag. Doing this in two steps to avoid bootstrapping issues.		 10:50
MoarVM/remove_callsite_flat_named_flag: cab24960ca | (Stefan Seifert)++ | 6 files
Free up MVM_CALLSITE_ARG_FLAT_NAMED flag

The flag is superseeded by the combination of MVM_CALLSITE_ARG_FLAT and MVM_CALLSITE_ARG_NAMED. Freeing it up, so we have a flag available for unsigned integers.
10:51 Geth left, Geth joined 11:37 linkable6 joined 11:59 patrickb joined 12:02 reportable6 left 12:03 reportable6 joined 12:38 evalable6 joined
nine Bootstrapping is da worst 13:06
lizmat curryworst > 13:34
?
lizmat runs 13:37
Nicholas nine: that (plus the NQP branch) works on "my" machine 13:50
nine And just 3 hours later I've finally managed to build the fix_unsigned branch after rebasing on top of remove_callsite_flat_named_flag 13:54
Nicholas \o/
ASAN yawns at your work so far.
(the branch I tested. Not the unsigned epic)
14:08 Colt joined
timo you've had the worst, now try the THIRST......... QUENCHER! 14:13
14:26 Colt left 14:27 Colt joined 14:30 Colt left 14:31 Colt joined 14:32 Colt left 14:34 Colt joined, Colt left, Colt joined 14:35 Colt left 17:30 linkable6 left, reportable6 left, notable6 left, evalable6 left, unicodable6 left, bisectable6 left, sourceable6 left, shareable6 left, quotable6 left, releasable6 left, statisfiable6 left, tellable6 left, benchable6 left, coverable6 left, squashable6 left, bloatable6 left, nativecallable6 left, greppable6 left, committable6 left, unicodable6 joined 17:31 benchable6 joined 17:32 coverable6 joined, nativecallable6 joined, evalable6 joined 17:33 tellable6 joined, reportable6 joined, releasable6 joined
nine I hope there is a way to avoid this uglyness: $!strings.write_uint8(my uint $zero := 0) 17:48
[Coke] add a new literal type with prefix u? 17:54
<-- Me, not helping. 17:55
18:02 reportable6 left 18:05 reportable6 joined
lizmat nine: maybe we need more candidates for write-uint? 18:07
m: dd Buf.new.write-uint8(2,767) # this seems to work ok? 18:09
camelia Buf.new(0,0,255)
nine lizmat: on fix_unsigned branches 18:21
lizmat nine: the code now says: "# for simplicity's sake, these are not multis" 18:22
they could well turn into multis afaics
m: multi sub a(int $a) { dd }; multi sub a(Int $a) { dd }; a 42; a my int $ = 666 18:23
camelia sub a(Int $a)
sub a(int $a)
lizmat m: my uint8 $a = my Int $ = 767; say $a # the non-native candidate would only need to do something like that? 18:25
camelia 255
18:31 bloatable6 joined 18:32 greppable6 joined, sourceable6 joined, statisfiable6 joined 18:33 linkable6 joined, committable6 joined
nine Ends in "No applicable candidates found to dispatch to for 'write_uint8'." 19:09
Nicholas you need more curry? 19:16
lizmat nine: is that really _uint8 ?? or -uint8 ? 19:17
19:31 notable6 joined 19:33 shareable6 joined, bisectable6 joined, squashable6 joined
nine _uint8 19:54
I have version for uint8, int8, uint and int but none seem to match 19:57
lizmat but but in Rakudo they're called with kebab-case ? 19:59
lizmat is confused
20:04 CaCode joined
nine Logical consequence: I'm talking about NQP ;) 20:08
20:10 vrurg left 20:13 vrurg joined 20:18 Geth left, Geth joined 20:19 [Coke] left 20:22 [Coke] joined
[Coke] . 20:22
20:41 Geth joined 20:53 Geth left, Geth joined 21:33 quotable6 joined 23:20 patrickb left
MasterDuke nqp::radix_I includes the radix ** number-of-digits-converted (github.com/Raku/nqp/blob/master/do...own#radix) as one of its return values, but that doesn't seem to be used all that frequently 23:21
i haven't benchmarked it yet, why couldn't that just be number-of-digits-converted? then the more common cases that don't use the value don't have all those extra bigint multiplications occurring, and the few users can do the exponentiation themselves 23:23
oh, it looks like it might speed it up a bit 23:33
m: use nqp; my $i; my int $r = (2**12).Int; my $l = ~(7**(+$r)); my $s = now; $i = nqp::radix_I(10, $l, 0, 0, Int)[0] for ^1_000; say now - $s; say $i
camelia 1.482196017
332331798909192794102011386849386170669696888974932434480342064556621190171437688707278118090123647686658608145199786447897387758210523180413213249103122582779768286375171704314531172355189641656150934709823053250062924250588570076715465…
MasterDuke locally that usually takes ~1.3s. if i strip out calculating the radix ** number-of-digits-converted and instead just return a bigint set to 1 (only slightly less work than actually required), the time drops to ~0.8s 23:36
of course not quite as big a difference with smaller strings. if i use 2**5 as the range in the above example (and increase the iterations to 100_000, the time drops from ~0.16s to ~0.12s 23:39
it's too late now, but maybe tomorrow i'll try creating a moarvm/nqp/rakudo trio of patches 23:45

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!