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.
01:47 MasterDuke joined
MasterDuke timo: no, those were just the ones that actually caused a malloc or realloc 01:47
timo so, skipping through the zstd compressed spesh log with raku code using Compress::ZSTD isn't too slow to be usable. that's nice 02:38
MasterDuke i just love zstd, i want to use it for everything
timo with ZSTD_writeSkippableFrame I can put some plain text near the start of the zstd file, like "hey btw this is a zstd compressed moarvm spesh log" 03:01
and apparently less can transparently read a zst file instead of showing you the binary "garbage"
it seems to be from a lesspipe.sh which is apparently a part of the less package, not sure if that's new-ish? 03:06
MasterDuke huh 03:09
Woodi timo: simpler way to find optimisations when some new one was put in place is to start new pass... but probably "multi-pass" things are banned in this # contecst ;) 05:48
other thing is to use recursion in locations when new optimisation was done. recursion with level 1 is probably just checking outer block :) 05:50
but as lizmat pointed rewriting slow things gives good results. sometimes re-architecturing can help... 05:53
06:25 kjp left 06:26 kjp joined 06:27 kjp left 06:28 kjp joined 08:02 sena_kun joined
patrickb incidentally one of the things near the top of my to-do list is getting zstd into core moar. That's a precondition for annotating comp units with their source code. (as we should really zstd compress the source) 17:58
MasterDuke nice 18:43
timo i could do that. would we make it a hard system dependency, or ship zstd in the third party folder? 19:27
patrickb I've always planned to ship zstd in the third party folder. 19:57
We do need some logic to optionally allow using a system provided lib instead, similar to what we do for the (some?) other third party libs. (-e.g. --has-libffi) 19:59
--has-zstd
timo right 20:01
do you need access to zstd stuff from bytecode or just from internal moar functions?
so i'm looking into the possibility to give objects in the nursery a little "tail" with extra info 20:03
by putting some information on where an object was allocated in this tail, at gc time we can count up stats on how often an object allocated at that spot was either freed in the nursery, or promoted to the second generation (where it wouldn't retain its tail any more) 20:04
unfortunately, the way spesh correlates events that are put into the spesh log with the context in which they are relevant doesn't directly support events that happen at a random delay 20:05
so there's the "spesh correlation id" that's set on a stack frame and any entry or exit or other changes to the stack change this ID, and then when spesh receives the logs, it keeps a "simulated" stack that follows the motions 20:07
the spesh log also gets types of the parameters in a call put into it, so that on the sim stack we can keep track of when a frame behaves differently when called with Int vs Str even if it's the same static frame, i.e. not different "multi" candidates 20:08
unfortunately, by the time a GC run happens, the frames that have created the objects are likely to no longer be on the sim stack 20:09
going via the sim stack is not strictly necessary to get something into the stats 20:11
but for the other method, spesh really kinda wants at least a callsite to be known, and for information about the arguments to be fully available, otherwise it by default throws the information away
20:59 vrurg_ joined 21:02 vrurg left
timo not sure if we actually want this, but i added a "section" to the spesh stats for stuff associated with a callsite but without type tuples 21:31
patrickb I believe I only need to use zstd down in the moar guts. Compressing / decompressing the sources should be transparent to anything using them (the debug server API). 22:01
lizmat fwiw, it would be nice if zstd functionality would be exposed so that we could write dispatchers using it 22:40
timo write dispatchers "using" it? 22:41
23:11 sena_kun left 23:42 vrurg_ left, vrurg joined 23:53 vrurg_ joined 23:55 vrurg 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!