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 00:43 kjp left 00:48 kjp joined 01:48 committable6 left, bloatable6 left, squashable6 left, greppable6 left, coverable6 left, nativecallable6 left, statisfiable6 left, bisectable6 left, shareable6 left, quotable6 left, benchable6 left, notable6 left, releasable6 left, sourceable6 left, tellable6 left, unicodable6 left, evalable6 left, reportable6 left, linkable6 left, nativecallable6 joined 01:49 tellable6 joined, bloatable6 joined, reportable6 joined, benchable6 joined, evalable6 joined 01:50 squashable6 joined, shareable6 joined 01:51 releasable6 joined, unicodable6 joined 02:49 committable6 joined 02:50 statisfiable6 joined 03:49 notable6 joined, greppable6 joined 03:51 bisectable6 joined 04:48 linkable6 joined 04:50 quotable6 joined 05:50 linkable6 left, quotable6 left, bisectable6 left, shareable6 left, nativecallable6 left, notable6 left, reportable6 left, tellable6 left, evalable6 left, statisfiable6 left, unicodable6 left, greppable6 left, bloatable6 left, benchable6 left, squashable6 left, releasable6 left, committable6 left, tellable6 joined, releasable6 joined, greppable6 joined, notable6 joined, unicodable6 joined 05:51 coverable6 joined, committable6 joined, quotable6 joined, statisfiable6 joined 05:52 linkable6 joined, squashable6 joined
Nicholas good *, #moarvm 06:14
timo ooh niiii~chon 06:17
...las 06:18
Nicholas Hello timo and hello to timo's cat 06:20
06:48 sourceable6 joined 06:50 bisectable6 joined 06:51 nativecallable6 joined, shareable6 joined 06:52 evalable6 joined 07:48 frost joined 07:50 bloatable6 joined, benchable6 joined 07:56 patrickb joined 08:03 reportable6 joined 08:19 Geth left 08:20 RakuIRCLogger left
timo i've been thinking a bit more about the callsite transformation cache business 08:40
08:40 RakuIRCLogger joined 08:41 Geth joined
timo first, trying to be clever and comparing the callsites in the intern cache with the one we expect by comparing flags until we hit the "remove from here" spot, then jumping ahead is not a great idea 08:41
since we're essentially competing against memcmp that we could have if we just call callsite_intern
so fixing that up to also be a memcmp would be a good first step 08:43
but then also: the "is inlined" flag is one bit in an 8 bit wide field
keeping 0 for "not inlined" and 1 for "inlined" we can use 253 numbers to indicate a position in another array 08:44
"not interned" and "interned"*
so an array of arrays with the outer array being "per arity" and the inner array being just a growing list of callsite -> pointer to another array would be a good start 08:46
that other array would have one slot for each of the flags the callsite has, and would point to the existing callsite that is equal to the given callsite except with the flag at that spot removed 08:47
now the bigger question becomes: is the size increase this entails worth whatever speed we gain from not having to go through all interned callsites of the "target" size 08:48
maybe what would work better instead is like a skip list that helps go through the lists of interned callsites faster by knowing the flags, for example 08:49
another thing that's of course also always possible is using a hash keyed on the flags bytestring 08:50
Nicholas: thoughts? :) 08:51
09:01 patrickb left
timo gist.github.com/timo/95b92b2c2f1a8...f0a8c24215 here's the data 09:08
callsites printed after a relatively simple progra run
no clue where these big numbers at the end coe from, those are supposed to be the arg_count values, but they should be 2x the amount of nameds + the arity as an upper bound 09:09
i wonder if maybe we're not using that field any more? 09:10
perhaps splitting them first by arity and second by whether it has named arguments is a good idea 09:11
jnthnwrthngtn It may be that a split of named or not already gets us a fairly big win, because without is the common case, and also the one with which there's relatively few permutations 09:45
The idea of stealing a few bits for storing a hint of where to look for a related callsite is neat 09:46
09:47 moon-child left
Nicholas "my brain is full" - I don't have any good answer to questions about hashes 09:48
09:51 moon-child joined
Geth MoarVM/make_temp_reg-init-all-64: ff687781e2 | (Nicholas Clark)++ | src/spesh/manipulate.c
All bits in the union returned by `make_temp_reg` should be initialised

  `make_temp_reg` returns `MVMSpeshOperand`, which is a union between various
types and structs, all of which are 64 bits or smaller.
Code in `optimize_bb_switch` evaluates `lit_i64 != -1` before calling
  `MVM_spesh_manipulate_release_temp_reg`. The struct within the union returned
... (9 more lines)		 09:59
MoarVM/make_temp_reg-init-all-64: 0ca25c96d9 | (Nicholas Clark)++ | src/spesh/manipulate.c
All bits in the union returned by `make_temp_reg` should be initialised

  `make_temp_reg` returns `MVMSpeshOperand`, which is a union between various
types and structs, all of which are 64 bits or smaller.
Code in `optimize_bb_switch` evaluates `lit_i64 != -1` before calling
  `MVM_spesh_manipulate_release_temp_reg`. The struct within the union returned
... (9 more lines)		 10:01
Nicholas 9 more lines one of which had a typo
Geth MoarVM: nwc10++ created pull request #1551:
All bits in the union returned by `make_temp_reg` should be initialised		 10:02
dogbert17 waves his wand hand and tries to conjure up brrt 10:41
10:43 Altai-man joined
Geth MoarVM/new-disp: b9cb40f56d | (Nicholas Clark)++ (committed by Jonathan Worthington) | src/spesh/manipulate.c
All bits in the union returned by `make_temp_reg` should be initialised

  `make_temp_reg` returns `MVMSpeshOperand`, which is a union between various
types and structs, all of which are 64 bits or smaller.
Code in `optimize_bb_switch` evaluates `lit_i64 != -1` before calling
  `MVM_spesh_manipulate_release_temp_reg`. The struct within the union returned
... (9 more lines)		 10:55
Altai-man ā³ 133 out of 1693 modules processed 11:05
this will take some time... 11:06
about Blin after 150 modules: *cough* hide-methods *cough* 11:42
lizmat feels called 11:58
Altai-man well, that's a regression... 12:00
12:02 reportable6 left 12:04 patrickb joined
Altai-man ā³ 759 out of 1693 modules processed 12:20
13:02 reportable6 joined
dogbert17 jnthnwrthngtn: it seems to me that after the following two commits, which go together, were applied the expr_jit started to get annoyed 13:22
github.com/MoarVM/MoarVM/commit/5e...0900b183e5 and github.com/rakudo/rakudo/commit/4e...bc533bf766
dogbert17 there's of course a chance that I messed up my 'bisect' totally 13:24
jnthnwrthngtn Hmm. Assuming it's correct, it sadly won't explain much, since I think it will have mostly just exposed more things for JITting rather than actually introducing the problem. 13:26
13:26 [Coke] left
jnthnwrthngtn Given this change would potentially give the expr JIT more things to compile it seems like a quite legitimate bissect outcome. 13:26
13:26 [Coke] joined
jnthnwrthngtn The dream outcome woulda been one introducing or changing a template. 13:27
I do wonder if it's worth going through the templates that differ between master and new-disp and commenting out each of them
dogbert17 it could be unless brrt make a sudden appearance :) 13:31
hmm, is it core_templates.expr which should be changed, i.e. remove stuff from? 13:33
jnthnwrthngtn Yes
dogbert17 I can give it a shot
do you have any wild guesses wrt which template it might be 13:34
jnthnwrthngtn 'fraid not, anything with flow control (a when or some such) is a good candidate. That and it should have changed from master to now, perhaps. 13:36
dogbert17 I have a short program which exposes the problem: 13:37
my $num = 600_851_475_143;
my $val = $num;
my @factors = ();
while ([*] @factors) != $num {
push @factors, (2...*).first(-> $x { $val %% $x && $x.is-prime });
$val = $val div @factors[*-1];
}
say @factors.max;
Geth MoarVM/new-disp: 1362ebd5cb | (Jonathan Worthington)++ | src/disp/resume.c
Add some basic resumption debug dumping

Which can help with tracking down issues in resuming dispatchers.		 13:40
Altai-man MoarVM oops: MVM_str_hash_fetch_nocheck called with a stale hashtable pointer 13:55
jnthnwrthngtn That means somebody is abusing hashes 13:56
Altai-man alright, 32 modules to go... 13:57
jnthnwrthngtn Highly doubt that'd be a new-disp regression, likely just flappy
Altai-man yes, that's likely 13:58
dogbert17 hmm, now that I have removed all templates from core_templates.expr I now get four label errors instead of one when the file was complete 13:59
perhaps I'm misunderstanding something here 14:00
jnthnwrthngtn o.O 14:01
dogbert17 dunno what else I can do 14:09
jnthnwrthngtn 'fraid I'm out of ideas too 14:18
timo wondering where exactly to put the bifurcation for named vs no named callsites in the intern cache 14:19
there could even be two mutexes if there's two "entire" intern caches 14:20
Altai-man MoarVM oops: Oversize callstack flattening record requested (wanted 139344, maximum 131040) looks like one, right? 14:21
timo so... less contention overall, in theory
wow, someone is passing very many arguents, eh?
jnthnwrthngtn Many too many, it looks like 14:44
Altai-man I think I have enough results to share, should I? 14:47
timo the corresponding MVMCallsite we make for flattening will also be at least 130 kilobytes? :D
Altai-man I can count presumably 5 different issues. 14:49
jnthnwrthngtn Altai-man: Yes, please. This is pretty much what decides about merge. 14:52
Altai-man alright, so the "new" ones are: Spit (Parameterizer callback must be a code handle), Slang::SQL (No such method 'ACCEPTS' for invocant of type 'VMNull'), Services::PortMapping (Oversize callstack) and a couple of CSS moduoles are failing now with the same error (This type cannot unbox to a native string: P6opaque, Scalar). And there is also hide-methods, which in total make 5. 14:54
lizmat I assume the hide-methods is the "callwith semantics" issue ? 14:55
or is there something I should do for that module ?
jnthnwrthngtn lizmat: No, it's something different. 14:56
lizmat: It's that it replaces .can iirc
lizmat ah, should I look into it more?
jnthnwrthngtn Well, if you can find a way to make it work on new-disp that'd probably be best 14:57
I don't know why Spit is a new one... 14:58
That issue is one I already PR'd some other modules with
It's using nqp::setparameterizer and should be using Metamodel::Primitives instead
So that one just needs a PR
timo phew, even with two individual intern caches split by has nameds or not, in perf the percentage of time spent in drop_positionals goes from 0.10% to 0.18%, so more time spent in there, but not easurably faster in total sadly 14:59
Altai-man great
jnthnwrthngtn The Slang::SQL and CSS ones sound like fallout (maybe deopt issues?) from the reinsated optimizations, so certainly need investigating
Sigh, this callwith thing is really tricky to fix 15:01
timo rubs eyes
uh oh, it appears like i actually broke raku tho 15:02
Altai-man the third module, CSS fails with the same issue as two others 15:08
15:22 patrickb left
Nicholas Would it be possible to list the (roughly) 5 issues that blin revealed on github.com/rakudo/rakudo/wiki/Raku...isp-branch ? 15:30
I'm getting a bit confused as to what is(n't yet) working
Altai-man aye, sorry I forgot it last time. :S
doing now
Nicholas thanks 15:32
[Coke] Nicholas: heh. "I came here to make that post" 15:34
converted to the bulleted list, so strikethrough is now a checked box to match new blin items added. 15:37
lizmat stops playing with the ecosystem and goes back to look at hide-methods on new-disp 15:41
jnthnwrthngtn: in the case of hide-methods, it looks like it succeeds in finding the B.bar method, but it is in fact the A.bar method that runs 15:49
jnthnwrthngtn lizmat: Did that program location previously do a method call and it went to A.bar? 16:01
lizmat yes
jnthnwrthngtn lizmat: We cache at callsites now, and once something is "linked" to a result, it'll stay that way. 16:02
lizmat hmmm.... but it was a different call site
jnthnwrthngtn Ah, then that doesn't explain it
lizmat there's no loop and no sub involved, so all the call-sites are different 16:03
dinner& 16:04
m: sub a { dd }; sub b { dd }; my &c = &a; for ^2 { c(); &c = &b } 16:30
camelia sub a()
sub b()
lizmat this gives the same on new-disp. Should it, or am I understanding call-site incorrect ? 16:31
or does it actually known &c can change?
jnthnwrthngtn It knows it can change 16:32
lizmat ok... 16:33
16:39 frost left 16:43 Altai-man left
lizmat jnthnwrthngtn: could this be troublesome? $class.^mro[1].can($name).head 16:44
jnthnwrthngtn Hm...do you ever mix into the meta-object?# 16:58
lizmat unless $class.^find_method("can").package =:= &can-wrapper.package { 17:01
$class.^add_method("can",&can-wrapper);
$class.^compose;
}
jnthnwrthngtn Ah...and then the callsite will have been found to the `can` before
17:02 squashable6 left
jnthnwrthngtn If you change it to `$class.^mro[1].^find_method('can')($name).head` does it help? 17:02
I also figured out a better strategy for the callwith + dispatcher nesting issue, that doesn't need any extensions to the mechanism *and* is better designed *and* will probably perform better 17:04
Alas, I'm too tired to implement it now. I did note down what it is.
So I don't forget by Monday :) 17:05
lizmat that change causes 4 errors instead of 1 17:06
jnthnwrthngtn Oh, that's 'cus it's wrong 17:07
lizmat afk for a bit& 17:08
jnthnwrthngtn Should probably be more like `my $type := $class.^mro[1]; $type.^find_method('can')($type, $name).head`
(e.g. the found method needs its incocant too)
*invocant
Also heading afk 17:09
18:02 reportable6 left 18:05 reportable6 joined
lizmat jnthnwrthngtn: fix for hide-methods on its way to the ecosystem 19:10
dogbert17 lizmat: have you tried test-t today? 19:26
lizmat yeah, no noticeable change 19:27
at least for me
dogbert17 did you try it with MVM_JIT_EXPR_DISABLE=1 as well?
lizmat no, should I expect a better performance with it? 19:28
dogbert17 since they expr-jit is acting up a bit at the moment yes
lizmat wow 19:33
19:33 squashable6 joined
lizmat 1.141 / .664 19:34
that *is* indeed a noticeable difference
dogbert17 that's really cool 19:35
lizmat now the amazing part: running on master: 19:40
1.361 / .650
running on master with MVM_JIT_EXPR_DISABLE=1 19:41
timo oh my
dogbert17 so master is finally beaten :)
lizmat 1.318 / .664
japhb \o/ 19:42
lizmat but also: on master, there's an advantage to do MVM_JIT_EXPR_DISABLE=1 even
so it looks expr-jit was sorta borked already ?
19:43 japhb left
lizmat dogbert17: master was already beaten, I think, just not the --race case, as that suffers more from the longer startup 19:43
dogbert17 perhaps, but now it can spew out scary errors if you run with MVM_JIT_DEBUG=1, i.e. on new-disp
timo lizmat: can you quickly turn on MVM_JIT_DEBUG=1 and see if any error lines appear on stderr? 19:44
dogbert17 I believe MasterDuke wrote that it also seems to get in the way of jitting in general
lizmat with or without the EXPR_DISABLE?
dogbert17 without
lizmat rebuilds again :) 19:45
nine I'm pretty sure those scary errors are there on master as well
19:46 japhb joined
lizmat dogbert17 timo gist.github.com/lizmat/eb1ff243b6b...94085051a5 19:49
timo wild
dogbert17 was that on master? 19:50
timo make your raku programs faster with this one weird trick. developers hate her!
lizmat no, new-disp
want me to run on master as well, dogbert17
timo oh i was hoping for output from master
lizmat ?
ah, ok, gimme a mo
dogbert17 if you want to verify nine's theory? 19:51
timo yeah
lizmat no errors on master 19:56
dogbert17 timo ^^
timo ok 19:57
dogbert17 sounds like we need to conjure up brrt
'use Slang::SQL; sql drop table if exists stuff;' running or compiling this is enough to trip up Slang::SQL 20:06
Geth MoarVM/new-disp: 060d3eeda6 | (Jonathan Worthington)++ | 2 files
Tidy up sp_getarg_* in expression JIT

  * Remove a now-unused macro
  * Add template for `sp_getarg_n`		 20:30
lizmat jnthnwrthngtn: should I rerun test-t, or is there still some general breakage with the expression JIT? 20:36
20:46 linkable6 left, evalable6 left 20:47 evalable6 joined, linkable6 joined
jnthnwrthngtn lizmat: Still the problem, I just spotted those things to clean up while seeing if I could figure it out 20:55
It's rather odd: I annotated instructions with their JIT labels, and the instruction whose label goes missing when the expr JIT is on doesn't even get compiled by the expr JIT 20:56
I may have a fix. 21:21
Geth MoarVM/new-disp: 9f22ac582a | (Jonathan Worthington)++ | src/jit/expr.c
Bail from template JIT prior to adding labels

The template JIT graph builder would first consider annotations, and after that see if there was a template. In the event that there was not one, this could lead to labels being produced, but never emitted, which then led to a missing label and the the entire JIT of the frame failing. Resolve this by first checking if there is a template, and only then ... (7 more lines)		 21:43
jnthnwrthngtn lizmat: That one should fix the breakage. 21:44
timo ooh 21:47
good work
21:47 linkable6 left, evalable6 left 21:48 evalable6 joined
jnthnwrthngtn afk for a bit, maybe for the evening 21:58
22:48 evalable6 left 22:50 linkable6 joined 23:20 sena_kun left
lizmat ok, this makes new-disp run test-t at 1.162 on my machine 23:24
running with MVM_JIT_EXPR_DISABLE=1 still gives a similar value 23:25
so it feels to me that this last change is just effectively disabling JIT without the environment variable 23:26
still, good to see test-t now at least 15% faster than on master :-) 23:27
MasterDuke if we made the jit abort instead of printing those errors with MVM_JIT_DEBUG=1, could we then use the jit bisect script to figure more precisely where things are going wrong? 23:31
lizmat oh, by the way, JIT_DEBUG is clean now 23:35
sleep& 23:42

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!