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.
[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
[TuxCM] I do not see significant change in that over the past week(s) 10:28
I just did a scrollback
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
[TuxCM] ah, well, maybe another process kicked in 13:09
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
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
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
MasterDuke hm, i'll see if i can come with anything sensible, but this is getting pretty far outside my experience 19:57