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:18 dogbert17 joined 00:19 dogbert11 joined 00:23 dogbert17 left 00:31 dogbert11 left
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
00:50 dogbert11 joined
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
00:55 dogbert17 joined 00:59 dogbert11 left
timo even raku tests are fine. now for spec tests 01:01
01:02 CaCode_ joined
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
01:04 reportable6 joined 01:05 CaCode- left
timo why am i now seeing profile files with >10k allocations of BOOTCapture 01:24
gist.github.com/timo/5edae0b9f0fc4...425ca59986 welp 01:25
02:09 dogbert17 left 02:28 dogbert17 joined 03:01 CaCode_ left 04:50 reportable6 left, notable6 left, quotable6 left, unicodable6 left, bloatable6 left, statisfiable6 left, greppable6 left, committable6 left, bisectable6 left, benchable6 left, squashable6 left, releasable6 left, linkable6 left, coverable6 left, shareable6 left, evalable6 left, tellable6 left, sourceable6 left, nativecallable6 left, reportable6 joined, quotable6 joined 04:51 benchable6 joined, tellable6 joined, notable6 joined, committable6 joined, linkable6 joined 04:52 shareable6 joined, squashable6 joined, unicodable6 joined 04:53 bloatable6 joined 05:08 frost left 05:32 SmokeMachine left, SmokeMachine joined 05:52 statisfiable6 joined, nativecallable6 joined 05:55 [Coke] left 05:57 dogbert11 joined 05:59 dogbert12 joined 06:00 dogbert17 left 06:02 reportable6 left 06:03 reportable6 joined, dogbert11 left 06:04 dogbert17 joined, dogbert12 left 06:08 Kaiepi left 06:51 greppable6 joined, bisectable6 joined, dogbert17 left 06:52 sourceable6 joined 07:08 Kaiepi joined 07:30 dogbert17 joined 07:33 dogbert11 joined 07:34 dogbert17 left 08:05 dogbert17 joined 08:06 dogbert11 left 08:13 dogbert11 joined 08:15 dogbert17 left 08:24 dogbert17 joined 08:28 dogbert11 left 08:50 coverable6 joined
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
09:21 frost joined
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
09:53 evalable6 joined
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
11:25 evalable6 left, linkable6 left, frost left 11:26 evalable6 joined 11:27 frost joined, linkable6 joined
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
11:38 [Coke] joined
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
11:50 releasable6 joined 12:02 reportable6 left 12:03 reportable6 joined
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
12:32 dogbert11 joined 12:35 dogbert17 left
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
13:48 Kaiepi left 14:13 dogbert17 joined 14:16 dogbert11 left
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
14:46 frost left
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
14:48 frost joined
[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
14:53 CaCode joined
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
17:05 leont_ joined
timo have you any measurements? 17:08
17:13 leont left, leont_ is now known as leont
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
17:34 Kaiepi joined
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
18:02 reportable6 left 18:04 reportable6 joined 18:47 sena_kun left 18:48 sena_kun joined 19:42 CaCode_ joined 19:43 CaCode_ left 19:44 CaCode left
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
21:19 evalable6 left, linkable6 left 21:20 evalable6 joined
ugexe some auths contain < and > 21:38
*besides the point* 21:39
22:22 linkable6 joined
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
22:45 squashable6 left 22:47 squashable6 joined
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!