This is exciting news! What's also exciting is that it's not just C++ that can run on this supercomputer; there is also good (currently unofficial) support for programming those GPUs from Julia, via the AMDGPU.jl…
Sxmo uses ModemManager[0] for calls+texts, and mmsd-tng[1] for MMS support. It generally works quite well (in my limited experience), modulo some dropped messages (might already be fixed?) and the modem occasionally…
It is certainly a shame, but I'm confident that Dagger and its new DTable should be able to cover all of the ground that JuliaDB covers, while being far easier to maintain. I think JuliaDB had some great ideas, but it…
Firstly, I'll say that we already have work started to implement out-of-core directly in Dagger: https://github.com/JuliaParallel/Dagger.jl/pull/289. With that PR in place, it should be possible to define a "storage…
Definitely not dead; Vega is well supported, and with some tweaks, Polaris probably works too (although it definitely was broken in HIP around ROCm 4.0.0 or so). I think AMD has some work to do on non-C++/Python…
For kernel programming, https://github.com/JuliaGPU/KernelAbstractions.jl (shortened to KA) is what the JuliaGPU team has been developing as a unified programming interface for GPUs of any flavor. It's not significantly…
AMD has done great work in a very short amount of time, but let's not forget that they're still very new to the GPU compute game. The ROCm stack is overall still pretty buggy, and definitely hard to build in ways other…
This is an issue with AMD not wanting to long-term support the code paths in ROCm components necessary to enable ROCm on these devices. My hope is that Polaris GPU owners will step up to the plate and contribute patches…
> Jax is even consider to do better in that department in terms on performance then all of julia so wat are u talking about Please provide sources for this claim
Yes, and that's why Julia gained CUDA support first. My point was to respond to "Why would someone use this instead of plain old OpenCL(or CUDA) with C++?", and my answer was, "you can use something other than OpenCL C…
OpenCL and various other solutions basically require that one writes kernels in C/C++. This is an unfortunate limitation, and can make it hard for less experienced users (researchers especially) to write correct and…
At least for the GPU case, the ecosystem is slowing moving towards writing generic kernels that can be executed on both the CPU (multithreaded) and the GPU, without doing anything special in the kernel itself, via…
JavaScript's JIT is a tracing JIT, so it can compile code in the background while the interpreter/less optimized compiled code is actually running. In Julia, the compiler runs first, and then the compiled code is run.…
Actually, Sxmo has MMS patches pending on the mailing list which allow receiving and viewing text, audio, and video content: https://lists.sr.ht/~mil/sxmo-devel/patches/14017 EDIT: Wifi works perfectly for me as well,…
Tim has been working on making it easy to use CUDA.jl and AMDGPU.jl pretty interchangeably through GPUArrays.jl, and this approach seems to be pretty extensible to other accelerators like Intel's dGPUs.…
> This is a complete novice, ill informed, question. So forgive it in advanced, but why have an AMD specific backend at all? Couldn't you just use AMD's HIP/HIP-IFY tool on the CUDA backend and get an AMD friendly…
This is exciting news! What's also exciting is that it's not just C++ that can run on this supercomputer; there is also good (currently unofficial) support for programming those GPUs from Julia, via the AMDGPU.jl…
Sxmo uses ModemManager[0] for calls+texts, and mmsd-tng[1] for MMS support. It generally works quite well (in my limited experience), modulo some dropped messages (might already be fixed?) and the modem occasionally…
It is certainly a shame, but I'm confident that Dagger and its new DTable should be able to cover all of the ground that JuliaDB covers, while being far easier to maintain. I think JuliaDB had some great ideas, but it…
Firstly, I'll say that we already have work started to implement out-of-core directly in Dagger: https://github.com/JuliaParallel/Dagger.jl/pull/289. With that PR in place, it should be possible to define a "storage…
Definitely not dead; Vega is well supported, and with some tweaks, Polaris probably works too (although it definitely was broken in HIP around ROCm 4.0.0 or so). I think AMD has some work to do on non-C++/Python…
For kernel programming, https://github.com/JuliaGPU/KernelAbstractions.jl (shortened to KA) is what the JuliaGPU team has been developing as a unified programming interface for GPUs of any flavor. It's not significantly…
AMD has done great work in a very short amount of time, but let's not forget that they're still very new to the GPU compute game. The ROCm stack is overall still pretty buggy, and definitely hard to build in ways other…
This is an issue with AMD not wanting to long-term support the code paths in ROCm components necessary to enable ROCm on these devices. My hope is that Polaris GPU owners will step up to the plate and contribute patches…
> Jax is even consider to do better in that department in terms on performance then all of julia so wat are u talking about Please provide sources for this claim
Yes, and that's why Julia gained CUDA support first. My point was to respond to "Why would someone use this instead of plain old OpenCL(or CUDA) with C++?", and my answer was, "you can use something other than OpenCL C…
OpenCL and various other solutions basically require that one writes kernels in C/C++. This is an unfortunate limitation, and can make it hard for less experienced users (researchers especially) to write correct and…
At least for the GPU case, the ecosystem is slowing moving towards writing generic kernels that can be executed on both the CPU (multithreaded) and the GPU, without doing anything special in the kernel itself, via…
JavaScript's JIT is a tracing JIT, so it can compile code in the background while the interpreter/less optimized compiled code is actually running. In Julia, the compiler runs first, and then the compiled code is run.…
Actually, Sxmo has MMS patches pending on the mailing list which allow receiving and viewing text, audio, and video content: https://lists.sr.ht/~mil/sxmo-devel/patches/14017 EDIT: Wifi works perfectly for me as well,…
Tim has been working on making it easy to use CUDA.jl and AMDGPU.jl pretty interchangeably through GPUArrays.jl, and this approach seems to be pretty extensible to other accelerators like Intel's dGPUs.…
> This is a complete novice, ill informed, question. So forgive it in advanced, but why have an AMD specific backend at all? Couldn't you just use AMD's HIP/HIP-IFY tool on the CUDA backend and get an AMD friendly…