jpsamaroo

8 ms·

1.
by jpsamaroo 4y ago
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 library (note: I
2.
by jpsamaroo 5y ago
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 getting filled up with m
3.
by jpsamaroo 5y ago
I think the OP's point is that running these optimizations in production as-is is dangerous because future code changes in the various places could accidentally impede the optimizer's ability to apply all the transformations that
4.
by jpsamaroo 5y ago
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 didn't go fa
5.
by jpsamaroo 5y ago
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 defin
6.
by jpsamaroo 5y ago
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 ecosystem engagement fo
7.
by jpsamaroo 5y ago
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 signifi
8.
by jpsamaroo 5y ago
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 than what
9.
by jpsamaroo 6y ago
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 to ROCm components t
10.
by jpsamaroo 6y ago
> 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
11.
by jpsamaroo 6y ago
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 o
12.
by jpsamaroo 6y ago
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 performant GPU code
13.
by jpsamaroo 6y ago
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 KernelAbstractions.jl. It&
14.
by jpsamaroo 6y ago
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. This will pr
15.
by jpsamaroo 6y ago
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
16.
by jpsamaroo 6y ago
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. KernelAbstractions.jl will also
17.
by jpsamaroo 6y ago
> 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 version