Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-12-19

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

All times shown according to UTC.

Time Nick Message
03:41 JimmyZ hmm, perl6 --profile -e 'my int $i =0; while $i < 10000000 { $i += 1 }'  allocates many Int, s/+=/= $i +/ avoids it
04:18 [Coke] m: andthen
04:18 camelia rakudo-moar 30edf7: OUTPUT«[31m===[0mSORRY![31m===[0m Error while compiling /tmp/HgxAxWEY6n␤Undeclared routine:␤    andthen used at line 1␤␤»
04:18 [Coke] m: sub stuff() { andthen say 3 } ; stuff
04:18 camelia rakudo-moar 30edf7: OUTPUT«[31m===[0mSORRY![31m===[0m Error while compiling /tmp/G0tv1Py3yQ␤Undeclared routine:␤    andthen used at line 1␤␤»
04:19 [Coke] Day 19 uses andthen, but it doesn't appear to be implemented?
04:34 TimToady it's an infix, not a prefix!
04:36 TimToady JimmyZ: the default is to keep temporary results in Int; we probably want to have a pragma that keeps it in natives
04:36 TimToady but we might well be able to optimize that one anyway
04:38 TimToady this optimization may well fall out of jnthn's native work, too, so that we can increment a native int in place
04:39 [Coke] m: sub stuff() { say 2 andthen say 3 } ; stuff
04:39 camelia rakudo-moar 30edf7: OUTPUT«2␤3␤»
04:40 [Coke] m: +
04:40 camelia rakudo-moar 30edf7: OUTPUT«[31m===[0mSORRY![31m===[0m Error while compiling /tmp/87AoFosxeR␤Preceding context expects a term, but found infix + instead␤at /tmp/87AoFosxeR:1␤------> [32m+[33m⏏[31m<EOL>[0m␤»
04:40 [Coke] any reason we can't get that error for a non infix andthen?
04:40 [Coke] also, whoops, this is moarvm, not p6
04:40 TimToady because we allow post-declaration of identifiers
04:50 njmurphy joined #moarvm
05:14 sivoais joined #moarvm
07:52 FROGGS joined #moarvm
08:22 brrt joined #moarvm
08:25 JimmyZ TimToady: I think escape analyse will help that, with inline optimization.
08:26 JimmyZ or Allocation sinking :P
08:29 * brrt backlogs
08:30 rurban joined #moarvm
08:30 brrt oh, we need escape analysis badly, if nothing else then to eliminate getlex/setlex
08:31 JimmyZ I'm looking at Allocation sinking optimization code in the luajit, and find it's even with a simplified escape analysis etc, it's about 1000 lines code
08:32 JimmyZ and alias analysis
08:34 brrt 1000 lines is not beyond our reach
08:34 brrt the trick is understanding how to apply it to our case :-)
08:35 JimmyZ yeah
08:59 jnthn Eliminating getlex/bindlex is a static optimization much more than a dynamic one, and really needs the langauge buy-in.
09:00 jnthn We already do that heavily in NQP, and it's done in the NQP optimizer
09:00 jnthn And where it happens in Rakudo already, it's done in the Rakudo optimizer. It's just that the analysis to do it for full Perl 6 is harder, so we're not so far along with it yet.
09:03 JimmyZ jnthn: Did you implement the Partial Escape Analysis one? the segfault one you didn't push :P
09:04 JimmyZ if I can ask it :)
09:04 JimmyZ *ask about
09:06 * JimmyZ takes care of it very much ....
09:41 brrt jnthn: i believe that, i'm just saying it turns up as really important
09:41 brrt :-)
10:22 JimmyZ japhb: I have a pull request for you :)
10:22 JimmyZ japhb: https://github.com/japhb/perl6-bench/pull/16
10:53 brrt left #moarvm
12:48 ingy joined #moarvm
13:00 timotimo 6600 or more seconds ;(
13:01 timotimo JimmyZ: usually, our benchmarks are scaled, as in they accept an argument that tells the program how long to run for
13:02 timotimo it might be interesting to have a port of it to nqp, too :)
13:03 JimmyZ yeah
13:04 timotimo have you looked at spesh output/profiler output yet?
13:04 JimmyZ the luajit's one is awesome, much better than java
13:04 JimmyZ timotimo: I have looked at profiler output
13:07 JimmyZ timotimo: https://gist.github.com/zhuomingliang/26e30224f06848908793 # a bit faster one, with custom BUILD
13:08 timotimo would it be faster to return self.bless(...) instead of Point.new?
13:08 timotimo in method add, i mean
13:09 JimmyZ don't know, I don't know how write it
13:09 timotimo and i wonder if there's a performance difference between submethod BUILD(num $x, num $y) { ... } and submethod BUILD(num $!x, num $!y) {}
13:09 timotimo just replace Point.new with self.bless in method add
13:11 JimmyZ timotimo: 2x faster
13:17 timotimo wow
13:17 timotimo what exactly?
13:19 timotimo the self.bless thing?
13:21 timotimo it's kind of weird to me that we're allocating 46000066 BOOTCode instances in my run of 1000000
13:22 JimmyZ timotimo: yeah
13:28 timotimo much much fewer BOOTCode when i create a custom submethod BUILD
13:31 timotimo for some reason, bless is calling Bool twice as often as BUILDALL
13:31 timotimo and that Bool is calling reify
13:32 timotimo oh wow
13:32 timotimo that's the check for bless having an initial * argument
13:34 JimmyZ timotimo: nqp's one is 3x faster than perl6 fastest one
13:35 timotimo i'll test a tiny patch
13:36 timotimo oh
13:36 timotimo the deprecation warning has been removed
13:38 timotimo i was just about to optimize the check for the whatever argument
13:39 JimmyZ timotimo: https://github.com/japhb/perl6-bench/pull/16/files # all is here
13:41 timotimo personally i prefer the for ^10000 over my int ... and $i = $i + 1
13:53 JimmyZ the fastest one in nqp is 552s
13:54 JimmyZ long way to go ;)
13:54 * timotimo is twiddling a thing or two
13:54 timotimo i'm not expecting big wins from what i'm doing right now
13:57 timotimo um ...
13:57 timotimo nope, my code isn't working
13:58 JimmyZ nqp's one is not that many BOOTCode
13:58 JimmyZ only 5
13:58 timotimo i apparently don't know how to iterate over a list-like thing
13:58 timotimo though i don't know 100% what that exact thing is
13:59 JimmyZ but it  allocate many BOOTNum, which should not
13:59 timotimo oh?
14:00 timotimo hum, what?
14:00 JimmyZ https://github.com/zhuomingliang/perl6-bench/blob/master/nqp/point_class_add2 # this one
14:01 timotimo reprname says VMIterator, nqp::iterval says "this is not an iterator"
14:01 JimmyZ change it to 1000000
14:02 JimmyZ if it doesn't allocates BOOTNum, It will be much faster, me thinks
14:02 JimmyZ like 2x
14:02 timotimo oh, you mean that's a non-native num
14:02 timotimo right
14:03 JimmyZ yeah
14:04 timotimo it must be boxing it to pass it to self.bless
14:04 timotimo if you directly nqp::create the Point object and setattr_n the values, that should avoid it
14:04 timotimo damn it.
14:04 timotimo how do i get the value out of an iterator and move it along?
14:04 timotimo i thought i just have to nqp::shift it
14:05 timotimo but that gives me "does not support positional operations"
14:07 timotimo ah, i figured it out
14:13 timotimo hm. using an iterator in BUILDALL and BUILD_LEAST_DERIVED doesn't make things faster
14:13 timotimo but it does create an iterator per BUILDALL/B_L_D
14:14 timotimo it causes the number of GC runs to go up noticably, too :\
14:15 * timotimo sadface
14:20 timotimo oh!
14:20 timotimo i made a detectable difference
14:20 timotimo i shall spectests
14:22 JimmyZ not sure, rakudo doesn't allocates BOOTNum
14:23 JimmyZ only nqp, looks like
14:31 timotimo please see if rakudo's latest commit gives you a measurable improvement
14:50 JimmyZ m: say 2492.84/2532.72
14:50 camelia rakudo-moar 30edf7: OUTPUT«0.984254␤»
14:50 JimmyZ timotimo: ^^
16:21 FROGGS joined #moarvm
16:36 lizmat joined #moarvm
17:10 timotimo oh. that's not nearly as much
17:21 timotimo JimmyZ: i'm not entirely happy about having 6 benchmarks with almost the same code
17:24 timotimo so ... the BOOTCode allocations seem to happen inside BUILDALL; possibly because we're taking a closure?
17:38 timotimo JimmyZ: you can avoid a whole lot of Parcel allocations just by removing the "return" from Point.add
18:13 TimToady timotimo: we should remove the * test in bless, if it's still there; maybe that's what you were doing, but it wasn't clear to me from the backlog
18:15 jnthn I thought I saw that get tossed just before the last release.
18:15 vendethiel joined #moarvm
18:15 jnthn TimToady: huh, return is still creating temporayr Parcels? I was sure I'd fixed that...
18:15 jnthn Oh...maybe that was for take, not return...
18:16 TimToady that would be timotimo:
18:17 jnthn Darn tab key still can't mind-read.
18:18 TimToady obviously it has not yet tabulated enough data
18:28 tgt joined #moarvm
19:05 d4l3k_ joined #moarvm
19:07 __rnddim__ joined #moarvm
19:16 lizmat the * test in bless is tossed in 2014.12
19:18 * hoelzro got his bless(*, ...)es out just in time!
19:26 jnthn Bless you!
19:45 rurban joined #moarvm
19:48 FROGGS joined #moarvm
19:56 hoelzro the code I was working on is over 2 years old; I'm surprised it works at all =)
20:01 TimToady .oO(No bless oblige!)
22:36 timotimo yes, it was tossed
22:36 timotimo i hadn't pulled the latest changes before i did the profiling
22:43 timotimo it turns out the check for * could take a whole lot of time
22:43 timotimo two call sto .Bool for example
22:43 timotimo well, it's all long gone now and i'm glad
22:44 lizmat well, not long, but yes   :-)
22:44 lizmat FWIW, I feel the spectest has gotten signifcantly (as in 5% or so) slower
22:44 lizmat however, that could also be me switching from Mavericks to Yosemite  :-(
22:45 timotimo uh oh
22:46 lizmat otoh, I haven't seen a single flapping failure in the spectest since I've moved to Yosemite
22:46 timotimo that's nice
22:50 lizmat ah, I take that back....  apperently it was doing something in the background a few hours ago
22:50 lizmat All tests successful.
22:50 lizmat Files=932, Tests=34129, 191 wallclock secs ( 8.88 usr  3.19 sys + 1159.09 cusr 140.72 csys = 1311.88 CPU)
22:55 timotimo oh!
22:55 timotimo so, how's it compare?
22:58 lizmat about the same
23:04 timotimo OK
23:04 * timotimo hasn't been optimizing for a long while now
23:06 carlin joined #moarvm
23:09 JimmyZ timotimo: almost same, but very different speed, we can't just keep the best one, but if we keep the worst one, someone(like me) will think he's not optimistic about it :)
23:09 JimmyZ and good morning ..

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