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.
timo i went through rakudo's dispatchers and replaced a bunch of drop + insert combinations and now gen/moar/CORE.d.setting compilation explodes with a segfault 00:47
timo changed capture-lex back, after that capture-lex-caller explodes :) 00:52
oh, i wonder if perhaps i got the callsite flag types mixed up. there's no check to explode early for that. that could perhaps be it 00:54
timo even raku tests are fine. now for spec tests 01:01
timo m: say 7017 * 100 / 8665 01:02
camelia 80.980958
timo getting just above a 20% win would have been nice compared to just below 20%, but i'll take it 01:03
timo why am i now seeing profile files with >10k allocations of BOOTCapture 01:24
gist.github.com/timo/5edae0b9f0fc4...425ca59986 welp 01:25
timo at least part of the problem is indeed that i've been replacing arguments with a different kind, which the new syscall is explicitly meant not to support 09:20
nine Could it support this? 09:41
timo it could, yeah. i'm already cloning the callsite so that memory management doesn't go wrong, so could as well build a new one with a tweaked flag there 09:42
nine I do the same here: github.com/MoarVM/MoarVM/blob/new-...sp.c#L1226 09:54
timo you'll be able to steal my helper, then, and save one FSA allocation 10:09
hey, does that currently leak callsite allocations? 10:10
i think it does 10:17
nine indeed! 11:28
timo this won't make that much of an impact i'm sure. good to plug that leak tho. and of course we'll have a function that replaces a capture's flag at an offset 11:35
actually, i'm accessing the callsite's flags directly here. naughty naughty. 11:36
oh, yes, that would be very bad if it turned out to be interned
nine That's what I did at first as well. And it led to "interesting" errors 11:37
timo when can we become a hivemind so we can share all knowledge of interesting error scenarios instantaneously 11:40
nine Btw. did you notice that the comments above the callsite manipulation functions promise interning but the functions actually don't do that? 11:41
timo that's rude 11:48
timo from my experiments it looks like interning is relatively performant actually 12:21
at least last time i tried i could not outperform it with my little cache for callsite mutation operations 12:22
then again, locking for interning was different back then 12:25
timo hm, not sure what it was like compared to changing nothing. was i making it do a lot more than before? bottlenecking it? 12:37
nine eq_I r26(1), r2(2), r23(1) # [063] start of exprjit tree 14:25
set r17(4), r26(1) # [064] start of exprjit tree
unless_i r17(4), BB(15) # [065] start of exprjit tree
Success!
timo *nice*, but how? 14:28
if this hits a ot of the boolifies we have, i imagine that would make a whole lot of workloads faster 14:33
Geth MoarVM/new-disp-nativecall: e2f7edce74 | (Stefan Seifert)++ | 3 files
Eliminate hllbool/boot-boolify-boxed-int pairs in spesh

No need to turn an int into an HLL bool just to turn it back to an int when using it as a condition for jumps. Eliminate those pairs same as we do with box/unbox.		 14:36
timo ah, that's how 14:38
nine box/unbox pair elimination was a great template 14:39
timo hey, if you ever want to check escape analysis out, we're building empty hashes for argument spesh for named arguments and can't toss them out yet because of deopt usages and escape analysis could use the materialization mechanism to fix this 14:42
nine Isn't that part of jnthnwrthngtn++'s next grant? 14:43
timo in theory yes 14:45
but you know how we all appreciate improving bus factors %) 14:46
timo there's something under the keys in my keyboard and i can't seem to get it out, jst move it between different keys by blowing between the keys 14:46
i an't pll off the keyaps either bease the last two times a key ame off the mehanism i old not get it bak 14:47
ccccccuuuuuuuu
[Coke] need some mini vacuum 14:48
nine timo: I've found turning over the keyboard, shaking and leting gravity do its job gets a disgusting amount of dirt our of keyboards... 14:49
much more so than vacuums or blowing
timo i got a tiny amount out. this is kind of sort of a chiclet keyboard, which is what i blame for the trouble: barely any distance between keycaps 14:50
huh, it helped more than i would have imagined. very nice! 14:52
timo i need to actually sit down and really work on my split keyboard's firmware / keymap 14:53
[Coke] I am looking forward to my keyboardio 100 once they are made. 14:56
timo i've posted pictures of my keyboard here, right? 14:58
MasterDuke nine: just curious, but does that last commit need to be in new-disp-nativecall? 16:39
nine no 16:40
I only pushed it to new-disp-nativecall because that was the quickest way to get it into geth ans an answer to timo's how question :) 16:41
MasterDuke ha 16:51
Geth MoarVM/optimize_hllbool_boolify_pairs: 4a2e0aa678 | (Stefan Seifert)++ | 3 files
Eliminate hllbool/boot-boolify-boxed-int pairs in spesh

No need to turn an int into an HLL bool just to turn it back to an int when using it as a condition for jumps. Eliminate those pairs same as we do with box/unbox.		 16:56
MoarVM: niner++ created pull request #1586:
Eliminate hllbool/boot-boolify-boxed-int pairs in spesh
timo have you any measurements? 17:08
nine It may have shaved off 1 % of csv-ip5xs but fluctuations are too high to draw conclusions 17:23
Current record is at 7.654s 17:24
timo ah, too bad 17:27
nine It's clearly faster. Just how much I can't say 17:29
timo there wouldn't be much reduction in allocation either, right? 17:37
nine Not due to hllbool as that just returns those global objects 17:38
timo right, that's fair
it's still got to be faster than runcfunc, or is runcfunc just good?
nine 7.520s by assuming that Inline::Language::ObjectKeeper's keep will usually find a free slot in the keeper array and rarely has to extend it. This means that I can push $objects.push($value); $objects.elems - 1 into a separate method and call that. This in turn gets the bytecode size below the inlining limit 17:39
I'm pretty sure the latter wouldn't be true with hllbool/boot-boolify-boxed-int still in place 17:40
Well the elimination simply removes several ops without adding any. So no matter how good runcfunc is, we'll end up being faster
timo we'll want not only to have jit based on repr for reprops, we'll also have interest in runcfunc being specialized into expr trees 17:42
not sure how far that's off in terms of worthwhile work
lizmat I have a slightly worrying message 19:47
nine lizmat: I'd prefer a happy one ;) 19:48
lizmat I have some code that reads about 7000 JSON files
one field in the resulting hash, should be the same as the filename (minus .json) 19:49
if I read this in serially, no problem
if I read this with .race, then 1 in about 7000 times the field is from *another* hash
I mean... 1 time it gets a hash from JSON::Fast that has (at least) one key/value fro another hash 19:50
lemme see if I can golf this 19:52
Geth MoarVM: MasterDuke17++ created pull request #1587:
Negative numbers should not be prime		 19:54
nine Good thing I'm so tired. Managed to stop reading up on negative primes after just a few minutes 20:02
lizmat ok, cannot reproduce it in a clean script 20:15
Geth MoarVM: 1bd61725d3 | (Daniel Green)++ | src/math/bigintops.c
Negative numbers should not be prime

The code from the paper just worked with unsigned values and I didn't notice.		 20:24
MoarVM: 9bb1aebcb3 | MasterDuke17++ (committed using GitHub Web editor) | src/math/bigintops.c
Merge pull request #1587 from MasterDuke17/negative_numbers_should_not_be_prime
lizmat it looks like Str.match is not threadsafe 20:28
at least something like:
$path.match(/ ':auth<' <( <-[>]>+ )> /)
github.com/rakudo/rakudo/issues/4601 20:53
lizmat is not happy she found this, but will be very happy when the cause of this is found 21:04
ugexe some auths contain < and > 21:38
*besides the point* 21:39
timo lizmat: giving the pointy block its own $/ fixes it, can you confirm? 22:27
the discrepancy may come from $/'s .orig attribute being set to a different thread's target string, thus causing the wrong result to come out of the match? 22:28
lizmat timo: indeed, a `my $/` inside the scope of the map fixes it 22:49
timo i wonder if it races in a way that makes the stringification of $match change even more afterwards
lizmat so basically, the standard $/ is shared between threads ? 22:50
wonder if that also applies to $_ then
timo do we set the target/orig of the $/ before we try matching against it?
it could be we're just getting the $/ from one level further outside
lizmat bur then we'd be getting garbage, no
?
timo don't think so, since we also grab the match result afterwards? 22:51
i guess you can add a little `start { "trololo".match(/lol/) for ^100_000 }` in there as well and see if that bleeds through 22:52
but start may have different handling than just giving a pointy block to .map
lizmat well, afaik, .race just calls a lot of starts?
timo sure, i'm just worried more about the lexical stacking of the block with the mainline code, i.e. what its OUTER:: is 22:53
the much simpler test i just did is add `say $/` after the race and see that it does contain a result
when there's a `my $/` inside the block, `say $/` after the race comes out Nil, otherwise it has a word in it 22:54
(zygotaxis)
more about the point before that: the compilation of the pointy block may be different actually from the compilation of a start block, because we also do something to capture dynamic variables and such at the point of the start 22:55
but in that case you could just have put a `my &do-the-thing = -> { ... }; start { do-the-thing() }` instead to work around that 22:56
lizmat interesting...
so maybe the nqp::getlexref('$/') is finding the outer $/?
ok, this also happens before my removal of the special getlexref handling of the .match proto 23:00
timo looks like MoarVM::Remote needs a little bit of adaptation for newer versions of moarvm
just the tests i think 23:01
japhb Gah ... I'm having trouble optimizing a module I just wrote because the runtime for repeated runs of a single benchmark can vary by a factor of 2x. MVM_SPESH_BLOCKING=1 MVM_SPESH_NODELAY=1 drops the variance down to less than 5% ... *except* then it's always the slower time range. GAH. 23:02
And the problem is the whole thing is a giant state machine made of a great many closures. So ... fun figuring out what's changing. :-( 23:03
MasterDuke MVM_SPESH_NODELAY=1 isn't really good for optimizing though, because it will cause moarvm to make bad choices 23:06
japhb You're suggesting blocking only? 23:07
MasterDuke yeah
japhb gives it a try
timo looking at the stack trace in moar-remote with "all lex" tells me that the frame with the -> $string literally doesn't have a $/ of its own
MasterDuke could also try disabling hash randomization
lizmat m: for ^10 { $/++ }; say $/ # this feels wrong
camelia 10
lizmat timo: right, I guess the inner $/ is optimized away 23:08
timo bisectable6: for ^10 { $/++ }; say $/ 23:09
bisectable6 timo, Will bisect the whole range automagically because no endpoints were provided, hang tight
japhb MasterDuke: Oh that is SO much better. MVM_SPESH_BLOCKING=1 brings the time range down to 3%. Not the fastest run I'd seen with no env vars, but much closer to the fast end than the slow one. I can work with this, I think. 23:10
timo oh, you already did it in the other channel
bisectable6 timo, ¦6c (59 commits): «10␤»
timo, Nothing to bisect!
japhb You know, I think one of you had even told me about the NODELAY "bad choices" problem, and it had just slipped my mind. 23:11
lizmat seems to have been like this forever ??
japhb Anyway, thank you MasterDuke++
MasterDuke np
timo i feel like i did that
but it's also a thing jonathan pointed out in the last conference talk
japhb Well then timo++ and jnthnwrthngtn++ too. :-) 23:12
lizmat $/ ?
japhb I'm just really slow sometimes, I suppose. ;-)
timo the thing japhb said
lizmat ah, ok 23:13
m: for ^10 { $/++ }; say $/ # so is this behaviour expected ?
camelia 10
lizmat m: $/++ for ^10; say $/ # I'd expect it from this 23:14
camelia 10
lizmat calls it a day 23:22
&
timo of all the things that have been called "a day", this is certainly one 23:33

Powered by Cro and the Raku® Programming Language.

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

Thank you!