9 Oct 2024
lizmat <1K open issues :-) 17:29
[Coke] \o/ 17:32
vrurg lizmat: considering the `handles` case, you'd need something extra to handle the `handles => *`. Though it could be another entry in the hash. 19:11
lizmat: Another point: conflicts. Especially dynamically added methods. The current semantics would be hard to follow then. 19:12
Though I'm not happy with the semantics either way. Using `handles` as a fallback resolution is more appealing to me. In which case `*` becomes the fallback of fallback. :) 19:14
MasterDuke lizmat: you're running the whateverables now right? i just killed bisectable somehow 22:00
huh. may have just killed it again. not sure why this particular query is causing it so much trouble though 22:06
lizmat MasterDuke: AlexDaniel is still running them 22:32
I just run Geth and RakuIRCLogger
10 Oct 2024
ab5tract lizmat awesome! :D 06:42
^^ ( <1K open issues) 06:43
Geth roast: 994d0be545 | (Elizabeth Mattijsen)++ | S05-grammar/inheritance.t
Add test for #2851
09:50
doomlord Hello, what would it take to change the MultiDimArray repr to use an array to implement fixed dimensions as strides and expose this functionality to raku-code? 11:15
I think that’s how people do this nowadays 11:16
Changing the C side is trivial, how do you expose that to Raku? 11:17
lizmat through NQP or through dispatch calls: disclaimer: never done that myself 11:19
question probably better asked on #moarvm
nine patrickb ab5tract suggestions?
doomlord lizmat: thanks, was it considered to implement that in pure raku on top of the Buf representation? That would be an alternative solution (dunno about performances) 11:22
lizmat I don't think jnthn ever considered that... but I have at some point :-) 11:27
if only for the fact that it would also run on the JVM
doomlord Indeed
lizmat also: I think with new-disp, I think a pure Raku / nqp implementation would only be 1 magnitude slower than a pure C one 11:28
doomlord Would be nice to hear some arguments against that 11:29
A part this performance aspect
Geth rakudo/main: a9c9e39850 | (Elizabeth Mattijsen)++ | src/core.c/Complex.rakumod
Make prefix - not negate 0 as real value in i

Fixes #2986
11:43
roast: f74eff7a6a | (Elizabeth Mattijsen)++ | S32-num/complex.t
Add tests for #2986
11:44
rakudo/main: 1cedcee68f | (Elizabeth Mattijsen)++ | t/12-rakuast/xx-fixed-in-rakuast.rakutest
Add test for #2996
11:49
doomlord lizmat: I think the future proof way would be to give the possibility for Bufs to move between devices. As it can be done in torch 11:54
lizmat "Bufs to move between devices" what do you mean by that? 11:55
doomlord Practice shows that the overhead is easily overcome by running shaders on the gpu
I mean that now there is the assumption that Bufs are on the main memory 11:56
lizmat ah, ok, gotcha
doomlord This is not the case in modern numerical libraries , a Buf can live on the gpu
lizmat I suggest making a problem solving issue for this, so more people can take part in this discussion 11:58
doomlord Indeed
lizmat afk for quite a few hours&
nine I think a more productive way is to just dig into it and provide an example implementation. You can easily base your fixed dimensional array on a 1 dimensional native array or even a Buf (though I don't think Buf provides any advantages here). 12:29
Doing it in pure Raku lets you focus on the API and algorithms first. When you have figured those out, you can profile and check where the performance bottleneck actually is and what changes to the VM would improve that state. Maybe it requires the VM knowing more about the storage format but maybe it's just better optimization of natively typed code in general. 12:30
If you want to be able to store it in GPU memory, then maybe basing on Buf is indeed helpful. 12:32
FWIW I have long considered heterogenous architectures (i.e. GPU computing) to be a bit of an archilles heel or architectural blind spot of Raku. But maybe it's not all that bad. I guess we'll only know once someone does actually try to use GPUs from Raku for some heavy computation. 12:34
After all Python of all languages is used heavily in this area. Though it's really just used to set up the computation pipeline rather than computation itself. 12:36
timo python's "buffer" API is something i've wanted for raku in the past 13:04