github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
brrt \o 06:35
yoleaux 9 Oct 2018 21:48Z <[Coke]> brrt: my TPF address is tpf-grants-secretary at perl-foundation.org.
brrt thank you
nwc10 o/ 06:36
brrt ohai nwc10 06:37
brrt is debugging jnthn's issue 06:39
brrt p6invokeunder is compiled and it really shouldn't be 06:52
it twiddles the interp_cur_op 06:54
timotimo that sounds like an easy fix for the explosions: remove the jitting of that op :) 06:59
masak hi, was gonna re-voice everyone, but it turns out I don't have op on the channel ;) 08:03
thank you for your continued patience
timotimo until then, #perl6-dev is a fine place to talk about moarvm stuff as well, i reckon 08:04
nwc10 poor starving, er silent ilmari 08:05
masak ilmari: you can try miming what you want to say
nwc10 masak: I fear that it's still the wee small hours of the morning in MST 08:06
masak nwc10: that's, like, the worst time to not have a voice 08:09
timotimo in +m, nobody can hear you scream
(except for ops)
jnthn good -moarning :) 08:34
brrt ohai jnthn
lizmat hehe... we haz a voice!
brrt you know what was the problem with reprname
.oO( Power to the People! )
nwc10 jnthn++ # UGT for all 08:35
jnthn
.oO( Democracy. That was the problem with reprname. )
jnthn brrt: So what was it? :) 08:35
brrt nothing. 08:36
It wasn't compiled under the legacy JIT though
so if the merge_bbs step wouldn't happen, the expr jit would consume it
and it would continue onto compiling p6invokeunder
jnthn oh!
brrt which, as it happens, modifies tc->cur_frame->return_address to *tc->interp_cur_op + 6
as you may or may not know, and for you sanity I hope you don't, but the special JIT invocation bytecode is only 4 bytes wide 08:37
lizmat is building and testing
jnthn I didn't :)
brrt so that will return into a goto NEXT which will read from the bytecode stream and jump into nonsense 08:38
jnthn haha
Wow :)
brrt++ for finding that
brrt which actually explains a great many things, like how we ended up in the strings section of the ELF at some point
jnthn lol 08:39
brrt ohai 11:26
I hit a snag with the invoke-jit thing
lizmat yuck 11:28
:q
oops :-)
brrt the expression compiler will spill to the locals of the frame, because it assumes that its stack frame may be destroyed 11:29
the nativecall-jit-in-non-jitted-code variant on the other hand, will not be able to do that, because the locals array can't be extended 11:30
since that would entail modifying the stack space. I... can probably hack arround that by having a spill policy flag or something
brrt or, I can spill-to-stack explicitly, and load-from-stack explicitly, hmmm 11:49
that is essentially the same thing, isn't it
lizmat rubberducks 11:54
brrt [Coke]++ posted my grant request, please comment: news.perlfoundation.org/2018/10/gra...-comp.html 14:14
timotimo comment sent 16:06
timotimo m: say 0.384 / 0.0027 16:15
camelia 142.222222
timotimo m: say 1.9 / 0.0027 16:16
camelia 703.703704
timotimo who wants to know what that is? :P 16:19
jnthn Hopefully a speedup? :) 16:20
timotimo yeah, but an extreme cheat 16:21
jnthn Looks like :P
timotimo my num @a = 1e0..500_000e0; my num @b = 500_000e0...1e0; my num $c = 5e0; my num @out; my $time = now; @out = @a Z+ (@b X* $c); say now - $time; say @out[99]
that's the slowest one
my num @a = 1e0..500_000e0; my num @b = 500_000e0...1e0; my num $c = 5e0; my num @out; my $time = now; for ^500_000 { @out[$_] = @a[$_] + @b[$_] * $c; }; say now - $time; say @out[99]
evalable6 1.835722
2499605
timotimo this one's in the middle
evalable6 0.3862004
2499605
timotimo use nqp; my num @a = 1e0..500_000e0; my num @b = 500_000e0...1e0; my num @c = 5e0; my num @out; my $time = now; nqp::vectorapply(@b, @c, @b, 95, 1, 64); nqp::vectorapply(@a, @b, @out, 93, 0, 64); say now - $time; say @out[99]
this one is very fast :)
jnthn SIMD? 16:24
timotimo yep 16:25
but no actually spelled-out intrinsics
just the C compiler doing it for me
literally a function with a bunch of tight loops that do only one operation either zip or cross 16:26
with checks for sizes and slot types and such
it'd even be faster without simd, i'm sure 16:29
i'm not entirely sure if spesh is currently capable of optimizing multiple occurences of metaops, like having a Z* and a Z+ somewhere
but i haven't actually checked
also, i got a very absurd result where having $c be @c instead, as a 500_000 slot num array with just 5e0 over and over and using @c[$_] in the loop, too 16:30
because it was faster
not in total, only the measured part 16:33
perhaps there's boxing/unboxing in one of the cases, but not in the other 16:34
i have no clue if this has a future at all :) 16:42
nine Turns out, when you don't have to pack argument information into flags to pass it on to some C code, the code can become quite a bit simpler. I wonder what that will do for performance 19:19
lizmat :-) sounds cool 19:23

Powered by Cro and the Raku® Programming Language.

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

Thank you!