github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
MasterDuke this is interesting, it's non-deterministic. sometimes the example (when on my branch) has 43k deopts, sometimes 688k. however, with MVM_SPESH_BLOCKING=1 it's always 688k 10:05
nwc10 hash randomisation can affect spesh 10:06
I *sort* of figured this out; jnthn said it directly
MasterDuke well, not just hash randomization, right? aiui, MVM_SPESH_BLOCKING=1 does more than just disable hash randomization 10:08
nwc10 yes. Not sure why it makes your numbers consistent 10:09
and it doesn't disable hash randomisation
you have to compile the C code conditionally to do tht
but hash randomisation is the big reason why the spesh behaviour can vary with a default build and no environment variables 10:10
MasterDuke hm, on master the number varies by a tiny amount, but it's always right around 688k (with or without MVM_SPESH_BLOCKING=1) 10:11
i wasn't even sure at first how there could be so many deopts on my branch, but i guess they're happening so fast that the spesh plan to remove the optimization doesn't have time to run. it would be nice if MVM_SPESH_BLOCKING=1 triggered the remove case, so i could easily get some timing numbers 10:16
how does a plan get triggered? 10:17
nine MasterDuke: MVM_SPESH_BLOCKING=1 means that executing threads are stopped while spesh creates a candidate. Without it the main program continues running while spesh is busy. I.e. with blocking enabled, speshed code will get more exercise and you will see more consistent results 10:19
MasterDuke but then i would expect to always see the fewer deopts because my removal code got hit? 10:21
or is creating a candidate the only thing that stops executing threads when MVM_SPESH_BLOCKING=1? and i need to add some `if (MVM_SPESH_BLOCKING=1) { stop_executing_thread() }` before/in/around my removal code? 10:24
nine don't know 10:25
MVM_SPESH_BLOCKING is implemented via a mutex on the spesh log 10:26
nine m: say "back from my new home!" 10:36
camelia back from my new home! 10:37
nine Hm...getting camelia to connect via IPv6 is a lot harder than expected though 11:49
MasterDuke heh. so i see a `Observed type specialization of 'reify-at-least' <...> It was planned for the type tuple: Type 0: List::Reifier (Conc)`. then `Deopt specialization of 'reify-at-least' <...> Removing a spesh candidate because it was deopted too many times (365)`. and then even later... `Observed type specialization of 'reify-at-least' <...> It was 17:03
planned for the type tuple: Type 0: List::Reifier (Conc)`
but i only ever see one type tuple. maybe it's oscillating between two type tuples, so initial speshialization, then a new tuple and removal, then back to the original? but all the type tuples seen in the log are the same? 17:06
brrt \o 17:07
nwc10 o/

Powered by Cro and the Raku® Programming Language.

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

Thank you!