🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
00:00 evalable6 joined 00:06 reportable6 left 00:07 reportable6 joined 01:14 frost joined 03:34 linkable6 left, evalable6 left, quotable6 left, greppable6 left, squashable6 left, unicodable6 left, tellable6 left, notable6 left, bisectable6 left, coverable6 left, statisfiable6 left, bloatable6 left, releasable6 left, benchable6 left, reportable6 left, sourceable6 left, committable6 left, nativecallable6 left, shareable6 left, releasable6 joined, statisfiable6 joined 03:35 quotable6 joined, tellable6 joined 03:36 unicodable6 joined, bisectable6 joined, evalable6 joined, committable6 joined, reportable6 joined, greppable6 joined, nativecallable6 joined 03:37 bloatable6 joined, squashable6 joined, notable6 joined, benchable6 joined, linkable6 joined, coverable6 joined, sourceable6 joined, shareable6 joined 06:07 reportable6 left 06:09 reportable6 joined
Xliff \o 06:10
tellable6 2022-09-04T11:31:05Z #raku-dev <lizmat> Xliff: wow, that's.... unexpected
2022-09-04T11:32:08Z #raku-dev <lizmat> Xliff: oddly enough, I don't see any slow down in core compilation
2022-09-04T12:00:51Z #raku-dev <lizmat> Xliff: could you golf a piece of code that compiles noticeably slower: I cannot reproduce what you see locally :-(
Xliff lizmat: Sorry. All I can pass along are my weekly compilation logs that I aborted, yesterday. 06:11
lizmat: Can you confirm stage parse time on your end? What time are you seeing? 06:12
lizmat no change 06:48
30 sec for stage parse of 6.c core 06:49
on my M1 mini
06:58 nebuchadnezzar joined
Xliff OK, I am getting 71 seconds. Last week it was 35 and fine. 07:17
So maybe I need to *sigh* nuke my moar blead.
Might be something environmental since I've recently had lots of system instability. 07:18
Another compile takes 70.511 07:20
So another 71.133 seconds after a nuke 07:25
And this is moar-blead
lizmat: Have often do you compile from git?
lizmat well... if I'm working on core stuff, several times a day 07:47
lately I've been focusing more on App::Rak...
07:48 sena_kun joined
lizmat core build time on my Intel mac also are normal 08:26
Xliff lizmat: Thanks. So it's more than likely environmental. 08:33
Wheee.
lizmat Xliff: *or* your code is using some feature that tickles something that slows things down
you are sure it is caused by the commit you mentioned ? 08:34
Xliff I don't think I mentioned a specific commit.
'And this is rakudo.
When CORE.c compile time comes in at over 40 seconds, I worry.
It generally hovers between 29 and 39 seconds.
And while I'm not actually documenting Raku compiles (and perhaps I should) I have been doing these weekly compiles for almost 2 years. 08:35
new-disp growing pains not withstanding. :) 08:36
So if there was a regression, it was done within the last week. Previous weeks compile times ran fine.
Not doing them this week because of the visible regression.
p6-GLib usually hovers in at around 345 seconds. Yesterday it took over 700! 08:37
Fortunately, I can still focus on $dayJob, which I have turned into a Raku-leaning position.
lizmat Xliff++ 08:41
Xliff: do you happen to use a lot of generics in your code ?
vrurg ^^ 08:42
Xliff lizmat: A moderate bit, yes. However not so much for my work in $dayJob, which has also been slightly affected. 08:50
09:08 evalable6 left, linkable6 left
nine You sure you're running an optimized build of MoarVM? 09:08
09:09 linkable6 joined 09:10 evalable6 joined 09:36 sena_kun left
Xliff nine: Yes. Again, I've been running these compiles for over 2 years. 09:39
So the process is unchanging from week to week
So I now have to assume it is due to recent problems with the environment itself. Those are harder to debug.
Geth nqp: c25f65458b | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM for latest fixes
09:52
10:09 sena_kun joined
Geth rakudo: 7342d9dc28 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get the latest MoarVM fixes
10:13
10:44 gfldex left, nine left, tailgate left 10:49 gfldex joined, nine joined, tailgate joined 10:54 Xliff left 12:09 reportable6 left 12:10 reportable6 joined 12:31 frost left 12:35 Kaiepi left 12:36 Kaiepi joined
lizmat notable6: weekly 12:50
notable6 lizmat, No notes for “weekly”
vrurg I'm a little bit lost about Xliff issues. Are they about compiling Rakudo? Or compiling gtk? 13:15
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2022/09/05/2022-...-in-at-50/ 13:25
vrurg: Xliff is seeing up to 2x slower compilation times in their code, /me does not see that in core compilation 13:26
however, it appears Xliff's code is using some generics, and since you worked on that recently, I thought I'd ping you on this 13:27
sena_kun lizmat++ 13:29
vrurg There is possible slowdown on run-time when generics are used, but that's because generics as such are nearly run-time only feature. But there is no chance it could affect Rakudo core compile times. 13:31
lizmat well, It *isn't* about core compile times, but Xliff library compile times 13:32
vrurg Neither compilation of modules should be affected because that would mean the core is using a lot of generics which is not true.
lizmat well... something changed in the past week... :-) 13:33
vrurg The only way to find out is to bisect. 13:34
lizmat yeah :-)
Unfortunately, Xliff is the only one with code to bisect 13:35
13:36 linkable6 left, evalable6 left, evalable6 joined 13:37 linkable6 joined
vrurg I just've refreshed my memory. The slowdown is possible due to the need to instantiate a generic if used as return type. And dispatching over a generic needs one extra guard over routine's return type because it is not something static per-signature. 13:41
But I don't see how this could cause 2x slowdown on compile times. BEGIN with lots of generics? Even then... 13:42
|Tux| Rakudo v2022.07-35-g7342d9dc2 (v6.d) on MoarVM 2022.07-9-g740f3bcbe
csv-ip5xs0.795 - 0.811
csv-ip5xs-205.094 - 5.330
csv-parser3.476 - 3.800
csv-test-xs-200.406 - 0.407
test6.222 - 6.403
test-t1.380 - 1.407
test-t --race0.826 - 0.827
test-t-2020.868 - 21.982
test-t-20 --race6.369 - 6.511
14:28
14:58 linkable6 left, evalable6 left, evalable6 joined, linkable6 joined 17:17 sena_kun left 17:49 sena_kun joined 17:53 melezhik joined 18:06 reportable6 left 18:08 reportable6 joined 18:31 epony left 18:33 epony joined 19:09 sena_kun left 19:11 melezhik left, sena_kun joined 19:36 squashable6 left 19:38 squashable6 joined 20:38 linkable6 left, evalable6 left 20:39 linkable6 joined 20:41 evalable6 joined, sena_kun left 20:49 sena_kun joined, sena_kun left 23:04 sourceable6 left, coverable6 left, statisfiable6 left, nativecallable6 left, unicodable6 left, benchable6 left, quotable6 left, linkable6 left, evalable6 left, greppable6 left, squashable6 left, releasable6 left, tellable6 left, committable6 left, bisectable6 left, releasable6 joined 23:05 linkable6 joined, benchable6 joined, quotable6 joined, squashable6 joined, sourceable6 joined, statisfiable6 joined 23:06 nativecallable6 joined, bisectable6 joined, tellable6 joined, coverable6 joined, greppable6 joined, unicodable6 joined 23:07 committable6 joined, evalable6 joined 23:57 squashable6 left 23:59 squashable6 joined