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
|