github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
AlexDaniel samcv: any news? :) 08:02
brrt \o 08:37
nine Now that I've ported base64_decode to NQP to get by with minimal changes to the nqp::serialize op, I realized that there's also the serialized_string_heap to deal with. And that can really not be accessed in any way. So it looks like I need to add an op anyway and this op can then return both the data and strings. 12:11
nine Oh but there is! The string heap (an nqp::list) is passed to the nqp::serialize op and therefore perfectly accessible :) 13:34
nine Aaaand it works :) NQP builds with MoarVM's MAST compiler completely replaced by MoarVM::BytecodeWriter and so does rakudo :) But boy is it slow 14:01
timotimo oh my :)
nine Stage mbc : 141.596
timotimo i'm not sure how well --profile-stage works
whoops :)
nine Of course I really took "first make it work, then make it fast" to heart. 14:02
timotimo of course 14:03
Geth MoarVM/jit-perf-map: 4b0263ec21 | (Bart Wiegmans)++ | 6 files
[JIT] Implement a perf map file on linux

So that we may profile (on linux) and have insight on the time spent on JIT-compiled frames.
Not sure if it will give good results, because we don't always compile with -fno-omit-frame-pointer.		 14:34
brrt nine++ 14:38
many amaze
timotimo jit perf map!! 14:43
brrt: any intent to delete the file? 14:45
when moar shuts down, i mean
brrt no, why
that's what /tmp is for
timotimo i guess
brrt hmm 14:46
maybe you're right though
I don't really have time for it
:-)
timotimo that's fair
brrt well, right now. Feel free to unlink it though
nine Only a BEGIN time EVAL issue left. Those are always the most fun 14:47
brrt good luck 14:49
nine LOL....if what I see is right, the fix for the BEGIN time EVAL issue also improved performance...dramatically: 16:15
Stage mbc : 11.565
(was 141.596 before)
diakopter hunh 16:20
diakopter can't wait to see the patch on that 16:20
nine Fix is just taking a MAST::Frame's $!frame_idx if available instead of looking for it in the frame list. Now it finds the frame and also doesn't have to iterate in most cases 16:22
Geth MoarVM/nqp-mbc: 2fd9da1665 | (Stefan Seifert)++ | lib/MAST/Nodes.nqp
Store serialized data and strings in MAST::CompUnit
 16:30
MoarVM/nqp-mbc: 0863feafee | (Stefan Seifert)++ | src/6model/serialization.c
Have nqp::serialize always return the serialized data
japhb nine: Wow, that was either a really slow iteration, or it was done a LOT, sheesh 17:13
nine: In github.com/MoarVM/MoarVM/commit/0863feafee , you seem to now have an MVM_free(output) on one path and not the other. Also, since you're not returning off either path now, and you're doing the base64_encode on both paths, why have two separate paths? 17:18
nine japhb: didn't want to duplicate the if condition. Also I still consider this thing to be a POC more than anything else. Especially the changes to MoarVM 17:28
japhb nine: One of my comments was dependent on the other. If the MVM_free was only on one path *intentionally*, then having two paths makes some sense. If the intent was that both paths end with the exact same two lines (base64_encode() followed by MVM_free(output)), then it makes sense to leave them outside the if block as they were originally. In other words, it's not clear why the only diff in that CL is 17:33
anything more than removing 'return NULL;' on line 912.
nine Well in the case where output is assigned to tc->serialized, free()ing it would be counter productive 17:52
japhb nine: Fair enough, but that leads me to a new question: Why are you stashing the pre-encoded form in tc->serialized and returning the encoded form from the routine? 18:30
japhb Meaning, why do you need both forms? 18:31
nine I don't. tc->serialized is for MoarVM's own MAST compiler while the base64 encoded return value is AFAICT for tests. Neither really suits me. 18:38
japhb Ah! OK, I understand now. Thank you! 18:47
nine Looks like there's just no way I can get a profile of that mbc code :/ 18:57
timotimo nine: even when using nqp::startprofile and nqp::endprofile manually? 19:17
and, i suppose, feeding the result into the compiler's method that post-processes the data 19:18
nine Still segfaulting in a broken stack ending in MVM_fixed_size_free called from JIT code 20:04
bin ends up 0 in MVMuint32 bin = bin_for(bytes); 20:06
nine bytes is 7626968 20:06
nine Ok, can't get rid of the segfault but it only happens after the profile got dumped. So it's good enough for me now 20:40
Preliminary investigation shows that we spend a lot of time in the methods that write to the byte code array. Which is good. Because those are the ones the new write* ops are supposed to help with :) And bad...because those methods all push which is not good for performance and changing that means changing a lot 20:41
timotimo tbh i would have assumed that push is a tiny bit faster than bind_pos, as we manage the position in C and as an attribute, rather than in nqp as a register 20:59
lizmat timotimo nine I can concur about push being faster than bindops 21:40
*bindpos

Powered by Cro and the Raku® Programming Language.

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

Thank you!