00:13 Manifest0 left 00:44 arkiuat left 00:57 arkiuat joined 01:04 deoac joined 01:23 guifa left 01:26 kylese left 01:27 kylese joined 02:15 kylese left, kylese joined 03:06 xinming left 03:07 xinming joined 04:33 deoac left 04:50 kylese left, kylese joined 05:25 Aedil joined 06:10 jmcgnh left 06:17 jmcgnh joined 06:59 Sgeo left
disbot4 <ng0177> ollama-rocm and ollama-cuda work well with both types of graphics cards on several Linux types. However, llamafile does not work with AMD GPU for me on several Linux. Ollama also has great support e.g. via "continue" plugin to vscode. My proposal (just) ist to upgrade its priority for implementation. 🙂 07:03
07:05 japhb left 07:14 arkiuat left 07:26 arkiuat joined 07:31 arkiuat left 07:37 japhb joined 07:52 japhb left, japhb joined 07:57 wayland76 joined 07:59 arkiuat joined 08:00 Aedil left 08:03 wayland76 left 08:04 arkiuat left 08:17 melezhik joined
melezhik . 08:17
I have create yet another Sparrow introduction target for operations and devops only using Bash as a main automation language - news.ycombinator.com/item?id=44754210 - pleas vote it if you like, thanks 08:18
08:27 melezhik left 08:31 Manifest0 joined, arkiuat joined 08:36 arkiuat left 08:38 kylese left 08:40 kylese joined 08:48 lichtkind joined 08:51 melezhik joined
melezhik please support my post on reddit as well if you like it - www.reddit.com/r/devops/comments/1...r_ansible/ , I decided to share it on r/devops as well 08:52
thanks
08:52 leedo left 08:53 melezhik left, leedo joined 08:55 arkiuat joined 08:59 arkiuat left 09:31 arkiuat joined 09:36 arkiuat left 09:56 arkiuat joined 09:59 Aedil joined 10:00 arkiuat left 10:19 wayland76 joined
wayland76 Hi! Where do I find information about the infrastructure team? (finanalyst mentioned it). github.com/rba/docker-raku-infra is the closest I've been able to find (along with various calls for volunteers), and a few passing references by people. Is there a channel/mailing list I need to join? Or a git repo or something? 10:21
I'm keen to avoid putting my hand up for Infra, but my day job is DevOps, and I think I could contribute towards getting the infra a bit more automated. 10:22
lizmat wayland76: you might want to introduce yourself on the #raku-infra channel 10:25
10:29 arkiuat joined 10:33 arkiuat left
wayland76 Thanks! 10:38
10:56 arkiuat joined 11:00 arkiuat left 11:20 arkiuat joined 11:24 arkiuat left 11:53 arkiuat joined 12:01 arkiuat left 12:29 arkiuat joined 12:34 arkiuat left 12:58 arkiuat joined 13:02 arkiuat left 13:32 arkiuat joined 13:37 arkiuat left
Geth raku.org/proto-25: e2a0f5f4e0 | librasteve++ | 9 files
Tims Changes
13:49
13:50 librasteve_ joined 13:55 lucerne left 13:57 lucerne joined 13:59 arkiuat joined
Geth raku.org/proto-25: 99015005ee | librasteve++ (committed using GitHub Web editor) | README.md
drop Install

the install step is not needed to run locally
14:11
raku.org/proto-25: b3dd0a8f64 | librasteve++ | service.raku
set host/port from ENV
14:18
ugexe librasteve_: i wonder if it should do `zef install . --deps-only` still. Like it seems like there is a dependency on Air::Plugin::Hilite 14:19
librasteve_ yeah … Air, Air::Plugin::Hilite, cro, Cromponent 14:27
to mention a few that come to mind
and all the deps they bring in 14:28
ugexe there are already steps before that to install Air and cro, but not Air::Plugin::Hilite 14:29
Geth raku.org/proto-25: 3ead456654 | librasteve++ | README.md
add zef install . --deps-only #e.g. Air::Plugin::Hilite
14:35
disbot4 <librasteve> good catch - I think --deps-only is better that explicitly adding zef install Air;:Plugin::Hilite since more plugins may come later 14:36
14:48 Sgeo joined 15:20 stanrifkin joined 15:44 lizmat left 15:46 Geth left, arkiuat left 15:52 lizmat joined 15:58 arkiuat joined
lizmat PSA: irclogs.raku.org is temporarily down 16:08
Note: logging is still functional 16:12
jdv what happened to five nines?
lizmat a USB hub that suddenly died and a hard reboot and sudden compilation errors :-( 16:14
jdv a likely story. i want my money back! 16:15
lizmat IRC logs server is up again 16:26
irclogs.raku.org/raku/live.html
16:50 Guest14 joined 16:52 Guest14 left
[Coke] \o/ 16:56
17:00 vasko4 left
disbot4 <librasteve> only five nines? 17:10
17:22 arkiuat left 17:33 vasko4 joined 17:36 arkiuat joined 17:41 arkiuat left 17:53 arkiuat joined 17:58 arkiuat left
cpli why do these lines of IO::Handle use nqp? github.com/rakudo/rakudo/blob/main...d#L78-L127 18:24
18:30 arkiuat joined 18:34 arkiuat left
[Coke] in general, core uses nqp historically for performance reasons, I think. 18:46
But I think there was only an ad hoc effort (not systemic) to go back and rewrite in raku. Some things have been. 18:47
I imagine it might be revisited again after Raku AST is the default.
(and there's more optimization on ast) 18:48
Voldenet Wouldn't nqp::if always be as fast or marginally faster than plain `if`, since it directly generates opcode? 18:59
Or is it possible for it to even be slower now? 19:00
19:02 arkiuat joined 19:04 deoac joined
lizmat those are all good points: I suggest someone rewrites that part in Raku and benchmarks 19:09
IO::Handle is notoriously convoluted 19:10
19:20 arkiuat left 19:47 lizmat left, lizmat_ joined 19:48 lizmat_ left 19:49 lizmat joined, arkiuat joined 19:55 arkiuat left 20:14 arkiuat joined 20:15 Aedil left 20:18 arkiuat left 20:36 arkiuat joined
timo i think `?? !!` translates relatively directly to nqp::if, but with a real if you have a real block that the optimizer has to directly inline if it doesn't have any actual need to be a true scope 21:01
if it results in the same bytecode after the optimizer, it'd be the same speed, but of course there's the time spent in the optimizer analyzing the "if" in question 21:02
ugexe if nqp::if is only "as fast" as using raku, then it is not a good use of nqp 21:04
timo with an nqp::if there isn't the chance of it turning into the "slow variant" when you don't look closely 21:15
21:30 arkiuat left 21:35 arkiuat joined 22:01 wayland joined, wayland76 left
Voldenet So I picked the nqp::if with $mode, just to see if there's going to be any difference on code that doesn't do actual IO 0x0.st/87uD.raku 22:03
> raku mode_nqp.raku ran 1.01 ± 0.04 times faster than raku mode.raku 22:04
I just noticed there's also Str comparison, so nqp version was 1.06 ± 0.06 times faster than this: 0x0.st/87un.raku 22:08
but keep in mind that I've used hyperfine to test cold run
22:17 lichtkind left
Voldenet with 100_000 iterations running that sub, nqp version is 1.13 ± 0.02 times faster 22:18
timo it would be interesting to see what the spesh log has about that sub, and if it gets inlined into the caller in any cases 22:20
Voldenet the more iterations I run, the more obvious is that startup time difference helps non-nqp version a lot 22:23
timo ideally, spesh could dead-code-eliminate the majority of that sub 22:27
well, not if the sub is only called a single time of course. if it's run in a loop, however, it should be possible 22:29
Voldenet without going too deep into details, `for ^1_000_000 { $n = x(:update, :exclusive) }`: i.imgur.com/yG51xx5.png 22:30
(nqp on the left)
it seems that nqp version simply doesn't allocate as much
non-nqp version allocates 1000000 `Code` objects 22:31
timo Code objects are allocated by `takeclosure` i think, we call the "clone" method there 22:36
you can see the right side has 2x as many frames entered
so less inlining of blocks happened
by the static optimizer i assume 22:37
Voldenet I'm suspecting that `$mode = do if …` could be slow 22:39
so, another rewrite, nothing fancy: 0x0.st/87SP.raku 22:40
>raku mode_nqp.raku ran 1.01 ± 0.01 times faster than raku mode.raku
that looks more promising 22:41
yeah, it does almost no additional allocations except some related to compiling the code 22:46
BOOTHash etc.
otoh the "simple" code is enormously ugly, I can't really say it's better in any way 22:51
except maybe ditching some lispness 22:52
ugexe it has more potential to be optimized 23:01
higher bus factor is also another bonus 23:02
23:14 apac joined 23:28 apac left