00:03 Altai-man_ joined 00:05 cognomin_ joined 00:06 sena_kun left 00:09 cognominal left 00:43 lucasb left 00:58 Altai-man_ left 01:11 moon-child left 01:16 moon-child joined 02:17 cognominal joined 02:20 cognomin_ left 03:08 cognomin_ joined 03:12 cognominal left
lizmat Files=1290, Tests=109646, 208 wallclock secs (28.37 usr 8.24 sys + 2931.04 cusr 263.28 csys = 3230.93 CPU) 04:45
07:09 reportable6 left 07:11 reportable6 joined
[Tux] Rakudo version 2019.11-53-g1945b9d27 - MoarVM version 2019.07.1-322-g8d0b50d3f
csv-ip5xs0.723 - 0.783
csv-ip5xs-206.580 - 6.963
csv-parser21.731 - 22.650
csv-test-xs-200.414 - 0.440
test7.173 - 7.327
test-t1.815 - 1.931
test-t --race0.848 - 1.010
test-t-2029.824 - 30.005
test-t-20 --race9.849 - 9.907
 08:37
(I am working on the box, as traffic is very heavy today)
09:11 patrickb joined 09:32 robertle joined 10:16 sena_kun joined 11:54 MasterDuke joined 12:04 Altai-man_ joined 12:07 sena_kun left 12:14 maettu left 12:16 maettu joined 12:22 maettu left 12:24 maettu joined 12:49 lucasb joined 13:14 EuAndreh[m] left, tyil[m] left 13:15 timotimo[m] left, Demos[m] left, AlexDaniel` left, rba[m] left 14:05 sena_kun joined 14:06 Altai-man_ left 14:34 AlexDaniel` joined, rba[m] joined, Demos[m] joined, EuAndreh[m] joined, tyil[m] joined, timotimo[m] joined 15:00 robertle left
Geth rakudo: 9d895914d5 | (Elizabeth Mattijsen)++ | src/core.c/DateTime.pm6
Make DateTime.new(epoch) about 20% faster

  - evade an expensive %hash.Bool check
  - cut down on number of Scalar containers needed by binding		 15:03
16:04 Altai-man_ joined 16:06 sena_kun left 16:22 patrickb left 18:05 sena_kun joined 18:07 Altai-man_ left 18:25 Guest38485 left 18:41 Guest38485 joined
Geth roast/master: 4 commits pushed by (Brian Collins)++, (Vadim Belman)++ 19:07
19:13 MasterDuke left
AlexDaniel c: 2019.07.1 gist.github.com/AlexDaniel/00198fa...5a435f70ef 19:30
committable6 AlexDaniel, ¦2019.07.1: «Could not connect socket: Connection refused␤ in block <unit> at ./sandbox/3326.p6 line 12␤␤ «exit code = 1»»
AlexDaniel c: 2019.07.1 gist.github.com/AlexDaniel/00198fa...5a435f70ef 19:31
committable6 AlexDaniel, ¦2019.07.1: «6.63195245␤»
AlexDaniel c: 2019.07.1 gist.github.com/AlexDaniel/00198fa...5a435f70ef
committable6 AlexDaniel, ¦2019.07.1: «6.7501165␤»
AlexDaniel c: 2019.11,2019.11,2019.11,2019.11 gist.github.com/AlexDaniel/00198fa...5a435f70ef
committable6 AlexDaniel, ¦2019.11: «7.384993␤» ¦2019.11: «7.3110439␤» ¦2019.11: «7.2990605␤» ¦2019.11: «7.8245853␤» 19:32
AlexDaniel I mean… indeed?
didn't expect to reproduce it that easily
19:33 jmerelo joined
AlexDaniel c: 2019.07.1,2019.07.1,2019.11,2019.11 gist.github.com/AlexDaniel/00198fa...5a435f70ef 19:34
committable6 AlexDaniel, ¦2019.07.1: «6.680612␤ «exit code = 42»» ¦2019.07.1: «6.65002243␤ «exit code = 42»» ¦2019.11: «7.2000728␤» ¦2019.11: «7.2845414␤»
AlexDaniel feels stable to me
bisect: 2019.07.1,2019.11 gist.github.com/AlexDaniel/00198fa...5a435f70ef 19:35
bisectable6 AlexDaniel, Using old=2019.07.1 new=2019.11 in an attempt to do what you mean
AlexDaniel, Bisecting by exit code (old=2019.07.1 new=2019.11). Old exit code: 42
AlexDaniel, bisect log: gist.github.com/f13bd0d8f43e344a64...5bd43dbb3b 19:36
AlexDaniel, (2019-08-06) github.com/rakudo/rakudo/commit/ae...accfc1e47f
AlexDaniel ok this can't be it 19:37
bisect: ae4ba74262b^,ae4ba74262b gist.github.com/AlexDaniel/00198fa...5a435f70ef
bisectable6 AlexDaniel, Using old=ae4ba74262b^ new=ae4ba74262b in an attempt to do what you mean
AlexDaniel oops
bisectable6 AlexDaniel, Bisecting by output (old=ae4ba74262b^ new=ae4ba74) because on both starting points the exit code is 0 19:38
AlexDaniel, bisect log: gist.github.com/2a86362d4c3c59c019...6f6cd7f7f7 19:39
AlexDaniel, (2019-08-05) github.com/rakudo/rakudo/commit/7a...120cc6b8d2
AlexDaniel what
c: ae4ba74262b^,ae4ba74262b gist.github.com/AlexDaniel/00198fa...5a435f70ef
committable6 AlexDaniel, ¦ae4ba74262b^: «6.705859␤ «exit code = 42»» ¦ae4ba74: «7.51988679␤»
AlexDaniel …that's exactly it 19:40
c: ae4ba74262b^,ae4ba74262b^,ae4ba74262b^,ae4ba74262b^,ae4ba74262b^,ae4ba74262b^,ae4ba74262b,ae4ba74262b,ae4ba74262b,ae4ba74262b,ae4ba74262b,ae4ba74262b gist.github.com/AlexDaniel/00198fa...5a435f70ef 19:41
vrurg: this doesn't make any sense
vrurg: how could it possibly affect performance
committable6 AlexDaniel, gist.github.com/44c459e804c8a2d023...eb669243cf 19:42
AlexDaniel but it does 19:43
vrurg AlexDaniel: boomer... 19:44
github.com/rakudo/rakudo/commit/7a...120cc6b8d2 is the bisected one, right?
AlexDaniel no no (2019-08-06) github.com/rakudo/rakudo/commit/ae...accfc1e47f
vrurg Not a little bit better... The real one could be +/-2 commits away from the bisect result. 19:46
Actually, what I would like to do is to run it through all compilable commits and build a graph.
AlexDaniel we can do that 19:47
it won't help you, though
because that's exactly the commit where performance changed
vrurg But doing so on my laptop makes little sense because macbook's active throttling makes benchmarking almost useless. Have to run in on one of my VM servers on a remote location. 19:48
AlexDaniel: what makes you so assured?
AlexDaniel vrurg: give me like a range of 50 commits and we'll do it real quick
vrurg: this: gist.github.com/44c459e804c8a2d023...eb669243cf
even with the noise it's very consistent 19:49
shareable6: ae4ba74262b^ 19:50
shareable6 AlexDaniel, whateverable.6lang.org/ae4ba74262b^
AlexDaniel shareable6: ae4ba74262b
shareable6 AlexDaniel, whateverable.6lang.org/ae4ba74262b
AlexDaniel ok I just confirmed that gcc version didn't change for these builds 19:52
vrurg Most convincing would be to see -10/+10 commits around it.
Or even -20/+20 to have 40 commits covered. 19:53
Then it could be tested on the master with and without 5 lines starting from github.com/rakudo/rakudo/commit/ae...2330fcR686 19:54
AlexDaniel vrurg: give me the start sha and end sha 19:55
and we'll plot it
vrurg Starting one: ecf2b1e4fa9605737cb6b657fb6b7bdd879fc4f8 19:56
Not that simple to move forward...
And lets finish with 7e1062659fb638abfe2af1563c5b59c953f18bc5 19:57
AlexDaniel c: ecf2b1e4fa..7e1062659f say 42 19:58
committable6 AlexDaniel, gist.github.com/aaddc9e89c2e6c69c4...6f289b13a7 19:59
AlexDaniel that's 70 commits but ok
c: ecf2b1e4fa..7e1062659f gist.github.com/AlexDaniel/00198fa...5a435f70ef
and then YOU WAIT 20:00
:)
20:04 Altai-man_ joined 20:06 sena_kun left
committable6 AlexDaniel, gist.github.com/83d8994ca0d980058c...e8e0898954 20:08
AlexDaniel vrurg: ↑ 20:09
so 7aa2848fa90 is kinda weird too 20:12
it's not linear, there was a merge, so it can look confusing
vrurg boomer, boomer, boomer... Does it mean that 6.c is that slow?
7aa2848fa90 could be a fluctuation. 20:13
AlexDaniel pretty sure it's not
c: 7aa2848,7aa2848,7aa2848,7aa2848 gist.github.com/AlexDaniel/00198fa...5a435f70ef 20:14
committable6 AlexDaniel, ¦7aa2848: «6.6688785␤ «exit code = 42»» ¦7aa2848: «6.6047737␤ «exit code = 42»» ¦7aa2848: «6.52240997␤ «exit code = 42»» ¦7aa2848: «6.8350428␤ «exit code = 42»»
AlexDaniel ok it is
vrurg Since it's a merge, I would also test around 74f2d3f46 which the other side. 20:15
AlexDaniel it already did, I think 20:16
also ae4ba74262b is not a merge
vrurg: also you probably mean “bummer”, boomer is somebody else :D 20:17
vrurg Aha, sounds similar... thanks... 20:18
But it's a weird thing anyway. It turns out that performance depends on compiler version. And, basically, in this case it means 6.d beats 6.c. 20:19
20:20 jmerelo left
nine Which is not surprising at all 20:20
vrurg nine: Well, not to me. I don't see anything related to optimizations which would depend on language revision in the core. 20:25
nine vrurg: decontrv vs. decontrv_v6c for example 20:27
vrurg nine: ok, makes sense. 20:30
Geth rakudo: vrurg self-assigned Async socket performance regression in 2019.11 github.com/rakudo/rakudo/issues/3326
cd321254d3 | (Elizabeth Mattijsen)++ | src/core.c/DateTime.pm6

  - don't use native ints, but bind to Int results
  - don't use infix:<div>, but nqp::div_I, we don't need a check for /0
  - don't use infix:<%>, but nqp::mod_I, we don't need a check for /0
Oddly enough, could *not* remove all use of infix:<%> (see code comments). I wonder if that's tickling an optimization bug of some sort.		 20:31
AlexDaniel vrurg: but why is it about 6.c if we default to 6.d? 20:35
vrurg AlexDaniel: And 6.e for core.e... There was a couple of reasons. Anyway, I need to think about a way around. 20:36
20:38 MasterDuke joined
vrurg I wonder how we gonna handle this when 6.e becomes the default. Shall 6.c core be compileable with 6.e? 20:43
nine vrurg: we keep old versions around to stay backwards compatible with existing code. I'm pretty sure we can upgrade our own code to the latest standard though :) 21:24
Geth problem-solving/CoC: 946e4d14d5 | (Elizabeth Mattijsen)++ | solutions/language/Path-to-Raku.md
Revert "s/RAKU_HOME/RAKUDO_HOME/"

This reverts commit 0ac3cb71be630f4b353c3e02775fb8d85d009530.		 21:52
problem-solving/CoC: 182828725a | (Elizabeth Mattijsen)++ | solutions/meta/CoC.md
Initial version of CoC

This is essentially a markdown version of
   raw.githubusercontent.com/perl6/sp...draft.pod6
with s/Perl 6/Raku/, intended as a starting point to further alterations and additions to make it up-to-date and applicable to today's realities.
lizmat hmmm... that first commit is an artefact :-(
22:05 sena_kun joined 22:06 Altai-man_ left 22:19 pmurias joined
Geth problem-solving/CoC: 732854aa1d | (Elizabeth Mattijsen)++ | solutions/language/Path-to-Raku.md
Revert "Revert "s/RAKU_HOME/RAKUDO_HOME/""

This reverts commit 946e4d14d568b7e47ea99420b729ce84b13b485d.		 22:34
problem-solving: lizmat++ created pull request #136:
A CoC for Raku		 22:38
23:00 jjatria joined
lizmat AlexDaniel: samcv tells me the tarballs should be there now 23:25
samcv sorry about that everyone. i released it after a late day at the office then logged off irc for a while 23:26
AlexDaniel OK 23:32
samcv: thank you ♥
I think I'm done now :)

Powered by Cro and the Raku® Programming Language.

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

Thank you!