[00:18] librasteve: That HN link now just says "No such item". HTH, [00:19] i can still see it [00:23] librasteve: Found the problem. The IRC logs included the following comma in the URL. Thanks! :) [00:48] getting ever closer to raku-level stack sampling in the firefox profiler UI [01:15] *** rmv joined [01:15] *** rmv left [01:15] *** rmv joined [01:20] *** rmv left [01:47] *** kylese left [01:48] *** kylese joined [02:15] *** kylese left [02:15] *** kylese joined [02:30] ugexe: Thanks! [02:31] timo: Context? Is there a web page/github repo/doco for what you're working on there? [04:23] *** vrurg_ joined [04:25] *** vrurg left [04:32] .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] wayland76, I'll pass your message to librasteve [05:30] *** camelia left [05:30] *** camelia joined [05:54] 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] 2026-07-04T04:32:41Z #raku librasteve Question: as part of the weekly, should we be scanning the docs for new tutorials, and including those in the weekly? [06:30] librasteve: Maybe this should go on the list of "Things we should include when this gets automated" :) . [06:37] https://github.com/librasteve/Weekly-Tools (I am resisting on adding to the list of things that are already automated) [06:48] 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:51] 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:54] (I'm hoping I'll have the Tree-Oriented Programming part in a usable form in the next couple of months). [07:20] 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:21] anyway now in the land of toasted banana bread [08:41] 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:45] am I doing something obviously wrong? https://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 [09:26] 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:28] *** Sgeo left [09:29] 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) [09:30] which lets you lower this value for specific interfaces [09:30] so, as long as default is 2, all can be 0 [09:35] though the biggest beef to me is that 2 is not accepted value [09:37] *** abraxxa joined [09:40] 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:42] `fs.protected_hardlinks = 1` `fs.protected_symlinks = 1` `fs.protected_fifos = 1` `fs.protected_regular = 2` [09:43] 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:54] *** rmv joined [09:54] *** rmv left [09:54] *** rmv joined [09:59] *** rmv left [10:00] *** wayland76 left [10:01] 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 [10:03] also, it doesn't validate `allow-recursion` which is probably top 1 problem [10:15] and sudo has no `show me current full config` it seems, so idk if any sane check can be done [11:02] *** erooke left [11:09] *** abraxxa left [11:10] *** abraxxa joined [11:30] *** erooke joined [11:59] Voldenet: thanks , I will see what I can do [12:02] bind check implies feeding its configuration via sudo cat /path/to/config [12:02] *** MasterDuke joined [12:06] 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:08] the ones I said are pretty much for sanity values [12:08] for sysctl [12:08] Yep [12:12] `named-checkconf -p` pretty much does this but resolves all includes [12:13] the format is `options { directory "/var/cache/bind"; forwarders { 8.8.8.8; }; listen-on port 53 { 10.0.0.1; }; }` [12:19] so it's a bit weird I suppose [12:20] 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:28] 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:39] 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:46] *** [Coke] left [12:49] so I'm not doing anything wrong, fwiw rakuast is roughly reproducing that short benchmark [12:51] I did a profile on that code - it does say that it was mostly jit-compiled https://i.tanomi.eu/0ij6u.html [12:51] and we didn't actually put much time into optimizing shaped arrays yet? [12:51] yeah, I'm guessing shaped arrays just do something on top of arrays [12:52] home#sources/6855B5384C8DD6D1328D25B4392E37FEA8923134 (Bench):62 - has 10k local deoptimizations; can you quickly check what that line is? [12:53] 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:54] can you try putting XR[100] outside the loop? i think it's supposed to be cached, but just to be sure ... [12:55] 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] > 62 $val.wallclock.abs / 1000000; [12:55] get-now home#sources/6855B5384C8DD6D1328D25B4392E37FEA8923134 (Bench):4 - 26.61% inclusive time O_O [12:56] … :O [12:56] yeah that should maybe be using floating point numbers for performance? but that should be outside of the part that is actually measured [12:56] 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 [12:57] it's really puzzling, but I can probably do that test without Bench and see if proportions are the same [12:58] benchmarking is a really tricky thing [13:00] 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:01] on my Zen2 i get ~0.25s, ~0.5s, and ~1.3s respectively [13:03] the profile was on my M2, so i don't know what the jit might do to archetype [13:04] but the proportions are roughly the same [13:06] eh, i'd say XRS is quite a bit worse on the Zen2. 5x slower instead of 2x [13:06] yes you can probably see the memory indirections [13:07] m2 has a lot faster memory [13:08] yeah, its kind of amazing how much faster it usually is [13:08] though if it had jit, maybe you could even see the same proportions [13:08] and i heard the battery tends to last forever even when doing intensive stuff [13:09] I'd be very skeptikal about free power, m2 max tdp is around 80W :p [13:10] skeptical, even [13:10] 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 [13:10] tdp isn't everything; if you can get the task done faster, the hardware can go back to sleep sooner [13:11] 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 [13:12] makes sense, but intensive to me would mean transcoding using all cores [13:16] *** erooke left [13:16] either way, I think if you disabled jit on x86 you might even see the same proportions [13:17] though the difference looks like some sort of double dereference somewhere [13:18] compared to the non-shaped array [13:18] ~0.4s, ~0.62s, and ~1.5s on Zen2 with jit disabled [13:19] so it's 4x slower [13:19] …but strangely it does look like jit doesn't do much for shaped case [13:20] i think the jit doesn't do as much for metamodel code, which the shaped case has extra of [13:21] m: say <0.25 0.5 1.3>.map(*.Real) Z/ <0.4 0.62 1.5>.map(*.Real) [13:21] rakudo-moar 7d3a0c0e3: OUTPUT: «(0.625 0.806452 0.866667)␤» [13:22] anyway, afk for probably most of the day. later... [13:22] okay then [13:27] *** MasterDuke left [13:27] role-based one is kinda slow too compared – I'm guessing that `$role.set($u, 42)` is the cause [13:28] metamodel code is meant to be eliminated from actual run-time if at all possible by dispatchers and such [13:31] I've reduced it to the way simpler case [13:33] *** erooke joined [13:34] 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] rakudo-moar 7d3a0c0e3: OUTPUT: «0.004458721␤0.003790797␤» [13:35] times in the 0.00n range are very likely to be very noisy [13:37] plus the "which one you do first" issue [13:40] yes, but I can't reproduce the case where role-based method would be faster [13:41] I can only if it's some random cpu lag [13:42] right [13:43] the XR case for me runs either 0.004 or .0025 [13:43] or 0.0034 actually [13:43] *** abraxxa left [13:44] 158.1 ms ± 9.6 vs 157.4 ms ± 11.2 ms [13:45] turning the number of iterations up by 10x and there is now an actual difference, but the numbers still have an astounding range [13:46] 167.3 ms ± 12.9 ms vs 161.8 ms ± 11.0 ms (for the entire command) [13:47] 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 [13:48] ah, that changes things [13:49] [...] ran 1.03 ± 0.05 times faster than [...] [13:50] I'm starting to believe that it's a problem with the measuring methodology I use which is [13:50] extremely poor [13:50] yeah, as i said it's really tricky :) [13:51] Bench is a tricky tool as well [13:51] Bench should warn about too small per-iteration times maybe [13:51] I mean, it doesn't do warmups, probably doesn't attempt various orders of execution [13:52] there is no way to "clear out" dynamic optimization results between runs either, and some things saturate [13:53] I would really not recommend running multiple different variants in the same process if you want to do comparisons like that [13:54] if you do different orders of the candidates in a new process each time, that could be all right, maybe even extra insightful [13:55] hyperfine probably makes more sense [13:55] yeah, that's what I'm using right now [13:56] I put an `if True {...} else {...}` in one variant and `if False {...} else {...}` in the other :) [13:56] though actually, dynamic optimizations are wanted for microbenchmarks imo [13:57] 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 [13:59] that kinda makes me want to make "better benchmarking tool" [13:59] do you know about japhb's old perl6-bench or what it's called? [14:00] 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:01] it sounds like something I should use [14:01] 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 [14:01] it hasn't been touched in a while, so it might want to be freshened up a little [14:02] 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:03] *** rmv left [14:03] hyperfine gets you far if you have enough iterations inside raku probably [14:08] right. as a raku core dev the "different versions" part used to be very interesting indeed [14:10] 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 [14:10] maybe filename has huge impact but I doubt [14:11] with Bench the difference didn't seem that significant [14:11] the only difference is whether you put "class" or "role" as the first word? [14:11] yes [14:11] *** rmv joined [14:11] *** rmv left [14:11] *** rmv joined [14:13] now i see it too, but only 2.4x [14:16] 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:20] 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] it could be that [14:21] that's still 50 million loops per second [14:21] that earlier X/XR was thin enough [14:21] that these guards also impacted that benchmark [14:22] it did only assign int to the array, it isn't exactly heavy [14:22] and the other is 13 mill loops per second? [14:22] 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 [14:23] yeah that one is more interesting to look at [14:24] ah, I could actually just use Bench with empty loop and non-empty and see the difference [14:28] non-empty loop (that sets element in array) is 10 times slower, so it does more [14:34] https://pastebin.com/SG82xf7H [14:34] | | Rate | ex | exr | x | xr | [14:34] | ex | 65.1/s | – | -63% | -86% | -96% | [14:35] so, role that does set thing in an array is a lot slower [14:36] I was inspired to look at performance of various things because of https://github.com/rakudo/rakudo/issues/6056 [14:36] does attempting to set a value outside of the cap generate a Failure object? [14:37] oh those aren't shaped arrays [14:37] *** sergot joined [14:38] 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 [14:39] yeah, it's constant [14:41] 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:42] I'm fairly sure that they could be optimizable [14:42] *** [Coke] joined [14:44] 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 [15:12] *** sergot left [15:13] *** sergot joined [16:25] *** bd3i left [16:25] *** 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 [19:51] *** rmv left [19:51] *** rmv joined [20:30] *** librasteve_ joined [20:33] *** librasteve_ left [20:33] *** librasteve_ joined [21:04] *** swaggboi left [21:32] *** swaggboi joined [22:18] downloading https://rakudo.org/dl/rakudo/rakudo-moar-2026.05-01-linux-x86_64-gcc.tar.gz from my home and GHA is very slow... [23:05] *** Pixi` joined [23:08] *** Pixi left [23:41] *** tejr left [23:59] *** tejr joined