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 01:03 reportable6 joined 01:57 frost joined 03:40 linkable6 left, evalable6 left, quotable6 left, statisfiable6 left, bloatable6 left, notable6 left, greppable6 left, coverable6 left, reportable6 left, unicodable6 left, bisectable6 left, nativecallable6 left, tellable6 left, sourceable6 left, shareable6 left, releasable6 left, squashable6 left 03:41 sourceable6 joined, releasable6 joined, statisfiable6 joined 03:42 linkable6 joined, evalable6 joined 03:43 linkable6 joined, evalable6 joined, notable6 joined 04:41 coverable6 joined, reportable6 joined, bloatable6 joined, squashable6 joined 04:42 quotable6 joined 04:43 shareable6 joined, tellable6 joined 05:41 bisectable6 joined, greppable6 joined 06:02 reportable6 left 06:03 reportable6 joined 06:14 Util left 06:21 Util joined 07:09 ilogger2 left 07:11 ilogger2 joined 07:41 nativecallable6 joined 07:43 unicodable6 joined
Nicholas good UGT, * 07:52
beware of geeks bearing links. 07:56
( which seemingly is *roughly* correct -- en.wikiquote.org/wiki/Yes,_Ministe...d_of_Nails )
jnthnwrthngtn
.oO( We're no strangers to moar... )
 08:47
lizmat
.oO( we can haz never enoagh )
 08:50
09:04 squashable6 left 09:06 squashable6 joined
jnthnwrthngtn All the VMIL videos can be found at www.youtube.com/playlist?list=PLx0...kboVTTPPa- 09:30
Geth MoarVM/master: 4 commits pushed by (Stefan Seifert)++, (Jonathan Worthington)++ 09:34
MoarVM: ca87b70acd | (Daniel Green)++ | 2 files
Lego jit implementation of nqp::abs_i

This was seen to cause bails in a profile/spesh log of a simple Text::Diff::Sift4 benchmark.		 09:35
MoarVM: 439cc33ec5 | (Jonathan Worthington)++ (committed using GitHub Web editor) | 2 files
Merge pull request #1572 from MasterDuke17/jit_abs_i

Lego jit implementation of nqp::abs_i
lizmat feels a bump coming up? 09:37
jnthnwrthngtn Wasn't planning to 09:39
lizmat ok, so this will be post 2021.10 ?
jnthnwrthngtn Not sure how that follows? I figure anything merged or committed today will be in 2021.10. 09:42
lizmat well... only a few days before the release... I guess a blin run would need to have these changes ?
jnthnwrthngtn Sure, but I figure the bump can be done before the blin run to take in anything else that may land before then. 09:44
lizmat ok :-) just checking...
jnthnwrthngtn My megamorphic handler changes won't go into 2021.10, I think
(Those are in a Rakudo branch) 09:45
Nicholas Does t/02-rakudo/03-cmp-ok.t failing have an issue yet? (with MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1) In that, I know that nine figured out that it was something to do with PEA. But that means it's beyond my ability to fix it. (this yaer) 10:23
nine Btw. I bet it's the same issue as the 15-gh_1202.t flapper 10:24
10:29 Altai-man joined
lizmat too bad the Q&A on the keynote are not part of the video :-) 10:40
jnthnwrthngtn Indeed, there were some good questions 10:50
nine How were the reactions in general? 10:53
10:56 Util left
jnthnwrthngtn nine: Positive; seems folks found it interesting. 10:56
Was suggested that new-disp may relate to dl.acm.org/doi/10.1145/3428288 (which was in my reading list) and that in some senses we might have "got there first" 10:58
nine I guess it's about time you collect your Phd :D 11:01
Nicholas I believe that he'd need to write an actual thesis. Code doesn't cut it. 11:02
11:03 Util joined
nine That abstract reads like it describes spesh linking which I think we even had before new-disp? 11:03
Nicholas (this is time consuming and not necessarily fun)
jnthnwrthngtn nine: Possibly yes :) 11:05
nine Academia is waaay behind :)
jnthnwrthngtn I'm pretty sure we were ahead on arxiv.org/abs/1807.00661 11:06
Geth MoarVM: 5c6fd3b4dc | (Jonathan Worthington)++ | src/spesh/optimize.c
Add missing facts to spesh link guard

When we want to perform specialization linking, we insert a guard on the argument we have, and potentially then decont and check what is in the container. However, we weren't placing facts as a result of adding the guard on the container, thus leaving an sp_decont in the resulting output that could have instead been lowered to something cheaper. Add them.		 11:38
12:02 reportable6 left 12:03 reportable6 joined
timo "you can have little a run time at compile time, as a treat" 13:14
on one slide i see for a few frames the "i'd" at the start and the "ku" (from "Raku") at the end were cut off and then popped in i wonder how that happened 13:20
Altai-man jnthnwrthngtn, bad news, github.com/rakudo/rakudo/commit/ca...91030e55e2 broke some modules. 13:30
the failure states differ 13:31
I think we had this batch of modules before, not sure if rings the bell: SupplyTimeWindow, StrictNamedArguments, Staticish, HTTP::Request::FormData. 13:33
No exception handler located for catch with Concurrent::Stack, it seems the bug was uncovered by new-disp, making it more prone to happen. 13:34
jnthnwrthngtn Hmmm 13:39
Well, then the alternative is we regress no modules but ship with a more busted callwith I guess
What do the failure modes look like? 13:40
Altai-man most modules are getting type objects (Any, Nil) instead of real values (strings, integers), for the SupplyTimeWindow it's `Died with X::TypeCheck::Return+{X::React::Died}`, but I guess it has the same cause. 13:41
jnthnwrthngtn Are they actually using callwith?
Altai-man alas, yes. e.g. github.com/FCO/SupplyTimeWindow/bl...Window.pm6 13:42
jnthnwrthngtn Hm, that looks like a relatively straightward usage of callwith 13:43
Altai-man or github.com/zostay/HTTP-Request-For...#L178-L197 13:45
jnthnwrthngtn Ah, there's a pattern here: they all involve multi 13:46
multi methods, even
OK, will see if I can track it down
Altai-man github.com/cjfields/bioperl6/blob/...m6#L30-L33 <- yes, the idea seems to be on spot.
jnthnwrthngtn++ 13:47
13:50 frost left
timo ohmygosh spesh log comments got a little shout-out :3 13:55
that was me! :D 13:56
and wow, 3 years, 2 months ago was the commit that introduced them
[Coke] \o/
13:58 linkable6 left 14:01 linkable6 joined
timo a parallel i've never seen before was that making moarvm more "programmable" (with new-disp and such) being a performance revolution is a little bit like programmable pipelines on GPUs, i.e. going from the "fixed function pipeline" in opengl to shaders 14:08
where first you had to do stuff like glMaterialfv(GL_FRONT, GL_SPECULAR, mat_specular); glMaterialfv(GL_FRONT, GL_SHININESS, mat_shininess); 14:09
glLightfv(GL_LIGHT0, GL_POSITION, light_position); glEnable(GL_LIGHTING); glEnable(GL_LIGHT0);
and it goes from GL_LIGHT0 to GL_LIGHT7
and now, well, you write a shader, which is like twenty times as much code to set up, but you can now have more than just 8 light sources! 14:10
jdv jnthnwrthngtn: cool presentation, thanks 14:21
timo aww, the questions didn't make it into the recording :( 14:38
cognominal_ A jnthn presentation ? A treat ! Where is that ? URL ? 14:40
Altai-man cognominal_, www.youtube.com/watch?v=3lxuCr54UL...mp;index=2 14:44
cognominal_ MoarVM, almost from Moravia ? 14:55
timo long live space race, long live morvamia 15:02
15:25 evalable6 left, linkable6 left 15:26 linkable6 joined 15:28 evalable6 joined
nine I got into that talk twice :) First with the GCC plugin, then with boot-foreign-code 16:25
timo yu 16:26
very good indeed
16:28 linkable6 left, evalable6 left
jnthnwrthngtn m: say 56.826 / 58.737 16:28
camelia 0.967465
jnthnwrthngtn m: say 103.2 / 106.8 16:29
camelia 0.966292
16:29 linkable6 joined
timo interesting. more speedups from the megamorphic handling branch? 16:38
jnthnwrthngtn No 16:44
Geth MoarVM/cheaper-frames: c1950524d7 | (Jonathan Worthington)++ | 5 files
Allocate ->work registers on the call stack

Thus saving us a pair of FSA calls to allocate and free the registers for every frame invocation. While microbenchmarks where we manage to inline everything will just get a bit more done while interpreting, a more realistic program will benefit from this. For example, the Rakudo build process completes in around 96.7% of the time it used to before ... (12 more lines)		 17:03
timo oh my 17:07
stack regioin? :) 17:08
cool, in any case :)
Geth MoarVM/cheaper-frames: d83edbeac0 | (Jonathan Worthington)++ | 5 files
Allocate ->work registers on the call stack

Thus saving us a pair of FSA calls to allocate and free the registers for every frame invocation. While microbenchmarks where we manage to inline everything will just get a bit more done while interpreting, a more realistic program will benefit from this. For example, the Rakudo build process completes in around 96.7% of the time it used to before ... (12 more lines)		 17:10
jnthnwrthngtn Ammended to fix the typo :)
timo can't have a terrible typo like that, after all! 17:18
nine groins 17:19
17:20 Altai-man left
lizmat as they would say in Flanders: amai! 17:20
MasterDuke there's a new warning at interp.c:6721 17:21
src/core/interp.c: In function ‘MVM_interp_run_nested’: 17:22
src/core/interp.c:6721:29: warning: unused variable ‘csrecord’ [-Wunused-variable]
6721 | MVMCallStackRecord *csrecord = MVM_callstack_allocate_nested_runloop(tc);
jnthnwrthngtn ooh, that looks related to the nine++ PR I merged earlier 17:23
I guess it's harmless (the function is called for its side-effect and the result isn't needed)
nine Ah yes, that variable is only used in a debug build for the assert: assert(tc->stack_top == csrecord); 17:24
MasterDuke clang doesn't complain, but gcc does 17:25
jnthnwrthngtn I'd call that a gcc bug, tbh 17:27
Sure it optimizes the assert out in a non-debug build, but I'm not sure it should leak the fact
So far as the source goes it is used 17:28
Or maybe bug is strong, but LTA at least.
MasterDuke interestingly i'm building with --debug=3 17:29
jnthnwrthngtn Even odder
OK, home time for me
MasterDuke still complains without the --debug
nine Finally got a fix! 17:31
The issue was that we took the deopt_idx for the guard from the MVM_SPESH_ANN_DEOPT_PRE_INS annotation. But in this case there was also a MVM_SPESH_ANN_DEOPT_SYNTH. 17:32
And if there's also a synth annotation we need to give preference to that.
As the synth's deopt idx will be what the materializations are registered under
MasterDuke nice 17:34
Geth MoarVM/fix-pea-segfaults: 6ade9ae6af | (Stefan Seifert)++ | src/spesh/optimize.c
Fix uninitialized registers after deopt from dispatch guards

A dispatch gets translated to a sequence of operations culminating in the runbytecode instruction. The pre-deopt index of the original instruction will be found on the runbytecode itself or any of the guards stacked up before it. When looking for the pre-deopt index, we didn't take into account, that the instruction holding a suitable deopt pre ins annotation may also itself have ... (10 more lines)		 17:53
nine So, this ^^^ fixes the bug but for some obscure reason leads to a hang in t/spec/S12-construction/destruction.t 17:54
What the? The hang is there even if I disable spesh?! 17:55
Anyone else seeing this? 17:57
18:02 reportable6 left
MasterDuke testing it 18:05
perf top says it spending all its time in __memset_avx2_unaligned_erms and MVM_gc_collect 18:10
oh, isn't that the test i recently changed?!
yep 18:11
i got rid of a 5s timeout, but added the `quietly $*VM.request-garbage-collection;` 18:12
18:28 evalable6 joined
Nicholas jnthnwrthngtn: ASAN setting builds (with the FSA debugger) *really* like your branch because, well, there's a lot less mallocing. 18:49
stage parse down from about 380s to 300s 18:50
this has little *real* world impact (the real world uses the FSA) but it makes paranoia faster
nine MasterDuke: you know what fixes it? Removing the $*VM.request-garbage-collection 19:04
MasterDuke that's odd...
nine Know what also fixes it? Replacing $*VM.request-garbage-collection with use nqp; nqp::force_gc; 19:10
lizmat and if you replace it with VM.request-garbage-collection ? 19:13
aka, without the dynvar lookup ?
nine still hangs 19:15
lizmat so than it's dispatch related, not dynvar lookup related, I'd say ? 19:16
nine How can my change, that only touches spesh's optimizer cause this hang to appear, even when I run with spesh disabled? 19:17
If it's your garden variety memory layout issue, why is it so damn consistent and reproducible even across machines?
There's no flapping whatsoever. Some combinations work all the time while the rest hangs all the time 19:18
MasterDuke fyi, also hangs with spesh disabled and rakudo's --optimize=off 19:19
nine Yeah, it's bizarre 19:20
19:28 linkable6 left, evalable6 left 19:29 linkable6 joined
Geth MoarVM: niner++ created pull request #1573:
Fix uninitialized registers after deopt from dispatch guards		 19:31
MasterDuke just looking to see what CI has to say? 19:33
nine No, it's up for real. Yes, it triggers that weird GC issue, but there's just no way it can be responsible for it. Unless jnthnwrthngtn has some super surprising insight :) 19:35
MasterDuke heh 19:36
speaking jnthnwrthngtn++, just finished the talk, very good 19:37
nine: will an instruction never have a MVM_SPESH_ANN_DEOPT_PRE_INS without also having a MVM_SPESH_ANN_DEOPT_SYNTH? 19:41
nine MasterDuke: actually that question points me at a mistake 19:43
For the second loop (looking for DEOPT_PRE_INS) to make sense, I have to reset ann to ins->annotations
But that makes me really wonder if there actually can be a situation where we have a MVM_SPESH_ANN_DEOPT_PRE_INS but not a MVM_SPESH_ANN_DEOPT_SYNTH?
MasterDuke couldn't the if just be `if (ann->type == MVM_SPESH_ANN_DEOPT_SYNTH || ann->type == MVM_SPESH_ANN_DEOPT_PRE_INS)`? 19:44
nine No, because we may encounter the MVM_SPESH_ANN_DEOPT_PRE_INS first, but need to give preference to MVM_SPESH_ANN_DEOPT_SYNTH 19:45
MasterDuke or can the compiler reorder those?
Geth MoarVM/fix-pea-segfaults: b92ca73b48 | (Stefan Seifert)++ | src/spesh/optimize.c
Fix uninitialized registers after deopt from dispatch guards

A dispatch gets translated to a sequence of operations culminating in the runbytecode instruction. The pre-deopt index of the original instruction will be found on the runbytecode itself or any of the guards stacked up before it. When looking for the pre-deopt index, we didn't take into account, that the instruction holding a suitable deopt pre ins annotation may also itself have ... (10 more lines)
MasterDuke ah, right 19:46
nine New way to fix it: put my $foo = Foo.new; my $chld = Child.new unless +@destructor_order; into a sub and call that from the loop 19:49
MasterDuke i wonder how expensive that pointer chasing is? might it be cheaper to store the index of the first MVM_SPESH_ANN_DEOPT_PRE_INS found in the first loop and return that if it exists after the loop? then you wouldn't have the second loop at all
nine Probably won't matter as we expect some 0-2 annotations 19:51
MasterDuke ha, then yeah
nine I guess putting the test code in a sub helps because we run destructors when returning from a frame. But then, the VM.request-garbage-collection call actually provides a frame to return from 19:54
I had hoped that after github.com/MoarVM/MoarVM/commit/bb...0f45c3e080 we'd be past those finalizer issues. But apparently there's at least one more oddity left 19:56
OTOH it may be good that there is this very small test case now. Because I still see applications leak and debugging those would be horrible 19:57
20:31 evalable6 joined 22:04 reportable6 joined 22:14 dogbert17 left 22:53 dogbert17 joined 23:53 notable6 left, unicodable6 left, evalable6 left, reportable6 left, greppable6 left, sourceable6 left, statisfiable6 left, linkable6 left, nativecallable6 left, quotable6 left, bloatable6 left, releasable6 left, shareable6 left, coverable6 left, tellable6 left, bisectable6 left, committable6 left, benchable6 left, squashable6 left, coverable6 joined, bloatable6 joined, sourceable6 joined 23:54 notable6 joined 23:55 committable6 joined, reportable6 joined 23:56 linkable6 joined, releasable6 joined, squashable6 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!