github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:04 pamplemousse joined
japhb AlexDaniel: What *software* did you use to create those graphs you've posted? I saw the bit about how you *recorded* the data with a helper C program and __rdtsc (might be able to get more accurate timings by just outputting a single newline, since you're just reading by lines on the C side, and perhaps using nqp ops or binary write to output that, since default Rakudo 'say' is slow) -- but I didn't see 00:09
how you *graphed* it.
timotimo self-made graphing software i believe 00:14
japhb timotimo: Yes, and I want to see that, because it's the most interesting bit to me. :-) 00:15
timotimo yes, i want to see it too 00:16
AD already said the code is too terrible to show, but may be cleaned up and released
03:12 pamplemousse left 03:37 moon-child joined 04:12 farcas1982regreg left
MasterDuke jnthn: you mean something else should stick hll_name in a spesh slot? and then the jit retrieves it? 06:52
07:23 farcas1982regreg joined
AlexDaniel japhb: yeah, I did write it myself. I did copy some stuff from github.com/AlexDaniel/orgsleep and now it's a bit more generalized, but the code is still kinda ugly 07:30
btw latest orgsleep graph here: imgur.com/a/lxW5UGV 07:31
I liked it more on the black background, but then you can't print it :)
nine MasterDuke: yes, e.g. in spesh/optimize.c. There's an MVM_spesh_add_spesh_slot_try_reuse which returns an int which you can safely use as literal value in the JIT. Use the JIT's get_spesh_slot value to turn that index back into an object. 07:51
08:34 sena_kun joined 08:56 Altai-man_ joined 08:59 sena_kun left
AlexDaniel japhb, timotimo: btw you can get the same aesthetic by simply using tom thumb: robey.lag.net/2010/01/23/tiny-mono...-font.html 09:50
10:57 sena_kun joined 10:59 Altai-man_ left
MasterDuke huh. i got a segv when accessing the `->flags` of an MVM_spesh_get_facts() result 11:19
seems like speshing getcurhllsym takes another ~0.3s off that Channel benchmark 11:37
lizmat MasterDuk++ 11:40
MasterDuke not sure how correct the implementation is...and now to see if we can also jit it using the spesh info 11:42
11:51 Voldenet left
nine MasterDuke: so what does spesh do with getcurhllsym? 11:53
11:54 Voldenet joined, Voldenet left, Voldenet joined
MasterDuke nine: added it to gist.github.com/MasterDuke17/f7907...3ed602fd8a 12:04
so i see using slots for operands. but hll_name is not an argument of the op 12:05
nine Do you even need to JIt getcurhllsym anymore? 12:15
MasterDuke dunno. why are hllbool(for) both speshed and jitted? 12:20
nine That's...an excellent question 12:23
MasterDuke interestingly, a spesh log no longer shows any bails because of getcurhllsym (it also didn't show any when i jitted it instead) 12:26
nine Ah, ok. hllboolfor takes 2 args: the truth value and the HLL name. If we only know the HLL name but not the truth value, we can still JIT it. If we also know the truth value (i.e. it's constant in a spesh candidate), we can optimize away the whole instruction and replace it with a spesh slot 12:28
MasterDuke so since getcurhllsym only takes one arg, just speshing is sufficient? 12:31
i guess it has to be, since it isn't safe to use an MVMString * in the jitting? 12:32
oh, or if it's not constant we could instead put the hll_name in the slot and then use that to jit it? 12:37
nine yes 12:42
12:56 Altai-man_ joined 12:59 sena_kun left
nwc10 good *, #moarvm 13:03
jnthn: Hurrah. On the third attempt I managed to get a SodaStream refill. (And on the 3rd supermarket, 2 more crates of beer (on offer)) 13:04
jnthn nwc10: Ah, nice. Next beer delivery here shall be Wednesday. Though they had already sold out of a couple of my favorites... 13:16
MasterDuke hm. it looks like usually an operand is replaced by a slot index. but i explicitly don't want to do that. can i add a new operand just to stick a slot index into it? 13:17
nwc10 and as to threes, I now have 3 full crates of beer. Just in case... 13:18
jnthn Good to have a strategic reserve of these things.
nwc10 (just in case the 25% offer doesn't come round again. Billa and Spar are *both* doing 25% this week, and Merkur did it a couple of weeks ago, so it might take a while for one of them to be so nice angain)
more beer than toilet paper. Not sure if this is the right priority. (And more gin than tonic This *isn't* the correct ratio) 13:19
jnthn At least here, the average toilet roll lasts longer than the average beer... :) 13:20
nwc10 that is a good point. I'd not considered it like that. Yes, at the rate that I go, the beer does *not* go flat.
jnthn Hm, probably the office needs more cookies ordering next week, especially given I'll probably be spending a decent amount of my time trying to implement the new dispatch proposal. :) 13:21
(The last batch lasted longer than any previous one had, since for a bunch of weeks we didn't go to the office.) 13:22
nwc10 having just found a headline on the BBC about the UK boozing and baking more, I have to confirm - *you* (home or co-workers) are *not* baking? (The children here have been making brownies. (and I bought more cooking chocolate and butter today, in case...) but *also* been eating brownies...) 13:23
to be fair, given finite time, if your head is up for it, I'd prefer you to buy cookies and write code, as I don't think that you can buy the code :-)/ 13:24
lizmat still hasn't used the oven... and tries to stay away from cookies 13:25
nwc10 "hasn't used the oven" - you moved in? 13:26
jnthn No, we're not baking. :)
nwc10 jnthn: I guess it's about equal - we're not cooking curry - we outsource *that* 13:27
jnthn Oddly, I do quite a lot of cooking, but nearly no baking.
lizmat yeah, cooking we do, no baking... :-)
nwc10 *I* almost never have baked. Ever. Never seem to have started. Also been told (and this seems to follow) that tolerance on most everything else cooking is 10-20%. Wherea baking has to be accurate. 13:28
That sounds like hard work :-)
jnthn I used to make nann bread or parathas to go with the curry, but didn't since we moved. My flat pan for doing that doesn't work on the new (induction) cooker.
And I didn't get around to either replacing it or buying one of those adapter pieces of metal (that I'm 101% sure I'm going to end up stupidly burning myself on...) 13:29
MasterDuke jnthn: btw, does what i say above make sense? 13:32
jnthn Which bit in particular? I skimmed through it but thought nine++ answered (correctly) everything... :) 13:33
MasterDuke i think i've correctly speshed getcurhllsym. but if spesh doesn't see a known value, could/should it stick the `g->sf->body.cu->body.hll_name` in a spesh slot (of a new created operand) so the op can be jitted? 13:35
jnthn Oh hmm, your JIT of getcurhllsym is very dubious
Uh, not JIT, sorry. spesh. 13:36
Because you're assuming you can turn it into a constant.
But nothing says you can. We can rebind the symbol to something else in the future.
oh hang on, did I read it wrong...
"/* Optimizes a getcurhllsym instruction away if the value is known */" at least sounds like it's going to be naughty 13:37
Yeah, looks like it is actually constanting the lookup, and it's not clear it should.
MasterDuke ah 13:39
jnthn Thing is, a lot of the time that *is* a safe assumption 13:40
MasterDuke need to insert guards?
jnthn How would that work? We'd have to check the value in the hash didn't change...meaning we'd have to do the hash lookup, meaning we didn't save any work. 13:41
MasterDuke sounds like we're in quite a pickle 13:43
jnthn I think we'd need a way to declare a given binding constant. 13:45
That said...
...this is not the only case of the problem.
nine MasterDuke: you can still look up that hll_name in spesh, stuff it into a spesh slot and use that when JITing getcurhllsym
jnthn GLOBAL and PROCESS are also very rarely changing.
Arguably %*ENV too 13:46
MasterDuke i would have to create a new operand and use it's spesh slot, right?
jnthn I wonder if we want some kind of "versioned hash" that has a counter that is bumped whenever it changes.
And we can guard against that
nine MasterDuke: no, insert a sp_getspeshslot instruction before the getcurhllsym 13:47
MasterDuke nine: huh. how does the jit access the previous instruction when it gets the getcurhllsym? 13:50
lizmat jnthn: samcv might know, but I think you already have some marker in hashes that you could save to see if the hash changed 13:53
of course, that would not apply to existing values being changed in there, but that's ok I guess ?
MasterDuke jnthn: re your "versioned hash" idea. does it make sense to proceed with some form of speshing/jitting getcurhllsym before that happens? and, how hard do you think it'd be to implement+incorporate?
jnthn lizmat: Existing values changing is exactly what we care about here :) 13:54
lizmat and if the value is a container ?
jnthn MasterDuke: Yes, I've no idea how half-baked the versioned hash idea actually is, so I'd not hold off on improvements.
MasterDuke k
nine MasterDuke: yeah...right...it'd still need it as an operand. So scrap that. You'd need to create a new spesh version of the op: sp_getcurhllsym with the right number of operands
jnthn lizmat: Doesn't matter
lizmat: Then we'd cache the container, still saving the hash lookup. 13:55
And the decont of the container would track anything assigned into it.
lizmat but the value inside the container might change ?
nine Before doing something like a versioned hash, we ought to establish, that we actually have something significant to gain here
jnthn lizmat: Yes, but we're not caching the value inside the container.
We'd be caching the container.
nine: tbh I'd not really thought about it for the curhllsym case; the idea came from pondering how we can make $*OUT lookup a lot more cacheable. 13:56
Which *is* a hot path.
lizmat still not grokking it :-)
jnthn lizmat: %h<foo> is 1. Look up the container under the key foo, 2. potentially then dereference the container to get the value inside of it. 13:57
MasterDuke i'm assuming the getcurhllsym i'm seeing the benchmark is from $*OUT (i.e., the `say`s) 13:58
jnthn lizmat: If you know the key in the hash wasn't rebound, you can save step 1.
MasterDuke: Yes, I think PROCESS is located that way
ah, gotta go afk a bit; bbl
lizmat ok, I thought you meant we'd be able to skip step 2
MasterDuke nine: does it have to be stored in the spesh slot of the new operand? or can i just create sp_getcurhllsym with a new operand value of `g->sf->body.cu->body.hll_name` and jit that into the function call with the operands as the arguments 14:05
nine That would essentially be exactly what your very first draft did - with the GC issue 14:09
Well, theoretical GC issue. Because I'm pretty sure that a CU's hll_name will always be allocated in gen2 directly as it always comes from deserialization. At least in the current implementation 14:10
MasterDuke oh right. well, i'll give v3 a go a bit later 14:26
14:57 sena_kun joined 14:58 Altai-man_ left
MasterDuke huh? i get a segv, frame 0 is `at_key (tc=0x555555559fb0, st=0x5555555c4408, root=<optimized out>, data=0x5555555d99a8, key_obj=0x55555730c300, result=result@entry=0x7fffffffdd40, kind=8) at src/6model/reprs/MVMNull.h:11` 15:46
f 0 is at `return !check || check == tc->instance->VMNull;`, but check, tc, tc->instance, and tc->instance->VMNull are all fine? 15:47
timotimo could be re-ordering by optimization or something 15:54
MasterDuke hm. maybe i should just show my current implementation, you might spot an obvious error
timotimo i can give it a try 15:56
MasterDuke gist.github.com/MasterDuke17/f7907...lsym-patch
timotimo i assume the changes that update_ops.p6 do aren't in the diff, but are on your machine? 15:58
MasterDuke yeah
timotimo the patches above are also all applied? 15:59
MasterDuke no, just that one
timotimo OK 16:00
where is that MVM_is_null called from? 16:02
the frame is at_key, but the code line it's pointing you at is MVM_is_null 16:03
MasterDuke gist.github.com/MasterDuke17/f7907...le-gdb-log
timotimo does it also crash with a lower -O option? 16:04
MasterDuke yeah 16:05
gist.github.com/MasterDuke17/f7907...mize-0-log recompiled moar with --optimize=0 16:07
16:11 AlexDani` joined
MasterDuke `key_obj` is just "" 16:11
16:12 AlexDaniel left
MasterDuke hm, but `sym` is "GLOBAL" 16:12
timotimo could the spesh slot be wrong-ish? 16:17
the spesh log will try to show the value
MasterDuke `# [000] specialized from sp_getcurhllsym` 16:20
`sp_getcurhllsym r12(2), lits(), sslot(3)` 16:21
oh, changing the op 2nd operand from `str` to `r(str)` seems to have fixed things 16:25
ok, now to jit it...but may have to afk first... 16:27
16:40 regreg joined 16:42 farcas1982regreg left, regreg is now known as farcas1982regreg 16:49 AlexDani` is now known as AlexDaniel, AlexDaniel left, AlexDaniel joined 16:56 Altai-man_ joined 16:58 sena_kun left 18:16 farcas1982regreg left 18:17 farcas1982regreg joined
MasterDuke success! do need to spectest now... 18:55
18:57 sena_kun joined 18:59 Altai-man_ left
MasterDuke how different is the region allocator from the fixed size allocator? 19:16
hm. why wouldn't i get a `expr bail: Cannot get template for: sp_getcurhllsym`, when i haven't created a template for it yet? 19:20
19:27 pamplemousse joined
timotimo you mean the allocator that spesh uses? 20:09
if that's the one you mean, it allocates extremely quickly, but it can't free individual pieces, only everything at once
which is why it's used for spesh data; everything allocated in there becomes garbage at the same time 20:10
so the allocator gets cleared and it all just goes poof
MasterDuke ah 20:21
have any idea about the template?
but probably afk for a bit 20:22
lizmat dl.acm.org/doi/pdf/10.1145/3309206
16Concurrent Hash Tables: Fast and General(?)! 20:23
20:27 farcas1982regreg left 20:33 farcas1982regreg joined 20:35 robertle joined 20:44 sena_kun left 20:53 robertle left 21:02 hankache joined 21:03 hankache left 21:04 hankache joined 21:05 hankache left, hankache joined 21:15 hankache left 21:58 pamplemousse left

Powered by Cro and the Raku® Programming Language.

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

Thank you!