4 ms·

It has nearly the same interface design as cuFFT, admittedly with less documentation. I’m not sure I understand this complaint versus the competition. https://r

It has nearly the same interface design as cuFFT, admittedly with less documentation. I’m not sure I understand this complaint versus the competition. https://rocm.docs.amd.com/projects/hipFFT/en/latest/api.html https://rocm.docs.amd.com/projects/hipFFT/en/latest/api.html If you’re complaining about cuFFTs design, how BLAS like interfaces are outdated, and a lack of a proper hypothetical heterogenous array programming language?, sure. But it’s not much better in Nvidia land.

westurner 3y ago
https://www.amd.com/en/graphics/servers-solutions-rocm-hpc https://www.amd.com/en/graphics/servers-solutions-rocm-hpc : > ROCm™-optimized libraries currently include BLAS, FFT, RNG, Sparse, NCCL (RCCL) and Eigen ... and Numba, which you can compile a symbolic expression for with sympy.utilities.lambdify. https://docs.sympy.org/latest/modules/numeric-computation.html#lambdify https://docs.sympy.org/latest/modules/numeric-computation.ht... AMD ROCm does do HPC. Which desktop/workstation AMD GPUs are now supported with optimization?
- atemerev 3y ago
  There are libraries, yes. I was talking about using it directly.
atemerev 3y ago
No, I mean for writing new code. I know that FFT is already in the libraries, I was using it as an example. About 200 LoC in CUDA, and 1200 lines of code in ROCm. ROCm is boilerplate-ridden and hardly usable for new code.
- westurner 3y ago
  That's a contrived example, then. Also because there's already an optimized version of FFT in their libraries. At least with open-source AMD code, it can be fixed with Pull Requests. FWIU, OpenCL is insufficient, CUDA is the closed-source fanboy favorite that the industry can't move away from, and Intel OneAPI may be the most portable but not the most performant. Impact-wise, contributing to the ROCm and OneAPI tools to help them be more competitive is in consumers' interest.
  - atemerev 3y ago
    The industry can't move from CUDA because you can easily write anything in CUDA, as opposed to ROCm. I needed once to write a lattice Boltzman CFD simulation, it is so much easier in CUDA compared to ROCm, I wouldn't even start the latter unless I am forced to. Eveything takes 5x amount of code and 5x amount of time. ROCm is bad API design, and no amount of gradual tinkering will save it. I wonder why AMD can't design something better. HIP exists, but it is a "lesser CUDA" (CUDA is actually a mediocre API, we can design things much better than that now).
    - westurner 3y ago
      What was the difference in runtime performance, and did you try CuPy? https://github.com/cupy/cupy https://github.com/cupy/cupy : > CuPy is a NumPy/SciPy-compatible array library for GPU-accelerated computing with Python. CuPy acts as a drop-in replacement to run existing NumPy/SciPy code on NVIDIA CUDA or AMD ROCm platforms. Projects using CuPy: https://github.com/cupy/cupy/wiki/Projects-using-CuPy https://github.com/cupy/cupy/wiki/Projects-using-CuPy

westurner 3y ago

https://www.amd.com/en/graphics/servers-solutions-rocm-hpc https://www.amd.com/en/graphics/servers-solutions-rocm-hpc : > ROCm™-optimized libraries currently include BLAS, FFT, RNG, Sparse, NCCL (RCCL) and Eigen ... and Numba, which you can compile a symbolic expression for with sympy.utilities.lambdify. https://docs.sympy.org/latest/modules/numeric-computation.html#lambdify https://docs.sympy.org/latest/modules/numeric-computation.ht... AMD ROCm does do HPC. Which desktop/workstation AMD GPUs are now supported with optimization?

atemerev 3y ago
There are libraries, yes. I was talking about using it directly.

atemerev 3y ago

No, I mean for writing new code. I know that FFT is already in the libraries, I was using it as an example. About 200 LoC in CUDA, and 1200 lines of code in ROCm. ROCm is boilerplate-ridden and hardly usable for new code.

westurner 3y ago
That's a contrived example, then. Also because there's already an optimized version of FFT in their libraries. At least with open-source AMD code, it can be fixed with Pull Requests. FWIU, OpenCL is insufficient, CUDA is the closed-source fanboy favorite that the industry can't move away from, and Intel OneAPI may be the most portable but not the most performant. Impact-wise, contributing to the ROCm and OneAPI tools to help them be more competitive is in consumers' interest.
- atemerev 3y ago
  The industry can't move from CUDA because you can easily write anything in CUDA, as opposed to ROCm. I needed once to write a lattice Boltzman CFD simulation, it is so much easier in CUDA compared to ROCm, I wouldn't even start the latter unless I am forced to. Eveything takes 5x amount of code and 5x amount of time. ROCm is bad API design, and no amount of gradual tinkering will save it. I wonder why AMD can't design something better. HIP exists, but it is a "lesser CUDA" (CUDA is actually a mediocre API, we can design things much better than that now).
  - westurner 3y ago
    What was the difference in runtime performance, and did you try CuPy? https://github.com/cupy/cupy https://github.com/cupy/cupy : > CuPy is a NumPy/SciPy-compatible array library for GPU-accelerated computing with Python. CuPy acts as a drop-in replacement to run existing NumPy/SciPy code on NVIDIA CUDA or AMD ROCm platforms. Projects using CuPy: https://github.com/cupy/cupy/wiki/Projects-using-CuPy https://github.com/cupy/cupy/wiki/Projects-using-CuPy