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.
nine MasterDuke: everything the optimizer does, makes compilation take longer 06:37
Nicholas good *, * 06:38
nine Good Friday! (We've already decided that Friday exists in IRC) 07:14
Nicholas "while stocks last" 07:42
MasterDuke nine: no argument there. but if you're squaring numbers you're probably doing something math-heavy, and would be ok for a slight slowdown in compilation for a speedup in runtime 09:16
hopefully after rakuast we can better separate what's currently done in the optimizer. break apart correctness checking and performance optimization and make the optimization(s) opt-in/out-able 09:42
MasterDuke backing up to removing the fsa and the double free. valgrind with --trace-children=yes doesn't get them, which is annoying. but asan does 10:01
gist.github.com/MasterDuke17/72c0b...9ad3cec7aa 10:02
happening in/because of MVM_6model_set_debug_name, which i took the mutex out of because i switched to using the linked list with looping on MVM_trycas 10:03
MasterDuke ok, added the mutex back to MVM_6model_set_debug_name and now everything passes 11:09
times look pretty much the same as on master 11:16
lizmat something I just found, that I found counter-intuitive: 11:55
sub a(Callable:D $a) { $a } creates 10 bytes of bytecode
sub a(&a) { &a } creates *50* bytes of bytecode 11:56
is there any reason for that discrepancy?
Geth MoarVM: nwc10++ created pull request #1644:
Add missing `static` qualifiers to various private functions		 12:45
jnthnwrthngtn lizmat: Well, everything has a reason, but it probably isn't a good one :) 13:24
lizmat yeah, that's why I figured I'd ask :-) 13:41
btw, the bytecode sizes are what the spesh log reported using -MSIL
is there a way to directly introspect bytecode size ?
jnthnwrthngtn moar --dump bytecode-file.moarvm 13:49
And you can get one of those by --target=mbc --output=bytecode-file.moarvm to Rakudo, I think
The inlining numbers are to be taken with a pinch of salt because they are actually after specialization 13:50
iirc
Well, they might be :)
lizmat ok
jnthnwrthngtn Some are, some aren't
The one that mentions it being a call to something unspecialized certainly is the unspecialized size
lizmat so I guess Callable:D $foo speshializes better than &foo 13:51
Geth MoarVM/master: 11 commits pushed by (Nicholas Clark)++, (Jonathan Worthington)++
review: github.com/MoarVM/MoarVM/compare/1...2de6d1d09f		 15:28
MoarVM: MasterDuke17++ created pull request #1645:
Remove the fixed size allocator (FSA)		 15:29
Nicholas forgot to say (and before I forget again) mimalloc on ppc32 grumbles a lot (to stderr) about large alloacations that it thinks are bogus, and then follows up with another message to the effect of "OK, actually it wasn't bogus". Lots and lots 16:01
Nicholas mimalloc on sparc32 fails assertions 16:01
Nicholas optional for the win 16:01
mainly beacuse I don't like debugging mimalloc 16:02
nine Nicholas: wow, now I'm really glad I asked. I thought that if anything atomic_load_explicit would be more expensive (because what could be cheaper than a MOV of equivalent?), but figured knowing is better than suspecting. Reading that it can actually be cheaper after all is a very nice surprise. 16:24
And this uncovered one of the many x86 biases I've gathered over the years...

Powered by Cro and the Raku® Programming Language.

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

Thank you!