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:04 reportable6 joined
moon-child me too 00:18
it makes perfect sense, but I never before considered that there was a limit to the number of branches and calls that could be in flight at a given time 00:19
Xliff jnthnwrthngtn: What would something like this look like in RakuAST. "sub a( &callback (gpointer) ) { ... }" 00:55
01:04 evalable6 left, linkable6 left 01:07 evalable6 joined
timo i definitely remember one example from that post 01:14
maybe i've read it in the past
it hasn't helped me make moar much faster yet :P
01:16 ggoebel left 01:29 frost joined 02:29 greppable6 left, releasable6 left, committable6 left, statisfiable6 left, nativecallable6 left, benchable6 left, bisectable6 left, squashable6 left, tellable6 left, quotable6 left, unicodable6 left, sourceable6 left, bloatable6 left, evalable6 left, shareable6 left, reportable6 left, coverable6 left, notable6 left 02:30 committable6 joined, sourceable6 joined 02:31 coverable6 joined, shareable6 joined, bisectable6 joined 02:32 quotable6 joined 03:29 unicodable6 joined 03:30 squashable6 joined, notable6 joined 03:31 tellable6 joined, releasable6 joined, greppable6 joined 04:00 squashable6 left, squashable6 joined
japhb That speed limits doc is very useful, thanks jnthnwrthngtn. I knew about some of the limits (the ones near the beginning mostly, as they existed back when I was doing a fair amount of assembly), but there were a fair few that were new. 04:08
04:15 squashable6 left 04:18 squashable6 joined 04:29 evalable6 joined 04:30 nativecallable6 joined 05:07 linkable6 joined 05:29 statisfiable6 joined 05:30 bloatable6 joined 05:54 nebuchadnezzar left, jnthnwrthngtn left, nebuchadnezzar joined, jnthnwrthngtn joined 06:02 reportable6 joined
Nicholas good *, #moarvm 06:16
06:18 brrt joined
brrt \o 06:24
06:29 benchable6 joined
Nicholas o/ 06:46
japhb: I have wondered about aarch64 JITs, but I won't have any real time for thinking about it, well, certainly before Christmas 06:58
07:11 brrt left 08:48 patrickb joined
patrickb o/ 08:49
Nicholas \o
08:50 Xliff left
patrickb Following yesterdays discussion about our JIT, I'd like to point out, that the idea has been floating around to make use of libgccjit as a way to move forward. We'd win a wide platform coverage, but giving up on the potential of the expr jit. (github.com/perl-foundation-outreac...ackend.md) 08:55
moon-child libgccjit isn't a true jit, just an in-memory compiler. I have no idea if raku can be fast without an inline cache 08:57
also gcc is really slow
09:26 squashable6 left 09:30 squashable6 joined 09:59 lizmat_ joined 10:03 lizmat left 10:08 lizmat_ left 10:09 lizmat joined 10:11 ggoebel joined
jnthnwrthngtn Curious. The Slang::SQL failure on new-disp is not a spesh bug. 10:32
m: use nqp; my $x := nqp::null(); say 1 ~~ $x.WHAT 10:34
camelia Cannot call method 'ACCEPTS' on a null object
in block <unit> at <tmp> line 1
jnthnwrthngtn m: use nqp; sub foo() { nqp::null }; my $cb := foo(); dd $cb 10:39
camelia Mu
jnthnwrthngtn m: use nqp; sub foo() { nqp::null }; my $cb := foo(); say $cb.HOW.name($cb)
camelia Mu
jnthnwrthngtn We no longer translate the null into a Mu there
Nicholas so this is underspecified behaviour of the language, which changed, and someone happened to be relying on the previous behaviour? 10:41
jnthnwrthngtn Pretty much. Though it's also relativley easy to mitigate without perf consequences. 10:42
I'm just a bit curious where it happened before now
Ah, I see it 10:43
I wonder why that didn't get ported...
gah, I've fixed this before and I suspect due to the same module :P github.com/rakudo/rakudo/commit/47...3153e75e3e 10:44
Nicholas change status to "Tests needed?" :-/ 10:46
10:53 Altai-man joined
jnthnwrthngtn OK, got a fix, will just spectest it 10:53
I think this has been a problem in new-disp since the start, not a regression since the blin prior to the most recent one, fwiw
Altai-man: Do you know off-hand which of the busted CSS modules has the shallowest dep chain? 10:56
Altai-man I'll calculate right away. :)
tellable6 2021-09-25T08:38:21Z #raku <Kaiepi> altai-man, Trait::Traced's update has been released. Data::Record and Kind::Subset::Parametric need more maintenance, but should be doable over the weekend
jnthnwrthngtn Thanks
I sent a PR for Spit, and will soon push the Slang::SQL fix, and lizmat++ fixed hide-methods, so we're at 3 out of 5 10:57
Unless the CSS one is terribly gnarly, I think we'll be at 5 out of 5 today
Altai-man jnthnwrthngtn, CSS::Module 10:58
oh, fixed, that's great
I think I'll do a Blin run once CSS one is sorted out
10:59 frost left
Altai-man lizmat++ 11:00
jnthnwrthngtn I'll maybe look at the oversize callstack thing too, although I dunno whether to patch MoarVM or patch the module, since if the module is hitting this it's doing something terribly inefficient... 11:01
11:02 patrickb left 11:18 frost joined
jnthnwrthngtn m: use nqp; my \x := $["middle", [:keyw("middle")]]; my \y = x[1][0].keys[0]; say nqp::how_nd(y).name("") 11:23
camelia Str
jnthnwrthngtn m: use nqp; my \x := :keyw("middle"); my \y = x.keys[0]; say nqp::how_nd(y).name("") 11:24
camelia Str
jnthnwrthngtn That comes back as a Scalar containing a Str on new-disp, and is a golf of the CSS issue
11:30 ggoebel left
lizmat for reference: test-t between master and new-disp, with expression JIT disabled: 11:30
master: 1.351 / .644 11:31
camelia ( no output )
lizmat new-disp: 1.142 / .685
m: say 1.351 / 1.142 11:32
camelia 1.183012
lizmat so test-t being 18% faster on new-disp
jnthnwrthngtn What's the difference with/without expression JIT on new-disp?
m: use nqp; my $x = "x"; my \iter = Rakudo::Iterator.OneValue($x); my \y = iter.pull-one; say nqp::how_nd(y).name("") 11:34
camelia Scalar
jnthnwrthngtn Hmm...where is the container going...
11:35 squashable6 left
jnthnwrthngtn m: use nqp; my $x = "x"; my \iter = Rakudo::Iterator.OneValue($x); my \y = Seq.new(iter)[0]; say nqp::how_nd(y).name("") 11:36
camelia Scalar
lizmat jnthnwrthngtn: 1.142 -> 1.193
m: say 1.193 / 1.142
camelia 1.044658
lizmat so I guess about 4% faster
(on new-disp) 11:37
expect similar values on master
jnthnwrthngtn m: use nqp; my \p = :key("value"); my \y = nqp::getattr(p, Pair, Q/$!key/); say nqp::how_nd(y).name("") 11:38
camelia Str
jnthnwrthngtn Aha! That prints Scalar on new-disp
- # This candidate is needed because it currently JITS better 11:41
- multi method new(Pair: Cool:D \key, Mu \value) {
+ # This candidate is needed because it currently JITs better
+ multi method new(Pair: Cool:D $key, Mu \value) {
my \p := nqp::p6bindattrinvres(
- nqp::create(self),Pair,'$!key',nqp::decont(key));
+ nqp::create(self),Pair,'$!key',$key);
m: say Iterable ~~ Cool
camelia True
jnthnwrthngtn Anything typed Cool gets a defensive Scalar container
So the change to $ here isn't so useful. But why is it Cool:D not Str:D here? 11:42
lizmat: ^^
(Mostly really the last question. If we change Cool to Str then we fix it.) 11:43
lizmat then by all means :-) 11:47
jnthnwrthngtn OK, if you don't see a problem changing it to Str I'll do that 11:48
11:52 squashable6 joined 12:02 reportable6 left 12:05 reportable6 joined
jnthnwrthngtn OK, 4 out of 5 :) 12:12
lizmat whee! 12:18
12:50 ggoebel joined
nine jnthnwrthngtn: github.com/MoarVM/MoarVM/commit/5b...de30eb6010 makes me wonder why :invokish doesn't automatically lead to a Deopt One After annotation getting generated. E.g. continuationinvoke could also invoke code that causes a global deopt, leading to the same situation. 12:53
Geth MoarVM/new-disp: 09d4d26a2f | (Jonathan Worthington)++ | 2 files
Allow larger-than-default callstack records

Some very large argument flattenings can result in us wanting to allocate huge flattening records on the callstack. This is not at all an Allow larger-than-default callstack records
Some very large argument flattenings can result in us wanting to allocate huge flattening records on the callstack. This is not at all an efficient thing to do, but we should retain support for flattenings up to the size we did before the new dispatch mechanism. At the same time, we don't want the call stack regions to be made especially large; in fact, the current sizing is probably a bit too big for programs with lots of continuations taken. Thus, allow for oversized records to be allocated, fixing the issue and giving us flexibility to adopt a smaller default size in the future, if we see that it would be worthwhile.		 12:57
jnthnwrthngtn 5 out of 5
Altai-man Blin?
jnthnwrthngtn nine: It'd be a deopt all after, I think?
Altai-man: Yes
nine: And maybe that fix shoulda been a deopt all point too, though it probably makes no practical difference at the moment (but deopt all ones are those that are meant for global deopt) 12:59
nine jnthnwrthngtn: now that you mention that... why does my fix work at all? I.e. why do we need that Deopt One point when it's about a global deopt?
Ah, so it's just not that picky? 13:00
at the moment at least
jnthnwrthngtn Yes, for now
But we might some day see a benefit from differentiating'
nine Ah, ok. Still the question remains whether :invokish should just imply deoptallpoint
jnthnwrthngtn Perhaps we could merge them, yes 13:03
That probably makes sense
The number of invokish things in new-disp is happily much lower :) 13:04
nine I noticed :)
Nicholas jnthnwrthngtn: not sure if you want to, but on an NQP rebase, commit 505b57386788a937cc6fdccb92d396c3fe079e4a and commit e0a9d9d555d3b2efab2f6adceeac1c306458d863 could be dropped 13:08
(former reverts the latter)
(immediately adjacent in history)
jnthnwrthngtn Ah yes, makes sense. I guess we'll do a rebase pre-merge
Just need to remember to do it 13:09
Nicholas actualy looks like 1c65a8a035069e0d2a0994ce6ab865b2b46b2ad0 and its predecessor are another pair
Altai-man (no blin as 6lang.org is down atm) 13:10
jnthnwrthngtn What is 6lang? 13:11
*6lang.org?
Registry Expiry Date: 2021-09-28T04:32:52Z
That...doesn't look terribly good 13:12
Altai-man jnthnwrthngtn, a server where builds are created and stored for bisectable (thus blin).
as AlexDaniel left there were plans to kinda migrate it this spring but it never came into anything.
jnthnwrthngtn OK, well, it looks like the domain has expired, given it now goes to a landing page. 13:13
*holding page
13:15 frost left
jnthnwrthngtn Guess I should make attempt number 2 at callwith semantics... 13:16
13:20 Altai-man left 13:21 Altai-man joined 13:28 Altai-man left 13:30 Altai-man joined
dogbert17 Altai-man: wasn't HTML::Canvas part of the list of broken modules? 13:49
Altai-man dogbert17, is it failing? I get rid of the latest blin cache already.
s/get/got/
dogbert17 it's failing for me 13:50
Altai-man what's the failure mode?
dogbert17 t/cairo-transforms.t ........ Type check failed in assignment to @*SEEN[0]; expected Mu but got Int (1)
in regex seen at /home/dogbert/.rakudobrew/versions/moar-master/install/share/perl6/site/sources/D27DF7B10F5C7149981B725C01E93011DF7A12F1 (CSS::Specification::Defs) line 12
Altai-man interesting, I remember this failure, but wasn't it fixed?
inb4: not
dogbert17 I'm beginning to suspect that it wasn't 13:51
Altai-man well, then we have yet another one more thing, I guess.
dogbert17 perhaps you can try it as well :)
here's the failing line: github.com/css-raku/CSS-Specificat...akumod#L12 13:54
Altai-man so the golf is somewhere in this module then 13:55
nine Was it fixed in rakudo or via PR to the module (or one of its dependencies)?
dogbert17 nine: good question 13:56
called originated from this module: modules.raku.org/dist/CSS::Module:...rakumod#L9 13:59
Altai-man ===> Install [OK] for HTML::Canvas:ver<0.0.19>:auth<cpan:WARRINGD>
dogbert17 s/called/call/
whee 14:00
Altai-man > /home/koto/Devel/perl6-dev/R/install/bin/raku --version
Welcome to š‘ššš¤š®ššØā„¢ v2021.08-248-g1d1565f1b.
dogbert17 then I suggest we blame my install and continue :)
Altai-man dogbert17, I'd still suggest you to try to reproduce my result...
dogbert17 this module has 'a lot' of deps 14:03
===> Testing [FAIL]: HTML::Canvas:ver<0.0.19>:auth<cpan:WARRINGD> 14:04
Aborting due to test failure: HTML::Canvas:ver<0.0.19>:auth<cpan:WARRINGD> (use --force-test to override)
Welcome to š‘ššš¤š®ššØā„¢ v2021.08-248-g1d1565f1b. ... Built on MoarVM version 2021.08-583-g09d4d26a2. 14:05
Altai-man oh, I'm dumb
and now it'll fail... 14:06
dogbert17 ?
Altai-man I did `z mod ...` without `--tests`. :)
yes, the same failure 14:07
looking back at the log, I mentioned about it logs.liz.nl/moarvm/2021-09-10.html#12:42 <- 14:08
but then I left and it wasn't addressed, sigh
added to merge blockers
jnthnwrthngtn Sigh, that one really has too painful deps for me to want to hunt. 14:09
Altai-man dogbert17, could you please golf it? 14:10
dogbert17 I can try but I'm afraid I might fail ... 14:11
14:13 ggoebel left
Altai-man hmm, just `CSS::Properties.new.parse-property("font", "italic 5pt courier", :warn);` works fine. I suspect it's something related to Proxies maybe... 14:20
14:34 ggoebel joined 14:37 brrt joined 14:51 ggoebel left 15:30 brrt left 16:01 ggoebel joined 16:12 Altai-man left
[Coke] So, down to one merge blocker? Any other pre-merge work needs doing? Are we going to stick with master or cutover to main as long as we're doing a big change? 16:31
Geth MoarVM/new-disp: c010316ab8 | (Jonathan Worthington)++ | src/disp/program.c
Update resume states only after all guards

When we work through a dispatch program with resumptions, we may need to update the dispatch state. When there are nested resumptions, we may end up with multiple of those updates, and they may have guards between them. This meant that an update could be performed even if the overall dispatch would fail and fall back to recording a new dispatch program. Make sure to only update them when the dispatch program is fully accepted.		 16:45
lizmat new-disp: 1.119 / .677 # feels a tad faster, but could be noise 16:52
m: say 1.193 / 1.119
camelia 1.06613
lizmat m: say 1.351 / 1.119
camelia 1.207328
lizmat so 20% faster than master! that rhymes! 16:53
jnthnwrthngtn :D 16:55
Got a bit further on callwith stuffs, but seems it'll run into tomorrow
Geth MoarVM/new-disp: 1e92a42be6 | (Jonathan Worthington)++ | src/disp/program.c
Fix a tyupo
 16:58
MoarVM/new-disp: e70726a705 | (Jonathan Worthington)++ | 3 files
Experimentally allow args to next resumption

This will hopefully be helpful in getting `callwith` working fully. It is heavily restricted (by existing checks): the capture must be derived directly from the arguments given to the `callwith` and may have some extra constants added. It is not allowed to have values from resume init states. This, however, seems like it shall not be required - which is good, since it would be a significant additional amount of complexity.
jnthnwrthngtn omg, I didn't...
OK, let's call it humor :P
lizmat BTW, startup time seems to also have been reduced quite a bit, I just noticed 17:01
compared to before, not with master 17:02
[Coke] (startup) nice 17:07
lizmat from .160 -> .135 for me 17:12
nine A meta typo? 17:18
MasterDuke how recent was that .160?
lizmat a few days ago 17:21
jnthnwrthngtn Good about startup. Guess it's a combination of things nicely adding up
Home time for me o/ 17:22
lizmat MasterDuke: I guess 18d0d227c070ce3d on nqp did that 17:30
17:35 evalable6 left, linkable6 left 17:37 linkable6 joined 17:38 ggoebel left 18:03 reportable6 left
MasterDuke now this is interesting, i changed how i am jitting scsetobj to just move the interpreter's implementation out into a function, and they both call that. but, i still get the same segv! 18:04
18:05 reportable6 joined
nine MasterDuke: which line exactly? 18:20
MasterDuke gist.github.com/MasterDuke17/42081...ktrace-log 18:22
the segv is when building nqp, and fwiw, with my change to move the interpreter implementation out to a function, the nqp build does complete with MVM_JIT_DISABLE=1 18:23
nine MasterDuke: "set disassembly flavor intel" would help me :)
nine literally grew up with intel assembler syntax 18:24
MasterDuke heh, i looked for an option like that a day or two ago, but didn't notice one
oh, i'm blind 18:25
nine Btw. IIRC you asked about moving up in the disassembler view. That seems to work reliably in rr
18:25 ggoebel joined
MasterDuke gist updated with a gdb_intel.log 18:25
hm, maybe i should switch. wonder if i'd need to reboot though, i just updated my kernel and i don't know if the zen workaround will still apply 18:26
nine Unless you reboot, the old kernel (with workaround) is still active 18:27
That disassembly looks completely different to scsetobj.asm?
MasterDuke well, i don't think i applied the workaround to the kernel i'm running now 18:28
right. scsetobj right now is just a jit_append_call to MVM_scsetobj_impl
18:31 brrt joined
MasterDuke gist.github.com/MasterDuke17/42081...rent-patch shows what the diff to my branch is right now 18:31
i have jitted a bunch of other ops on this branch, but before this diff everything built ok and passed spectests 18:32
github.com/MasterDuke17/MoarVM/tre...ss_hot_ops the branch 18:40
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2021/09/27/2021-...ming-haku/ 18:44
nine I get the feeling that it's actually not your JIT code of scsetobj itself that's segfaulting 18:46
MasterDuke agreed 18:47
nine It's MVM_OP_scobjcount 18:52
jnthnwrthngtn + MVMint64 idx = ins->operands[1].lit_i64; 18:53
I think this is incorrect; the index is from a register, not a constant
So it should be s/lit_i64/reg.orig/
And MVM_JIT_REG_VAL just below 18:54
MasterDuke jnthnwrthngtn: ah, thanks. however, i just made those changes and still get the same segv 18:55
nine MasterDuke: ooooh it's such a trivial mistake :)
MasterDuke mine? 18:56
nine github.com/MoarVM/MoarVM/blob/mast...dasc#L1886 we want that to read WORK[sc], not WORK[dst]
Otherwise we read an uninitialized register (the one we would write into!) and explode 18:57
MasterDuke ha!
[Coke] many eyes make light work? (mixing a metaphor but maybe making a new one.) 18:58
So that bug is on *master*? oops.
MasterDuke heh. now i get to go back through all my different version of implementing scsetovj as a primitive instead of just a function call and see if any are correct...
or, do people think it's big enough that just doing it as a function call is good? 18:59
nine Btw how did I find out it was scobjcount in the first place? greped for "cmp" in emit.dasc to find one that would compare to a constant, noted that cmp_repr_id does and that 0x11 was MVM_REPR_ID_SCRef, then duplicated the | mov ARG1, TC; lines in the affected ops to make them distinguishable 19:00
MasterDuke nine: do you want to fix that on master right now? or should i just included that as a separate commit on my branch?
nine Well I think master is safe enough as there's only one caller in all of rakudo and that's blocked by the lack of scsetobj 19:01
MasterDuke there are a couple calls in nqp 19:02
it's even explicitly tested in nqp's tests
jnthnwrthngtn Gah, I forgot to push the callwith stuff I was working on at the office :/ 19:04
Nicholas You could have an evening off 19:05
jnthnwrthngtn Indeed :)
Nicholas (or fight teh dependencies for HTML::Canvas)
jnthnwrthngtn Only thing being I planned to work from home tomorrow. 19:06
Nicholas I think there's only one sensible choice :-)
jnthnwrthngtn Yeah, or that
Sigh, HTML::Canvas is not only "lots of native deps" but also "needs a newer version than is packaged" 19:14
bbl 19:15
Nicholas jnthnwrthngtn++ # bbl was the sensible choice :-)
jnthnwrthngtn (But generally: assume that I'm not going to be fixing HTML::Canvas without a golf that doesn't have all the deps.)
MasterDuke btw, did you figure out/fix that object creation benchmark regression?
jnthnwrthngtn MasterDuke: Yes, it's faster than master now 19:16
MasterDuke great
jnthnwrthngtn really away :) o/
Nicholas \o
MasterDuke fyi to anybody who cares, nqp and rakudo now build and pass all their tests on my branch with the fix to scobjcount + jitting of scsetobj 19:17
nine++
19:44 linkable6 left
[Coke] MasterDuke++ nine++ 19:52
I'll work on golfing the HTML::Canvas issue. 20:21
20:35 evalable6 joined
[Coke] so I built rakudo new-disp, installed zef into that local dir, ran a zef install of HTML::Canvas with that zef... and it all worked?\ 20:52
(oh, wait, I just did install-deps) 20:53
whew.
looks like it's related to this syntax: test-sheet(-> \ctx { ... }) 21:06
dogbert17 I didn't even understand what that did :( 21:11
21:45 brrt left
[Coke] github.com/css-raku/CSS-Specificat...od#L11-L13 21:53
That's the line that's throwing the error, but the stack strace is about 6 deep across the various modules.
gist.github.com/coke/1941961de1897...a4ffee7b61 is the golf so far. 21:56
jnthnwrthngtn [Coke]: Could try making `<?{@*SEEN[$opt]++}>` to `<?{dd @*SEEN; dd $opt; @*SEEN[$opt]++}>` to see if there's any clues in that
[Coke] added the stack trace.
jnthnwrthngtn [Coke]: Also: is it sensitive to MVM_SPESH_DISABLE=1 in the environment?
Oh, interesting, since it ends up very quickly in CSS::Properties I wonder if HTML::Canvas entirely golfs out of this 21:57
[Coke] nope, still fails
jnthnwrthngtn Oh, interesting. Then not an optimization/deoptimization bug. 21:58
"expected Mu" is really odd
I mean, Int is Mu, so what's going on... 21:59
22:03 ggoebel_ joined
[Coke] so, the golf needed .font called 2x. I see github.com/css-raku/HTML-Canvas-ra...#L120-L127 22:07
22:08 ggoebel left
[Coke] (which has a Proxy on the .font call) 22:08
and a 'self!call('font', $!font)', which looks maybe dispatchy
added ll-exception trace as well 22:17
22:46 linkable6 joined 23:31 AlexDaniel left
MasterDuke how come the callee-saved registers are (almost?) never used directly in op implementations in emit.dasc? the implementations have just always been so small they haven't been needed? 23:44
23:47 AlexDaniel joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!