> It's the same with Apple's M1. I don't know anyone who is using it.

"I can't believe Nixon won. I don't know anyone who voted for him."

Yes, a misquotation, but still. The Java/JVM world has dived into it. Java is all JVM code and it's platform-independent, and unlike, say, Python, the Java world never dived that heavily into native-interface code that tied them to a specific instruction set, they built a faster JVM instead of going out to native code. M1 is so good you can get better performance on a M1 MBA with significantly longer battery life compared to an i9 MBP of the previous generation.

Same for average users who don't do any of the developer things - HN itself is a bubble and most users don't know or care the uarch is different at all, they just know a base-tier M1 feels better than an i9, and they're right.

> So I would expect an AMD CPU on TSMCs 5nm to be pretty close in terms of performance per watt. It's just that the mainstream market isn't willing to pay the premium price for 5nm yet

Apple and AMD are going to be on the same node this year.

"For many years, AMD GPUs were cheaper and equally or more performant than NVIDIA GPUs. Did that stop NVIDIAs lead in AI training? No, software support is the key component. It's the same with Apple's M1. I don't know anyone who is using it. People need obscure x64 instructions and CUDA. And that means you buy AMD CPU + NVIDIA GPU as the cheapest high-performance combination."

Riiight, but, OP isn't necessarily talking purely from an AI/ML use case.

Well if you don't need the high performance, then I'd expect people will go for a cheap CPU, meaning no M1 Ultra.

ML training isn't the only application of high performance computing. Apple is making video editing machines - which is why they have the mix of cores that they do. Simulations are also high-performance computing applications.

> Apple is making video editing machines - which is why they have the mix of cores that they do.

Nope. They have that mix because they've decided to prioritize power consumption reduction (I suspect because they sell way, way more laptops that desktops/servers). It's actually a PITA for developers (you have to ensure that your compute-heavy threads are always on the performance cores), and conceptually confusing for users if they ever have to confront it. For pure performance, with no concern for power consumption, there are faster solutions.

Software changes much faster these days. We are all dealing with high abstraction layers and legacy x86/64 and even CUDA can be replaced without much disruption in most cases.

If it’s proven that Apple can consistently provide better performance per watt per dollar and have enough chips available that people can actually buy, I think they can stand a chance to gain the AI market.

"even CUDA can be replaced without much disruption in most cases"

Tell that to AMD who's been missing out on the very lucrative government data-center market because they can't replace CUDA well enough. BTW, PyTorch and TensorFlow still ship without AMD support despite AMD's ROCm being around for 6 years now.

iirc there are comments saying that ROCm is not very mature yet. I wish OpenCL can evolve to compete with CUDA

Is that more an indictment of ROCm immaturity or of PyTorch/TensorFlow unwillingness to support it?

I believe ROCm isn't usable yet.

I don't know anyone who successfully trained a state of the art neural network on anything that was not NVIDIA. AMD keeps offering their own forks of PyTorch and TensorFlow, but last time I checked they were years outdated, and nobody uses them. So either PyTorch/TensorFlow are secretly sponsored by NVIDIA, or AMD's and Apple's CUDA replacements aren't mature enough yet. Given how many bugs there still are in CUDA despite them being around for a long time,

I'd guess that building a GPU-capable BLAS library is just a lot more work than one would think. I mean I also always wonder why CUDA comes with 400 MB of GPU shaders ... but apparently they need that to cover every edge case in a fast way.

FYI, this is the ROCm "getting started" guide: https://github.com/RadeonOpenCompute/ROCm-docker/blob/master...

NVIDIA has a GUI installer for CUDA.

> building a GPU-capable BLAS library is just a lot more work than one would think

I made a few pieces when needed: dense and sparse matrices, conjugate gradient, householder QR decomposition, other things. Wasn’t terribly hard.

I only needed to support relatively new GPUs, that’s one reason why. Another one, I based on DirectCompute not ROCm. The thing’s well tested (modern videogames are using compute shaders a lot), and works with all 3 vendors of GPUs. The main downside it’s Windows only.

> NVIDIA has a GUI installer for CUDA.

It’s still more friction compared to D3D runtime, which is an essential OS component installed and updated as a part of the OS.

DirectCompute is only the execution of fully trained neural networks, so they can skip all the gradient calculations, which are the compute-heavy and memory-heavy part.

To give you and idea, I need 24GB of GPU RAM to build a background separation model, but once it's finished, it's only 500kb of parameters and it can run on CPU in JavaScript in realtime.

As for the friction, CUDA is easy enough for motivated gaming kids to handle. AMD is not. But I'd predict that today's GPU enthusiast kids will become tomorrow's AI experts. As an example, look at the LAION chat which is a weird mixture of childish humor, gaming memes, and discussions about analytical approximations for probabilistic differential equations. (the Elucidated paper applied to Imagen's DDPM)

DirectCompute is pretty close to CUDA. When handled with care, it can do these compute-heavy pieces with similar performance.

The main downside is the libraries: cuBLAS, cuFFT, and similar pieces of CUDA are manually optimized, and nVidia ships multiple versions of these compute kernels for different GPUs. DirectCompute doesn’t have an equivalent, need to implement manually in HLSL. This can be tricky because for optimal performance different chips need slightly different implementations.

It is the former, that Nvidia effectively sponsors ML libraries. If you're training a neural network, and you are hiring expensive ML people, you're likely just going to pay the Nvidia tax than work on ROCm support.

My use of ROCm for signal processing has been pretty nice so far, and I think the ROCm BLAS library is up to par now.

ROCm is pretty mature, but harder to support than CUDA. Its BLAS library works well. PyTorch and TensorFlow are likely getting a lot more help from Nvidia than from AMD on compatibility. The ROCm ecosystem is a lot smaller, too, so there are many fewer examples to copy.

Still, if you want to do floating point math with high performance for a lot cheaper than Nvidia, investing the time in ROCm is probably worth it.

In our case, we train on NVIDIA and then port to C++ with AVX. It's a bit more work, but deployment on AMD CPUs is even cheaper than on AMD GPUs.