»ö« Welcome to Perl 6! | perl6.org/ | evalbot usage: 'perl6: say 3;' or rakudo:, niecza:, std:, or /msg camelia perl6: ... | irclog: irc.perl6.org | UTF-8 is our friend!
Set by sorear on 25 June 2013.
00:00 timotimo left, timo1 joined 00:01 timo1 is now known as timotimo, beastd joined 00:05 bfulgham_ joined
timotimo t.h8.lv/p6bench/2014-04-08-spesh.html - got some graphs for y'all 00:06
did i really build these with spesh? :\
it seems like i did; it must be that the first few benchmarks hardly benefit from it 00:10
but forest fire already got a few percent faster
00:11 rurban joined
timotimo interesting to see is the apparent regression of for loops? 00:11
from 2014.02 to 2014.03
00:13 rurban1 joined
timotimo oh well. 00:15
00:15 xenoterracide joined
timotimo it's still pretty discouraging to see the performance difference between rakudo and nqp 00:15
00:16 rurban left 00:18 rurban1 left
timotimo oh, huh 00:21
didn't i have something i wanted to offer as low hanging fruit for the weekly this week?
still quite a lot of work to do in the optimization department then ... 00:24
that just means i'll have sufficient amounts of stuff to do in the coming time
00:30 autark joined 00:44 beastd left 00:48 jnap left 00:55 kbaker_ joined 00:58 eternaleye left 00:59 autark left, autark joined 01:02 dayangkun_ joined 01:05 bfulgham_ left 01:06 dayangkun left 01:07 hoverboard joined 01:10 pmurias left 01:11 Ben_Goldberg joined 01:14 rurban joined, BenGoldberg left, Ben_Goldberg is now known as BenGoldberg 01:19 rurban left 01:28 klapperl joined 01:31 klapperl_ left 01:32 thou left 01:36 bfulgham_ joined 01:41 havenwood joined 01:49 jnap joined 01:51 plobsing joined 01:54 jnap left 01:56 btyler joined 01:57 jnap joined 01:59 hoverboard left 02:01 Alula left, Alula joined, jnap left 02:02 bfulgham_ left 02:05 raiph joined 02:07 thou joined 02:09 lustlife joined 02:15 rurban joined 02:20 rurban left 02:25 rurban joined 02:28 xragnar_ joined, xragnar is now known as Guest20786, xragnar_ is now known as xragnar 02:31 Guest20786 left 02:55 kbaker_ left 02:56 raiph left 02:58 jnap joined 02:59 woosley joined 03:02 jnap left 03:13 hoelzro left 03:15 bfulgham_ joined 03:22 xenoterracide left 03:34 thou left 03:36 havenwood left, hoverboard joined 03:43 hoelzro joined 03:48 rurban left 03:58 jnap joined 04:02 kaare_ joined 04:03 jnap left 04:19 rurban joined 04:21 pdcawley left, rurban1 joined 04:23 xenoterracide joined, pdcawley joined 04:24 rurban left 04:26 rurban1 left 04:28 xenoterracide left 04:30 Psyche^_ joined 04:31 eternaleye joined 04:34 Psyche^ left 04:49 kaare_ left 04:59 jnap joined 05:03 jnap left 05:04 btyler left 05:10 bfulgham_ left 05:11 dylanwh joined 05:15 IllvilJa left, SamuraiJack joined 05:17 kaare_ joined 05:23 kaleem joined, IllvilJa joined, rurban joined, telex left 05:26 telex joined 05:28 rurban left, flussence left, flussence joined 05:35 labster left 05:36 labster joined 05:40 IllvilJa left 05:50 hoverboard left 05:51 kaleem left 05:52 darutoko joined 06:00 jnap joined 06:04 jnap left 06:08 adu joined 06:12 BenGoldberg left 06:14 autark left 06:16 autark joined
jnthn timotimo: Remember that spesh only kicks in after things are *invoked* a bunch of times. If the main body of the program is just a loop, there's not a lot for it to do, I'd guess... 06:45
06:47 kaleem joined 06:53 eternaleye left, eternaleye joined 07:01 jnap joined 07:05 jnap left 07:08 zakharyas joined 07:12 Ven joined 07:16 Alula left, Alula joined 07:19 nebuchad` is now known as nebuchadnezzar 07:20 denis_boyun_ joined 07:25 rurban joined 07:29 denis_boyun_ left, eiro left, denis_boyun_ joined 07:30 adu left, rurban left 07:42 dmol joined 07:48 fhelmberger joined 07:49 adu joined 07:50 adu left 08:00 kivutar joined 08:17 kivutar left 08:18 rurban joined 08:26 plobsing left 08:29 WJB left, kivutar joined, WJB joined 08:38 brrt joined 08:49 dakkar joined 09:00 Alula left, Alula joined 09:02 jnap joined 09:05 eiro joined 09:06 jnap left 09:10 denis_boyun_ left 09:17 jlaire_ is now known as jlaire 09:19 Rix joined 09:22 integral_ is now known as integral 09:23 Alina-malina left 09:24 Alina-malina joined 09:39 labster left, telex left, hoelzro left, dayangkun_ left, ribasushi left, segomos_ left, simcop2387 left, ilbot3 left, xfix left, ashleydev left, renormalist left, JimmyZ left, ponbiki left, TimToady left, xfix joined, renormalist joined, ashleydev joined, rurban left, brother joined, JimmyZ joined, retupmoca joined, daxim_ joined, Woodi joined, pnu joined, simcop2387 joined, dayangkun_ joined, TimToady joined, pnu left, pnu joined, TimToady left, dayangkun_ left, kaare_ left, colomon left, jlaire left, perlpilot left, aborazmeh left, Bucciarati left, araujo left, SHODAN left, Alula left, PZt left, tadzik left, dalek left, FROGGS left, japhb_ left, rurban_ left, stevan_ left, sivoais left, anocelot left, huf left, LordV left, xybre left, takesako____ left, zamolxes left, Tene left, yoleaux left, Juerd left, isacloud_ joined 09:40 jlaire joined, Bucciarati joined, colomon joined, atrodo joined, kaare_ joined, Util joined, segomos joined, anocelot joined, Juerd joined, Tene joined, Tene left, Tene joined, huf joined, yoleaux joined, ChanServ sets mode: +v yoleaux, ribasushi joined, takesako____ joined, LordV joined, araujo joined, japhb_ joined, stevan_ joined, tokuhirom joined, rurban_ joined, tadzik joined, xybre joined 09:41 dalek joined, ChanServ sets mode: +v dalek, markov joined, pnu left, zakharyas left, flussence left, woolfy left, mattp_ left, sjn left, prammer left, mls left, Rounin left, atta left, [Coke] joined, Rounin joined, sjohnson joined, bcode left, SHODAN joined, sjn joined, mls joined, zakharyas joined, woolfy joined, prammer joined, mattp_ joined, dagurval joined 09:42 pnu joined, dagurval left, segomos left, Rix left, autark left, xragnar left, klapperl left, ivan`` left, yves__ left, jnthn left, benabik left, bjz left, Yappo__________8 left, yeltzooo left, zacts left, cognominal left, FROGGS[mobile] left, Khisanth left, effbiai left, slavik left, cosimo left, ClarusCogitatio left, mtj_ left, klapperl joined, Yappo__________8 joined, markov left, autark joined, cosimo joined, jnthn joined, yves__ joined, flussence joined, FROGGS joined, bjz joined 09:43 mathw joined, FROGGS[mobile] joined, Ven left, dwarring left, Pleiades` joined, jercos joined, xragnar joined 09:44 rurban joined, bowtie joined, PerlJam joined 09:45 dagurval joined, zamolxes joined, synopsebot joined 09:46 Gothmog_ joined, jercos_ joined, mtj_ joined 09:47 atta joined, bcode_ joined, ilbot3 joined, breinbaas joined, ivan`` joined 09:48 cognominal joined, bcode_ is now known as bcode 09:49 Rix joined, revdiablo joined, telex joined 09:50 yeltzooo joined, jercos_ left 09:51 Ulti joined, sivoais joined, ClarusCogitatio joined 09:52 aborazmeh joined 09:54 hoelzro joined, ponbiki joined, ponbiki is now known as Guest65441, slavik joined 09:56 isacloud_ left, isacloud_ joined, japhb_ left, japhb_ joined 09:57 bcode left, mls left, mls joined, pnu left, pnu joined, bcode joined, effbiai joined 10:00 Khisanth joined
lizmat it's windy today 10:00
10:00 rindolf joined
dalek ast: baf5685 | (Elizabeth Mattijsen)++ | S17-concurrency/lock.t:
Add a Thread/lock stress test

Which so far fails all the time. Not sure whether the test is ok.		 10:02
10:02 zacts joined, zacts is now known as Guest59041 10:03 rurban left, woolfy left, zakharyas left, rurban_ left, japhb_ left, tokuhirom left, atrodo left, isacloud_ left, dylanwh left, timotimo left, mkz left, sergot left, hugme left, sorear left, raydiak left, risou left, zakharyas joined, mkz joined, raydiak joined, rurban joined, isacloud_ joined, risou joined, japhb_ joined, rurban_ joined 10:04 woolfy joined, hugme joined, ChanServ sets mode: +v hugme, segomos joined, timotimo joined 10:05 denis_boyun joined 10:06 TimToady joined 10:08 sergot joined 10:12 rurban left, rurban joined 10:15 japhb_ left, mkz left, tokuhirom joined 10:16 mkz joined 10:17 sorear joined, atrodo joined 10:19 dylanwh joined 10:23 Alula joined 10:26 rurban left, Ven joined, cibs left, effbiai left, yeltzooo left, mtj_ left, xragnar left, FROGGS left, bjz left, jercos left, yves__ left, flussence left, Pleiades` left, jnthn left, sjn left, Rounin left, huf left, yoleaux left, Tene left, araujo left, Juerd left, colomon left, Woodi left, retupmoca left, brother left, JimmyZ left, renormalist left, Alina-malina left, dakkar left, eternaleye left, SamuraiJack left, woosley left, lue left, Exodist left, frettled_ left, nebuchadnezzar left, xinming_ left, [particle] left, vendethiel left, aindilis left, camelia left, baest left, mtk left, masak left, arnsholt left, yogan left, amkrankruleuen left, larks left, apejens left, crazedpsyc left, rjbs left, Celelibi left, ggherdov_ left, masak joined 10:27 frettled joined, jtpalmer joined, xragnar joined, amkrankruleuen joined, amkrankruleuen left, amkrankruleuen joined, Celelibi joined, SamuraiJack joined, sjn joined, jercos joined, jnthn joined, yves__ joined, renormalist joined, vendethiel joined, larks joined, yeltzooo joined, xinming_ joined, dakkar joined, effbiai joined, baest joined, Exodist joined, nebuchadnezzar joined, crazedpsyc joined, bjz joined, lue joined, Tene joined, yoleaux joined, retupmoca joined, colomon joined, [particle] joined, Tene left, Tene joined, ChanServ sets mode: +v yoleaux, huf joined, FROGGS joined, aindilis joined, Rounin joined, rjbs joined, Pleiades` joined, apejens joined, Woodi joined, mtk joined, masak is now known as Guest3496, japhb_ joined, markov joined, eternaleye joined, Alina-malina joined 10:28 camelia joined, japhb_ left, japhb_ joined, mtj_ joined, woosley joined, araujo joined
jnthn lizmat: fails all the time on just Moar? 10:29
10:29 ChanServ sets mode: +v camelia
jnthn lizmat: If it fails on JVM too it's probably the test. 10:29
10:29 flussence joined 10:30 brother joined, Juerd joined, ggherdov_ joined 10:32 cibs joined, arnsholt joined 10:34 JimmyZ joined 10:35 SamuraiJack left
dalek osystem: cb659e0 | dagurval++ | META.list:
Added WebService::Justcoin
 10:35
10:39 [particle] left, effbiai left, baest left, amkrankruleuen left, xragnar left, jtpalmer left, frettled left, Guest3496 left, rindolf left, slavik left, dagurval left, autark left, klapperl left, prammer left, dalek left, daxim_ left, WJB left, kivutar left, kaleem left, Psyche^_ left, lestrrat left, cxreg2 left, integral left, hummeleB1 left, salv0 left, masak_ joined, cxreg joined, klapperl joined, jtpalmer joined, hummeleBop1 joined, rindolf joined, Psyche^ joined 10:40 xragnar joined, daxim_ joined, effbiai joined, kaleem joined, frettled joined, autark joined, prammer joined, integral joined, integral left, integral joined, baest joined, dalek joined, ChanServ sets mode: +v dalek, amkrankruleuen joined, amkrankruleuen left, amkrankruleuen joined, [particle] joined, kivutar joined, salv0 joined, lestrrat joined, slavik joined 10:45 dagurval joined 10:46 Alula left 10:47 Alula joined 10:58 yogan joined
lizmat jnthn: the test fails on the JVM as well, but generally later, as in up to 12 times (rather than the first time already in the moarvm case) 10:59
10:59 labster joined 11:00 Alula left, Alula joined
lizmat I'm not completely sure the code is ok, but then again, Lock.condition and the ConditionVariable class ate not specced 11:00
so speccially, (as opposed to technically), I'm not sure what they should do 11:01
commuting& 11:02
11:02 lizmat left 11:09 kurahaupo joined 11:10 markov left
timotimo o/ 11:14
jnthn: that's a good point that i hadn't considered! 11:16
11:17 pecastro joined 11:19 woolfy left 11:20 xragnar left
jnthn lizmat: They ain't spec'd yet, but they have the semantics you'd expect condvars to have anywhere. 11:20
(provided you have an expectation ;))
timotimo: While my students do exercises I've been looking at some of the benchmarks and the code they call. 11:21
timotimo: The worst offender is the push one
11:21 xragnar joined
jnthn Which is 2000 times slower o.O 11:22
Then I found why: we always slurpy push
Even for the single value case.
I'll probably fix that one tonight.
The other huge pain point that makes assigning to arrays and hashex expensive is:
%h<a> = 42;
timotimo oops, slurpy push is certainly expensive for single values 11:23
jnthn This creates a scalar which a whence, which in turn means taking a closure, which means a Block and CodeRef allocation.
timotimo oh! oof! :)
jnthn timotimo: yes, and in push @a, ...; push sub is slurpy and so is push method!
Anyway, the whence the triggers the lambda and binds ths scalar 11:24
But if we know full well we're going to be assigning...which we often can syntactically, that is an insane amount of overhead.
timotimo ah, i get it now
jnthn The reason for all this is that: 11:25
r: my $a := %h<a>; say %h<a>:exists; $a = 42; say %h<a>:exists;
timotimo it's all autoviv
camelia rakudo-jvm 2b8977: OUTPUT«(timeout)»
..rakudo-parrot 2b8977, rakudo-moar 2b8977: OUTPUT«===SORRY!=== Error while compiling /tmp/tmpfile␤Variable '%h' is not declared␤at /tmp/tmpfile:1␤------> my $a := %h<a>⏏; say %h<a>:exists; $a = 42; say %h<a>:e␤ expecting any of:␤ …»
jnthn m: my %h; my $a := %h<a>; say %h<a>:exists; $a = 42; say %h<a>:exists; 11:26
camelia rakudo-moar 2b8977: OUTPUT«False␤True␤»
timotimo oh!
jnthn That has to work.
But that's *not* the common case
timotimo yeah, that's certainly something you don't see that often
jnthn But we pessimize every darn thing.
timotimo that's what we do :)
it may seem easy to syntactically find out, but how do we signal it downwards?
also, will the same kind of depessimization help slurpy assignments like %h<a b c> = 1, 2, 3? 11:27
jnthn I'm pondering how to do it 11:28
I know full well whatever I come up with, Pm and/or TimToady probably won't like it. 11:29
We already ahve a bind_key and bind_pos; I'm tempted to do assign_keya nd assign_pos...
timotimo that's new public api?
jnthn I guess they would be, yeah :S 11:30
I think we can't afford to not do something like this, though.
timotimo it'll definitely give us a nice speed boost in the general case 11:32
dalek kudo-star-daily: bb44ecd | coke++ | log/ (5 files):
today (automated commit)
 11:34
11:41 daniel-s_ joined
jnthn Overall, I plan to make a pass through CORE.setting and look carefully at the bytecode we're generating 11:45
For each of the benchmarks.
Finishing up multispec will also help. 11:47
nwc10 what's multispec? 11:48
[Coke] we're having enough trouble with a monospec! 11:50
jnthn nwc10: In a multi-dispatch we currently always make a call tot he proto first 11:51
nwc10: If the proto simply says "look in the cache", then that's a huge waste of a callframe and other things.
nwc10: multispec lets us tell the VM how to find the cache out of the code object 11:52
nwc10 ah right. Yes, that does sound like a place to win speed
jnthn So it can completely skip that.
nwc10 which will benefit all 3 backends?
oh, how is the JS backend work?
jnthn Well, in the case of things like infix:<+>, I think the proto is at least as costly as the operation itself.
It needs to be implemented per backend... 11:53
11:53 kivutar left
nwc10 yes, but how often do we call + :-) 11:53
jnthn I'll likely also do it for JVM.
Somebody else can take care of it for Parrot if they want things faster there.
guess we can PIC it on the two also 11:55
to abuse the term PIC a little :) 11:56
timotimo i don't know what that term means :(
[Coke] position independent code? 12:00
nwc10 aha 12:04
Polymorphic Inline Cache
jnthn yes, that 12:06
findmethod calls after spesh either are resolved statically or get a monomorphic cache
We use such a technique on JVM too. 12:07
timotimo ah, yes
nwc10 who is doing Star this month? 12:08
jnthn I'm pondering a similar inline cache for multi-dispatch.
timotimo hmm, spesh is not far-reaching enough to help any with the hash assignment problem, aye?
because it doesn't inline?
jnthn timotimo: I dunno if it can ever really be in general.
It's not just inlining, it's a lot of things.
timotimo mhm 12:09
it'd be a complicated pattern to match against
jnthn The mere presence of the closure prevents compile-time lex to loc of self and so forth
timotimo ah
jnthn You'd need to thus teach spesh to also do such things
timotimo anything more simple you could offload onto me for today? :) 12:10
oh, and what invocation did you use to figure out what exact bytecodes were called? moarvm --dump?
jnthn yeah but I'm actually reading the spesh log
cus it tells me the bytecode on hot paths for free :)
timotimo ah :) 12:11
well ... "hot" :)
12:11 kaare_ left
jnthn more hot than not :) 12:11
12:11 SamuraiJack joined
timotimo since 0K is kind of unreachable ... yeah, you get that property for free :P 12:11
jnthn Did you get anywhere with the NQP opt stuff?
So we can lower and spesh the grammar rules?
timotimo no :| 12:13
12:13 rindolf left
timotimo i had absolutely no clue where to look for the cause of the problem 12:13
12:14 Alula left 12:15 Alula joined 12:16 kaare_ joined, isacloud_ left 12:17 isacloud_ joined 12:18 sorear left, mkz left, tokuhirom left, rurban_ left, flussence left, japhb_ left, dylanwh left 12:19 zakharyas left, xfix left, atrodo left 12:20 tokuhirom joined, atrodo joined 12:21 zakharyas joined, rurban_ joined, dylanwh joined, flussence joined, araujo left 12:22 sorear joined, japhb_ joined 12:23 daniel-s_ left, daniel-s_ joined 12:26 mkz joined 12:27 araujo joined 12:38 daniel-s_ left 12:40 xenoterracide joined 12:41 kbaker_ joined 12:57 guru joined, guru is now known as ajr_ 13:01 rurban joined 13:06 rurban left 13:15 raiph joined 13:22 aborazmeh left 13:25 [particle] left 13:28 kaare_ left
jnthn timotimo: ah, ok... 13:28
Guess I'll have to look at that then.
timotimo: adding a single-item candidate to sub push shoiuld be eas to do and test 13:29
multi sub push(@a, \thing) { @a.push(thing) } 13:30
unshift too
13:33 xenoterracide left 13:40 benabik joined 13:41 thou joined 13:54 btyler joined 13:56 SamuraiJack left 14:02 rurban joined 14:07 rurban left 14:11 jnap joined 14:12 sftp left 14:13 sftp joined 14:19 PZt joined 14:21 rurban joined 14:22 geekosaur left, geekosaur joined 14:24 jnap left 14:31 rurban left 14:32 jnap joined 14:36 thilp joined 14:41 treehug88 joined 14:42 virtualsue joined 14:45 TimToady left, mathw left, cosimo left, Yappo__________8 left, mls left, sjohnson left, takesako____ left, anocelot left, Bucciarati left, ribasushi left, simcop2387 left, dmol left, brrt left, darutoko left, pdcawley left, lustlife left, go|dfish left, Vlavv left, Timbus left, gtodd left, Goodbox left, Bucciarati joined, Timbus joined, Goodbox joined, pdcawley joined, TimToady joined, Yappo__________8 joined 14:46 darutoko joined 14:47 bluescreen10 joined 14:48 simcop2387 joined, ribasushi joined, mathw joined, anocelot joined 14:49 mhasch joined, dmol joined, gtodd joined, brrt joined 14:50 go|dfish joined, Vlavv joined, nwc10 joined, cosimo joined 14:51 sjohnson joined, takesako____ joined 14:55 mls joined 14:56 dotuser joined, dotuser left 14:57 ajr_ left 14:58 kaare_ joined 14:59 lustlife joined 15:02 denis_boyun left 15:05 guru joined, salv0 left, guru is now known as Guest31987, Guest31987 is now known as ajr_
cognominal it seems that rakudo build twice as fast using spesh 15:16
15:17 falk0n joined
benabik Woo! 15:18
15:20 salv0 joined
cognominal just a feeling, I have no hard numbers. Setting parses in less of 1 min on my macbook. I think it was around 2 minutes 15:21
15:22 kaleem left 15:24 kurahaupo left 15:32 zakharyas left 15:33 brrt left 15:39 lustlife left 15:43 lustlife joined 15:44 perigrin left 15:45 perigrin joined
jnthn cognominal: Don't think it's that dramatic, but yeah, I get the whole setting built in less than a minute on this machine. 15:46
cognominal indeed, but it was two minutes not long ago, so I don't know what made the difference. 15:47
at least, mesh machinery did not slowed it down :) 15:49
15:49 ldthien0 joined, ldthien0 left 15:52 bfulgham_ joined, xinming_ left 15:53 bjz left, xinming_ joined 15:58 ldthien0 joined 16:02 ribasushi left 16:03 ribasushi joined, ribasushi left, ribasushi joined, ribasushi left
dalek kudo/nom: 9eaf468 | jonathan++ | src/core/List.pm:
Greatly cheapen single-item push/unshift subs.
 16:04
16:04 ribasushi joined, ribasushi left, rurban_ left, ribasushi joined, ribasushi left 16:05 ribasushi joined, ribasushi left, ribasushi joined, ribasushi left, kurahaupo joined 16:06 ribasushi joined, ribasushi left, ribasushi joined, ribasushi left 16:07 ribasushi joined, ribasushi left, Ven left, ribasushi joined, ribasushi left 16:08 ribasushi joined, ribasushi left, ribasushi joined, ribasushi left 16:09 fhelmberger left, ribasushi joined, ribasushi left, ribasushi joined, ribasushi left 16:11 rurban joined 16:12 hoverboard joined 16:13 ribasushi joined, ribasushi left 16:19 ribasushi joined, ribasushi left, ribasushi joined, ribasushi left
timotimo oh, i seem to have been under the impression that the methods were also pessimized for single element pushes/unshifts 16:24
jnthn timotimo: They are, but that's a harder fix, so I picked the easy thing first. :) 16:25
16:25 ajr_ left
timotimo ah! 16:25
but the improvement stacks?
16:26 denis_boyun_ joined
timotimo did you check if our accessor methods for the node classes and such get improved much by spesh or should i have a quick look? 16:26
16:26 guru joined 16:27 guru is now known as Guest75024
JimmyZ Was accessor methods inlined yet? :) 16:27
16:27 Guest75024 is now known as ajr_
timotimo we don't inline methods yet 16:27
jnthn timotimo: Yes, the improvements will stack 16:28
[Coke] jnthn++
16:30 spider-mario joined
timotimo jnthn: would you be okay with me implementing eqaddr on known values? 16:31
that opcode is the result of the "unless $value =:= NO_VALUE" things we have in the accessors
16:32 bfulgham_ left
jnthn timotimo: Yeah, I'm totally fine with that, but I *think* we may be missing one thing for it to trigger 16:33
timotimo: But I totally forget what, so try it :)
timotimo hehe.
jnthn thinks he just made @a eqv @b about 3 times faster 16:35
timotimo \o/ 16:36
16:38 ribasushi joined, ribasushi left
jnthn Mighta got several percent improvement on each .new too 16:38
for the defualt candidate anyway
16:39 thien joined, bjz joined 16:40 spider-mario left, spider-mario joined 16:42 ajr_ left 16:46 ribasushi joined
dalek kudo/nom: 6b80fe2 | jonathan++ | src/core/Mu.pm:
Optimize new's delegation to make it cheaper.

Saves around 5% off Foo.new.		 16:46
kudo/nom: 3e609e0 | jonathan++ | src/core/Mu.pm:
Make @a eqv @b around 3 times faster.
kudo/nom: 29bc5f6 | jonathan++ | src/core/Any.pm:
Use = in auto-viv, not &infix:<=>.

The latter forces a sub call; the former is compiled inline.
16:49 ldthien0 left
timotimo was &infix:<=> used to work around some kind of bug perhaps? 16:49
ribasushi sorry for the annoying joinflood earlier 16:50
fixed now
16:50 telex left
vendethiel yay ! 16:50
that's a lot
jnthn timotimo: Maybe, but it's a gone bug now 16:51
At least, so says spectest 16:52
timotimo very well
16:53 denis_boyun___ joined 16:54 denis_boyun_ left
timotimo hmm. given how many times we call .new on things for basically everything, a 5% win there should translate to a very good win for pretty much everything we do 16:55
16:56 telex joined
timotimo fwiw, my desktop is down to 38.7 seconds for stage parse on moar :) 16:58
1:32 for a whole make m-install after a clean 16:59
17:00 thou left 17:04 eMBee left, kurahaupo_mobile joined 17:08 kurahaupo left, Guest59041 left, Guest59041 joined, dakkar left, Guest59041 is now known as zacts, kurahaupo_mobile left 17:12 bluescreen100 joined 17:16 bluescreen10 left 17:17 cognominal left, cognominal joined 17:19 rindolf joined, a3gis joined 17:21 virtualsue left
dalek kudo/nom: dd1f4fa | jonathan++ | src/core/Any.pm:
Add non-slurping candidates for various list subs.

Prevent an extra layer of wrapping, and way more likely to inline. For
  map on a 5-element list in a loop, around a 5% saving.		 17:21
kudo/nom: ad962d0 | jonathan++ | src/core/ (3 files):
Optimize coercion to Order enum.

In the long run, it'd be good to emit better code for coercion to an enum type. For now, this hot-paths it in cmp and <=>, which are used in a whole range of operations. Knocked 15% off a sort benchmark.
kudo/nom: b37ef4f | jonathan++ | src/core/Any.pm:
Micro-opt on sort sub.
vendethiel Optimization time o/ 17:22
timotimo ah, i remember what the LHF was i wanted to put into the p6weekly 17:23
17:30 havenwood joined
colomon jnthn++ 17:39
17:40 raiph left, raiph joined, Rotwang joined, guru joined
japhb jnthn: Why no non-slurping version of join? 17:41
yoleaux 2 Apr 2014 08:41Z <jnthn> japhb: yes, the panda p6doc thing is known to fail install on both JVM and MoarVM. It's not entirely clear why yet, but the failures are likely related.
17:41 guru is now known as Guest88401, Guest88401 is now known as ajr_
jnthn japhb: optional $sep parameter cannot be followed by slurpy 17:42
japhb: Though, could find another way :)
The array/hash slicing code really, really needs an optimization pass now it's had a correctness one :) 17:45
japhb jnthn: I was thinking: multi join($sep, @values) 17:48
Yeah, I believe that!
timotimo recently did some informal performance measurements in that area and really has to concur 17:49
jnthn japhb: oh, yeah...duh :) 17:50
[Coke] jnthn++ again 17:51
jnthn japhb: Adding it
jnthn slept awfully last night, taught all day, and so isn't the sharpest two short planks in the jar tonight... :P
jnthn spectests a few more changes 17:52
japhb "sharpest two short planks in the jar" -- well that's ... evocative. :-) 17:54
timotimo benchmarks the recent rakudo optimizations
jnthn hehe 17:55
I should probably get some dinner :) 17:56
japhb timotimo: It occurs to me that the visit_2d_indices_* microbenchmarks should have both loops doing the sqrt of the usual SCALE, but then it further occurs to me that you'd want to then increase SCALE by 4x each run, rather than 2x, and further it might be good to generalize this so that you can specify a factoring of SCALE (e.g. SCALE_1 * SCALE_2 * SCALE_3) that will DTRT. 18:00
timotimo hmm
i'm still not quite getting why the "please do at least 3 runs in every case" code didn't work out 18:01
it's quite annoying to only see a single data point for the rakudos for example for the parse-json benchmark
japhb And on a different case, we might want to do e.g. push performance tests for 1, 8, 64 ... length things to push, to see how scaling and micro-optimizations work out for operations on collections of various sorts. 18:03
timotimo: Hmmm, I'd have to go spelunking again to figure out what went wrong there.
Maybe if I can get a little time later, that would be nice.
(nice to work on, I mean) 18:04
timotimo i would like that, thanks!
18:04 xinming__ joined
jnthn going for dinner...bbl 18:05
18:07 xinming_ left
ajr_ jnthn appears to be going for a world record in metaphor-garbling; that's >= 3 in 7 words. :-)* 18:14
18:15 raiph left
timotimo ajr_: so *that*'s why that idiom seemed foreign to me! 18:16
ajr_ It's at least a combination of "not the sharpest knife in the drawer/pencil in the jar" and "thick as two short planks", ("thick" = stupid) compounded with the meta message of confusion. 18:19
timotimo thanks for clearing that up :) 18:21
18:29 falk0n left 18:37 zacts left 18:45 cognominal left 18:46 cognominal joined 18:50 dwarring joined 18:52 mattp__ joined, mattp_ left 19:02 rurban left 19:03 rurban joined 19:07 darutoko left 19:15 thou joined, a3gis left, a3gis_ joined
vendethiel .u 0x2297 19:17
yoleaux No characters found
vendethiel .u 2297
yoleaux U+2297 CIRCLED TIMES [Sm] (⊗)
19:20 [particle] joined
timotimo ⊕_⊕ 19:25
t.h8.lv/p6bench/2014-04-08-rakudo_opt.html - the optimization of push is clearly visible, giving 2x speed in one of the two benchmarks. the other optimizations are not so visible it seems
man, our empty for loops have some significant catching up to do 19:26
19:28 hoverboard left
jnthn timotimo: Well, the others came more from me looking through CORE.setting rather than analizing the benchmarks 19:30
*analyzing
19:30 lizmat joined
dalek kudo/nom: 5d74bce | jonathan++ | src/core/Int.pm:
Further optimization of postfix ++ and --.
 19:32
timotimo yeah, that's fine ;)
i had expected to see a good difference in the bigger benchmarks, though 19:33
forest fire in particular
vendethiel jnap: what are those # XXX for ?
lizmat has arrived in Zürich and is pleasantly surprised by jnthn++ avalanche of commits today 19:34
timotimo jnthn: do we have any clue why the empty for loop seems to have such massive overhead compared to perl5? 19:35
jnthn lizmat: Given I slept 3 hours last night, so am I ;)
timotimo: Yeah, at least somewhat. We don't flatten the block in. 19:36
timotimo: There is an opt for that, but it's level 3.
timotimo i run rakudo-moar with --optimize=3 in the benchmarks 19:38
jnthn ah
and yeah, it makes a small difference
So the cost is elsewhere
In Perl 5, iiuc, when you do: 19:39
for (my $i = 1; $i < 100000; $i++ { }
Then $i is allocated once, and you're fiddling wiht the same scalar
Whereas in Perl 6 that is a scalar that gets ++'d creating a new Int each time. 19:40
timotimo oh, i see
jnthn So if we want to get the same we need to work out that we're allowed to cheat :) 19:41
Not having to support binding *and* assignment turns out to be rather useful.
Perl 6 wants both so...we have "fun"
dalek ast: 6dd6ced | (David Warring [email@hidden.address] | integration/advent2013-day2 (2 files):
adding advent 2013 days 22 & 23
 19:45
lizmat dinner& 19:46
19:46 lizmat left 19:54 isBEKaml joined 20:03 pippo joined
pippo Hi perl6! 20:04
vendethiel o/
PerlJam hello pippo
pippo m: $b=0; my @a; for ^10_000 {@a[$_]=[0,1]}; say time; for ^10_000 {$b+=@a[$_][1]}; say time; 20:05
camelia rakudo-moar b37ef4: OUTPUT«===SORRY!=== Error while compiling /tmp/pViob_i21Z␤Variable '$b' is not declared␤at /tmp/pViob_i21Z:1␤------> $b⏏=0; my @a; for ^10_000 {@a[$_]=[0,1]}; s␤ expecting any of:␤ postfix␤»
pippo m: my $b=0; my @a; for ^10_000 {@a[$_]=[0,1]}; say time; for ^10_000 {$b+=@a[$_][1]}; say time; 20:06
camelia rakudo-moar b37ef4: OUTPUT«1396987562␤1396987562␤»
pippo m: my $b=0; my @a; for ^10_000 {@a[$_]="1,2".split(',')}; say time; for ^10_000 {$b+=@a[$_][1]}; say time;
camelia rakudo-moar b37ef4: OUTPUT«(timeout)1396987604␤»
pippo ^^anybody know why this takes so much time?? 20:07
20:08 kbaker_ left
vendethiel creating an array for 2 elems and splitting a string? 20:08
PerlJam pippo: at a guess, all the memory allocations
moritz one problem is that split compiles a regex, and iirc doesn't cache it 20:09
flussence m: my $b=0; my @a; for ^10_000 {@a[$_]=[0,1]}; say time; for ^10_000 {$b+=@a[$_][1]}; say time; say $b
vendethiel helped a friend fix a performance problem on a Gameoflife in ruby : moved [" ", "x"] outside of the loop (for display) and went from 3 fps to 60+fps
camelia rakudo-moar b37ef4: OUTPUT«1396987747␤1396987747␤10000␤»
flussence okay, so it's not just optimising that out...
20:10 isBEKaml left, spider-mario left
flussence split has a non-regex special case though, so it's not that problem either. There's a lot of code in there though... 20:11
dalek rl6-roast-data: 0fd5db1 | coke++ | / (6 files):
today (automated commit)
pippo So when the first "say time" is executed @a is not yet constructed? 20:14
timotimo ... huh? 20:15
in which code exactly?
vendethiel pippo: trick =>
r: say time - BEGIN time
camelia rakudo-jvm b37ef4: OUTPUT«Unhandled exception: java.lang.RuntimeException: Missing or wrong version of dependency 'src/Perl6/Grammar.nqp'␤ in (gen/jvm/main.nqp)␤␤»
..rakudo-parrot b37ef4, rakudo-moar b37ef4: OUTPUT«0␤»
20:15 Rotwang left
vendethiel what do you waaaaaaant from me, rakudo-jvm ! 20:16
pippo timotimo: my $b=0; my @a; for ^10_000 {@a[$_]="1,2".split(',')}; say time; for ^10_000 {$b+=@a[$_][1]}; say time;
vendethiel r: my int $i = 0; for ^100000 { $i += $u }; say time - BEGIN time;
camelia rakudo-parrot b37ef4, rakudo-moar b37ef4: OUTPUT«===SORRY!=== Error while compiling /tmp/tmpfile␤Variable '$u' is not declared␤at /tmp/tmpfile:1␤------> my int $i = 0; for ^100000 { $i += $u⏏ }; say time - BEGIN time;␤ expecting any …»
..rakudo-jvm b37ef4: OUTPUT«Unhandled exception: java.lang.RuntimeException: Missing or wrong version of dependency 'src/Perl6/Grammar.nqp'␤ in (gen/jvm/main.nqp)␤␤»
vendethiel r: my int $i = 0; for ^100000 { $i += $_ }; say time - BEGIN time; 20:17
camelia rakudo-moar b37ef4: OUTPUT«No such method 'STORE' for invocant of type 'Int'␤ in block at src/gen/m-CORE.setting:16846␤ in block at /tmp/tmpfile:1␤␤»
..rakudo-jvm b37ef4: OUTPUT«Unhandled exception: java.lang.RuntimeException: Missing or wrong version of dependency 'src/Perl6/Grammar.nqp'␤ in (gen/jvm/main.nqp)␤␤»
..rakudo-parrot b37ef4: OUTPUT«Cannot modify an immutable value␤ in block at gen/parrot/CORE.setting:17045␤ in block at /tmp/tmpfile:1␤␤»
vendethiel r: my int $i = 0; for ^100000 { $i = $i + $_ }; say time - BEGIN time; # forgot that ..
camelia rakudo-parrot b37ef4: OUTPUT«3␤»
..rakudo-jvm b37ef4: OUTPUT«Unhandled exception: java.lang.RuntimeException: Missing or wrong version of dependency 'src/Perl6/Grammar.nqp'␤ in (gen/jvm/main.nqp)␤␤»
..rakudo-moar b37ef4: OUTPUT«0␤»
[Coke] (if you don't need all of rakudo, just use p or m)
pippo vendethiel: I did not want to time all the proggy. Just the last for cycle part. :-) 20:18
vendethiel: I did not want to time all the proggy. Just the last "for" loop part. :-) 20:19
timotimo also, BEGIN is when the parser hits the code, CHECK is after all code has been compiled 20:22
so if you compare BEGIN now with CHECK now, you'll get the time between the parser hitting the BEGIN now and the parser finishing and stuff being compiled 20:23
pippo timotimo: any clue on why when I construct the array with split it takes an eternity? 20:24
20:25 hoverboard joined
flussence something is seriously broken there actually... I've been letting that line of code run for several minutes now. 20:25
pippo flussence: I also think so. 20:26
timotimo hum. 20:27
20:29 kbaker joined 20:31 mdiei joined
moritz pippo: try to split on rx/\,/ instead 20:31
pippo moritz: sorry. How? 20:32
timotimo i can get 100_000 times the split and put stuff into the array in 45 seconds
moritz pippo: .split(rx/\,/) instead of .split(',') 20:33
pippo timotimo: th block that takes time is not the array construction but array manipulation one i.e. "for ^10_000 {$b+=@a[$_][1]};" 20:34
timotimo ah, hm.
pippo moritz: trying
moritz: trying... 20:35
flussence having said that, the first loop takes some indefinite amount of time in perl6-p too... 20:36
(only 8s in moar)
jnthn so, I'm re-writing Str.split taking a string delim... 20:38
20:38 kivutar joined
pippo moritz: it is immensly faster!! Thank you! How did you know? 20:40
20:40 virtualsue joined
flussence there's only two code paths to choose from there :) 20:41
20:42 a3gis_ left
moritz pippo: split compiles the separator into a regex internally 20:45
pippo: and that's slow
timotimo well, it's only slow because it does that every time anew :)
20:45 hummeleBop1 left
moritz aye 20:45
jnthn uh, the split I'm looking at doesn't... 20:46
moritz oh 20:47
then the regex version is much faster than the Cool version :/
and my information likely comes from an outdated version
PerlJam So ... how does this affect the *second* loop? 20:48
moritz does it? 20:49
somehow I read conflicting statements
PerlJam Assuming pippo's statement is accurate ... <pippo> timotimo: th block that takes time is not the array construction but array manipulation one
dalek ast: fe727fc | (David Warring [email@hidden.address] | integration/advent2013-day22.t:
typo
timotimo right. good question.
moritz r: say 'a,b'.split(',').^name 20:50
camelia rakudo-parrot 5d74bc, rakudo-jvm 5d74bc, rakudo-moar 5d74bc: OUTPUT«List␤»
moritz m: say 'a,b'.split(rx/\,/).^name
camelia rakudo-moar 5d74bc: OUTPUT«List␤»
20:51 Alula left 20:52 Alula joined
pippo moritz: yes it does. On my machine the first loop is always done quickly (the first "say time" is executed and time is printed) The second one takes tooooooo long to appear. 20:54
moritz: with your suggestion my CSV manipulation program went from 20 min to 2 min to execute !! Yep! :-) 20:55
moritz: ty. 20:57
20:58 kaare_ left
PerlJam Here's what I get on my computer: gist.github.com/perlpilot/10191112 20:58
sergot night night! o/ 20:59
PerlJam (that's Moar btw) 21:00
though perl6-j appears to exhibit the same behavior 21:02
21:03 havenwood left
pippo PerlJam: Nice! Also here on perl6-{j,m} 21:04
21:07 rindolf left
jnthn r: say "".split(':') 21:09
camelia rakudo-parrot 5d74bc, rakudo-jvm 5d74bc, rakudo-moar 5d74bc: OUTPUT«␤»
jnthn r: say "".split(':').perl
camelia rakudo-parrot 5d74bc, rakudo-jvm 5d74bc, rakudo-moar 5d74bc: OUTPUT«("",).list␤»
PerlJam pippo: btw, are you actually using Text::CSV? 21:13
21:13 lizmat joined
pippo PerlJam: Nope. Is it fast? 21:13
21:13 woolfy joined
PerlJam Dunno how fast it is comparatively. I just thought you should know about it if you didn't :) 21:14
pippo PerlJam: Thank you. I'll try it on my next proggy :-)) 21:15
21:16 treehug88 left 21:18 kbaker left
mdiei hello from finland 21:22
hows monks doing
21:24 FROGGS[mobile] left
timotimo hm? 21:26
21:26 benabik left
jnthn pippo, PerlJam: I've now got a version here where gist.github.com/perlpilot/10191112 runs faster with Version A than Version B. :) 21:30
spectesting at the moment 21:31
21:32 virtualsue left
pippo jnthn: \o/ !!! 21:33
jnthn: jnthn++ 21:34
21:37 raiph joined
lizmat r: multi a (int $a) { say "signed $a" }; a(42) # works 21:39
camelia rakudo-parrot 5d74bc, rakudo-jvm 5d74bc, rakudo-moar 5d74bc: OUTPUT«signed 42␤»
lizmat r: multi a (uint $a) { say "unsigned $a" }; multi a (int $a) { say "signed $a" }; a(42) # expected to work as well, but doesn't :-(
camelia rakudo-parrot 5d74bc: OUTPUT«Cannot call 'a'; none of these signatures match:␤:(uint $a)␤:(int $a)␤ in any at gen/parrot/BOOTSTRAP.nqp:1219␤ in sub a at /tmp/tmpfile:1␤ in block at /tmp/tmpfile:1␤␤»
..rakudo-moar 5d74bc: OUTPUT«Cannot call 'a'; none of these signatures match:␤:(uint $a)␤:(int $a)␤ in sub a at /tmp/tmpfile:1␤ in block at /tmp/tmpfile:1␤␤»
..rakudo-jvm 5d74bc: OUTPUT«Cannot call 'a'; none of these signatures match:␤:(uint $a)␤:(int $a)␤ in any at gen/jvm/BOOTSTRAP.nqp:1212␤ in sub a at /tmp/tmpfile:1␤ in block at /tmp/tmpfile:1␤␤»
lizmat if we could MMD on uint, then we could make a candidate for [] that doesn't check the index 21:40
jnthn lizmat: You've broken its ability to compile-time dispatch it by introducing ambiguity.
21:40 hoverboard left
jnthn lizmat: So it leaves it to runtime and calls it with the boxed Int instead. 21:41
And that doesn't match int/uint in a multi-dispatch.
Otherwise in int vs. Int we'd never reach the Int one.
lizmat hmmm...
m: multi a (uint $a) { say "unsigned $a" }; multi a (Int $a) { say "int $a" }; a(-42); a(42) 21:42
camelia rakudo-moar 5d74bc: OUTPUT«int -42␤unsigned 42␤»
dalek kudo/nom: da1ef6e | jonathan++ | src/core/Str.pm:
Optimize split on a literal string.

Use native str/int and nqp:: ops to get something of a speedup. Also, don't use an infinite range, since that makes evaluation of the map too lazy, causing other performance issues.		 21:43
21:43 woolfy left
lizmat but uint / Int MMD works apparently
21:43 woolfy joined
jnthn lizmat: Yeah, though...I worry it's by accident ;) 21:43
pippo jnthn: pulling...
jnthn pippo: Hopefully it helps a bit. 21:44
I'm still not too happy with it.
lizmat jnthn: I could try and run a spectest
jnthn But should be an improvement.
lizmat: spectest on...?
pippo jnthn: I'll test it immeditly and let you how it is here :-)
lizmat creating a uint / Int candidates for []
jnthn crazedpsyc: We already have an int candidate afaik 21:45
oops
lizmat: ^^
how on earth did I end up with a c instead of an l...
lizmat well, if we change the int candidate to a uint, then the negative indexes would be caught by the generic Num case
and bomb there, while the simple [0] cases would not need to check whether the index is < 0 21:46
jnthn They...won't.
lizmat ?? 21:47
jnthn int and uint are currently treated identically
uint isn't really implemented in general; it's only really native arrays that know what to do wiht it.
There's no sense in which uint in a signature is doing any kind of checking. 21:48
lizmat m: multi a (uint $a) { say "unsigned $a" }; multi a (Int $a) { say "int $a" }; a(-42); a(42) # then why does this work ?
camelia rakudo-moar 5d74bc: OUTPUT«int -42␤unsigned 42␤»
jnthn You so don't want to know. :)
42 as a literal is alomorphic 21:49
The - defeats that and leaves us with an Int, so far as the optimizer is concerned.
At present, the only way you ever reach a native multi candidate is if the dispatch is resolved at compile time.
Worse, it's done in the optimizer. 21:50
lizmat but, it the negative indexes are caught at run time
pippo jnthn: lightning fast! Thank you!! :-))
jnthn Hm, that may not actually be true...
m: multi a (uint $a) { say "oops" }; my int $x = -5; a($x) 21:51
camelia rakudo-moar 5d74bc: OUTPUT«oops␤»
lizmat m: multi a (uint $a) { say "oops" }; multi a (Int $a) { say "whoopie" }; my int $x = -5; a($x) 21:52
camelia rakudo-moar 5d74bc: OUTPUT«oops␤»
21:52 ajr_ left
lizmat m: multi a (uint $a) { say "oops" }; multi a (Int $a) { say "whoopie" }; my int $x = -5; a($x); a(-5) 21:52
camelia rakudo-moar 5d74bc: OUTPUT«oops␤whoopie␤»
jnthn It really, really, doesn't know about this. It knows enough that it can get $a + $b to the (int, int) candidate if $a and $b are declared as int.
lizmat ack, got you now 21:53
so for now, we still need the <0 check in the int candidate, because of the [$x] case
jnthn The whole area is really...icky. Especially as we probably shoudln't be sending $a + $b to the (int, int) candidate
unless a pragma is in force 21:54
Generally, we do about enough that native ints are worth using if you're careful.
And can be a notable speedup. 21:55
Same with num.
But it's sure as heck not polished.
lizmat ack, got ya 21:56
jnthn The thing that really needs opt in that area is basic array and hash assignment, though. 21:57
lizmat Files=801, Tests=31033, 189 wallclock secs ( 8.18 usr 3.58 sys + 1257.33 cusr 90.99 csys = 1360.08 CPU) 21:58
that is significantly down from 200+ wallclock yesterday! 21:59
jnthn \o/
lizmat that's at least a 5% improvement!
wow!
jnthn Yeah, it's faster on my laptop too :)
Down from 464 to 443
Poor thing only has 2 cores.
Well, 2 physical, 4 virtual.
Anyway, we almost got you a 3 minute spectest :) 22:01
lizmat yup
what's even better: running a spectest on parrot in the day, would cost me 20% of my battery
now it's down to something like 5% 22:02
jnthn :)
How fast is the core setting build for you, ooc?
22:04 lustlife left
lizmat 1:10 last I checked 22:04
jnthn oh
51.67s on my laptop for the lot 22:05
lizmat hmmm....
jnthn 81.59s for full Rakudo build.
pippo good night perl6! 22:07
jnthn oh, but I was running with spesh
pippo exit
22:07 pippo left
timotimo at some point i'm hopeful we'll be able to propagate knowledge about integers somewhat deep into the innards of ... stuff 22:08
so that perhaps spesh or jit will be able to remove checks like "is the index < 0 here?"
i think that needs either inlining or more facts known at the callsite
jnthn Just did it without. 53.90s for CORE.setting and 84.63s for the whole build.
lizmat real1m40.408s 22:09
user1m38.560s
sys0m1.563s
jnthn r: say 51.67 / 53.90
lizmat for the whole build
camelia rakudo-parrot 5d74bc, rakudo-jvm 5d74bc, rakudo-moar 5d74bc: OUTPUT«0.958627␤»
jnthn r: say 81.59 / 84.63
camelia rakudo-parrot 5d74bc, rakudo-jvm 5d74bc, rakudo-moar 5d74bc: OUTPUT«0.964079␤»
lizmat I guess that jnthn has fewer but faster CPU's
jnthn i7 :)
Anyway, seems spesh currently wins about 4%-5% saving. Not bad given it basically can't analyze too deeply into regexes yet. 22:10
lizmat 2.8GHz i7 for me
22:10 hoverboard joined
jnthn Or deal with named args which show up all over. 22:11
timotimo do you already have an idea what the named args are going to require for us to handle them?
jnthn yeah
We need to get the names made part of the callsite. 22:12
It's mildly tricky.
But not awfully bad.
lizmat: 2.9 :) 22:13
timotimo will that just be a MVMString **?
lizmat that explains then :-)
jnthn timotimo: After bytecode loading, I guess yes
timotimo: In the mbc file I suspect they are just stored as string heap indexes. 22:14
timotimo bytecode loading? i seem to be missing something
oh, of course, the callsites are in the mbc file
jnthn timotimo: Well, callsites are one segment of the mbc file, which is all handled in bytecode.c.
lizmat also, I'm running on battery now, so probably not getting overclocked
jnthn There is one other nice consequence of this refactor, btw.
Right now if you call, say, foo(bar => baz)
Then it's a
prepargs [cs idx] 22:15
argconst_s 0, "foo"
22:15 woolfy left
jnthn arg_o 1, rX 22:15
invoke_o # or whatever
22:15 woolfy joined
jnthn And one of those instructions can go away afer this :) 22:15
timotimo mhm, but that's still at least an index into the literals heap?
jnthn Well, we resolve the index at load time... 22:16
In the spesh case, though, we know for a given callsite what arg buffer location holds a given name.
So we can just use the unsafe sp_getarg_o
Which once we can JIT will probably end up being a few instructions... 22:17
timotimo which part am i going to optimize right now? the caller side or the callee side? 22:18
22:18 hoverboard left 22:19 lizmat_ joined
timotimo well, maybe not "going to", but "supposed to" :P 22:19
22:19 woolfy left 22:20 lizmat left
jnthn Well, it's the callee that's specialized 22:20
But the caller can have an instruction less per named arg it'll pass too after this.
timotimo oh, so we have a non-specializer-related opt, which is moving the argconst_s from the bytecode into the callsite storage 22:21
and after that, the specializer can continue specializing even if it sees named arguments, because it knows about the named parameters from the callsite 22:22
jnthn right
timotimo i'll have a further look into the code before i decide whether or not i'll take that off of your plate :) 22:23
22:23 lizmat_ left
timotimo do you have a comment on my uthash padding code? i'm not very confident in it, but i've patched all usages of HASH_ functions to decide whether or not padding is needed 22:23
unfortunately, it now crashes and burns almost immediately
22:25 lizmat joined
jnthn timotimo: It's hard to say at a casual glance... 22:25
timotimo: I'm a bit surprised to see modulo show up in there though. 22:26
timotimo well, it's three bytes of 0 and then one with data
but we have blocks that go up to 12 bytes
jnthn ah
hm
timotimo so i could either "if index == 3 || index == 7 || index == 11"
or use modulo
jnthn yeah, I'll need to look more closely. 22:27
22:27 rurban left
timotimo i went for the shorter code forn ow 22:27
jnthn I'm really uncofortable how the change leaks out in github.com/MoarVM/MoarVM/commit/846d59e8b2 too 22:28
timotimo yes.
so am i
didn't have a better idea yet
22:29 BenGoldberg joined
jnthn time for me to try and sleep...hopefully more than last night 22:32
o/
timotimo gnite and good luck!
oh, huh
if an arg is named, there's actually two args in the callsite and the first is the name and the second is the value, eh? 22:33
oh, no, it's not "in the callsite", it's passed along
i think i get it
22:33 jlaire left 22:34 mdiei left, rurban joined 22:35 bluescreen100 left 22:36 rurban1 joined 22:38 Ben_Goldberg joined, BenGoldberg left, Ben_Goldberg is now known as BenGoldberg 22:39 rurban left 22:42 thou left, dmol left 22:43 raiph left 22:45 denis_boyun___ left 22:48 jlaire joined
timotimo i seem to be somewhat tired as well 22:49
maybe i'll end up getting a decent sleep rhythm again if i get some sleep now? 22:50
lizmat as am I
yes, good rhythm is good
so good night, #perl6!
timotimo good rhythm lhyzmhat! :)
lizmat and you, timotimo timotimo timotimo :-) 22:51
22:53 kivutar left 23:04 DarthGandalf left 23:07 DarthGandalf joined 23:09 btyler left
timotimo i have found code that deserializes callsites from the bytecode file (apparently) and i've found a place in the byetcode verifier where it expects a named arg to be followed by its parameter 23:11
so these things i'll have to change. but i'm not seeing the code that writes out the callsites
23:18 FOAD left 23:19 FOAD joined 23:40 rurban1 left 23:47 cooper- joined 23:53 xenoterracide 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!