Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6, 2014-04-08

Perl 6 | Reference Documentation | Rakudo

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

All times shown according to UTC.

Time Nick Message
00:00 timo1 joined #perl6
00:01 beastd joined #perl6
00:05 bfulgham_ joined #perl6
00:06 timotimo http://t.h8.lv/p6bench/2014-04-08-spesh.html - got some graphs for y'all
00:06 timotimo did i really build these with spesh? :\
00:10 timotimo it seems like i did; it must be that the first few benchmarks hardly benefit from it
00:10 timotimo but forest fire already got a few percent faster
00:11 rurban joined #perl6
00:11 timotimo interesting to see is the apparent regression of for loops?
00:11 timotimo from 2014.02 to 2014.03
00:13 rurban1 joined #perl6
00:15 timotimo oh well.
00:15 xenoterracide joined #perl6
00:15 timotimo it's still pretty discouraging to see the performance difference between rakudo and nqp
00:21 timotimo oh, huh
00:21 timotimo didn't i have something i wanted to offer as low hanging fruit for the weekly this week?
00:24 timotimo still quite a lot of work to do in the optimization department then ...
00:24 timotimo that just means i'll have sufficient amounts of stuff to do in the coming time
00:30 autark joined #perl6
00:55 kbaker_ joined #perl6
00:59 autark joined #perl6
01:02 dayangkun_ joined #perl6
01:07 hoverboard joined #perl6
01:11 Ben_Goldberg joined #perl6
01:14 rurban joined #perl6
01:28 klapperl joined #perl6
01:36 bfulgham_ joined #perl6
01:41 havenwood joined #perl6
01:49 jnap joined #perl6
01:51 plobsing joined #perl6
01:56 btyler joined #perl6
01:57 jnap joined #perl6
02:01 Alula joined #perl6
02:05 raiph joined #perl6
02:07 thou joined #perl6
02:09 lustlife joined #perl6
02:15 rurban joined #perl6
02:25 rurban joined #perl6
02:28 xragnar_ joined #perl6
02:58 jnap joined #perl6
02:59 woosley joined #perl6
03:15 bfulgham_ joined #perl6
03:36 hoverboard joined #perl6
03:43 hoelzro joined #perl6
03:58 jnap joined #perl6
04:02 kaare_ joined #perl6
04:19 rurban joined #perl6
04:21 rurban1 joined #perl6
04:23 xenoterracide joined #perl6
04:23 pdcawley joined #perl6
04:30 Psyche^_ joined #perl6
04:31 eternaleye joined #perl6
04:59 jnap joined #perl6
05:11 dylanwh joined #perl6
05:15 SamuraiJack joined #perl6
05:17 kaare_ joined #perl6
05:23 kaleem joined #perl6
05:23 IllvilJa joined #perl6
05:23 rurban joined #perl6
05:26 telex joined #perl6
05:28 flussence joined #perl6
05:36 labster joined #perl6
05:52 darutoko joined #perl6
06:00 jnap joined #perl6
06:08 adu joined #perl6
06:16 autark joined #perl6
06:45 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:47 kaleem joined #perl6
06:53 eternaleye joined #perl6
07:01 jnap joined #perl6
07:08 zakharyas joined #perl6
07:12 Ven joined #perl6
07:16 Alula joined #perl6
07:20 denis_boyun_ joined #perl6
07:25 rurban joined #perl6
07:29 denis_boyun_ joined #perl6
07:42 dmol joined #perl6
07:48 fhelmberger joined #perl6
07:49 adu joined #perl6
08:00 kivutar joined #perl6
08:18 rurban joined #perl6
08:29 kivutar joined #perl6
08:29 WJB joined #perl6
08:38 brrt joined #perl6
08:49 dakkar joined #perl6
09:00 Alula joined #perl6
09:02 jnap joined #perl6
09:05 eiro joined #perl6
09:19 Rix joined #perl6
09:24 Alina-malina joined #perl6
09:47 ilbot3 joined #perl6
09:47 Topic for #perl6 is now »ö« Welcome to Perl 6! | http://perl6.org/ | evalbot usage: 'perl6: say 3;' or rakudo:,  niecza:, std:, or /msg camelia perl6: ... | irclog: http://irc.perl6.org | UTF-8 is our friend!
09:47 breinbaas joined #perl6
09:47 ivan`` joined #perl6
09:48 cognominal joined #perl6
09:49 Rix joined #perl6
09:49 revdiablo joined #perl6
09:49 telex joined #perl6
09:50 yeltzooo joined #perl6
09:51 Ulti joined #perl6
09:51 sivoais joined #perl6
09:51 ClarusCogitatio joined #perl6
09:52 aborazmeh joined #perl6
09:54 hoelzro joined #perl6
09:54 ponbiki joined #perl6
09:54 slavik joined #perl6
09:56 isacloud_ joined #perl6
09:56 japhb_ joined #perl6
09:57 mls joined #perl6
09:57 pnu joined #perl6
09:57 bcode joined #perl6
09:57 effbiai joined #perl6
10:00 Khisanth joined #perl6
10:00 lizmat it's windy today
10:00 rindolf joined #perl6
10:02 dalek roast: baf5685 | (Elizabeth Mattijsen)++ | S17-concurrency/lock.t:
10:02 dalek roast: Add a Thread/lock stress test
10:02 dalek roast:
10:02 dalek roast: Which so far fails all the time.  Not sure whether the test is ok.
10:02 dalek roast: review: https://github.com/perl6/roast/commit/baf56856eb
10:02 zacts joined #perl6
10:03 zakharyas joined #perl6
10:03 mkz joined #perl6
10:03 raydiak joined #perl6
10:03 rurban joined #perl6
10:03 isacloud_ joined #perl6
10:03 risou joined #perl6
10:03 japhb_ joined #perl6
10:03 rurban_ joined #perl6
10:04 woolfy joined #perl6
10:04 hugme joined #perl6
10:04 segomos joined #perl6
10:04 timotimo joined #perl6
10:05 denis_boyun joined #perl6
10:06 TimToady joined #perl6
10:08 sergot joined #perl6
10:12 rurban joined #perl6
10:15 tokuhirom joined #perl6
10:16 mkz joined #perl6
10:17 sorear joined #perl6
10:17 atrodo joined #perl6
10:19 dylanwh joined #perl6
10:23 Alula joined #perl6
10:26 Ven joined #perl6
10:26 masak joined #perl6
10:27 frettled joined #perl6
10:27 jtpalmer joined #perl6
10:27 xragnar joined #perl6
10:27 amkrankruleuen joined #perl6
10:27 amkrankruleuen joined #perl6
10:27 Celelibi joined #perl6
10:27 SamuraiJack joined #perl6
10:27 sjn joined #perl6
10:27 jercos joined #perl6
10:27 dakkar joined #perl6
10:27 jnthn joined #perl6
10:27 yves__ joined #perl6
10:27 renormalist joined #perl6
10:27 vendethiel joined #perl6
10:27 larks joined #perl6
10:27 crazedpsyc joined #perl6
10:27 bjz joined #perl6
10:27 yeltzooo joined #perl6
10:27 xinming_ joined #perl6
10:27 lue joined #perl6
10:27 effbiai joined #perl6
10:27 baest joined #perl6
10:27 Exodist joined #perl6
10:27 nebuchadnezzar joined #perl6
10:27 Tene joined #perl6
10:27 Rounin joined #perl6
10:27 rjbs joined #perl6
10:27 yoleaux joined #perl6
10:27 apejens joined #perl6
10:27 retupmoca joined #perl6
10:27 colomon joined #perl6
10:27 [particle] joined #perl6
10:27 Tene joined #perl6
10:27 huf joined #perl6
10:27 FROGGS joined #perl6
10:27 aindilis joined #perl6
10:27 Woodi joined #perl6
10:27 mtk joined #perl6
10:27 Pleiades` joined #perl6
10:27 japhb_ joined #perl6
10:27 markov joined #perl6
10:27 eternaleye joined #perl6
10:27 Alina-malina joined #perl6
10:28 camelia joined #perl6
10:28 japhb_ joined #perl6
10:28 mtj_ joined #perl6
10:28 woosley joined #perl6
10:28 araujo joined #perl6
10:29 jnthn lizmat: fails all the time on just Moar?
10:29 jnthn lizmat: If it fails on JVM too it's probably the test.
10:29 flussence joined #perl6
10:30 brother joined #perl6
10:30 Juerd joined #perl6
10:30 ggherdov_ joined #perl6
10:32 cibs joined #perl6
10:32 arnsholt joined #perl6
10:34 JimmyZ joined #perl6
10:35 dalek ecosystem: cb659e0 | dagurval++ | META.list:
10:35 dalek ecosystem: Added WebService::Justcoin
10:35 dalek ecosystem: review: https://github.com/perl6/ecosystem/commit/cb659e0bb6
10:39 masak_ joined #perl6
10:39 cxreg joined #perl6
10:39 klapperl joined #perl6
10:39 jtpalmer joined #perl6
10:39 hummeleBop1 joined #perl6
10:39 rindolf joined #perl6
10:39 Psyche^ joined #perl6
10:40 xragnar joined #perl6
10:40 daxim_ joined #perl6
10:40 frettled joined #perl6
10:40 effbiai joined #perl6
10:40 kaleem joined #perl6
10:40 autark joined #perl6
10:40 prammer joined #perl6
10:40 integral joined #perl6
10:40 baest joined #perl6
10:40 integral joined #perl6
10:40 dalek joined #perl6
10:40 amkrankruleuen joined #perl6
10:40 amkrankruleuen joined #perl6
10:40 [particle] joined #perl6
10:40 kivutar joined #perl6
10:40 salv0 joined #perl6
10:40 lestrrat joined #perl6
10:40 slavik joined #perl6
10:45 dagurval joined #perl6
10:47 Alula joined #perl6
10:58 yogan joined #perl6
10:59 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 labster joined #perl6
11:00 Alula joined #perl6
11:00 lizmat I'm not completely sure the code is ok, but then again, Lock.condition and the ConditionVariable class ate not specced
11:01 lizmat so speccially, (as opposed to technically), I'm not sure what they should do
11:02 lizmat commuting&
11:09 kurahaupo joined #perl6
11:10 markov left #perl6
11:14 timotimo o/
11:16 timotimo jnthn: that's a good point that i hadn't considered!
11:17 pecastro joined #perl6
11:19 woolfy left #perl6
11:20 jnthn lizmat: They ain't spec'd yet, but they have the semantics you'd expect condvars to have anywhere.
11:20 jnthn (provided you have an expectation ;))
11:21 jnthn timotimo: While my students do exercises I've been looking at some of the benchmarks and the code they call.
11:21 jnthn timotimo: The worst offender is the push one
11:21 xragnar joined #perl6
11:22 jnthn Which is 2000 times slower o.O
11:22 jnthn Then I found why: we always slurpy push
11:22 jnthn Even for the single value case.
11:22 jnthn I'll probably fix that one tonight.
11:22 jnthn The other huge pain point that makes assigning to arrays and hashex expensive is:
11:22 jnthn %h<a> = 42;
11:23 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.
11:23 timotimo oh! oof! :)
11:23 jnthn timotimo: yes, and in push @a, ...; push sub is slurpy and so is push method!
11:24 jnthn Anyway, the whence the triggers the lambda and binds ths scalar
11:24 jnthn But if we know full well we're going to be assigning...which we often can syntactically, that is an insane amount of overhead.
11:24 timotimo ah, i get it now
11:25 jnthn The reason for all this is that:
11:25 jnthn r: my $a := %h<a>; say %h<a>:exists; $a = 42; say %h<a>:exists;
11:25 timotimo it's all autoviv
11:25 camelia rakudo-jvm 2b8977: OUTPUT«(timeout)»
11:25 camelia ..rakudo-parrot 2b8977, rakudo-moar 2b8977: OUTPUT«[31m===[0mSORRY![31m===[0m Error while compiling /tmp/tmpfileâ�¤Variable '%h' is not declaredâ�¤at /tmp/tmpfile:1â�¤------> [32mmy $a := %h<a>[33mâ��[31m; say %h<a>:exists; $a = 42; say %h<a>:e[0mâ�¤    expecting any of:â�¤   …»
11:26 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␤»
11:26 timotimo oh!
11:26 jnthn That has to work.
11:26 jnthn But that's *not* the common case
11:26 timotimo yeah, that's certainly something you don't see that often
11:26 jnthn But we pessimize every darn thing.
11:26 timotimo that's what we do :)
11:26 timotimo it may seem easy to syntactically find out, but how do we signal it downwards?
11:27 timotimo also, will the same kind of depessimization help slurpy assignments like %h<a b c> = 1, 2, 3?
11:28 jnthn I'm pondering how to do it
11:29 jnthn I know full well whatever I come up with, Pm and/or TimToady probably won't like it.
11:29 jnthn We already ahve a bind_key and bind_pos; I'm tempted to do assign_keya nd assign_pos...
11:29 timotimo that's new public api?
11:30 jnthn I guess they would be, yeah :S
11:30 jnthn I think we can't afford to not do something like this, though.
11:32 timotimo it'll definitely give us a nice speed boost in the general case
11:34 dalek rakudo-star-daily: bb44ecd | coke++ | log/ (5 files):
11:34 dalek rakudo-star-daily: today (automated commit)
11:34 dalek rakudo-star-daily: review: https://github.com/coke/rakudo-star-daily/commit/bb44ecdad5
11:41 daniel-s_ joined #perl6
11:45 jnthn Overall, I plan to make a pass through CORE.setting and look carefully at the bytecode we're generating
11:45 jnthn For each of the benchmarks.
11:47 jnthn Finishing up multispec will also help.
11:48 nwc10 what's multispec?
11:50 [Coke] we're having enough trouble with a monospec!
11:51 jnthn nwc10: In a multi-dispatch we currently always make a call tot he proto first
11:51 jnthn nwc10: If the proto simply says "look in the cache", then that's a huge waste of a callframe and other things.
11:52 jnthn 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
11:52 jnthn So it can completely skip that.
11:52 nwc10 which will benefit all 3 backends?
11:52 nwc10 oh, how is the JS backend work?
11:52 jnthn Well, in the case of things like infix:<+>, I think the proto is at least as costly as the operation itself.
11:53 jnthn It needs to be implemented per backend...
11:53 nwc10 yes, but how often do we call + :-)
11:53 jnthn I'll likely also do it for JVM.
11:53 jnthn Somebody else can take care of it for Parrot if they want things faster there.
11:55 jnthn guess we can PIC it on the two also
11:56 jnthn to abuse the term PIC a little :)
11:56 timotimo i don't know what that term means :(
12:00 [Coke] position independent code?
12:04 nwc10 aha
12:04 nwc10 Polymorphic Inline Cache
12:06 jnthn yes, that
12:06 jnthn findmethod calls after spesh either are resolved statically or get a monomorphic cache
12:07 jnthn We use such a technique on JVM too.
12:07 timotimo ah, yes
12:08 nwc10 who is doing Star this month?
12:08 jnthn I'm pondering a similar inline cache for multi-dispatch.
12:08 timotimo hmm, spesh is not far-reaching enough to help any with the hash assignment problem, aye?
12:08 timotimo because it doesn't inline?
12:08 jnthn timotimo: I dunno if it can ever really be in general.
12:08 jnthn It's not just inlining, it's a lot of things.
12:09 timotimo mhm
12:09 timotimo it'd be a complicated pattern to match against
12:09 jnthn The mere presence of the closure prevents compile-time lex to loc of self and so forth
12:09 timotimo ah
12:09 jnthn You'd need to thus teach spesh to also do such things
12:10 timotimo anything more simple you could offload onto me for today? :)
12:10 timotimo oh, and what invocation did you use to figure out what exact bytecodes were called? moarvm --dump?
12:10 jnthn yeah but I'm actually reading the spesh log
12:10 jnthn cus it tells me the bytecode on hot paths for free :)
12:11 timotimo ah :)
12:11 timotimo well ... "hot" :)
12:11 jnthn more hot than not :)
12:11 SamuraiJack joined #perl6
12:11 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?
12:11 jnthn So we can lower and spesh the grammar rules?
12:13 timotimo no :|
12:13 timotimo i had absolutely no clue where to look for the cause of the problem
12:15 Alula joined #perl6
12:16 kaare_ joined #perl6
12:17 isacloud_ joined #perl6
12:20 tokuhirom joined #perl6
12:20 atrodo joined #perl6
12:21 zakharyas joined #perl6
12:21 rurban_ joined #perl6
12:21 dylanwh joined #perl6
12:21 flussence joined #perl6
12:22 sorear joined #perl6
12:22 japhb_ joined #perl6
12:23 daniel-s_ joined #perl6
12:26 mkz joined #perl6
12:27 araujo joined #perl6
12:27 araujo joined #perl6
12:40 xenoterracide joined #perl6
12:41 kbaker_ joined #perl6
12:57 guru joined #perl6
13:01 rurban joined #perl6
13:15 raiph joined #perl6
13:28 jnthn timotimo: ah, ok...
13:28 jnthn Guess I'll have to look at that then.
13:29 jnthn timotimo: adding a single-item candidate to sub push shoiuld be eas to do and test
13:30 jnthn multi sub push(@a, \thing) { @a.push(thing) }
13:30 jnthn unshift too
13:40 benabik joined #perl6
13:41 thou joined #perl6
13:54 btyler joined #perl6
14:02 rurban joined #perl6
14:11 jnap joined #perl6
14:13 sftp joined #perl6
14:19 PZt joined #perl6
14:21 rurban joined #perl6
14:22 geekosaur joined #perl6
14:32 jnap joined #perl6
14:36 thilp joined #perl6
14:41 treehug88 joined #perl6
14:42 virtualsue joined #perl6
14:45 Bucciarati joined #perl6
14:45 Timbus joined #perl6
14:45 Goodbox joined #perl6
14:45 pdcawley joined #perl6
14:45 TimToady joined #perl6
14:45 Yappo__________8 joined #perl6
14:46 darutoko joined #perl6
14:47 bluescreen10 joined #perl6
14:48 simcop2387 joined #perl6
14:48 ribasushi joined #perl6
14:48 mathw joined #perl6
14:48 anocelot joined #perl6
14:49 mhasch joined #perl6
14:49 dmol joined #perl6
14:49 gtodd joined #perl6
14:49 brrt joined #perl6
14:50 go|dfish joined #perl6
14:50 Vlavv joined #perl6
14:50 nwc10 joined #perl6
14:50 cosimo joined #perl6
14:51 sjohnson joined #perl6
14:51 takesako____ joined #perl6
14:55 mls joined #perl6
14:56 dotuser joined #perl6
14:58 kaare_ joined #perl6
14:59 lustlife joined #perl6
15:05 guru joined #perl6
15:16 cognominal it seems that rakudo build twice as fast using spesh
15:17 falk0n joined #perl6
15:18 benabik Woo!
15:20 salv0 joined #perl6
15:21 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:43 lustlife joined #perl6
15:45 perigrin joined #perl6
15:46 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:47 cognominal indeed, but it was two minutes not long ago, so I don't know what made the difference.
15:49 cognominal at least, mesh machinery did not slowed it down  :)
15:49 ldthien0 joined #perl6
15:52 bfulgham_ joined #perl6
15:53 xinming_ joined #perl6
15:58 ldthien0 joined #perl6
16:03 ribasushi joined #perl6
16:03 ribasushi joined #perl6
16:04 dalek rakudo/nom: 9eaf468 | jonathan++ | src/core/List.pm:
16:04 dalek rakudo/nom: Greatly cheapen single-item push/unshift subs.
16:04 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/9eaf4682dc
16:04 ribasushi joined #perl6
16:04 ribasushi joined #perl6
16:05 ribasushi joined #perl6
16:05 ribasushi joined #perl6
16:05 kurahaupo joined #perl6
16:06 ribasushi joined #perl6
16:06 ribasushi joined #perl6
16:07 ribasushi joined #perl6
16:07 ribasushi joined #perl6
16:08 ribasushi joined #perl6
16:08 ribasushi joined #perl6
16:09 ribasushi joined #perl6
16:09 ribasushi joined #perl6
16:11 rurban joined #perl6
16:12 hoverboard joined #perl6
16:13 ribasushi joined #perl6
16:19 ribasushi joined #perl6
16:19 ribasushi joined #perl6
16:24 timotimo oh, i seem to have been under the impression that the methods were also pessimized for single element pushes/unshifts
16:25 jnthn timotimo: They are, but that's a harder fix, so I picked the easy thing first. :)
16:25 timotimo ah!
16:25 timotimo but the improvement stacks?
16:26 denis_boyun_ joined #perl6
16:26 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 guru joined #perl6
16:27 JimmyZ Was accessor methods inlined yet? :)
16:27 timotimo we don't inline methods yet
16:28 jnthn timotimo: Yes, the improvements will stack
16:28 [Coke] jnthn++
16:30 spider-mario joined #perl6
16:31 timotimo jnthn: would you be okay with me implementing eqaddr on known values?
16:31 timotimo that opcode is the result of the "unless $value =:= NO_VALUE" things we have in the accessors
16:33 jnthn timotimo: Yeah, I'm totally fine with that, but I *think* we may be missing one thing for it to trigger
16:33 jnthn timotimo: But I totally forget what, so try it :)
16:33 timotimo hehe.
16:35 * jnthn thinks he just made @a eqv @b about 3 times faster
16:35 timotimo \o/
16:38 ribasushi joined #perl6
16:38 jnthn Mighta got several percent improvement on each .new too
16:38 jnthn for the defualt candidate anyway
16:39 thien joined #perl6
16:39 bjz joined #perl6
16:40 spider-mario joined #perl6
16:46 ribasushi joined #perl6
16:46 dalek rakudo/nom: 6b80fe2 | jonathan++ | src/core/Mu.pm:
16:46 dalek rakudo/nom: Optimize new's delegation to make it cheaper.
16:46 dalek rakudo/nom:
16:46 dalek rakudo/nom: Saves around 5% off Foo.new.
16:46 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/6b80fe2645
16:46 dalek rakudo/nom: 3e609e0 | jonathan++ | src/core/Mu.pm:
16:46 dalek rakudo/nom: Make @a eqv @b around 3 times faster.
16:46 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/3e609e0c43
16:46 dalek rakudo/nom: 29bc5f6 | jonathan++ | src/core/Any.pm:
16:46 dalek rakudo/nom: Use = in auto-viv, not &infix:<=>.
16:46 dalek rakudo/nom:
16:46 dalek rakudo/nom: The latter forces a sub call; the former is compiled inline.
16:46 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/29bc5f6cbd
16:49 timotimo was &infix:<=> used to work around some kind of bug perhaps?
16:50 ribasushi sorry for the annoying joinflood earlier
16:50 ribasushi fixed now
16:50 vendethiel yay !
16:50 vendethiel that's a lot
16:51 jnthn timotimo: Maybe, but it's a gone bug now
16:52 jnthn At least, so says spectest
16:52 timotimo very well
16:53 denis_boyun___ joined #perl6
16:55 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:56 telex joined #perl6
16:58 timotimo fwiw, my desktop is down to 38.7 seconds for stage parse on moar :)
16:59 timotimo 1:32 for a whole make m-install after a clean
17:04 kurahaupo_mobile joined #perl6
17:08 Guest59041 joined #perl6
17:12 bluescreen100 joined #perl6
17:17 cognominal joined #perl6
17:19 rindolf joined #perl6
17:19 a3gis joined #perl6
17:21 dalek rakudo/nom: dd1f4fa | jonathan++ | src/core/Any.pm:
17:21 dalek rakudo/nom: Add non-slurping candidates for various list subs.
17:21 dalek rakudo/nom:
17:21 dalek rakudo/nom: Prevent an extra layer of wrapping, and way more likely to inline. For
17:21 dalek rakudo/nom: map on a 5-element list in a loop, around a 5% saving.
17:21 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/dd1f4fad6b
17:21 dalek rakudo/nom: ad962d0 | jonathan++ | src/core/ (3 files):
17:21 dalek rakudo/nom: Optimize coercion to Order enum.
17:21 dalek rakudo/nom:
17:21 dalek rakudo/nom: In the long run, it'd be good to emit better code for coercion to an
17:21 dalek rakudo/nom: enum type. For now, this hot-paths it in cmp and <=>, which are used
17:21 dalek rakudo/nom: in a whole range of operations. Knocked 15% off a sort benchmark.
17:21 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/ad962d0aa2
17:21 dalek rakudo/nom: b37ef4f | jonathan++ | src/core/Any.pm:
17:21 dalek rakudo/nom: Micro-opt on sort sub.
17:21 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/b37ef4fbf4
17:22 vendethiel Optimization time o/
17:23 timotimo ah, i remember what the LHF was i wanted to put into the p6weekly
17:30 havenwood joined #perl6
17:39 colomon jnthn++
17:40 raiph left #perl6
17:40 raiph joined #perl6
17:40 Rotwang joined #perl6
17:40 guru joined #perl6
17:41 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:42 jnthn japhb: optional $sep parameter cannot be followed by slurpy
17:42 jnthn japhb: Though, could find another way :)
17:45 jnthn The array/hash slicing code really, really needs an optimization pass now it's had a correctness one :)
17:48 japhb jnthn: I was thinking: multi join($sep, @values)
17:48 japhb Yeah, I believe that!
17:49 * timotimo recently did some informal performance measurements in that area and really has to concur
17:50 jnthn japhb: oh, yeah...duh :)
17:51 [Coke] jnthn++ again
17:51 jnthn japhb: Adding it
17:51 * jnthn slept awfully last night, taught all day, and so isn't the sharpest two short planks in the jar tonight... :P
17:52 * jnthn spectests a few more changes
17:54 japhb "sharpest two short planks in the jar" -- well that's ... evocative.  :-)
17:54 * timotimo benchmarks the recent rakudo optimizations
17:55 jnthn hehe
17:56 jnthn I should probably get some dinner :)
18:00 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
18:01 timotimo i'm still not quite getting why the "please do at least 3 runs in every case" code didn't work out
18:01 timotimo it's quite annoying to only see a single data point for the rakudos for example for the parse-json benchmark
18:03 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 japhb timotimo: Hmmm, I'd have to go spelunking again to figure out what went wrong there.
18:03 japhb Maybe if I can get a little time later, that would be nice.
18:04 japhb (nice to work on, I mean)
18:04 timotimo i would like that, thanks!
18:04 xinming__ joined #perl6
18:05 jnthn going for dinner...bbl
18:14 ajr_ jnthn appears to be going for a world record in metaphor-garbling; that's >= 3 in 7 words. :-)*
18:16 timotimo ajr_: so *that*'s why that idiom seemed foreign to me!
18:19 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:21 timotimo thanks for clearing that up :)
18:29 falk0n left #perl6
18:46 cognominal joined #perl6
18:50 dwarring joined #perl6
18:52 mattp__ joined #perl6
19:03 rurban joined #perl6
19:15 thou joined #perl6
19:15 a3gis_ joined #perl6
19:17 vendethiel .u 0x2297
19:17 yoleaux No characters found
19:17 vendethiel .u 2297
19:17 yoleaux U+2297 CIRCLED TIMES [Sm] (⊗)
19:20 [particle] joined #perl6
19:25 timotimo ⊕_⊕
19:25 timotimo http://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
19:26 timotimo man, our empty for loops have some significant catching up to do
19:30 jnthn timotimo: Well, the others came more from me looking through CORE.setting rather than analizing the benchmarks
19:30 jnthn *analyzing
19:30 lizmat joined #perl6
19:32 dalek rakudo/nom: 5d74bce | jonathan++ | src/core/Int.pm:
19:32 dalek rakudo/nom: Further optimization of postfix ++ and --.
19:32 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/5d74bce579
19:32 timotimo yeah, that's fine ;)
19:33 timotimo i had expected to see a good difference in the bigger benchmarks, though
19:33 timotimo forest fire in particular
19:33 vendethiel jnap: what are those # XXX for ?
19:34 * lizmat has arrived in Zürich and is pleasantly surprised by jnthn++ avalanche of commits today
19:35 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 ;)
19:36 jnthn timotimo: Yeah, at least somewhat. We don't flatten the block in.
19:36 jnthn timotimo: There is an opt for that, but it's level 3.
19:38 timotimo i run rakudo-moar with --optimize=3 in the benchmarks
19:38 jnthn ah
19:38 jnthn and yeah, it makes a small difference
19:38 jnthn So the cost is elsewhere
19:39 jnthn In Perl 5, iiuc, when you do:
19:39 jnthn for (my $i = 1; $i < 100000; $i++ { }
19:39 jnthn Then $i is allocated once, and you're fiddling wiht the same scalar
19:40 jnthn Whereas in Perl 6 that is a scalar that gets ++'d creating a new Int each time.
19:40 timotimo oh, i see
19:41 jnthn So if we want to get the same we need to work out that we're allowed to cheat :)
19:41 jnthn Not having to support binding *and* assignment turns out to be rather useful.
19:41 jnthn Perl 6 wants both so...we have "fun"
19:45 dalek roast: 6dd6ced | (David Warring david.warring@gmail.com)++ | integration/advent2013-day2 (2 files):
19:45 dalek roast: adding advent 2013 days 22 & 23
19:45 dalek roast: review: https://github.com/perl6/roast/commit/6dd6ced135
19:46 lizmat dinner&
19:54 isBEKaml joined #perl6
20:03 pippo joined #perl6
20:04 pippo Hi perl6!
20:04 vendethiel o/
20:04 PerlJam hello pippo
20:05 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«[31m===[0mSORRY![31m===[0m Error while compiling /tmp/pViob_i21Zâ�¤Variable '$b' is not declaredâ�¤at /tmp/pViob_i21Z:1â�¤------> [32m$b[33mâ��[31m=0; my @a; for ^10_000 {@a[$_]=[0,1]}; s[0mâ�¤    expecting any of:â�¤        postfixâ�¤Â»
20:05 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␤»
20:06 pippo m: my $b=0; my @a; for ^10_000 {@a[$_]="1,2".split(',')}; say time; for ^10_000 {$b+=@a[$_][1]}; say time;
20:06 camelia rakudo-moar b37ef4: OUTPUT«(timeout)1396987604␤»
20:07 pippo ^^anybody know why this takes so much time??
20:08 vendethiel creating an array for 2 elems and splitting a string?
20:08 PerlJam pippo: at a guess, all the memory allocations
20:09 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
20:09 * 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
20:09 camelia rakudo-moar b37ef4: OUTPUT«1396987747␤1396987747␤10000␤»
20:09 flussence okay, so it's not just optimising that out...
20:11 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 perl6-roast-data: 0fd5db1 | coke++ | / (6 files):
20:11 dalek perl6-roast-data: today (automated commit)
20:11 dalek perl6-roast-data: review: https://github.com/coke/perl6-roast-data/commit/0fd5db10f7
20:14 pippo So when the first "say time" is executed @a is not yet constructed?
20:15 timotimo ... huh?
20:15 timotimo in which code exactly?
20:15 vendethiel pippo: trick =>
20:15 vendethiel r: say time - BEGIN time
20:15 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)␤␤»
20:15 camelia ..rakudo-parrot b37ef4, rakudo-moar b37ef4: OUTPUT«0␤»
20:16 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;
20:16 vendethiel r: my int $i = 0; for ^100000 { $i += $u }; say time - BEGIN time;
20:16 camelia rakudo-parrot b37ef4, rakudo-moar b37ef4: OUTPUT«[31m===[0mSORRY![31m===[0m Error while compiling /tmp/tmpfileâ�¤Variable '$u' is not declaredâ�¤at /tmp/tmpfile:1â�¤------> [32mmy int $i = 0; for ^100000 { $i += $u[33mâ��[31m }; say time - BEGIN time;[0mâ�¤    expecting any …»
20:16 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)␤␤»
20:17 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␤␤»
20:17 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)␤␤»
20:17 camelia ..rakudo-parrot b37ef4: OUTPUT«Cannot modify an immutable value␤  in block  at gen/parrot/CORE.setting:17045␤  in block  at /tmp/tmpfile:1␤␤»
20:17 vendethiel r: my int $i = 0; for ^100000 { $i = $i + $_ }; say time - BEGIN time; # forgot that ..
20:17 camelia rakudo-parrot b37ef4: OUTPUT«3␤»
20:17 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)␤␤»
20:17 camelia ..rakudo-moar b37ef4: OUTPUT«0␤»
20:17 [Coke] (if you don't need all of rakudo, just use p or m)
20:18 pippo vendethiel: I did not want to time all the proggy. Just the last for cycle part. :-)
20:19 pippo vendethiel: I did not want to time all the proggy. Just the last "for" loop part. :-)
20:22 timotimo also, BEGIN is when the parser hits the code, CHECK is after all code has been compiled
20:23 timotimo 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:24 pippo timotimo: any clue on why when I construct the array with split it takes an eternity?
20:25 hoverboard joined #perl6
20:25 flussence something is seriously broken there actually... I've been letting that line of code run for several minutes now.
20:26 pippo flussence: I also think so.
20:27 timotimo hum.
20:29 kbaker joined #perl6
20:31 mdiei joined #perl6
20:31 moritz pippo: try to split on rx/\,/ instead
20:32 pippo moritz: sorry. How?
20:32 timotimo i can get 100_000 times the split and put stuff into the array in 45 seconds
20:33 moritz pippo: .split(rx/\,/) instead of .split(',')
20:34 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.
20:34 pippo moritz: trying
20:35 pippo moritz: trying...
20:35 flussence having said that, the first loop takes some indefinite amount of time in perl6-p too...
20:36 flussence (only 8s in moar)
20:38 jnthn so, I'm re-writing Str.split taking a string delim...
20:38 kivutar joined #perl6
20:40 pippo moritz: it is immensly faster!! Thank you! How did you know?
20:40 virtualsue joined #perl6
20:41 flussence there's only two code paths to choose from there :)
20:45 moritz pippo: split compiles the separator into a regex internally
20:45 moritz pippo: and that's slow
20:45 timotimo well, it's only slow because it does that every time anew :)
20:45 moritz aye
20:46 jnthn uh, the split I'm looking at doesn't...
20:47 moritz oh
20:47 moritz then the regex version is much faster than the Cool version :/
20:47 moritz and my information likely comes from an outdated version
20:48 PerlJam So ... how does this affect the *second* loop?
20:49 moritz does it?
20:49 moritz somehow I read conflicting statements
20:49 PerlJam Assuming pippo's statement is accurate ... <pippo> timotimo: th block that takes time is not the array construction but array manipulation one
20:49 dalek roast: fe727fc | (David Warring david.warring@gmail.com)++ | integration/advent2013-day22.t:
20:49 dalek roast: typo
20:49 dalek roast: review: https://github.com/perl6/roast/commit/fe727fc4ab
20:49 timotimo right. good question.
20:50 moritz r: say 'a,b'.split(',').^name
20:50 camelia rakudo-parrot 5d74bc, rakudo-jvm 5d74bc, rakudo-moar 5d74bc: OUTPUT«List␤»
20:50 moritz m: say 'a,b'.split(rx/\,/).^name
20:50 camelia rakudo-moar 5d74bc: OUTPUT«List␤»
20:52 Alula joined #perl6
20:54 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:55 pippo moritz: with your suggestion my CSV manipulation program went from 20 min to 2 min to execute !! Yep! :-)
20:57 pippo moritz: ty.
20:58 PerlJam Here's what I get on my computer: https://gist.github.com/perlpilot/10191112
20:59 sergot night night! o/
21:00 PerlJam (that's Moar btw)
21:02 PerlJam though perl6-j appears to exhibit the same behavior
21:04 pippo PerlJam: Nice! Also here on perl6-{j,m}
21:09 jnthn r: say "".split(':')
21:09 camelia rakudo-parrot 5d74bc, rakudo-jvm 5d74bc, rakudo-moar 5d74bc: OUTPUT«␤»
21:09 jnthn r: say "".split(':').perl
21:09 camelia rakudo-parrot 5d74bc, rakudo-jvm 5d74bc, rakudo-moar 5d74bc: OUTPUT«("",).list␤»
21:13 PerlJam pippo: btw, are you actually using Text::CSV?
21:13 lizmat joined #perl6
21:13 pippo PerlJam: Nope. Is it fast?
21:13 woolfy joined #perl6
21:14 PerlJam Dunno how fast it is comparatively.  I just thought you should know about it if you didn't :)
21:15 pippo PerlJam: Thank you. I'll try it on my next proggy :-))
21:22 mdiei hello from finland
21:22 mdiei hows monks doing
21:26 timotimo hm?
21:30 jnthn pippo, PerlJam: I've now got a version here where https://gist.github.com/perlpilot/10191112 runs faster with Version A than Version B. :)
21:31 jnthn spectesting at the moment
21:33 pippo jnthn: \o/ !!!
21:34 pippo jnthn: jnthn++
21:37 raiph joined #perl6
21:39 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␤»
21:39 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 :-(
21:39 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␤␤»
21:39 camelia ..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␤␤»
21:39 camelia ..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␤␤»
21:40 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:41 jnthn lizmat: So it leaves it to runtime and calls it with the boxed Int instead.
21:41 jnthn And that doesn't match int/uint in a multi-dispatch.
21:41 jnthn Otherwise in int vs. Int we'd never reach the Int one.
21:41 lizmat hmmm...
21:42 lizmat 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␤»
21:43 dalek rakudo/nom: da1ef6e | jonathan++ | src/core/Str.pm:
21:43 dalek rakudo/nom: Optimize split on a literal string.
21:43 dalek rakudo/nom:
21:43 dalek rakudo/nom: Use native str/int and nqp:: ops to get something of a speedup. Also,
21:43 dalek rakudo/nom: don't use an infinite range, since that makes evaluation of the map
21:43 dalek rakudo/nom: too lazy, causing other performance issues.
21:43 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/da1ef6e545
21:43 lizmat but uint / Int MMD works apparently
21:43 woolfy joined #perl6
21:43 jnthn lizmat: Yeah, though...I worry it's by accident ;)
21:43 pippo jnthn: pulling...
21:44 jnthn pippo: Hopefully it helps a bit.
21:44 jnthn I'm still not too happy with it.
21:44 lizmat jnthn: I could try and run a spectest
21:44 jnthn But should be an improvement.
21:44 jnthn lizmat: spectest on...?
21:44 pippo jnthn: I'll test it immeditly and let you how it is here :-)
21:44 lizmat creating a uint / Int candidates for []
21:45 jnthn crazedpsyc: We already have an int candidate afaik
21:45 jnthn oops
21:45 jnthn lizmat: ^^
21:45 jnthn how on earth did I end up with a c instead of an l...
21:45 lizmat well, if we change the int candidate to a uint, then the negative indexes would be caught by the generic Num case
21:46 lizmat and bomb there, while the simple [0] cases would not need to check whether the index is < 0
21:46 jnthn They...won't.
21:47 lizmat ??
21:47 jnthn int and uint are currently treated identically
21:47 jnthn uint isn't really implemented in general; it's only really native arrays that know what to do wiht it.
21:48 jnthn 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 ?
21:48 camelia rakudo-moar 5d74bc: OUTPUT«int -42␤unsigned 42␤»
21:48 jnthn You so don't want to know. :)
21:48 jnthn 42 as a literal is alomorphic
21:49 jnthn The - defeats that and leaves us with an Int, so far as the optimizer is concerned.
21:49 jnthn At present, the only way you ever reach a native multi candidate is if the dispatch is resolved at compile time.
21:50 jnthn Worse, it's done in the optimizer.
21:50 lizmat but, it the negative indexes are caught at run time
21:50 pippo jnthn: lightning fast! Thank you!! :-))
21:50 jnthn Hm, that may not actually be true...
21:51 jnthn m: multi a (uint $a) { say "oops" }; my int $x = -5; a($x)
21:51 camelia rakudo-moar 5d74bc: OUTPUT«oops␤»
21:52 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 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␤»
21:52 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.
21:53 lizmat ack, got you now
21:53 lizmat so for now, we still need the <0 check in the int candidate, because of the [$x] case
21:53 jnthn The whole area is really...icky. Especially as we probably shoudln't be sending $a + $b to the (int, int) candidate
21:54 jnthn unless a pragma is in force
21:54 jnthn Generally, we do about enough that native ints are worth using if you're careful.
21:55 jnthn And can be a notable speedup.
21:55 jnthn Same with num.
21:55 jnthn But it's sure as heck not polished.
21:56 lizmat ack, got ya
21:57 jnthn The thing that really needs opt in that area is basic array and hash assignment, though.
21:58 lizmat Files=801, Tests=31033, 189 wallclock secs ( 8.18 usr  3.58 sys + 1257.33 cusr 90.99 csys = 1360.08 CPU)
21:59 lizmat that is significantly down from 200+ wallclock yesterday!
21:59 jnthn \o/
21:59 lizmat that's at least a 5% improvement!
21:59 lizmat wow!
21:59 jnthn Yeah, it's faster on my laptop too :)
21:59 jnthn Down from 464 to 443
21:59 jnthn Poor thing only has 2 cores.
21:59 jnthn Well, 2 physical, 4 virtual.
22:01 jnthn Anyway, we almost got you a 3 minute spectest :)
22:01 lizmat yup
22:01 lizmat what's even better: running a spectest on parrot in the day, would cost me 20% of my battery
22:02 lizmat now it's down to something like 5%
22:02 jnthn :)
22:02 jnthn How fast is the core setting build for you, ooc?
22:04 lizmat 1:10 last I checked
22:04 jnthn oh
22:05 jnthn 51.67s on my laptop for the lot
22:05 lizmat hmmm....
22:05 jnthn 81.59s for full Rakudo build.
22:07 pippo good night perl6!
22:07 jnthn oh, but I was running with spesh
22:07 pippo exit
22:08 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 timotimo so that perhaps spesh or jit will be able to remove checks like "is the index < 0 here?"
22:08 timotimo i think that needs either inlining or more facts known at the callsite
22:08 jnthn Just did it without. 53.90s for CORE.setting and 84.63s for the whole build.
22:09 lizmat real1m40.408s
22:09 lizmat user1m38.560s
22:09 lizmat sys0m1.563s
22:09 jnthn r: say 51.67 / 53.90
22:09 lizmat for the whole build
22:09 camelia rakudo-parrot 5d74bc, rakudo-jvm 5d74bc, rakudo-moar 5d74bc: OUTPUT«0.958627␤»
22:09 jnthn r: say 81.59 / 84.63
22:09 camelia rakudo-parrot 5d74bc, rakudo-jvm 5d74bc, rakudo-moar 5d74bc: OUTPUT«0.964079␤»
22:09 lizmat I guess that jnthn has fewer but faster CPU's
22:09 jnthn i7 :)
22:10 jnthn 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 #perl6
22:11 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?
22:11 jnthn yeah
22:12 jnthn We need to get the names made part of the callsite.
22:12 jnthn It's mildly tricky.
22:12 jnthn But not awfully bad.
22:13 jnthn lizmat: 2.9 :)
22:13 timotimo will that just be a MVMString **?
22:13 lizmat that explains then  :-)
22:13 jnthn timotimo: After bytecode loading, I guess yes
22:13 jnthn 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
22:14 timotimo oh, of course, the callsites are in the mbc file
22:14 jnthn timotimo: Well, callsites are one segment of the mbc file, which is all handled in bytecode.c.
22:14 lizmat also, I'm running on battery now, so probably not getting overclocked
22:14 jnthn There is one other nice consequence of this refactor, btw.
22:14 jnthn Right now if you call, say, foo(bar => baz)
22:14 jnthn Then it's a
22:15 jnthn prepargs [cs idx]
22:15 jnthn argconst_s 0, "foo"
22:15 jnthn arg_o 1, rX
22:15 jnthn invoke_o # or whatever
22:15 woolfy joined #perl6
22:15 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?
22:16 jnthn Well, we resolve the index at load time...
22:16 jnthn In the spesh case, though, we know for a given callsite what arg buffer location holds a given name.
22:16 jnthn So we can just use the unsafe sp_getarg_o
22:17 jnthn Which once we can JIT will probably end up being a few instructions...
22:18 timotimo which part am i going to optimize right now? the caller side or the callee side?
22:19 lizmat_ joined #perl6
22:19 timotimo well, maybe not "going to", but "supposed to" :P
22:20 jnthn Well, it's the callee that's specialized
22:20 jnthn But the caller can have an instruction less per named arg it'll pass too after this.
22:21 timotimo oh, so we have a non-specializer-related opt, which is moving the argconst_s from the bytecode into the callsite storage
22:22 timotimo 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
22:23 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 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 timotimo unfortunately, it now crashes and burns almost immediately
22:25 lizmat joined #perl6
22:25 jnthn timotimo: It's hard to say at a casual glance...
22:26 jnthn 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
22:26 timotimo but we have blocks that go up to 12 bytes
22:26 jnthn ah
22:26 jnthn hm
22:26 timotimo so i could either "if index == 3 || index == 7 || index == 11"
22:26 timotimo or use modulo
22:27 jnthn yeah, I'll need to look more closely.
22:27 timotimo i went for the shorter code forn ow
22:28 jnthn I'm really uncofortable how the change leaks out in https://github.com/MoarVM/MoarVM/commit/846d59e8b2 too
22:28 timotimo yes.
22:28 timotimo so am i
22:28 timotimo didn't have a better idea yet
22:29 BenGoldberg joined #perl6
22:32 jnthn time for me to try and sleep...hopefully more than last night
22:32 jnthn o/
22:32 timotimo gnite and good luck!
22:32 timotimo oh, huh
22:33 timotimo 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 timotimo oh, no, it's not "in the callsite", it's passed along
22:33 timotimo i think i get it
22:34 rurban joined #perl6
22:36 rurban1 joined #perl6
22:38 Ben_Goldberg joined #perl6
22:48 jlaire joined #perl6
22:49 timotimo i seem to be somewhat tired as well
22:50 timotimo maybe i'll end up getting a decent sleep rhythm again if i get some sleep now?
22:50 lizmat as am I
22:50 lizmat yes, good rhythm is good
22:50 lizmat so good night, #perl6!
22:50 timotimo good rhythm lhyzmhat! :)
22:51 lizmat and you, timotimo timotimo timotimo   :-)
23:07 DarthGandalf joined #perl6
23:11 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 timotimo so these things i'll have to change. but i'm not seeing the code that writes out the callsites
23:19 FOAD joined #perl6
23:47 cooper- joined #perl6
23:53 xenoterracide joined #perl6

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

Perl 6 | Reference Documentation | Rakudo