01:48 ilbot3 joined 04:33 fengc joined 05:32 domidumont joined 05:37 domidumont joined 07:29 zakharyas joined 08:48 Ven joined 09:44 domidumont joined 09:54 zakharyas joined
dalek arVM: dc0b36c | jnthn++ | src/core/op (2 files):
Mark getlexcaller as :noinline.
arVM: 6075599 | jnthn++ | src/spesh/graph.c:
Don't lose handlers during multi-level inlines.

If the inlinee itself has inlines and those have handlers, we could end up with them going missing.
11:03 brrt joined
jnthn m: say 11085521589 / 17534022355 11:07
camelia rakudo-moar 33ab86: OUTPUT«0.632229237796␤»
brrt wonders what these are the numbers for 11:09
jnthn If this is right, the above two fixes above which in turn unblock removing &EXHAUST in Rakudo result in the program 'class A { has $.i = 0; method m() { $!i++ } }; my $a = A.new; for ^5000000 { $a.m() }; say $a.i' running in 63% of the CPU cycles it used to 11:10
I suspect both thanks to the removal of the late-bound &EXHAUST lookup but also unblocking various bits of inlining 11:11
brrt that... would.. be something
nwc10 at one time did we have semi-regular benchmark graphs? 11:13
jnthn nwc10: Daily in www.moarvm.org/measurements/perl6-bench/
nwc10 jnthn: could you link to that in whichever blog blogs this awesomeness? 11:14
hangon, do we have them comparing some sort of "current" and the past 1 or 2 releases?
brrt cool stuff 11:16
nwc10 was hoping for something MBA-enabled PHB-friendly
brrt if i read that correctly, perl5 is still 5 times faster on an empty loop? 11:17
say, 10 times 11:18
jnthn nwc10: www.moarvm.org/measurements/perl6-b...eases.html compares xmas release vs. previous monthly vs. HEAD
nwc10 jnthn++
brrt then again, native perl6 is rather faster 11:19
jnthn brrt: Yeah, we win on native (go JIT) but not on the other, largely 'cus our integers are bigints and GC-allocated rather than bigint 11:21
uh, rather than machine int
brrt very nice plots indeed
jnthn japhb++ made the tooling, with help from others...I just wired up a daily run
lunch & 11:24
nwc10 jnthn: would you be able to symlink the most recent page as somethig like www.moarvm.org/measurements/perl6-b...eases.html 11:26
so that there's a non-stale idiot proof URL?
(I'd guess s/$date/current/ for each variant, at the time of writing the files)
better maybe 'today' than 'current', but this is a bikeshed 11:27
jnthn Hm, could probably be done :) 11:54
nwc10 or you could just make it on a Monday and call it "this-week" :-) 11:59
arnsholt Another suggestion, while we're talking about it: Maybe change the tic labels in the plots to 2^$n rather than decimal notation? 12:48
I must confess I find it hard to keep track of it once the values start getting into the millions
And it'd make it clearer that it's log-scale
13:11 brrt joined
brrt shall i rename the dynamic array macros from MVM_DYNAR_* to MVM_VECTOR_* 13:12
since the usual name is vector rather than 'dynamic array'
jnthn m: say 11085521589 - 11025486002 13:20
camelia rakudo-moar ef376d: OUTPUT«60035587␤»
jnthn m: say 60035587 / 11085521589
camelia rakudo-moar ef376d: OUTPUT«0.005415675439␤»
jnthn Hm, not so much as hoped
nwc10 you really need a built-in function to do that calculation :-) 13:21
timotimo we call the bot's command that does it "jnthnize"
jnthn m: say "sped up get_boxed_ref by {255009758 / 315012162}" 13:24
camelia rakudo-moar ef376d: OUTPUT«sped up get_boxed_ref by 0.8095235320␤»
jnthn uh, that's not true either. Made it run in 81% of the time it used to 13:25
Guess that's something
timotimo nice 13:26
dalek arVM: 1339332 | jnthn++ | src/6model/reprs/P6opaque. (2 files):
Eliminate loop in get_boxed_ref, decreasing cost.

Takes around 20% off get_boxed_ref, which is a hot path in anything doing lots of Int operations in Rakudo. (Much less than 20% off an overall program; only 0.5% on my loop/method call/increment benchmark for example).
arVM/even-moar-jit: fcb2edb | brrt++ | src/jit/ (6 files):
Move TileList from linked list to vector

Allow easier backwards and forwards traversal in the tilelist, which is relevant in several steps of the register allocator
  (such as precoloring).
brrt oh, waitaminute
dalek arVM/even-moar-jit: 746b340 | brrt++ | src/jit/compile.c:
Be a sport, clean up yer mess
brrt it pisses me off, a little, that this is yet another sideways step 13:59
but it is a nice simplification if i say so myself 14:03
14:05 zakharyas joined
brrt you know what sucks about C 14:09
it gives you a choice between integers of various sizes
this is not good for somebody who has trouble deciding 14:10
because What If I'm Wrong
i know that the only true answer is
of course you're doing it wrong
you should accept wrongness 14:11
it is the basic state of the universe
tomboy64 brrt: just always go with double
brrt lol
tomboy64 and you shall be saved :D
brrt seems like a great idea for register indices
i'll keep that in mind
tomboy64 ;)
brrt general purpose registers, floating point registers, non-volatile registers.... 14:14
i'm actually not all that far away from going mad 14:15
but, in a good way 14:17
register allocators are pretty
you know that i'm planning, not only a heap (heaps are my favorite data structure), but also topological sort (one of my favoritae algorithms) 14:18
japhb jnthn, timotimo, nwc10: I keep this in my ~/bin just because I got tired of doing the speed up computation: gist.github.com/japhb/6d263ce20620...81d187b40d 14:41
It shows the times faster/slower as well as % more/less time, so you get both ways of saying it. :-) 14:42
timotimo it could also do memory :)
japhb And if I ever forget the order of the args, then I am again thankful it's Perl 6
timotimo (because i've been known to, at least in the past, try to improve memory usage, too)
japhb Hmmm, I guess a "smaller" is in order to go with this "faster" 14:43
timotimo :) 14:44
dalek arVM/slower/elim-take-dispatcher: 6331770 | jnthn++ | src/spesh/ (5 files):
Eliminate takedispatcher where possible on inline.

This does work, however the analysis overhead seems to lose any wins we might otherwise get. May be able to implement it smarter; for now, will put it aside.
jnthn Throwing that failed experiment out there in case anybody wants to play. :)
16:05 domidumont joined
jnthn Been working locally on eliminating use of lexotic etc. in favor of control exceptions for return 17:48
Hopefully will get it working tomorrow. :)
[Coke] jnthn++ 17:51
18:10 edehont joined
jnthn Here's my scribblings about possible upcoming changes, fwiw: gist.github.com/jnthn/d74caa20d7ad...781c6a9030 18:19
jnthn goes to do nom prep stuff 18:20
timotimo "However, an exception object" 18:25
i didn't understand that sentence
interesting changes 18:27
18:36 zakharyas joined 18:54 vendethiel joined 19:12 lizmat_ joined 20:30 edehont joined