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:54 MasterDuke joined, p6bannerbot sets mode: +v MasterDuke, MasterDuke left, MasterDuke joined, herbert.freenode.net sets mode: +v MasterDuke, p6bannerbot sets mode: +v MasterDuke
Geth rakudo: 501231ee42 | (Timo Paulssen)++ | 2 files
Eliminate A Few Scalar Allocs For Push-All

I could not measure a performance benefit in the benchmark I had, but the bytecode got a bit simpler and total allocation count decreased a little.		 01:24
03:17 MasterDuke left 03:23 Ven`` joined 03:24 p6bannerbot sets mode: +v Ven`` 03:34 Ven`` left 05:01 llfourn joined 05:02 p6bannerbot sets mode: +v llfourn 08:39 dct left 08:46 dct joined, p6bannerbot sets mode: +v dct 09:01 dct left
lizmat Files=1262, Tests=87961, 381 wallclock secs (19.86 usr 6.05 sys + 2615.41 cusr 221.77 csys = 2863.09 CPU) 10:43
^^ looks like my work on adding return types is slowing down the spectest significantly :-(
Geth rakudo: 7a68df2b7d | (Elizabeth Mattijsen)++ | 3 files
Add return signatures to Dateish/Date/DateTime where appropriate
 10:46
[Tux] Rakudo version 2018.12-70-g501231ee4 - MoarVM version 2018.12-8-g45d15efe9
csv-ip5xs0.943 - 0.972
csv-ip5xs-207.219 - 7.362
csv-parser22.429 - 22.511
csv-test-xs-200.424 - 0.425
test6.915 - 6.973
test-t1.866 - 1.894
test-t --race0.844 - 0.866
test-t-2030.839 - 31.488
test-t-20 --race9.643 - 9.750
 11:04
lizmat m: sub a() { 42 }; for ^1_000_000 -> int $_ { a }; say now - INIT now 11:20
camelia 0.58137785
lizmat m: sub a(--> Int:D) { 42 }; for ^1_000_000 -> int $_ { a }; say now - INIT now 11:21
camelia 0.3867178
lizmat huh?
m: sub a() { 42 }; for ^1_000_000 -> int $_ { a }; say now - INIT now
camelia 0.184703
lizmat ah, more like it
so it looks like there *is* quite a penalty for adding a return type :-(
roughly 2x as slow in this benchmark :-( 11:22
R#2573 # jnthn timotimo 11:38
synopsebot R#2573 [open]: github.com/rakudo/rakudo/issues/2573 Adding a return type slows execution down
nine lizmat: I'm not terribly surprised. The return type is a constraint, therefor we have to generate code to check if the constraint is met. OTOH it could help the VM, since if we know what code is called and there's a return type constraint, we could rely on that. But I'm not aware of any optimization making use of this currently. 12:46
lizmat nine: I guess the question becomes: should I continue adding return types, should I remove them, or should I just stop adding them 12:47
so I guess the --> Mu signature means: don't generate constraint type checking code 12:48
rather than checking against Mu
12:48 lucasb joined, p6bannerbot sets mode: +v lucasb
timotimo huh, even after speshing a, it still makes explicit calls into typecheckrv and decontrv spesh plugins 12:50
lizmat timotimo: so you're saying there's a deficiency there ?
timotimo not entirely sure, i'm investigating 12:51
13:01 pmurias joined, p6bannerbot sets mode: +v pmurias
pmurias are there plans to get precompilation of scrips working in rakudo? 13:03
lizmat it's somewhere on the list of todo's waiting for someone to have that itch sufficiently ? 13:07
timotimo benchable: sub a(--> Int:D) { 42 }; for ^1_000_000 -> int $_ { a; a; a; a; a }; say now - INIT now 13:14
benchable6 timotimo, No new data found
timotimo ..oh?
13:16 MasterDuke joined, p6bannerbot sets mode: +v MasterDuke, MasterDuke left, MasterDuke joined, herbert.freenode.net sets mode: +v MasterDuke, p6bannerbot sets mode: +v MasterDuke
MasterDuke timotimo: think you need to give it a revision 13:17
timotimo oh, right 13:18
benchable: releases sub a(--> Int:D) { 42 }; for ^1_000_000 -> int $_ { a; a; a; a; a }; say now - INIT now
benchable6 timotimo, starting to benchmark the 36 given commits
timotimo so the spesh log for a shows that it's gotten 'identity' to use, but it's not actually inlining identity into a? 13:20
i haven't looked at the spesh log for the other one, though tbh
MasterDuke timotimo: btw, any idea why a --profile-compile of some of Xliff's GTK code (with a 5s parse time) would show all the exlusive time in await?
timotimo MasterDuke: how multithreaded is it? 13:21
i mean, with an await in there, it probably has at least two threads? 13:22
benchable6 timotimo, benchmarked the given commits and found a performance difference > 10%, now trying to bisect
MasterDuke it's just the compilation, so i guess just whatever spesh does
timotimo so perhaps it has a subprocess that does some precomp 13:23
benchable6 timotimo, Ā«hit the total time limit of 300 secondsĀ»
timotimo d'oh 13:24
MasterDuke so the the profile isn't really helpful
timotimo could be
MasterDuke *then the
benchable: 2016.12,2017.12,2018.12,HEAD sub a(--> Int:D) { 42 }; for ^1_000_000 -> int $_ { a; a; a; a; a }; 13:28
benchable6 MasterDuke, starting to benchmark the 4 given commits
MasterDuke, Ā¦2016.12: Ā«1.3913Ā» Ā¦2017.12: Ā«0.3946Ā» Ā¦2018.12: Ā«1.3964Ā» Ā¦HEAD: Ā«1.4191Ā» 13:29
MasterDuke, benchmarked the given commits and found a performance difference > 10%, now trying to bisect
MasterDuke, gist.github.com/8a40e8bab2b7b3b964...02d05b40fd 13:30
timotimo could we get the revisions as clickable links? :3 13:32
MasterDuke committable6: 1070fa0,a41c37c sub a(--> Int:D) { 42 }; for ^1_000_000 -> int $_ { a; a; a; a; a }; say now - INIT now
committable6 MasterDuke, Ā¦1070fa0: Ā«0.1335828ā¤Ā» Ā¦a41c37c: Ā«1.307461ā¤Ā»
MasterDuke timotimo: i think there's an issue for that
timotimo cool
MasterDuke github.com/rakudo/rakudo/commit/1070fa0 13:33
github.com/rakudo/rakudo/commit/a41c37c
geth: ver github.com/rakudo/rakudo/commit/a41c37c 13:34
Geth: help 13:35
Geth MasterDuke, Source at github.com/perl6/geth To add repo, add an 'application/json' webhook on GitHub pointing it to hack.p6c.org:8888/?chan=#perl6 and choose 'Send me everything' for events to send | use `ver URL to commit` to fetch version bump changes
pmurias lizmat: I'm wondering if it might makes sense to check if roast tests pass when precompiled
MasterDuke Geth: ver github.com/rakudo/rakudo/commit/a41c37c
Geth MasterDuke, version bump brought in these changes: github.com/perl6/nqp/compare/2018....4-ge1929a4
MasterDuke Geth: ver github.com/perl6/nqp/commit/e1929a...18d59903ac 13:36
Geth MasterDuke, version bump brought in these changes: github.com/MoarVM/MoarVM/compare/2...5-g0c5f6e5
MasterDuke some of those moarvm commits look relevant 13:37
github.com/MoarVM/MoarVM/commit/28...38d344c67b and github.com/MoarVM/MoarVM/commit/51...99a9ecdfc5 13:38
lizmat afk for a few hours& 13:39
nine OMG I think I've found a fix for issue #2563 13:40
dogbert11 the spesh bug issue? 13:44
nine yep 13:45
dogbert11 very cool 13:47
13:54 Ven`` joined 13:55 p6bannerbot sets mode: +v Ven``
AlexDaniel nine++ 14:36
nine: thank you very much!
robertle: do you need a point release or can you apply it as a patch yourself? 14:37
14:49 AlexDani` joined 14:50 p6bannerbot sets mode: +v AlexDani`
pmurias if we can't determin the current $*KERNERL.hostname (in the browser) what should it return? 14:58
Geth nqp: 9f9e4fae37 | (Paweł Murias)++ | src/vm/js/nqp-runtime/runtime.js
[js] Fix bug
 15:06
nqp: fbbfb6c0a9 | (Paweł Murias)++ | src/vm/js/nqp-runtime/ctx.js
[js] Remove left over debugging message
nqp: ab46ec2c2c | (Paweł Murias)++ | src/vm/js/nqp-runtime/ctx.js
[js] Fix uncaught exception handlers getting wrong context
rakudo/master: 6 commits pushed by (Paweł Murias)++ 16:05
pmurias jnthn: what's our policy in regards to serializing things that are special cased in our variant serialization being forced to be serialized as objects by being placed into WVals? 16:18
jnthn: is that something that should silently work or is that just potential trouble? 16:19
16:35 AlexDani` is now known as AlexDaniel
MasterDuke committable6: a41c37c,a41c37c^ sub a(--> Int:D) { 42 }; for ^1_000_000 -> int $_ { a; a; a; a; a }; say now - INIT now 17:48
committable6 MasterDuke, Ā¦a41c37c: Ā«1.3292806ā¤Ā» Ā¦a41c37c^: Ā«0.105792ā¤Ā»
18:18 Kaiepi joined, p6bannerbot sets mode: +v Kaiepi 18:30 lizmat joined, p6bannerbot sets mode: +v lizmat 18:34 Kaiepi left
lizmat timotimo: re 501231ee423ebc8ce6de , would you recommend doing that for all of the push-all methods ? 19:02
timotimo maybe 19:12
it's the tiniest improvement it seems like
lizmat well, for hot code paths that may make a difference 19:13
timotimo right
lizmat and it's not going to make things worse for non-hot paths, right ?
timotimo i think it won't, though better check 19:17
MasterDuke didn't jnthn recently undo that kind of optimization somewhere? with some explanation of why it might not always be better? 19:22
19:27 Ven`` left 19:51 Ven`` joined 19:52 p6bannerbot sets mode: +v Ven`` 19:56 MasterDuke left
Geth rakudo: a904d25a57 | (Elizabeth Mattijsen)++ | 23 files
Convert all $target to \target in iterators

Inspired by 501231ee423ebc8c, appears to have a positive effect on the spectest so this appears to be a good thing.		 20:18
20:48 lucasb left
Geth rakudo: 5cf65b57cb | (Elizabeth Mattijsen)++ | src/core/Map.pm6
Add return signatures to Map.methods/subs
 20:54
21:12 Ven`` left 21:13 Ven`` joined 21:14 p6bannerbot sets mode: +v Ven``
Geth rakudo: 87698317a9 | (Elizabeth Mattijsen)++ | src/core/Map.pm6
Simplify Map.Hash

Removes one call to nqp::elems, because we need the iterator we can use that as the condition for the if (as an iterator on an empty hash will always start out to be false)		 21:14
timotimo lizmat: you think putting a setelemspos in a push-all where we know the exact amount would be beneficial? 21:15
lizmat timotimo: and then doing bindpos ? 21:16
you mean doing a loop with bindpos as opposed to pushing values ?
timotimo nah, i thought setelemspos it back to what it was 21:17
you know, we can make these ops return whatever we want if nothing is currently relying on them
lizmat only knows about setelems
timotimo oh
setelemspos is what it's called somewhere interally
lizmat ah, ok
timotimo like, setelemspos($foo, setelemspos($foo, 0)) could have the inner one return the current number of elems
wait, that's nonsense %) 21:18
lizmat setelems current returns $foo
and that's very handy
timotimo setelemspos($foo, setelemspos($foo, elems($foo) + 20))
oh, OK
lizmat fwiw, I've tried that several times, pre-sizing the buffer... but it made things worse for small buffers 21:19
timotimo though we can have a version in the compiler as a desugar that just handles getting the "right" return value back as cheaply as possible
ah, hm.
lizmat do you have an idea at how many elements it makes sense to pre-size?
anyways, this smells like premature opts.. :-)
timotimo i do not
Geth rakudo: ugexe++ created pull request #2574:
Add naive $?DISTRIBUTION implementation		 22:15
jnthn pmurias: We probably shouldn't have that happening, though I think the variant serialization thing can slowly go away; it exists for historical reasons. 22:36
yoleaux 24 Dec 2018 22:04Z <SmokeMachine> jnthn: thanks for your issue on Red! That's a great idea!
24 Dec 2018 22:12Z <SmokeMachine> jnthn: sorry, wrong Jonathan! :)
28 Dec 2018 22:39Z <Xliff> jnthn: Can you wrap submethod BUILD via .^add_method? ie: Are submethods handled the same as methods, internally?
jnthn .tell Xliff Yes, submethods are added via .^add_method; it drops them into a different table based on a type distiction. 22:37
yoleaux jnthn: I'll pass your message to Xliff.
22:58 Ven`` left 22:59 Ven`` joined 23:00 p6bannerbot sets mode: +v Ven`` 23:24 pmurias left

Powered by Cro and the RakuĀ® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!