| [Tux] | This is Rakudo version 2016.05-41-g6bb23a5 built on MoarVM version 2016.05-18-g1339332 | 06:53 | |
| test 19.701 | |||
| test-t 12.581 | |||
| csv-parser 34.852 | |||
| consistently under 13 for the past three days | 06:54 | ||
| dalek | kudo/nom: 4e66e0a | (Daniel Green)++ | src/core/List.pm: Speed up List.pm's infix:<,> ~40% by using a STATEMENT_LIST to convert to a ternary and postfix while |
09:54 | |
| kudo/nom: ba6a288 | lizmat++ | src/core/List.pm: Merge pull request #779 from MasterDuke17/List.pm_optimizations Speed up List.pm's infix:<,> ~40% by using a STATEMENT_LIST to conver… |
|||
| kudo/nom: 85cdb9e | ugexe++ | src/core/CompUnit/Repository/FileSystem.pm: Access packages in the $base Makes `META6.json` and `META.info` follow the same behavior in regards to access modules in a package $base See: irclog.perlgeek.de/perl6-toolchain/...i_12593703 |
09:55 | ||
| kudo/nom: affe025 | lizmat++ | src/core/CompUnit/Repository/FileSystem.pm: Merge pull request #778 from ugexe/patch-6 Access packages in their CUR::FS $base |
|||
| kudo/nom: de5db8c | lizmat++ | src/core/List.pm: An empty infix:<,> only needs a List object itself Won't even allocate a $!reified now when iterating, as it will fall back to the EmptyIterator now |
10:57 | ||
| kudo/nom: 03a403a | lizmat++ | src/core/List.pm: Streamline List.Capture Also, fixes problem introduced recently. Basically, only create a full-fledged Capture if there is any data to put in the Capture. |
|||
| kudo/nom: 3bd9fd6 | lizmat++ | src/core/Rakudo/Internals.pm: Give the EmptyIterator a sink-all just in case Haven't been able to make it run yet, but it seems correct to have it anyway. |
11:42 | ||
| kudo/nom: e403c1b | lizmat++ | src/core/List.pm: Make List.FLATTENABLE_LIST a bit cheaper If there's a $!todo, there will be a $!reified created anyway, so no need to check for $!reified.DEFINITE then. Also part of the effort to get rid of !ensure-allocated. |
|||
| kudo/nom: dfbf1ec | (Daniel Green)++ | src/core/List.pm: Somw whitespace/legibility changes |
12:01 | ||
| |Tux| | lizmat++ | 12:26 | |
| This is Rakudo version 2016.05-49-ge403c1b built on MoarVM version 2016.05-18-g1339332 | |||
| test 19.013 | |||
| test-t 11.979 | |||
| csv-parser 34.152 | |||
| dalek | kudo/nom: b2f8ba9 | lizmat++ | src/core/List.pm: Make List.join on empty lists 2x as fast And half the number of allocations. Basically doesn't initialize $!reified if it is not needed. |
12:30 | |
| lizmat | afk for a few hours & | 12:31 | |
| ugexe | so what exactly is the difference between `sub foo() { 1; }` and `sub foo() { $ = 1; }`? | 14:01 | |
| months ago i would have to use the later on windows if they were called from a lazy loop, otherwise it would just instantly iterate the entire list without making the appropriate calls | 14:03 | ||
| geekosaur | the former can be optimized away since it's a compile time constant? (I don't know if that happens) the latter has a pointless assignment but that could well defeat optimization | 14:05 | |
| jnthn | If those cause some different behavior then it's likely an optimizer bug or something, yes | ||
| ugexe | and now they manage to cause that 'Cannot assign to immutable' under certain circumstances. is that probably a bug as well? since i cant golf it down im assuming its some edge case bug | 14:08 | |
| geekosaur | the other possibility is that one or both gets JITted wrong, but tracking that would be "fun" | 14:09 | |
| [Coke] | we should start a "what needs to happen to bump the spec version" document with practical considerations on jnthn++'s earlier post-christmas suggestions. | 16:18 | |
| like "what should roast's 6.d-errata branch look like, in comparison to 6.c-errata (which was a rushed snapshot) and how do we get there?" | 16:19 | ||
| jnthn | ugexe: You can try MVM_SPESH_DISABLE=1 in the environment to rule out that sort of optimization bug, fwiw | 16:25 | |
| [Coke]: I'm guessing a 6.c.1 is on the cards sooner than a 6.d, but yes :) | 16:26 | ||
| [Coke] | jnthn: right, same discussion. ... except we can probably cut a few corners on a 6.c.1 in terms of roast. | 16:33 | |
| but I'd really like to hash out what roast should really look like sooner than later, so maybe we do make that a precondition of cutting a new spec, even a .1 | |||
| jnthn | Well, I suspect we'll converge on doing it in a way we're happy with over a few releases, but yes, no reason not to start off in that direction in .1 :) | 16:34 | |
| Also to figure out soon is adding a CORE.d.setting or so; I think nine++ may have had a branch somewhere doing that | 16:38 | ||
| [Coke] | jnthn: we'll also need a 6.c.1 setting, neh? | 16:41 | |
| jnthn | [Coke]: Only if we have anything new | 16:42 | |
| [Coke] | (but we could totally add an experimental 6.d first) | ||
| jnthn | I don't know we added any new subs? | ||
| Or new types? | |||
| [Coke] | jnthn: if we don't have anything new, we don't need a .1, neh? | ||
| jnthn | We have a lot of fixes, which have test coverage | ||
| And so are things you can rely on in 6.c.1 | 16:43 | ||
| (But not in a plain 6.c) | |||
| The doc I wrote up back in Jan (or was it Feb...) noted that only certain kinds of change triggered the need for a new setting. | |||
| nine | jnthn: yes there's a branch for language versioning | 16:44 | |
| jnthn | We'll want a 6.d.a at some point sorta-soonish when I change the behavior of await :) | 16:47 | |
| jdv79 | wasn't await changed not that long ago already? | 17:09 | |
| timotimo | hm, how so? | 17:15 | |
| jdv79 | as part of the async cleanup pre-xmas i think | 17:25 | |
| timotimo | ah. well, whatever is pre-christmas doesn't impact the roast letter uppage :) | ||
| jnthn: is it silly to assume people would want to use await inside callbacks that have passed through C? should we have automatic detection for "are we in a sub-runloop" and not try to do continuation magic with await in that case? | 17:26 | ||
| sexy-coder-girl | quit | 18:11 | |
| timotimo | sexy-coder-girl: yo zoffix, you know there's a newer weechat version than that? :) | 18:14 | |
| sexy-coder-girl | timotimo: that's what I got in the Debian repo | ||
| jnthn | jdv79: No, await stayed about the same I think. It was supplies that got a big design cleanup. | 18:30 | |
| timotimo: I suspect we can do something smart scheduler wise about native callbacks | |||
| timotimo | yeah, i thought the vm could just set a dynamic variable, but we could also have an op for "are we in a sub-runloop" | 18:31 | |
| jdv79 | ok | 20:02 | |
| jnthn | I suspect I'll get to the await stuff during the summer... Seems I'm doing a stint of "omg, where do all the CPU cycles go to" at the moment :) | 20:03 | |
| jdv79 | nice. sounds tedious but fun when wins are gotten. | 20:05 | |
| jnthn | Well, getting the raw data isn't especially tedious thanks to the nice tools in the valgrind suite. | 20:07 | |
| Some of the debugging when improvements have unexpected consequences can be :) | 20:08 | ||
| Though it's a lot less tedious than last month's focus on GC/concurrency torture testing. | 20:09 | ||
| And fixing things that shook out. | |||
| I suspect the await stuff won't be too bad, though I'm ready for something I hadn't thought of to smack me in the face when I start taking continuations on one thread and then invoking them on another... :) | 20:10 | ||
| mst | callbacks that have passed through C are always interesting | 20:33 | |
| dalek | kudo/nom: 0cc70dc | lizmat++ | src/core/List.pm: A literal '' is better Not sure what I was thinking when I introduced the native str. This removes one allocation per call to .join. |
22:02 | |
| kudo/nom: 56cc3ae | lizmat++ | src/core/List.pm: Streamline List.is-lazy, about 30% faster Step one of more streamlining with regards to reify-until-lazy / fully-refied. |
22:06 | ||
| kudo/nom: 48fe6ae | lizmat++ | src/core/Array.pm: Streamline Array.is-lazy in the same manner We should probably not have a separate Array.is-lazy. But that's for another day. |
22:18 | ||
| lizmat | good night, #perl6-dev | ||
| Zoffix | night | 22:19 |