sena_kun m: my Array enum PageSizes «:Letter[0,0,612,792] :Tabloid[0,0,792,1224]»; dd (PageSizes::Letter).value.pairs; dd (PageSizes::Letter).pairs; 10:22
camelia (0 => 0, 1 => 0, 2 => 612, 3 => 792).Seq
Ambiguous call to 'pairs(PageSizes: )'; these signatures all match:
(Enumeration: *%_)
(List:D: *%_)
in block <unit> at <tmp> line 1
sena_kun bisectable6, my Array enum PageSizes «:Letter[0,0,612,792] :Tabloid[0,0,792,1224]»; dd (PageSizes::Letter).value.pairs; dd (PageSizes::Letter).pairs;
bisectable6 sena_kun, Will bisect the whole range automagically because no endpoints were provided, hang tight
sena_kun, Output on all releases: gist.github.com/16b1014d7de3a231f4...925d4b0159
sena_kun, Bisecting by exit code (old=2021.03 new=e2ec160). Old exit code: 0
sena_kun, bisect log: gist.github.com/223dba45e4b44e3d9a...d7dc070b2a
sena_kun, (2021-03-05) github.com/rakudo/rakudo/commit/61...cd6aaef410
sena_kun, Output on all releases and bisected commits: gist.github.com/97d2fc1d9c3b5ea115...1b5d3d44c2
lizmat sena_kun++ 10:28
sena_kun lizmat++ for actually working on things. :) 10:30
lizmat sena_kun: pretty sure you're also working on things :-)
dogbert17 m: my $a = sprintf "%.*f", 7, 0.00000012; say $a 11:02
camelia 0.0000001
dogbert17 hmm, I don't immediately understand this directive 11:03
lizmat: do you know off the top of your head? 11:04
lizmat * allows you to specify the field width as a parameter ? 11:05
rather than in the format ?
dogbert17 m: my $a = sprintf "%.*f", 7, 0.00000012 for ^10
camelia ( no output )
dogbert17 what happens if you run the above on your machine but iterating 1000 times instead? 11:06
on my system BAD things happen
lizmat around ~90 iterations it starts to reliably hang on my machine 11:09
dogbert17 after a while the oom killer might kick in 11:10
lizmat doesn't happen with optmizations switched off
dogbert17 the above is my golf attempt of the problem nwc10 reported in /spec/S32-temporal/juliandate.t 11:10
lizmat looks like a good golf to me :-) 11:11
correction: with --optimize=0, it only happens later 11:12
dogbert17 should it be reported as a rakudo or moarvm problem, what do you think? 11:13
lizmat feels like a MoarVM issue to me
dogbert17 I suspect that as well 11:14
if spesh is turned of the problem vanishes 11:16
*off
dogbert17 github.com/MoarVM/MoarVM/issues/1466 11:24
dogbert17 the problem is not present on the 2021.03 release 11:30
lizmat yeah, I think we'd noticed that before 11:30
dogbert17 cool, I wonder if our bots can bisect this, I'm afraid they will crash 11:31
lizmat dogbert17: devise a piece of code that will timeout after X seconds and then mark that as a failure ? 11:32
dogbert17 that is cheating :-)
bisect: old=2021.03 new=HEAD my $p = Promise.at(now + 2).then({ exit 1 }); my $day-frac = sprintf "%.*f", 7, 0.00000012 for ^500 11:36
bisectable6 dogbert17, Bisecting by exit signal (old=2021.03 new=e2ec160). Old exit signal: 0 (None)
dogbert17, bisect log: gist.github.com/9d1fb7d5099be52867...ed9162d0bd 11:37
dogbert17, (2021-04-08) github.com/rakudo/rakudo/commit/a9...e94c7c765d
lizmat i wouldn't be surprised the decont logging merge is to blame
it was also responsible for 25% performance loss on test-t
dogbert17 investigates while making lunch 11:39
dogbert17 lizmat: your guess was correct 11:49
lizmat yeah. MasterDuke was saying something else was going on, causing the slowdown
so the extra logging was a trigger for other problems, not the cause of the slowdown itself
is what I took away from that discussion 11:50
dogbert17 issue updated with our findings 11:51
lizmat dogbert17++ 11:52
timotimo japhb: i don't know of a cross-program profiling solution, but concating / demuxing Log::Timeline data from multiple processes could be interesting, and of course there's the concepts of how OpenTelemetry / OpenTracing work, where you pass the ID of an "interval" (forgot their name) with requests so you can correlate things happening across multiple processes or machines properly 12:09
but that does require you to have start and end points put in your code that happen to give you a good idea of where to look closer 12:16
i do believe telemeh gives you output for when native calls happen, which includes all the TLS stuff, and i think socket reading/writing is also in there 12:17
telemeh output from two processes is probably not correlatable? i don't know how rdtscp and context switches and different cpu cores interact exactly 12:19
[Tux] Rakudo v2021.03-149-g95d61d684 (v6.d) on MoarVM 2021.03-46-ga29a9cc12
csv-ip5xs0.853 - 0.874
csv-ip5xs-208.877 - 9.221
csv-parser25.840 - 25.844
csv-test-xs-200.378 - 0.382
test7.896 - 8.255
test-t2.354 - 2.437
test-t --race0.929 - 1.016
test-t-2040.804 - 41.867
test-t-20 --race11.290 - 11.344
14:07
tux.nl/Talks/CSV6/images/test-t-d30.png 14:08
lizmat [Tux]: the problem has been localized, the revert / fix just didn't make it to Rakudo yet 14:13
[Tux] 👍🏻 14:16
is optimizing breaks's into non-exceptions where possible still on the todo? 14:17
lizmat it is afaik 14:18
[Tux] top
lizmat well, not near the top :-)
[Tux] I know. Lemme just keep hope(s) 14:19
lizmat I think you will find Text::CSV to be a lot faster after newdisp lands
[Tux] I also note that RT#122892, RT#123597, RT#123980, RT#61602, and RT#127358 still show unresolved in my local test suite 14:20
lizmat perhaps refer to them in the new repo ? 14:21
[Tux] I could do so. What repo shall I put them in as issue?
github.com/rakudo/rakudo/issues ← that one? 14:23
lizmat no
you don't need to add issues, just change the reference
I'm trying to find the mapper for that 14:25
[Tux] So change RT#122892 to issue#3430 ?
Which shows as resolved. /me looks into this specific issue 14:27
lizmat 123597 now lives at: github.com/Raku/old-issue-tracker/issues/3645 14:29
123980 now lives at: github.com/Raku/old-issue-tracker/issues/3717
[Tux] tux.nl/Files/rt#122892.pl 14:30
lizmat not found?
61602 now lives at: github.com/Raku/old-issue-tracker/issues/520
127358 now lives at: github.com/Raku/old-issue-tracker/issues/5082 14:31
I'm not sure where 122892 lives
[Tux] tux.nl/Files/issue-3430.pl 14:32
lizmat download ? 14:33
[Tux] gist.github.com/Tux/110e7b8e266b5f...0d060018e4 14:35
lizmat I think the error message explains ? 14:42
also: s/.perl/.raku/ :-)
[Tux] done and pushed 14:46
tux.nl/Files/20210410164859.png - I'll see if I can understand the reds 14:49
now to the kitchen. my turn to cook
lizmat m: dd Nil.IO # this feels weird, yet making that return Nil breaks installation of core modules :-( 16:30
camelia IO::Path
japhb timotimo: Hmmm, thank you for the ideas. :-) 18:19