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

Powered by Cro and the Raku® Programming Language.

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

Thank you!