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:17 dct left
releasable6 Next release in ≈1 day and ≈15 hours. 4 blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 03:00
04:38 Ven`` joined 04:47 Ven`` left 05:01 tyil left 05:15 tyil joined 05:48 robertle left 06:33 jmerelo joined
jmerelo Hi 06:34
07:22 ufobat_ joined 07:38 jmerelo left
samcv nice. ok i'm free tomorrow for release 07:57
also i am looking into being organizer for PerlCon 2020
[TuxCM] goed bezig Sam! 07:58
samcv i am in talks with people at booking about getting time off to do it or possibly doing it on work time, or partially on wowrk time 08:02
the guy was very suprised i'd only been working there for 5 weeks :P
08:08 tyil left 08:17 tyil joined
Tux__ Rakudo version 2018.12-302-g121ca5fda - MoarVM version 2018.12-105-gc0435e55a 09:51
csv-test-xs-20 0.430 - 0.431
csv-ip5xs 0.741 - 0.758
test-t --race 0.861 - 0.903
test-t 1.868 - 1.883
csv-ip5xs-20 6.097 - 6.245
test 7.117 - 7.185
test-t-20 --race 10.680 - 10.872
csv-parser 22.378 - 22.926
test-t-20 31.840 - 33.044
jnthn Good morning o/ 10:23
lizmat jnthn o/ 10:44
m: FOO: for <a b> { FIRST say "bar"; .say; last } # works fine 10:45
camelia bar
a
lizmat m: FOO: for <a b> { FIRST say "bar"; .say; last FOO } # huh?
camelia bar
labeled last without loop construct
in block <unit> at <tmp> line 1

a
10:59 dogbert2_ joined
lizmat bisectable: FOO: for <a b> { FIRST say "bar"; .say; last FOO } 10:59
bisectable6_ lizmat, Bisecting by exit code (old=2015.12 new=121ca5f). Old exit code: 0
lizmat, bisect log: gist.github.com/478f77f09ea66e4ac6...a244cfbb77 11:00
lizmat, (2017-01-29) github.com/rakudo/rakudo/commit/03...481f13ac5f
dogbert2_ jnthn: any theories as to why github.com/rakudo/rakudo/commit/ee...ba22d24f4e slows down some code as much as 80% and increasing the amount of GC's massively?
jnthn dogbert2_: No 11:04
What code?
dogbert2_ jnthn: sec
jnthn: gist.github.com/dogbert17/7423640a...0295154ee9
I can't say that it's $work code but worth mentioning anyway :) 11:05
jnthn Hmmmm
dogbert2_ uh oh
lizmat 29M Scalar allocations ? 11:06
dogbert2_ yes
before it was 2M allocations 11:07
lizmat looks to me that @a[$i * $j++] = 1 is boxing the 1 every time ??? 11:10
also: it is winding up in the ASSIGN-POS(int,Int) candidate, rather than the ASSIGN-POS(int,int) one
dogbert2_ compared with older code I noticed that a call to push-all was no longer jit'ed although it was before 11:11
lizmat: I guess that the increased number of gc's has something to do with the 29M scalars 11:15
lizmat yeah, that's just the result of the many allocations
dogbert2_ lizmat: the code is one of my test benchmarks which I use quite often so I knew that the change causing this was quite recent 11:16
lizmat dogbert2_++ # good to know these exist
jnthn There's only one NQP commit involved too 11:17
dogbert2_ jnthn: does it make any sense? 11:18
jnthn No.
In that the code in question doesn't seem to be doing any compile-time evaluation 11:19
dogbert2_ it is very odd, but the previous rakudo commit, i.e. github.com/rakudo/rakudo/commit/d9...5f29c5b8c3 doesn't have this regression 11:20
jnthn has a poke at it 11:30
dogbert2_ jnthn++
lizmat jnthn: changing the last lines to "say @a.grep(* > 1).sum;" seems to tickle a weird OSR / deopt case: 148484 On Stack Replacements / 282176 deoptimizations 11:31
jnthn I can imagine how that one happens 11:33
We don't yet have anything to discard bad choices in specialization
dogbert2_ runtime: HEAD: real 0m5,946s d904b7048bf: real 0m3,490s
jnthn Oh, I guess CORE.setting perhaps has things that are compile-time evaluated 11:34
And it's tripping over one of those
Hmm
jnthn wonders how to have cake and eat it... 11:35
lizmat suspects the " = 1 " 11:36
jnthn ?
lizmat as a thing that may get compile-time evaluated ?
as part of constant folding > 11:37
?
jnthn Oh,
No, that's not a problem 11:38
It's that some code in CORE.setting is used at BEGIN time
I suspect it's that, anyway
lizmat perhaps the BEGIN hack I put in the core_epilogue recently ?
jnthn No, it's the commit dogbert2_ found 11:39
And it'll be because we index an array or some such in a BEGIN or constant or whatever in CORE.setting
There's probably quite a few places that do that
lizmat ah, I think I understand 11:41
dogbert2_ note that both head and d904b7048bf allocates 29M scalars, it's 2018.10 which only allocates 2M, still both 2018.10 and d904b7048bf are a lot faster than HEAD 11:42
2018.10 is the fastest though: real 0m3,317s and 63 GC's. Head and d904b7048bf do 376 GC's on my machine 11:43
jnthn The change I put in was becuase if a closure was taken inside of a BEGIN block then it was against a provisional compilation and it could have bogus lexical indices
...somehow :)
Since I think it only afflicted a closure in such code, I guess we might recover it by making it check we're actually inside of one 11:44
Adding such a check gets a bit back, but not everything 11:46
Or I think not everything, need another measurement
No, not close to everything. 11:48
I wonder if I can find a different solution to the regression I was fixing
dogbert2_ perhaps you can if you have some l...h 11:53
jnthn :) 11:54
Mm....celery soup today, I think
dogbert2_ no Indian food? 11:58
jnthn Not today :)
Had some earlier this week
And probably will at the weekend
I can relax it a bit and not regress on the bug and get back some of the performance 11:59
But still not all of it 12:00
dogbert2_ a tricky problem then
I find it interesting that 2018.10 only needs to do 2M scalar allocs given that the profiler isn't lying to me 12:02
jnthn I'm a bit curious which cases are triggering compilation of slower lookups that are on the hot path here
After my tweak, I mean. 12:03
I expected that'd get the bunch of them
Ah, think I got a fix that does both 12:10
It can spectest while I lunch )
dogbert2_ clever move, jnthn++
dogbert2_ follows jnthn's example and goes for lunch 12:11
12:15 lucasb joined 12:46 tyil left
jnthn Yay, it passes 12:58
dogbert2_ hooray 13:00
13:02 tyil joined
jnthn Pushed both NQP and Rakudo fixes 13:05
lizmat did we lose Geth again? 13:09
dogbert2_ how much speed did you manage to regain? 13:11
jnthn lizmat: Looks like 13:14
dogbert2_: I think all of it
haha
PEA: replacement impossible due to prof_allocated
The profiler is preventing scalar replacement :P
I guess ideally we'd rewrite it to an op that logs the number of replaced allocations 13:15
dogbert2_ on my system I now get: real 0m3,679s 13:20
that's a two second improvement 13:21
jnthn And as good as it used to be? 13:32
btw, working on the profiler 13:33
lizmat fwiw, this also seems to affect test-t in a positive way :-) 13:34
jnthn :) 13:36
So, it wasn't the pea merge after all
lizmat let's see what the next test-t says... pretty sure it won't be near 1.6, but rather at about 1.8 still 13:38
perhaps 1.75
dogbert2_ jnthn: yes, as good as it used to be 13:43
jnthn Good. 13:45
dogbert2_ only 2018.10 is a bit faster 13:46
but not by much 13:47
jnthn m: say 13:50
camelia 5===SORRY!5===
Argument to "say" seems to be malformed
at <tmp>:1
------> 3say7⏏5<EOL>
Other potential difficulties:
Unsupported use of bare "say"; in Perl 6 please use .say if you meant to call it as a method on $_, or use an …
jnthn grr
m: say 29326275 - 153082
camelia 29173193
jnthn That's how many Scalar container allocations PEA gets rid of :) 13:51
Now that the profiler doesn't block the optimization happening
Profiler UI doesn't report that yet
In fact, not spitting the info out for it yet
Oh, also not JITting that prof_replaced yet either, but that's in theory easy :) 13:52
Yay, there we go 13:54
japhb Always nice to see someone having a productive day. :-) 13:56
dogbert2_ jnthn++ is on a roll
must be that Celery soup :)
jnthn timotimo++ can probably do nice stuff in his shiny new profiler UI, but I've also put a simple calculation/display on the overview page of the HTML output of the built-in one too 14:18
In this case, "Scalar replacement eliminated 29172848 allocations (that's 89.4%)." :)
Which is, uh, unusually good :P
.tell timotimo github.com/MoarVM/MoarVM/commit/64...603d6f595b 14:24
yoleaux jnthn: I'll pass your message to timotimo.
jnthn All pushed :)
timotimo o/ 14:55
yoleaux 14:24Z <jnthn> timotimo: github.com/MoarVM/MoarVM/commit/64...603d6f595b
timotimo jnthn: do we want logging for "scalar-replaced object was materialized"? 14:56
dogbert2_ hi timotimo 14:57
jnthn timotimo: Hmm, maybe some day 14:59
Though I guess deopt is relatively rare
I mean, if you're motivated to add it right away, sure :)
timotimo motivation? in this economy?! ;) 15:04
15:05 Geth left, Geth joined, ChanServ sets mode: +v Geth 15:19 Tux__ is now known as |Tux|
|Tux| The number of languages is still growing :) tux.nl/Talks/CSV6/speed5.html 15:20
dogbert2_ |Tux| interesting numbers 15:36
I see that, according to the profiler, running test-t, from |Tux| CSV repo, there are 30k local deopts. Is that much? 15:40
jnthn dogbert2_: It's quite a lot, but not automatically bad 15:43
dogbert2_ I guess it's application dependant but it 'felt' high
timotimo hard to say what percentage of a frame's run are pre- vs post-deopt 15:45
like, does the frame have a loop in it that runs a whole bunch before it stumbles upon a deopt? or is it a short frame that deopts on the second-to-last instruction? or is it a frame that deopts in the first 10%?
but if there's a loop, it'll try to OSR again, right?
jnthn Yes, it'll typically try to deopt again 15:47
timotimo re-opt :)
jnthn I mean, if you look at a `for $fh.lines() { }` it'll typically deopt quite often - once per time it needs to read from the filesystem because it depleted its buffer.
And it's a strategic deopt there, 'cus it keeps the rare path out of the optimized code 15:48
timotimo the moarperf profiler will display deopt and OSR info better soon-ish
jnthn But yeah, it feels high enough it'd be worth looking into where it's happening
timotimo: yay :)
timotimo i haven't looked into why exactly it doesn't already, i've put a little bit of code in, but it seems to always give 0s
|Tux| has no idea what a deopt is:/ 15:54
timotimo it's when the optimized code was built based on an assumption and the assumption wasn't upheld in one spot 15:55
|Tux| thnx
timotimo when that happens, the optimized code isn't allowed to continue running as it was; it has to be "deoptimized"
depending on how complex the optimizations have been, undoing them can become more and more complex
dogbert2_ 10k deopts in e.g. reify-until-lazy SETTING::src/core/List.pm6:99 15:56
|Tux| in this test case, the code is pretty "stable": there are no attributes of the global CSV object that change during the process
dogbert2_ thx for the explanation
|Tux| (which is allowed in user-cases)
dogbert2_ perhaps it has something to do that the csv file in question contains 10k lines 15:58
|Tux| likely then 15:59
dogbert2_ was a bit shocked when I saw that Perl6 is slower than Rust :)
timotimo we've got a bit more work to do for sure :) 16:01
16:41 ufobat___ joined 16:45 ufobat_ left
lucasb can I request the creation of additional labels to help categorize rakudo issues? 17:36
timotimo you can definitely request it :)
lucasb I think "native types" and "type captures" would fit into some issues 17:37
there's nativecall but no "native types"
I wish I could label the issues myself, but I don't have the rights... 17:38
timotimo hm, "type captures" 17:39
maybe that can be made a little less specific
lucasb timotimo: there's a list of bugs with regard type captures, there's why I thought of a dedicated label
timotimo are all type capture related issues regarding signatures of subs, or also some for roles? 17:40
lucasb bugs when "role R[::Type] {...}" and "sub f(::Type $x)" doesn't get properly captured
timotimo mhm 17:41
would you say CStruct would also fit into "native types"? how about Buf? my int @foo? 17:42
lucasb I was thinking initially of int/uint/num/str issues, but hey, the more aways issues are labeled, the better, no? :) 17:44
*more ways
timotimo we can probably have a single label just for "unsigned" support
"native types" now exists, though the description could probably use an improvement 17:45
lucasb timotimo: thanks 17:46
timotimo could "generic types" be a label for the "type captures" thing? 17:47
lucasb don't you prefer a Perl 6 term instead of a Java one? :) 17:48
j/k 17:49
jnthn I thought that terminology was...generic :) 17:50
timotimo hey, that's type erasure 17:51
AlexDaniel` samcv:
samcv: well, I'm away till Monday…
lucasb native types issues: R#2692 R#2579 R#2542 R#2541 R#2414 (if someone could label them :) 17:54
synopsebot R#2692 [open]: github.com/rakudo/rakudo/issues/2692 Accessing native attributes discards sign information
R#2579 [open]: github.com/rakudo/rakudo/issues/2579 smallnatives are neither tested nor working
R#2542 [open]: github.com/rakudo/rakudo/issues/2542 A native variable definition + initialization is **not** a left value
R#2541 [open]: github.com/rakudo/rakudo/issues/2541 Post-incrementing native integers across overflow boundary
R#2414 [open]: github.com/rakudo/rakudo/issues/2414 [perf] Native attrs compile into an attrref instead of attr
AlexDaniel` and I think there were some changes in moarvm after the last time I ran Blin
so-o-o… enjoy that free time? :)
I mean, maybe having a changelog ahead of time would be nice…
lucasb R#2354 17:56
synopsebot R#2354 [open]: github.com/rakudo/rakudo/issues/2354 uintN handles signature bit differently for scalars and attributes
18:04 dct joined 19:21 dct left 19:52 robertle joined
[TuxCM] On request of lizmat 20:04
Rakudo version 2018.12-303-g4a2124a62 - MoarVM version 2018.12-106-g64d41cc1b
csv-ip5xs0.734 - 0.753
csv-ip5xs-206.333 - 6.462
csv-parser23.568 - 23.837
csv-test-xs-200.438 - 0.446
test7.690 - 8.365
test-t1.912 - 1.929
test-t --race0.874 - 0.977
test-t-2032.344 - 32.636
test-t-20 --race10.764 - 10.920
lizmat hmmm... disappointing :-( I'd expected more :-(
in reduction of test-t
21:36 MasterDuke left 21:54 pyrimidine left 21:55 pyrimidine joined 22:49 sivoais left 22:55 lucasb left
releasable6 Next release in ≈19 hours. 4 blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 23:00
23:07 TreyHarris 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!