Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-12-20

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

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

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary