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.
timotimo outpew pew 00:19
that seems pretty clear, the append grapheme function seems to read too far in whatever was allocated in MVM_string_utf8_c8_decodestream on line 47 00:20
471
and get_all_in_buffer reads just outside the end of that same buffer 00:21
not sure why exactly the same buffer is being read as 2 bytes and written as 4 bytes, though
it does seem to be the same buffer, at least it is the same address
Geth roast: 6a46d3d6f8 | (Zoffix Znet)++ | S32-encoding/decoder.t
Remove whitespace
02:25
roast: b6fc8e0212 | (Zoffix Znet)++ | S32-encoding/decoder.t
Cover SEGV in utf8-c8 proc read

Covers R#2158 github.com/rakudo/rakudo/issues/2158
02:26
synopsebot R#2158 [open]: github.com/rakudo/rakudo/issues/2158 [SEGV][regression][⚠ blocker ⚠] :enc<utf8-c8> on Proc drops content / SEGVs
Geth rakudo: JJ++ created pull request #2192:
Uses DISTRO when available, refs #2190
07:37
synopsebot RAKUDO#2190 [open]: github.com/rakudo/rakudo/issues/2190 Substitute Rakudo::Internals::is-win to $*DISTRO.is-win for easier (or possible) testing of code
Geth roast: JJ++ created pull request #462:
Adds test for translate-nl
07:47
jnthn morning o/ 09:16
Geth rakudo: d021af232a | (Elizabeth Mattijsen)++ | src/core/Hash.pm6
Revert "Manually inline Hash!AT-POS-CONTAINER"

This reverts commit 1cd654a224077eb1aab7eaa43ea7d2eebb109c4f.
As Jonathan pointed out, this was *not* an improvement.
09:50
jnthn :)
lizmat++ for checking
jnthn spent 4+ hours analyzing and tweaking that stuff yesterday :)
lizmat should have checked before :-( 09:51
yoleaux 7 Aug 2018 21:16Z <benjikun> lizmat: Thanks
lizmat jnthn: apart from the speed, I did *not* see any difference in --profile :-(
jnthn fwiw, the inliner does somewhat (though needs to get smarter at) exclude the cost of nested inlines 09:52
When considering whether to inline something
lizmat so, how can I see an inline with --profile?
jnthn So you can actually have two small methods, have the second inline into the first and the first into its caller, but if you manually inlined the second into the first then you might not get the first inlined into the caller 09:53
lizmat yeah, I get that.. I just didn't think replacing a private method call with an nqp::op would actually increase the size of the body 09:54
jnthn It can
You never know what's behind an nqp::op without checking
Some of them do just go down to a single bytecode instruction
But some of them expand into a fairly involved QAST tree 09:55
lizmat so how does one check? again, apart from the speed difference, the --profiles between the two cases are identical
the test case being: my %h = a => 42; for ^1_000_000 -> int $_ { my $a = %h.AT-KEY("a") }
jnthn Look for the definition of the op
BTW, AT-KEY inlines into postcircumfix:<{ }> and that in turn is inlined into the caller, so a benchmark with %h<a> should also show little difference :) 09:56
The big desugar-y ones are mostly near the top of Actions.nqp
lizmat huh?? 09:57
jnthn As in, %h<a> should be close to %h.AT-KEY("a")
In terms of performance
Geth nqp/truffle: ee63d0ecd6 | (Paweł Murias)++ | 11 files
[truffle] Implement nqp::getcurhllsym, nqp::bindcurhllsym, nqp::gethllsym, nqp::bindhllsym
lizmat I'm *very* surprised by the phrase "AT-KEY inlines into postcircumfix:<{ }>" 09:58
jnthn Why?
lizmat because postcircumfix:<{ }> calls AT-KEY, not the other way around ? 09:59
lizmat multi sub postcircumfix:<{ }>( \SELF, \key ) is raw { 09:59
SELF.AT-KEY(key);
}
jnthn Yes 10:00
jnthn So the body of AT-KEY is inlined into (or if you like, copied into) postcircumfix:<{ }> 10:00
lizmat ok, so because { } can be looked up at compile time, rather than the method call .AT-KEY, this makes it faster ? 10:02
jnthn All this happens at runtime as part of what spesh does
lizmat ok, so before, I would use AT-KEY directly, so it wouldn't have to go through postcircumfix:<{ }> 10:03
jnthn Right, and now it should (in theory) make nearly no difference
pmurias MasterDuke: you can rebootstrap with j-bootstrap-files 10:04
lizmat so now in hot code, it *is* better to use postcircumfix:<{ } because it will inline better ?
pmurias MasterDuke: on the jvm backend
lizmat jnthn: is there still a point in using a sub as a helper instead of a private method ?
jnthn Well no, AT-KEY will also be inlined; I'm just saying that there's less need to write .AT-KEY instead because inlining makes the difference a lot smaller than it once was 10:05
And it's converging on "no difference"
Probably no reason to avoid private methods, unless you don't actually need `self`, in which case the `sub` would save passing an arg (and arguably in that case `sub` is the more correct choice anyway :)) 10:06
lizmat wouldn't it make the body smaller, so easier to stay under the inline limit ? 10:07
jnthn Why would methods have a bigger body than a sub?
lizmat because they would need to be looked up at runtime and need more info? 10:08
ah, but private methods are not MMD so probably already resolved at compile time ?
jnthn Oh, you mean the callsite is a little bigger in the caller...
lizmat yea
jnthn That depends
In the case the call is from a class I think it's probably the same number of bytes of bytecode
lizmat specifically: self!AT_KEY_CONTAINER(key) vs AT_KEY_CONTAINER(self,key) 10:09
jnthn If the call is from a role then a spesh plugin is used
So the pre-spesh size is a little larger
However, the post-spesh size would be the same
lizmat my specific example is not from a role
jnthn OK, then it should be the same bytecode size (the static optimizer resolves it into a wval instruction) 10:10
(And that wval instruction is the same as a sub lexical lookup instruction)
lizmat ok, so no point changing into a sub then
jnthn No
And to be clear, the rules *are* changing with time in this area, so the answers would have probably been a bit different some time ago :) 10:11
The aim being to run the code people naturally write faster
Thus why I'm keen to have things like %h<a> perform just as well as %h.AT-KEY("a") even if it naively should be worse :) 10:12
lizmat ok, gotcha :-) 10:14
pmurias MasterDuke: sorry, got confused by a github issue and direct the reply to you instead of the person asking there 10:19
pmurias dead code spotted: github.com/perl6/nqp/blob/master/s...d.nqp#L358 - we are emitting an op that does exist here 11:34
|Tux| Rakudo version 2018.06-353-gd021af232 - MoarVM version 2018.06-387-g50b063e04
csv-ip5xs0.964 - 0.965
csv-ip5xs-207.789 - 7.902
csv-parser25.248 - 25.854
csv-test-xs-200.445 - 0.478
test8.817 - 8.957
test-t2.228 - 2.232
test-t --race0.944 - 0.947
test-t-2038.991 - 39.610
test-t-20 --race12.584 - 12.711
12:03
Geth rakudo: 9e71c22d91 | (Elizabeth Mattijsen)++ | src/core/Hash.pm6
Simplify my Int %h.ASSIGN-KEY a bit
12:28
roast/master: 6 commits pushed by (JJ Merelo)++, (Zoffix Znet)++ 12:36
roast: 67d6f94dc2 | (Zoffix Znet)++ (committed using GitHub Web editor) | S32-str/encode.t
Document the assumptions in translate-nl test
12:40
rakudo: 4da2f60713 | (Elizabeth Mattijsen)++ | src/core/Hash.pm6
Simplify Hash.Map coercion
12:52
rakudo: 0601c43ca5 | (Elizabeth Mattijsen)++ | src/core/Hash.pm6
No reason to decont(self), it is already deconted
rakudo: 4eaff4524c | (Elizabeth Mattijsen)++ | src/core/Hash.pm6
Simplify Hash.head
Geth rakudo: 12bd328b88 | (Elizabeth Mattijsen)++ | src/core/Hash.pm6
Slightly simplify Hash.roll
13:05
nqp/truffle: 23d5dd4af5 | (Paweł Murias)++ | 2 files
[truffle] Implement nqp::getenvhash
13:06
rakudo: f0b705cdb0 | (Elizabeth Mattijsen)++ | src/core/Hash.pm6
Simplify Hash.roll(N)
13:12
Geth rakudo: 9327f95bc7 | (Elizabeth Mattijsen)++ | src/core/set_intersection.pm6
Simplify Map (&) Map
13:20
Geth rakudo: 934c3f9d28 | (Elizabeth Mattijsen)++ | src/core/set_subset.pm6
Simplify Map (<=) Map
13:32
Geth rakudo: eee7714177 | (Elizabeth Mattijsen)++ | src/core/Stash.pm6
Simplify Stash.AT-KEY
13:49
Geth rakudo: 1070fa0c84 | (Elizabeth Mattijsen)++ | src/core/set_difference.pm6
Simplify Setty (-) Map
14:37
rakudo: 368415432b | (Elizabeth Mattijsen)++ | src/core/set_symmetric_difference.pm6
Simplify Map (^) Map
rakudo: 81bcc54056 | (Elizabeth Mattijsen)++ | src/core/set_elem.pm6
Simplify Any (elem) Map
Geth rakudo: fc865a9a06 | (Elizabeth Mattijsen)++ | src/core/set_addition.pm6
Simplified Setty (+) Map and Map (+) Map
14:43
lizmat FROGGS_ o/ 14:48
Geth rakudo: 7f1e41dd32 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm6
Simplifies several QuantHash helper methods
15:00
lizmat and that concludes the Map '$!storage' simplifications I could find
timotimo lizmat: does CORE.setting get noticably smaller from the start of your changes to the end, maybe excluding things jnthn did? 15:01
lizmat m: say 14075824 - 14074208 15:02
camelia 1616
timotimo ok, that's not earth-shattering
but always nice toh ave
lizmat yeah, I think it's more important that methods got closer to the inline limit, I think
timotimo so i've been thinking yesterday 15:05
about the profiler tool
we can offer a pretty simple guide just based on naming and call structure for users who want to compare multiple different implementations of the same task, and automagically UI-ify that for them
timotimo like, if we have a task "florbify" and implementations "florbify_array" and "florbify_hash", we could ask the user to have essentially a sub warm-up_florbify_hash() { for ^100 { florbify_hash() } }; warm-up_florbify_array { for ^100 { florbify_array() } }; sub time_florbify_array { for ^100_000 { florbify_array } }; sub time_florbify_hash { for ^100_000 { florbify_hash } } 15:07
and then warm-up_florbify_hash(); warm-up_florbify_array(); time_florbify_array(); time_florbify_hash() 15:08
timotimo what that won't let us do - yet - is see which GC runs belong to which phase 15:09
and multi-threaded stuff will be difficult to properly assign to the correct phase of execution 15:10
that'll need some additional thinking i guess
Geth nqp/truffle: cac942750d | (Paweł Murias)++ | 6 files
[truffle] Teach @Deserialize how to handle a current HLL param
15:29
Geth ¦ rakudo: zoffixznet self-assigned :enc<utf8-c8> on Proc drops content / SEGVs github.com/rakudo/rakudo/issues/2158 16:02
Geth ¦ rakudo: zoffixznet self-unassigned :enc<utf8-c8> on Proc drops content / SEGVs github.com/rakudo/rakudo/issues/2158 16:21
Geth rakudo/return-type-check-plugin: fe5c8d4973 | (Jonathan Worthington)++ | 2 files
Use a spesh plugin for return value type checks

Decreases the size of the bytecode we produce for return type checks, since the code to do that can be quite complex (especially given the Nil/Failure sneak-through semantics and that we might have a coercion to do). Also lets us optimize some cases a little better.
17:13
nqp: 39bfe08c43 | (Zoffix Znet)++ | tools/build/MOAR_REVISION
[MoarVM Bump] Brings 6 commits

MoarVM bump brought: github.com/MoarVM/MoarVM/compare/2...1-g91d2878 91d2878 Document why we're bumping buffer by 1 f700c13 Merge pull request #936 from xelak6/master 4ec15fc Increase the result buffer size. 09717ad Make the callercode op inline-aware 50b063e Mark sp_speshresolve as :useshll 082dddf Remove incorrect byte sum
17:20
¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...1-g91d2878
rakudo: 74ea72e714 | (Zoffix Znet)++ | tools/build/NQP_REVISION
[NQP Bump] 39bfe08 [MoarVM Bump] Brings 6 commits

NQP bump brought: github.com/perl6/nqp/compare/2018....7-g39bfe08
MoarVM bump brought: github.com/MoarVM/MoarVM/compare/2...1-g91d2878 91d2878 Document why we're bumping buffer by 1 f700c13 Merge pull request #936 from xelak6/master 4ec15fc Increase the result buffer size. 09717ad Make the callercode op inline-aware 50b063e Mark sp_speshresolve as :useshll 082dddf Remove incorrect byte sum
¦ rakudo: version bump brought these changes: github.com/perl6/nqp/compare/2018....7-g39bfe08
roast: 31dacf58f8 | (Zoffix Znet)++ | S32-encoding/decoder.t
Unfudge now-passing test

Closes github.com/rakudo/rakudo/issues/2158 R#2158
17:21
synopsebot R#2158 [open]: github.com/rakudo/rakudo/issues/2158 [SEGV][regression][tests committed][⚠ blocker ⚠] :enc<utf8-c8> on Proc drops content / SEGVs
travis-ci NQP build failed. Zoffix Znet '[MoarVM Bump] Brings 6 commits 17:25
travis-ci.org/perl6/nqp/builds/413690775 github.com/perl6/nqp/compare/56f16...bfe08c43ed
pmurias MasterDuke: I'm going through the 59, trying to get sections of it that don't depend on bigger missing features to pass and thanks to you suprisingly large amounts of ops work :) 19:15
Geth nqp/truffle: 26042b7f91 | (Paweł Murias)++ | src/vm/jvm/runtime/org/perl6/nqp/truffle/nodes/expression/NQPModNumNode.java
[truffle] Use nqp::mod_n semantics NQP wants
19:45
nqp/truffle: 47cb3ca074 | (Paweł Murias)++ | 2 files
[truffle] Implement nqp::sha1
MasterDuke pmurias: yeah, that single test file certainly covers a lot of functionality 21:44
Geth rakudo: fa73bb48d5 | (Elizabeth Mattijsen)++ | 2 files
Add a number of missing deconts

Fix for R#2167
22:03
synopsebot R#2167 [open]: github.com/rakudo/rakudo/issues/2167 [easy to resolve][good first issue][medium difficulty] Explosions due to missing deconts in a bunch of Set ops
lizmat and that concludes my hacking for today& 22:12
Geth nqp: 59429960fb | (Jonathan Worthington)++ | src/vm/moar/QAST/QASTOperationsMAST.nqp
Don't emit decont of callee if unrequired

We can know it's not required when either:
  * It's a QAST::WVal and the value isn't a container
  * It's coming from a speshresolve; these plugins are written by the
   compiler implementor, and in the odd case where the plugin may give
... (6 more lines)
22:21
timotimo oooh nice 22:26
travis-ci NQP build failed. Jonathan Worthington 'Don't emit decont of callee if unrequired 22:26
travis-ci.org/perl6/nqp/builds/413813714 github.com/perl6/nqp/compare/39bfe...429960fbfc
timotimo just jvm failing 22:27
Error while compiling op strfromname (source text: "nqp::strfromname(~$/)"), no registered operation handler