wayland76 librasteve: That HN link now just says "No such item". HTH, 00:18
ugexe i can still see it 00:19
wayland76 librasteve: Found the problem. The IRC logs included the following comma in the URL. Thanks! :) 00:23
timo getting ever closer to raku-level stack sampling in the firefox profiler UI 00:48
01:15 rmv joined, rmv left, rmv joined 01:20 rmv left 01:47 kylese left 01:48 kylese joined 02:15 kylese left, kylese joined
wayland76 ugexe: Thanks! 02:30
timo: Context? Is there a web page/github repo/doco for what you're working on there? 02:31
04:23 vrurg_ joined 04:25 vrurg left
wayland76 .tell librasteve Question: as part of the weekly, should we be scanning the docs for new tutorials, and including those in the weekly? 04:32
tellable6 wayland76, I'll pass your message to librasteve
05:30 camelia left, camelia joined
librasteve wayland: if you mean “should wayland be scanning he docs for changes…” my answer is “yes, please do and share them here using the weekly bot” if you mean “should steve be scanning the docs for changes”, my answer is tbh I don’t think that new tutorials arrive that often (a couple per year?) and my raku tuits are limited, so please keep and eye on the Docs & Website PRs section that I already assemble :-) 05:54
tellable6 2026-07-04T04:32:41Z #raku <wayland76> librasteve Question: as part of the weekly, should we be scanning the docs for new tutorials, and including those in the weekly?
wayland76 librasteve: Maybe this should go on the list of "Things we should include when this gets automated" :) . 06:30
librasteve github.com/librasteve/Weekly-Tools (I am resisting on adding to the list of things that are already automated) 06:37
wayland76 Oh, lovely! It was on my list, but not until next year :) . I've just recently done an estimate on my upcoming projects, and I think I might have the Data-Oriented Programming basics done by the end of the year. 06:48
Also, you asked one time whether AI made large projects like Data-Oriented Programming feel/seem more achievable. I gave an inconclusive answer at the time, but now my answer is yes. 06:51
(I'm hoping I'll have the Tree-Oriented Programming part in a usable form in the next couple of months). 06:54
librasteve yeah - I used Claude on the Weekly Tools - practically vibe coded the comment search since it is a "throw-away" helper script saved me hours of coding time 07:20
anyway now in the land of toasted banana bread 07:21
Voldenet hm, I've been comparing performance of shaped and unshaped arrays and I'm quite surprised at how much slower are unshaped arrays inside of the role 08:41
am I doing something obviously wrong? pastebin.com/z8SZWPve 08:45
I'd think they should be faster since the bounds are constant
08:46 erooke left 09:23 erooke joined
Voldenet melezhik.: so I've tested scc@check=sysctl and it should accept `net.ipv4.conf.all.rp_filter = 2` (which is more secure), but it's very complicated 09:26
09:28 Sgeo left
Voldenet basically, `net.ipv4.conf.default.rp_filter = 2` `net.ipv4.conf.all.rp_filter = 0` is the norm, so every created interface will get secure rp_filter 09:29
and rp_filter for every interface will be max({current}, all)
which lets you lower this value for specific interfaces 09:30
so, as long as default is 2, all can be 0
though the biggest beef to me is that 2 is not accepted value 09:35
09:37 abraxxa joined
Voldenet also, handful of things that should be set `kernel.dmesg_restrict = 1`, `kernel.unprivileged_bpf_disabled = 2`, `kernel.unprivileged_userns_clone = 0`, `kernel.yama.ptrace_scope = 1|2` 09:40
`fs.protected_hardlinks = 1` `fs.protected_symlinks = 1` `fs.protected_fifos = 1` `fs.protected_regular = 2` 09:42
some things are situational, like on my machine I allow ptrace to everything as long as uid is valid, but I hear it's not normally valid, e.g. webserver could spawn its process for user 09:43
09:54 rmv joined, rmv left, rmv joined 09:59 rmv left 10:00 wayland76 left
Voldenet for bind check I don't know how to use it, tbh. 10:01
feeding it output from `named-checkconf -p` doesn't seem to work
also, it doesn't validate `allow-recursion` which is probably top 1 problem 10:03
and sudo has no `show me current full config` it seems, so idk if any sane check can be done 10:15
11:02 erooke left 11:09 abraxxa left 11:10 abraxxa joined 11:30 erooke joined
melezhik. Voldenet: thanks , I will see what I can do 11:59
bind check implies feeding its configuration via sudo cat /path/to/config 12:02
12:02 MasterDuke joined
As for sysctl I can add those check you said. The whole idea behind scc is to provide some minimal essentials checks , not trying to be over complicated , also it’ll be possible to switch oh/off some specific checks by passing cli options for scc plugin 12:06
Voldenet the ones I said are pretty much for sanity values 12:08
for sysctl
melezhik. Yep
Voldenet `named-checkconf -p` pretty much does this but resolves all includes 12:12
the format is `options { directory "/var/cache/bind"; forwarders { 8.8.8.8; }; listen-on port 53 { 10.0.0.1; }; }` 12:13
so it's a bit weird I suppose 12:19
MasterDuke Voldenet: there have been several other times when people have noticed that shaped arrays were slower than un-shaped. in a couple of instances there were specific regressions that were fixed. i'm not aware of anything right now that's known to be a problem with them, but timo may have an idea 12:20
a profile of the role vs role-param-is-shape shows one of the biggest differences is the shaped one has `archetypes src/Perl6/Metamodel/ClassHOW.nqp:53` way up at the top, called for each iteration 12:28
timo my general assumption is: if a metamodel method is called too often, a dispatcher may have missed an opportunity to do something, or something it did went wrong? 12:39
12:46 [Coke] left
Voldenet so I'm not doing anything wrong, fwiw rakuast is roughly reproducing that short benchmark 12:49
I did a profile on that code - it does say that it was mostly jit-compiled i.tanomi.eu/0ij6u.html 12:51
timo and we didn't actually put much time into optimizing shaped arrays yet?
Voldenet yeah, I'm guessing shaped arrays just do something on top of arrays
timo home#sources/6855B5384C8DD6D1328D25B4392E37FEA8923134 (Bench):62 - has 10k local deoptimizations; can you quickly check what that line is? 12:52
sorting by exclusive time puts DYNAMIC at the top, which we generate a call to whenever a dynamic variable is used, and next is DIVIDE_NUMBERS which comes from rationals 12:53
can you try putting XR[100] outside the loop? i think it's supposed to be cached, but just to be sure ... 12:54
MasterDuke did you profile while running the benchmark? that might explain all the deopts. it would be much cleaner to just profile the individual cases 12:55
Voldenet > 62 $val.wallclock.abs / 1000000;
timo get-now home#sources/6855B5384C8DD6D1328D25B4392E37FEA8923134 (Bench):4 - 26.61% inclusive time O_O
Voldenet … :O 12:56
timo yeah that should maybe be using floating point numbers for performance? but that should be outside of the part that is actually measured
MasterDuke yeah, spesh is going to optimize best for whichever version gets run first and won't do as good a job on all the other versions
Voldenet it's really puzzling, but I can probably do that test without Bench and see if proportions are the same 12:57
timo benchmarking is a really tricky thing 12:58
MasterDuke on my M2 (so no jit), i get ~0.32s for X, ~0.46s for XR, and ~0.7s for XRS, testing with `<...>; for ^10_000 { for ^100 { $x.set($_, 42) } };` 13:00
on my Zen2 i get ~0.25s, ~0.5s, and ~1.3s respectively 13:01
the profile was on my M2, so i don't know what the jit might do to archetype 13:03
Voldenet but the proportions are roughly the same 13:04
MasterDuke eh, i'd say XRS is quite a bit worse on the Zen2. 5x slower instead of 2x 13:06
Voldenet yes you can probably see the memory indirections
m2 has a lot faster memory 13:07
MasterDuke yeah, its kind of amazing how much faster it usually is 13:08
Voldenet though if it had jit, maybe you could even see the same proportions
timo and i heard the battery tends to last forever even when doing intensive stuff
Voldenet I'd be very skeptikal about free power, m2 max tdp is around 80W :p 13:09
skeptical, even 13:10
MasterDuke yeah. unfortunately the idle power draw in linux is terrible compared to macos. on the only-couple-times-a-year i'm in macos it can sit for over a week doing nothing and only lose a couple percent. linux it only lasts max of three days before it runs out
timo tdp isn't everything; if you can get the task done faster, the hardware can go back to sleep sooner
MasterDuke but they do have roughly the same draw under load 13:11
so i get hours and hours on battery even when compiling moarvm/nqp/rakudo repeatedly
Voldenet makes sense, but intensive to me would mean transcoding using all cores 13:12
13:16 erooke left
Voldenet either way, I think if you disabled jit on x86 you might even see the same proportions 13:16
though the difference looks like some sort of double dereference somewhere 13:17
compared to the non-shaped array 13:18
MasterDuke ~0.4s, ~0.62s, and ~1.5s on Zen2 with jit disabled
Voldenet so it's 4x slower 13:19
…but strangely it does look like jit doesn't do much for shaped case
MasterDuke i think the jit doesn't do as much for metamodel code, which the shaped case has extra of 13:20
Voldenet m: say <0.25 0.5 1.3>.map(*.Real) Z/ <0.4 0.62 1.5>.map(*.Real) 13:21
camelia (0.625 0.806452 0.866667)
MasterDuke anyway, afk for probably most of the day. later... 13:22
Voldenet okay then
13:27 MasterDuke left
Voldenet role-based one is kinda slow too compared – I'm guessing that `$role.set($u, 42)` is the cause 13:27
timo metamodel code is meant to be eliminated from actual run-time if at all possible by dispatchers and such 13:28
Voldenet I've reduced it to the way simpler case 13:31
13:33 erooke joined
Voldenet m: role XR { method foo { }}; class X { method foo { } }; my XR $xr .= new; my $t = now; for ^10000 { $xr.foo }; say now - $t; my X $x .= new; $t = now; for ^10000 { $x.foo }; say now - $t; 13:34
camelia 0.004458721
0.003790797
timo times in the 0.00n range are very likely to be very noisy 13:35
plus the "which one you do first" issue 13:37
Voldenet yes, but I can't reproduce the case where role-based method would be faster 13:40
I can only if it's some random cpu lag 13:41
timo right 13:42
the XR case for me runs either 0.004 or .0025 13:43
or 0.0034 actually
13:43 abraxxa left
timo 158.1 ms ± 9.6 vs 157.4 ms ± 11.2 ms 13:44
turning the number of iterations up by 10x and there is now an actual difference, but the numbers still have an astounding range 13:45
167.3 ms ± 12.9 ms vs 161.8 ms ± 11.0 ms (for the entire command) 13:46
actually, looks like my moarvm was compiled with -O1 LOL 13:47
because I was digging around in the internals so I wanted less of the "value optimized out" nonsense
Voldenet ah, that changes things 13:48
timo [...] ran 1.03 ± 0.05 times faster than [...] 13:49
Voldenet I'm starting to believe that it's a problem with the measuring methodology I use which is 13:50
extremely poor
timo yeah, as i said it's really tricky :)
Voldenet Bench is a tricky tool as well 13:51
timo Bench should warn about too small per-iteration times maybe
Voldenet I mean, it doesn't do warmups, probably doesn't attempt various orders of execution
timo there is no way to "clear out" dynamic optimization results between runs either, and some things saturate 13:52
I would really not recommend running multiple different variants in the same process if you want to do comparisons like that 13:53
if you do different orders of the candidates in a new process each time, that could be all right, maybe even extra insightful 13:54
Voldenet hyperfine probably makes more sense 13:55
timo yeah, that's what I'm using right now
I put an `if True {...} else {...}` in one variant and `if False {...} else {...}` in the other :) 13:56
Voldenet though actually, dynamic optimizations are wanted for microbenchmarks imo
timo you'll still want to run the microbenchmark at a high enough number of iterations for the dynamic optimizer to actually pay off 13:57
getting measurements for different numbers of iterations can be interesting to see the effect of that
13:58 rmv joined
Voldenet that kinda makes me want to make "better benchmarking tool" 13:59
timo do you know about japhb's old perl6-bench or what it's called?
it's a tool that builds variants of rakudo (different backends, as well as perl5), runs microbenchmarks against multiple of these versions at increasing iteration counts until a time budget is spent, then spits out graphs 14:00
Voldenet it sounds like something I should use 14:01
timo it's now maybe easier to just get a tarball from the whateverable mothership instead of building rakudos yourself, though it can still be useful to compare code changes or compile flag changes or things like that
it hasn't been touched in a while, so it might want to be freshened up a little
Voldenet I'm not too interested in multiple versions – I usually have N pieces of code and I want to find out which is faster 14:02
14:03 rmv left
Voldenet hyperfine gets you far if you have enough iterations inside raku probably 14:03
timo right. as a raku core dev the "different versions" part used to be very interesting indeed 14:08
Voldenet Huh, on my system `role` is significantly slower (the code is `class X { method foo { } }; my X $x .= new; for ^1_000_000_00 { $x.foo }`) 14:10
> raku x.raku ran 2.63 ± 0.10 times faster than raku xr.raku
maybe filename has huge impact but I doubt
with Bench the difference didn't seem that significant 14:11
timo the only difference is whether you put "class" or "role" as the first word?
Voldenet yes
14:11 rmv joined, rmv left, rmv joined
timo now i see it too, but only 2.4x 14:13
ah, that's an empty method call. i assume the whole loop body gets turned into just a few guards, and the role case may have one or two guards more than the other one 14:16
I'd say that's a bit "too" micro to be too useful, though we may be able to improve that anyway if we dig deeper into what spesh does exactly 14:20
Voldenet it could be that
timo that's still 50 million loops per second 14:21
Voldenet that earlier X/XR was thin enough
that these guards also impacted that benchmark
it did only assign int to the array, it isn't exactly heavy 14:22
timo and the other is 13 mill loops per second?
if you have two versions of your code and one is a hundred thousandth of a second slower than the other, maybe it's not worth looking too closely
yeah that one is more interesting to look at 14:23
Voldenet ah, I could actually just use Bench with empty loop and non-empty and see the difference 14:24
non-empty loop (that sets element in array) is 10 times slower, so it does more 14:28
pastebin.com/SG82xf7H 14:34
| | Rate | ex | exr | x | xr |
| ex | 65.1/s | – | -63% | -86% | -96% |
so, role that does set thing in an array is a lot slower 14:35
I was inspired to look at performance of various things because of github.com/rakudo/rakudo/issues/6056 14:36
timo does attempting to set a value outside of the cap generate a Failure object?
oh those aren't shaped arrays 14:37
14:37 sergot joined
timo the cap is just how many the array is initialized with on creation? 14:38
oh, the index is the first arg not the second
Voldenet yeah, it's constant 14:39
I've ditched shaped arrays in this specific test, because I've seen they're 2 or 3 times slower and it's noise – I'm kinda interested about `role` vs `class` only now 14:41
I'm fairly sure that they could be optimizable 14:42
14:42 [Coke] joined
timo right, you'll want to look at the spesh log for these variants now. maybe start with -MSIL to get a summary of inline success/failures to make sure the things that get inlined are getting inlined 14:44
15:12 sergot left 15:13 sergot joined 16:25 bd3i left, bd3i joined 17:18 johnjay left 17:46 rmv left 18:21 Sgeo joined 19:11 abbe left 19:18 abbe joined 19:21 abbe left 19:50 abbe joined 19:51 rmv joined, rmv left, rmv joined 20:30 librasteve_ joined 20:33 librasteve_ left, librasteve_ joined 21:04 swaggboi left 21:32 swaggboi joined
ingy downloading rakudo.org/dl/rakudo/rakudo-moar-2...gcc.tar.gz from my home and GHA is very slow... 22:18
23:05 Pixi` joined 23:08 Pixi left 23:41 tejr left 23:59 tejr 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!