00:00 vendethiel joined 01:29 vendethiel joined 01:55 Ven joined 04:43 vendethiel joined 05:11 vendethiel joined 05:35 vendethiel joined 06:42 vendethiel joined
JimmyZ timotimo: github.com/japhb/perl6-bench/pull/...28be71e9R1 # I got a much faster version, which is faster than Lua 5.1.5 :P 06:59
timotimo what. 07:00
JimmyZ timotimo: but I port it to perl6, it 5x slower
:(
timotimo right
:\
we've got a lot of stuff ahead of us in terms of optimizations still 07:01
JimmyZ the nqp version is fast enough, 83s
timotimo i wonder if we should attempt to do code-gen in BUILDALLPLAN 07:02
rather than iterate over the build plan, we could generate a short method 07:03
JimmyZ now the 3 test speed is very different, which is ok to exist, unless there are the same speed
*are
timotimo: yeah, the constuctor does too much work 07:04
timotimo well, to be fair, derived classes make it a tiny bit more complicated :) 07:05
JimmyZ eah 07:08
*yeah
timotimo well, at some point we'll have "final" classes or "closed" or whatever we call that 07:09
when we have a type that we know is final, we can do a bit more agressive optimizatifying
except, there's always roles that may be mixed into the stuff we're working with
JimmyZ the 83s one is good for testing vm opitmization though ;) 07:10
timotimo SGTM 07:12
have you looked at the way it speshes yet?
07:12 lizmat joined
JimmyZ timotimo: I didn't, I' on a slow x86 machine, while hack.p6c.org is so slow I can't do things on it 07:13
hack.p6c.org network. 07:14
timotimo ah, only the network 07:19
fair. i'll have a look in a couple of hours
JimmyZ That'd be nice ;) 07:20
timotimo have you tried using nqp::create in the perl6 version as well? 07:21
that'd show how much overhead the constructor has
at least i think so 07:22
JimmyZ timotimo: github.com/japhb/perl6-bench/pull/...a9b01d8eR1
timotimo oh, huh.
JimmyZ each one has a nqp version 07:23
timotimo GTG for now 07:24
JimmyZ bye
hmm, add a multi add method, 83s -> 150s 08:14
timotimo huh, is something not getting speshed right? 08:19
JimmyZ don't know :( 08:21
08:22 vendethiel joined 08:47 vendethiel joined 09:06 dalek joined 09:08 FROGGS[mobile] joined 09:13 FROGGS joined 09:37 vendethiel joined 09:58 rurban joined 10:01 vendethiel joined
JimmyZ timotimo: I found nqp's multi method is 2x slower, but perl6's not :( 10:24
perl6's is the same speed
timotimo: github.com/japhb/perl6-bench/pull/...c1b2533R33 10:26
10:27 vendethiel joined
timotimo i'm not entirely sure how multi methods in nqp behave 10:56
12:37 vendethiel joined
JimmyZ jnthn: gist.github.com/zhuomingliang/78fa...16d2d5a890 # Is it right? added 3 MVM_ASSIGN_REF 15:13
timotimo JimmyZ: which one was i supposed to benchmark/spesh-analyze? 15:22
JimmyZ nqp/point_class_add2 15:23
timotimo thx
oh, so nqp?
JimmyZ if you have a interest about multi method, that is nqp/point_class_add2_multi_method :P 15:24
timotimo thought so
which of the perl6 versions is most interesting to analyze?
JimmyZ if you want to optimize rakudo buildplan, that's perl6/point_class_add 15:25
timotimo i wish i could 15:26
i see nothing obvious that i'd have sufficient time for right now
JimmyZ if you want spesh, that's perl6/point_class_add2
timotimo i'll probably need to reduce the number of iterations there, eh? :)
JimmyZ you mean buildplan? 15:27
timotimo yes
and number of iterations means the perl6 versions of the benchmarks
could you please use for ^$number instead of while ... ? :)
JimmyZ yeah, but better one gens codes something like nqp/point_class_add2 ;) 15:28
why ^$number? 15:29
even only the loop, without add, it's 1.2s, still slower than luajit one(which is with add and only 0.2s) :P 15:30
timotimo not really $number 15:31
whaaaaat
how can we be so slow?
i thought we can totally uber-jit that code by now??
JimmyZ timotimo: we have mov eax, WORK[src] etc.. 15:32
timotimo of course
JimmyZ and every op has it
timotimo the CPU isn't smart enough to optimize the assembly code for us? :) 15:33
damn, we need to do our own work then :(
15:33 vendethiel joined
JimmyZ yeah, every op we need access memory, luajit didn't do it. 15:33
timotimo gist.github.com/timo/1b806ded05324473b76e 15:38
15:41 FROGGS joined
timotimo it's pretty amazing how much spesh works before we even reach the user's code 15:42
the "new" method apparently calls wval twice, even though the bindattr calls have turned into sp_p6obind_n 15:45
not sure if it just doesn't debump the usage count
timotimo looks
the usages-- lines are commented out, so maybe it used to cause trouble 15:47
that results in better code during spesh now 15:51
JimmyZ hmm, looks like set op is needless? 15:57
and what sp_getspeshslot is doing there? looks like needless too? 16:02
dalek arVM: 383dac3 | timotimo++ | src/6model/reprs/P6opaque.c:
re-enable usage debump for setattr ops on p6opaque
 16:04
timotimo how do you think? 16:05
set ops are often useless, but there's an added difficulty: our deoptimization strategy requires us to keep a bunch of "useless extra" registers around
getspeshslot and wval ops get kicked out often-ish now 16:06
JimmyZ think what? 16:09
timotimo about the patch i just pushed 16:10
16:11 zakharyas joined
timotimo in my case it makes the methods x and y faster, but new slower ... ?!? 16:11
JimmyZ I still don't know MVM_spesh_use_facts vs usage--; 16:12
timotimo the first is for kicking out guard instructions
the latter is for kicking out pure instructions that write to a register that has 0 (or less, i suppose) usages 16:13
JimmyZ ok, I think I know nothing about guard
:(
timotimo it's what log instructions turn into if we find the same value often 16:15
i don't understand why the bindattr_n calls in the new method don't get spesh'd into better variants 16:16
also, something must be wrong with the dump of facts, all the registers seem to have 0 usages 16:17
actually ... the fuck? no sp_getattr at all happens 16:18
ah, they are called sp_p6obind and p6oget*_* 16:19
JimmyZ because they allocates BOOTNum? 16:23
nqp/point_class_add2 vs perl6/point_class_add2, the code are the same(except s/:=/=/), but perl6 is 5x slower. if you compared it :P 16:31
which is good to compare it's codegen/spesh 16:32
16:33 japhb_ joined 16:35 carlin joined 16:36 dana joined, btyler_ joined 16:37 njmurphy joined 16:44 colomon joined 16:45 timotimo joined, dalek joined, woolfy joined
timotimo it uses bindattr_n directly 16:45
16:46 nine joined
timotimo the nqp version is hard to introspect because the code that gets generated is so slim already :) 16:49
JimmyZ yeah
16:50 njmurphy joined
JimmyZ it just needs allocation sink optimization and jit ... 16:51
timotimo "just" :)
but that could impact the perl6 version's performance positively
JimmyZ timotimo: the code in luajit 1000 lines ,but it needs to understand well to port moarvm, which is not easy 16:52
timotimo it could very well be that the impedance mismatch between moarvm and luajit's internals is so big that we can't "just port it"
JimmyZ timotimo: yeah 16:53
so it's not easy :(
01:00 am here ,good night 16:55
timotimo the amount of BOOTCode allocations is insane 16:59
16:59 synopsebot joined
timotimo 20% time spent in the GC 16:59
i'm not pleased
17:04 lue joined
timotimo is null a valid implementation of const_i64 r(...) liti64(0)? 17:18
17:31 Ven joined
TimToady the intent has been to compile the BUILDALLPLAN--that's why we removed the * from BUILD, to make that easier 17:53
timotimo oh, neat 18:07
do you have a good hunch what exactly we should use to create the compilation output? 18:08
QAST and getcomp's later stages?
TimToady has no clue what jnthn++ was intending to do 18:18
18:41 nine joined 19:48 FROGGS_ joined 20:40 zakharyas joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!