| [Coke] | Sure, a PR can't hurt. just leave a comment that it's exploratory. | 00:09 | |
| thanks for trying it out. | |||
| [Tux] | This is Rakudo version 2016.05-73-g60731a0 built on MoarVM version 2016.05-18-g1339332 | 06:53 | |
| test 19.246 | |||
| test-t 11.927 | |||
| csv-parser 22.418 | |||
| dalek | kudo/nom: 42f07cd | lizmat++ | src/core/IO/Handle.pm: Fix scoping issue with IO::Handle.comb(N) |
08:12 | |
| kudo/nom: 65e1b54 | lizmat++ | src/core/Iterator.pm: Squeeze a few % out of default Iterator code - use nqp::eqaddr instead of =:= - use nqp::not_i instead of ! - use nqp::add_i instead of prefix ++ - use postfix until instead of empty body until |
|||
| lizmat | m: class A { method sink { say "sunk" } }; use nqp; nqp::stmts(A.new) # jnthn: looks like nqp::stmts doesn't sink | 08:14 | |
| camelia | ( no output ) | ||
| lizmat | m: class A { method sink { say "sunk" } }; A.new | 08:15 | |
| camelia | rakudo-moar 60731a: OUTPUTĀ«sunkā¤Ā» | ||
| lizmat | m: class A { method sink { say "sunk" } }; STATEMENT_LIST(A.new) | ||
| camelia | ( no output ) | ||
| lizmat | nor does STATEMENT_LIST apparently | ||
| dalek | kudo/nom: d292d76 | lizmat++ | src/core/Any-iterable-methods.pm: Remove 2 unnecessary no-sink's, MasterDuke++ |
08:36 | |
| lizmat | afk for a few hours& | ||
| jnthn | lizmat: nqp::stmts will not, it's just too low level | 08:43 | |
| STATEMENT_LIST probably should | |||
| lizmat | jnthn: ok, so I will not use STATEMENT_LIST to prevent sinking | 10:30 | |
| m: class A { method sink { say "sunk" } }; my $a = A.new; $a # shouldn't this just say "sunk" ? | 10:35 | ||
| camelia | rakudo-moar d292d7: OUTPUTĀ«WARNINGS for /tmp/GDbzqJZ7_5:ā¤Useless use of $a in sink context (line 1)ā¤Ā» | ||
| lizmat | jnthn: at appears that postfix while also doesn't sink | 11:04 | |
| m: class A { method sink { say "sunk" } }; while $++ < 5 { A.new } # sinks | 11:05 | ||
| camelia | rakudo-moar d292d7: OUTPUTĀ«sunkā¤sunkā¤sunkā¤sunkā¤sunkā¤Ā» | ||
| lizmat | m: class A { method sink { say "sunk" } }; A.new while $++ < 5 # doesn't sink | ||
| camelia | ( no output ) | ||
| lizmat | I guess that's one of the reasons MasterDuke could remove the no-sinks in many places without problems | ||
| question is: this is probably a bug, right ? | |||
| dalek | kudo/nom: 57d66ee | lizmat++ | src/core/Iterator.pm: Remove unnecessary no-sinks from default Iterator Turns out they were not needed at all because postfix while/until currently doesn't sink (which could be argued is a bug). Replaced with nqp::while/until which *are* guaranteed to not sink. MasterDuke17++ for pursuing this |
11:23 | |
| kudo/nom: 3b9b613 | lizmat++ | src/core/ (2 files): Remove no-sink from basic List/Array iterators |
11:48 | ||
| kudo/nom: 2095ed6 | lizmat++ | src/core/Any-iterable-methods.pm: Remove no-sink from the grep family |
12:16 | ||
| [Tux] | Drrrrrrrrrrrrrrrrrum Rrrrrrrolllllllllllllllllllllllllllllll ā¦ā¦ā¦ | 14:36 | |
| This is Rakudo version 2016.05-79-g2095ed6 built on MoarVM version 2016.05-18-g1339332 | |||
| test 18.609 | |||
| test-t 10.702 | |||
| csv-parser 21.906 | |||
| YiiiiiiiiiHa! | 14:37 | ||
| timotimo | wow | 14:38 | |
| that's an improvement! | |||
| how many "return" statements are in your code all in all, btw? | 14:39 | ||
| because that's going to get super crazy improvement soon | |||
| and after a bit more complex optimization later on it'll almost be free | |||
| nine | Woah! I would love to know what exactly was responsible for this speedup :) | 14:43 | |
| [Tux] | timotimo, 47 | 14:45 | |
| timotimo | [Tux]: any clue how many of them are on hot paths? | 14:46 | |
| [Tux] | moment ā¦ | ||
| jnthn | Also, note that every routine will get a little faster due to less overhead from return related stuff too, once that stuff lands | 14:47 | |
| timotimo | \o/ | 14:48 | |
| [Tux] | 6 are real hot (when no parse errors happen) | ||
| 19 including end-of-row and end-of-file states | 14:50 | ||
| many more when extended features are used | |||
| masak | [Tux]: how many can be trivially removed, because they're the last line of a routine? | 14:51 | |
| [Tux] | none | ||
| lizmat and I already did that | |||
| masak | aha. | 14:53 | |
| [Coke] | nice to give lizmat & jnthn some positive feedback on their speedup work. | 15:05 | |
| dalek | kudo/nom: b6902e5 | TimToady++ | src/core/Exception.pm: s/call/resolve caller/ "Cannot call foo(Bar); none of these signatures match" is confusing insofar as it can be taken to mean that foo(Bar) actually exists as a candidate. Message now reads "Cannot resolve caller foo(Bar)". |
17:19 | |
| timotimo | don't you mean callee? | 17:26 | |
| [Coke] | I htnk you would already have had to resolve the callee. | 18:02 | |
| wait. | 18:03 | ||
| yup, I need more Coke Zero. | |||
| stmuk_ | try Club Mate :) | 18:06 | |
| [Coke] | I think I had some of that in switzerland. Wasn't my favorite, as I recall | 18:07 | |
| hoelzro | I've seen very colorful language used to describe the taste of club mate | 18:14 | |
| hoelzro doesn't care for it either | |||
| I think it's an acquired taste | 18:15 | ||
| [Coke] recalls finding an ample supply of Zero there, though. | |||
| mst | hoelzro: I would rather drink my own urine. | 18:23 | |
| hoelzro | haha | 18:41 | |
| that's some of the colorful language I've seen employed =) | |||
| stmuk_ likes it | 18:48 | ||
| lizmat | nine: I think it's 57d66ee76aa727b7ed | 20:03 | |
| mostly | |||
| dalek | kudo/nom: 8cfa6c7 | lizmat++ | src/core/Any-iterable-methods.pm: Streamline .unique 20% faster for all unique values, 30% faster for all identical values. - remove unnecessary no-sink's - use nqp::eqaddr instead of =:= - more generally, use nqp::ops |
20:30 | |
| [Coke] | is the hope that eventually spesh will be smart enough to make rakudo ops like =:= fast enough to use? | 20:34 | |
| s/fast.*/as fast as nqp ops/ ? | 20:35 | ||
| lizmat | that is my hope, yes | 20:37 | |
| in profiles, infix:<=:=> typically takes 2% of the CPU in any type of iterator | 20:38 | ||
| fwiw, I think the nqp::p6bool is to blame there | 20:39 | ||
| jnthn | The problem is that it's a megamorph, and spesh is pretty awful and coping with those. | 20:41 | |
| (with regard to =:=) | 20:42 | ||
| [Coke] | megamorph is a MTG term. Does it mean here that it has a lot of multis? | 20:46 | |
| jnthn | MTG is a TLA I don't know :P | 20:47 | |
| Not "a lot of multis", but rather "called with a lot of different argument types" | |||
| [Coke] | magic the gathering, a collectible card game. :) | 20:48 | |
| jnthn | oh :) | ||
| timotimo | right, because we =:= all kinds of different types | ||
| even though it doesn't actually make any difference to the optimization in this very case | |||
| jnthn | Yeah. Spesh in its present form produces specializations by type, and doesn't yet try to track if the specialization is actually more general :) | 20:49 | |
| And it puts a limit on how many specializations it'll make, and inlining only uses existing specializations of the target. | |||
| Which between them mean bad things for =:= | 20:50 | ||
| (But fine things for many, many cases) | |||
| We have the same problem with .sink, which can be called on a huge number of argument types, but just evaluates to Nil | 20:51 | ||
| And various other things | |||
| jnthn gets an early night o/ | 21:07 | ||
| lizmat | good night, jnthn | 21:09 | |
| dalek | kudo/nom: 4173600 | lizmat++ | src/core/Iterator.pm: Temporary fix for RT #128357 |
21:13 | |
| kudo/nom: 8887a7c | lizmat++ | src/core/Any-iterable-methods.pm: Streamline .repeated, like .unique |
21:28 | ||
| kudo/nom: 87e91cc | lizmat++ | src/core/Any-iterable-methods.pm: Streamline .squish, like .unique |
21:50 |