Perl 6 language and compiler development | Logs at colabti.org/irclogger/irclogger_log/perl6-dev | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
Set by Zoffix on 27 July 2018.
00:19 entonian joined 00:22 entonian left 00:28 MasterDuke joined, MasterDuke left, MasterDuke joined 02:16 Ven`` joined 02:23 Ven`` left 04:01 tyil left 04:24 tyil joined 05:36 dogbert11 joined 05:38 nebuchad` joined, tobs` joined, vrurg_ joined 05:41 nine_ joined, vrurg left, dogbert17 left, camelia left, nine left, tobs left, nebuchadnezzar left, tobs` is now known as tobs, vrurg_ is now known as vrurg 05:43 TreyHarris left 05:45 camelia joined 05:47 ChanServ sets mode: +v camelia 06:07 TreyHarris joined 06:50 nebuchad` is now known as nebuchadnezzar 07:17 tyil left 07:20 tyil joined 07:26 nebuchadnezzar left 07:28 nebuchadnezzar joined 08:27 nine_ is now known as nine 09:58 hankache joined
[TuxCM] Rakudo version 2018.12-304-geb8561ba1 - MoarVM version 2018.12-107-g19515dbdd
csv-ip5xs0.735 - 0.808
csv-ip5xs-206.263 - 6.608
csv-parser22.588 - 22.935
csv-test-xs-200.446 - 0.498
test7.618 - 7.893
test-t1.820 - 1.828
test-t --race0.877 - 1.238
test-t-2031.412 - 31.539
test-t-20 --race10.519 - 11.113
 10:18
lizmat test-t --race 0.877 - 1.238 # wow, wtf is going on here? 10:22
10:27 |Tux| left
[TuxCM] I do not see significant change in that over the past week(s) 10:28
I just did a scrollback
10:32 |Tux| joined
lizmat Files=1267, Tests=88061, 408 wallclock secs (21.15 usr 6.38 sys + 2931.64 cusr 226.79 csys = 3185.96 CPU) 10:38
[TuxCM] I'm puzzled about the range... which seems much wider than the other benchmarks 10:39
11:11 hankache left 11:19 lucasb joined 12:44 dalek left
[TuxCM] ah, well, maybe another process kicked in 13:09
15:40 AlexDaniel joined
MasterDuke jnthn, timotimo: that recent fix/optimization with marking mixin types (or something like that, i'm a little lost on the detail), think it would help with that new operator optimization problem? istr something about grammars getting recompiled because of mixins 16:00
timotimo i don't think so, no 16:18
16:41 ufobat_ joined 16:45 ufobat___ left
MasterDuke timotimo: hm. i think i had gotten kind of stuck, had any insights recently? 16:52
timotimo no good ideas :( 16:53
MasterDuke oh well 16:55
16:57 sivoais joined 17:19 Geth left 18:04 AlexDani` joined 18:05 AlexDaniel left 18:12 AlexDani` left
jnthn MasterDuke: No, it's about optimizing attribute access 18:35
MasterDuke jnthn: ah, right, now that rings a bell 19:22
btw, any further thoughts about optimizing new operators? 19:23
timotimo the thing we've mostly been looking at was optimizing adding the same operator over and over 19:24
which i honestly don't consider worth a whole lot
MasterDuke timotimo: the same behavior happens adding multiple different operators 19:25
timotimo optimizing adding the same one over and over will help by completely cutting out changes to the grammar the second time around 19:26
we won't be able to apply that for different operators 19:27
that's my guess at least
jnthn As I've noted before: we need to build a dependency graph so we can only invalidate the NFAs that are implicated by the language change 19:37
Now we invalidate All The Things. So if you add an infix, we also re-generate the NFAs for prefix, postfix, term, etc. 19:38
timotimo how will the dependencies relate to the list of fates? it's not exactly 1:1, is it? 19:40
jnthn The NFAs are per rule, and per alternation, and a given alternation is in one rule 19:43
So making a graph of which rules call which other rules and use with alternations would allow us to traverse it from the category of operator that is added
So adding an infix invalidates infixish too, for example 19:44
timotimo in theory, this work could be parallelized 19:45
though i don't feel so hot about adding a thread during compilation
MasterDuke i think i understand what you mean, but i don't know enough to start implementing. is there any(thing|where) relatively simple to start with?
i would love to be able to parallelize compilation 19:46
jnthn MasterDuke: I think the changes would be mostly in the NQP repository; take a look in Cursor
Also also the QAST::Regex node structure, and perhaps QRegex::NFA 19:47
timotimo at the very first step we'd have to figure out what calls to other rules are being parsed and added 19:49
not all of them are going to be part of an NFA
there must be code that figures this exact thing out already 19:50
since in order to build an nfa, it'll have to recursively descend into other methods' NFAs
jnthn Yeah, probably the graph wants building out of looking at the QAST::Regex nodes and stashing that somewhere, perhaps in the meta-object 19:51
19:56 gfldex left
MasterDuke hm, i'll see if i can come with anything sensible, but this is getting pretty far outside my experience 19:57
20:17 samcv left 20:18 samcv joined 22:40 robertle left 23:00 squashable6 left 23:03 squashable6 joined, ChanServ sets mode: +v squashable6 23:08 lucasb left 23:11 titsuki left, titsuki 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!