01:29 nine left 01:30 nine joined
ab5tract lizmat awesome! :D 06:42
^^ ( <1K open issues) 06:43
09:08 MasterDuke left 09:37 sena_kun joined
Geth roast: 994d0be545 | (Elizabeth Mattijsen)++ | S05-grammar/inheritance.t
Add test for #2851
 09:50
10:01 sena_kun left 10:04 sena_kun joined, sena_kun left 11:13 doomlord joined
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?
11:20 doomlord left, doomlord joined
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
11:24 doomlord left 11:25 doomlord joined
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
11:29 doomlord left
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
11:52 doomlord joined
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
11:54 doomlord left 11:55 doomlord joined
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&
11:59 doomlord left
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
14:41 doomlord joined
doomlord timo: what does python buffer have that raku ones don’t have? The ability to alias each other? 14:42
nine: I think that raku lazy evaluation fits gpu computing. For instance one could imagine multiple matrix operations to be piled up by the language as in a Seq of operation, that then gets executed into a pipeline when the result is requested. This could be a high level interface 14:44
Like it happens in python 14:46
Compiling raku to gpu? I don’t think that’s feasible. An idiomatic low lever api to Vulkan or other computing shaders on nativish buffers would possibly be an easier project 14:48
Something like Inline::* 14:49
14:49 doomlord left 14:58 doomlord joined
doomlord It should support standard well thought libraries 15:02
such as BLAS. As well as abominations such as rocm.docs.amd.com/projects/composa...ocs-5.7.1/
15:02 doomlord left
timo what i mean by the buffer api as that you can just get a binary view into many different kinds of objects 16:01
what's this syntax that i just discovered 17:16
m: class Test { has (Rat); }
camelia ( no output )
17:42 sena_kun joined
Geth roast: 4489a37e86 | (Elizabeth Mattijsen)++ | S05-grammar/inheritance.t
Add test for #3038
 18:17
roast: 0e25ee24b8 | (Elizabeth Mattijsen)++ | S16-filehandles/open.t
Add test for #3073
 18:44
roast: e5baa0c63b | (Elizabeth Mattijsen)++ | S04-exception-handlers/catch.t
Add test for #3080
 18:55
roast: 3cd5e8d87d | (Elizabeth Mattijsen)++ | S04-declarations/state.t
Add tests for #3083
 18:59
roast: 0f6824e95b | (Elizabeth Mattijsen)++ | S02-lexical-conventions/comments.t
Add test for #3143
 21:46
22:05 sena_kun left 22:19 sena_kun joined 22:26 sena_kun left
[Coke] hurls github.com/orgs/community/discussions/141112 23:17
upvote if you like.

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!