🦋 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.
[Coke] yes, next blin run will probably do that. 00:11
... I'll kick that off now while thinking of it. 00:12
Merging GLOBAL symbols failed: duplicate definition of symbol SSL # haven't seen that in a while 00:22
ok, maybe will kick this off tomorrow... 00:24
00:24 MasterDuke left 01:03 MasterDuke joined
MasterDuke timo: any idea why there are so many deopts happening when compiling CORE.c.setting with rakuast? 01:04
MVM_spesh_deopt_find_inactive_frame_deopt_idx was called ~40m times 01:05
and `spesh_cand->body.num_deopts` has some decently high numbers. most common value is 86 at 3.7m times, and 1134 (which is one of the largest numbers) occurs 556k times 01:07
guess i should see what the numbers are during a non-rakuast compile to compare...
ok, almost the same. 36m total calls. largest value is actually almost twice as high (2700) 01:17
but i guess number of deopts isn't the reason rakuast is slower...
01:18 MasterDuke left 06:59 [Tux] left 07:03 [Tux] joined 07:21 lizmat joined
nine The pretty obvious next step is fixing make install 07:33
07:34 [Tux] left
nine MasterDuke: I put almost no consideration on performance when implementing except for the architectural avoidance of traversing the whole tree multiple times. A plain normal Raku-level profile would probably be a good start 07:36
tellable6 nine, I'll pass your message to MasterDuke
07:37 [Tux] joined
[Tux] Rakudo v2025.03-236-gbe3d06a71 (v6.d) on MoarVM 2025.03-13-gb405e940e
csv-ip5xs0.260 - 0.278
csv-ip5xs-201.118 - 1.176
csv-parser1.095 - 1.100
csv-test-xs-200.137 - 0.138
test1.820 - 1.889
test-t0.408 - 0.417
test-t --race0.268 - 0.275
test-t-204.957 - 5.055
test-t-20 --race1.255 - 1.264
 07:51
tux.nl/Talks/CSV6/speed4-20.html / tux.nl/Talks/CSV6/speed4.html tux.nl/Talks/CSV6/speed.log
08:04 nine left, nine joined 09:17 lizmat left 09:56 finanalyst joined
timo deopt is not equal to deopt :) 10:34
"deopt all" vs "deopt one" is already a decent difference 10:35
"deopt all" on very very deep stacks can be rather expensive, which i saw on one of these worst-case generated-code kind of examples 10:36
nine I think the number of deopts alone tells you practically nothing. You'd need to compare it to number of optimized runs. 10:44
timo and whether the deopt happens early or late in a frame, and if it's in an OSR'd frame, it might actually deopt many more times than it is invoked 10:46
nine Anyway, as I said, it's the wrong end to start from anyway. You look at spesh logs to see how you can improve spesh. When freshly written, totally unoptimized code is running a bit slow on the 10 year old battle-tested VM, you should look at that new code, not the VM. 10:54
11:30 JimmyZhuo joined
JimmyZhuo From: 6guts blog, Closer examination revealed that the cloning of the backtrack stack was, however, overly defensive; eliminating that copying led to a huge memory and time improvement. 11:34
this is a longstanding problem, It was about 200+ secs to compile the setting with parrot for me, with moarvm it's about 70 secs. 11:36
not sure how much DFA helps 11:38
I think It's a big headache? 11:44
12:39 JimmyZhuo left
timo can you be more specific? 12:47
13:09 JimmyZhuo joined
JimmyZhuo timo: me? 13:09
13:20 JimmyZhuo left
timo yes 13:33
this is about core setting compilation performance? or something related to deopt? 13:34
14:10 dogbert17 joined
dogbert17 lizmat, do you know if anyone has run 'make stresstest' under RAKUAST? 14:11
[Coke] I think that run was spec, not stress. 14:14
dogbert17 [Coke], I gave it a try and there were a couple of failures 14:15
[Coke] Sure, can you put them in a gist? 14:16
(or a ticket on rakudo/rakudo)
I think spectest has 3 remaining failures.
dogbert17 Can do 14:17
the following three files might warrant a look: t/spec/6.c/MISC/bug-coverage-stress.t, t/spec/S02-types/version-stress.t, t/spec/integration/advent2012-day04.t 14:31
16:26 dogbert17 left 16:56 dogbert17 joined
dogbert17 I have posted morde detail wrt the failing stress test here: gist.github.com/dogbert17/ddad8ff5...394549101c 19:00
20:49 MasterDuke joined
MasterDuke nine: yeah, i was hoping there was something to do in rakudo (specifically rakuast) to reduce the deopts 20:52
tellable6 hey MasterDuke, you have a message: gist.github.com/3381f5f695cbe84b69...d0f3928fb2
MasterDuke i've tried doing a --profile-compile of compiling CORE.c.setting on the bootstrap branch, but it just silently dies (though maybe it's memory related, i should try on my desktop) 20:53
i've done one when compiling CORE.e.setting, but nothing stood out. nodify is called a *lot*, but i couldn't find out an effective way to cache the results or create singletons for the most common things looked up ('Node', 'Origin', 'Name', 'ApplyListInfix', 'CompUnit' are the top 5) 20:56
20:59 MasterDuke left 21:10 MasterDuke joined
MasterDuke same thing on my desktop, it just silently dies and doesn't create a profile (and no notifications from the oom killer in dmesg) 21:11
if anyone is curious, i.imgur.com/E6fHBNf.png is a screen shot of my CORE.e.setting profile-compile, sorted by exclusive time 21:19
a couple days ago i tried adding `attach()` and `SET-NODE-ORIGIN()` variants without the `:$as-key-origin` parameter and its handling in the body, since that was only set *very* infrequently, but it didn't seem to make any difference 21:23
i also tried adding a `Nodify()` that only took a single scalar argument since that was also most common, but again it didn't seem to make a difference 21:26
21:28 guifa left 21:39 mandrillone joined
mandrillone Maybe a good optimization would be to keep the Rakuast nodes in a flat array and reference them by their index. That’s normally a big win for treelike structures 21:40
It improves cache locality and often reduces memory usage
I’d say surely reduces memory usage in a language with containers 21:42
one has always to be careful about the layout of data in each node and their size 21:43
MasterDuke yeah. but probably not a trivial change
mandrillone I can imagine that 21:44
21:49 mandrillone left, mandrillone joined 21:53 MasterDuke left 21:55 lizmat joined 22:06 mandrillone left 22:30 lizmat left

Powered by Cro and the Raku® Programming Language.

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

Thank you!