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.
Nicholas good *able6, #moarvm 08:53
lizmat :-) 09:12
jnthnwrthngtn o/ 11:14
lizmat jnthnwrthngtn o/ 11:17
lizmat is feeling a lot less under the weather than yesterday
Nicholas \o 11:24
jnthnwrthngtn Stomach better, brain still mushy. 11:36
nine Well, progress 11:40
lizmat m: class A { has uint32 $!foo = 0x0ffffffff; method bar() { say $!foo } }; A.new.bar # meh 11:43
camelia -1
lizmat seems like native uint attributes lose their unsignedness 11:44
m: class A { has uint8 $!foo = 0x0ff; method bar() { say $!foo } }; A.new.bar # shorter
camelia -1
jnthnwrthngtn lizmat: Yeah, there's an issue for that 11:45
Just got this:
MoarVM oops: MVM_str_hash_entry_size called with a stale hashtable pointer
at gen/moar/Metamodel.nqp:4834 (/home/jnthn/dev/MoarVM/install/share/perl6/lib/Perl6/Metamodel.moarvm:enum_from_value)
from SETTING::src/core.c/Enumeration.pm6:54 (/home/jnthn/dev/MoarVM/install/share/perl6/runtime/CORE.c.setting.moarvm:FROM-VALUE)
And I think I saw a Rakudo PR recently about this?
Hah, yes! github.com/rakudo/rakudo/pull/4634 11:46
jnthnwrthngtn I'm so very glad to see all the QAST-y bits go away in NativeCall in github.com/rakudo/rakudo/pull/4629 12:06
I was looking at it and thinking "oh no, this could be an annoying thing to have to migrate in RakuAST" and now we won't have do :) 12:07
jnthnwrthngtn OK, all new-disp nativecall PRs reviewed; nine++ 12:21
nine Big thank you! Will probably fix the issues you pointed out tomorrow. 12:33
jnthnwrthngtn Ah, github.com/MoarVM/MoarVM/pull/1581 is still to merge 12:35
jnthnwrthngtn I'd really like to see it go in a week or so before the release 12:35
jnthnwrthngtn An approve \o/ 12:54
Geth MoarVM/master: 19 commits pushed by (Jonathan Worthington)++
review: github.com/MoarVM/MoarVM/compare/f...addda15faa
jnthnwrthngtn And in it goes. :)
inb4: yes, this is a good time for a bump :)
nine As anticipated, having spent significant time on this PR when we were looking for those strange errors on CI has made reviewing it much quicker
jnthnwrthngtn :) 12:55
lizmat jnthnwrthngtn: do we need to merge something in NQP as well ?
nine ? ^^ ? 12:56
nine lizmat: no 12:58
lizmat and not in rakudo either then, I assume
hmm... so what got merged into MoarVM just now then? 12:59
#1581 I guess ? 13:00
jnthnwrthngtn lizmat: Yes 13:03
It re-works how we handle returning and stack unwinding to full take advantage of the new callstack introduced in new-disp 13:04
*fully 13:05
Which allows various simplifications and thus a speedup
jnthnwrthngtn Also things using special return mechanism get to avoid malloc/free and just have state on the callstack instead, so there's a small win there also 13:05
nine And this stuff becomes easier to understand as well. Instead of special cases and branches all over the frame handling code, the callstack tells the story of what should happen when. In a sense the callstack becomes its own program. 13:09
lizmat bumped 13:24
fwiw, I got a wrong dependency messages just again 13:26
nuked the lib/.precomp and it went away 13:27
wonder whether we should provide a utility script to nuke all .precomp dirs
also, no noticeable improvement of test-t on my machine 13:28
nine thinks what we need is fixes, not better workarounds 13:29
lizmat last time I did a full .precomp nuke, it cleared about 1G in files 13:30
so there's use of such a script in other cases as well :-)
nine Same happens here. But then, we're probably recompiling rakudo more often than others recompile their raku programs 13:31
lizmat indeed :-) 13:32
jnthnwrthngtn lizmat: It's worth ~5% on a recursive fib benchmark (where the recursion implies loads of frame creation); ~2% or so is more likely on more typical applications. 13:39
And on micro-benchmarks where we overwhelmingly inline stuff, it's worth nearly nothing 13:40
lizmat yeah, I think the test-t benchmark is already pretty good at inlining
jnthnwrthngtn I saw a slight spectest time improvement from it also 13:41
lizmat makes mental note to run one tonight 13:45
lizmat m: my $a = "42"; for ^1000000 { my int $b = $a.Int }; say now - INIT now 13:56
camelia 0.381197921
lizmat m: my $a = "42"; for ^1000000 { my int $b = my str $ = $a }; say now - INIT now
camelia 0.061885142
lizmat quite a difference eh?
jnthnwrthngtn I'm not even sure the second of those should compile...
m: my $a = "4.6"; say $a.Int; say (my int $ = my str $ = $a); 13:58
camelia 4
4
lizmat m: my $a = "4.6e0"; say $a.Int; say (my int $ = my str $ = $a); 13:59
camelia 4
4
jnthnwrthngtn m: my $a = ""; say $a.Int; say (my int $ = my str $ = $a); 14:00
camelia 0
0
jnthnwrthngtn m: my $a = " "; say $a.Int; say (my int $ = my str $ = $a); 14:01
camelia 0
0
jnthnwrthngtn m: my $a = "?5"; say $a.Int; say (my int $ = my str $ = $a); 14:02
camelia Cannot convert string to number: base-10 number must begin with valid digits or '.' in '3⏏5?5' (indicated by ⏏)
in block <unit> at <tmp> line 1
jnthnwrthngtn m: my $a = chr(8722) ~ "5"; say $a.Int; say (my int $ = my str $ = $a);
camelia -5
Error encoding ASCII string: could not encode codepoint 8722
in block <unit> at <tmp> line 1
jnthnwrthngtn Ah, there's a difference :)
timo i did not expect moarvm to become based on ROP, return-oriented programming :) 16:23
dogbert17 MoarVM panic: Memory allocation failed; could not allocate 14391929568 bytes # hmm 17:41
have a suspicion that this is somehow GC-related. Here's the gist gist.github.com/dogbert17/93fc8512...ce49522baa 17:54
jnthnwrthngtn #4 0x00007ffff7924e5f in MVM_spesh_alloc (tc=0x555555623ac0, g=0x7ffff3b491d0, bytes=16195990944) at src/spesh/graph.c:41 18:03
#5 0x00007ffff793f20d in analyze_phi (tc=0x555555623ac0, g=0x7ffff3b491d0, ins=0x7ffff2cf374e) at src/spesh/optimize.c:2021
That's a big phi...
I'm guessing something accidentally goes negative or similar... 18:04
dogbert17 it's relatively easy to repro by setting the nursery size to ~50k and running: while MVM_SPESH_NODELAY=1 ./rakudo-m -Ilib t/spec/S32-num/complex.t; do :; done 18:07
sometimes it fails with 'MoarVM panic: Invalid owner in item added to GC worklist' 18:08
dogbert17 it's the kind of stuff Nine eats for breakfast :) 18:38
MasterDuke92 is it just me, or is github.com/MoarVM/MoarVM/blob/mast...#L136-L205 not really taking a substring like i would expect? 22:18
i.e., it doesn't start the string `start` num of graphemes in 22:19
looks like it happened here github.com/MoarVM/MoarVM/commit/6e...b7e4a27b37 22:23
jnthnwrthngtn: ^^^ 22:24
timo i don't think it skipped the beginning before that either? 22:41
oh 22:42
there it is
do we actually ever use the function with a nonzero start value? 22:43
MasterDuke92 github.com/MoarVM/MoarVM/blob/mast...ps.c#L1759 22:46
and i came across it because i'm just trying something that passes a value for `start` to MVM_string_ascii_encode_substr and noticed it didn't seem to be doing anything 22:49