201–210 of 323 posts
Earlier quoted context omitted.
But ARM didn't start out as a shitpile of attempted backwards compatibility with an 8 bit CPU. The i8086 was made as an evolution of the i8080.
And it's also not really "nearly as old" considering how fast stuff developed in the early day - the first ARM CPUs launched in 1986, and the i8086 in 1978 - 8 years earlier.
Earlier quoted context omitted.
Oh so the M2 is a lot slower than Samsung phones? Samsung Galaxy S20 FE 5G = 2147483647 multi-core score https://browser.geekbench.com/v5/cpu/15129294 But only 8928 multi-core for the new M2. Or maybe that page is kinda unreliable?
Regardless of how fast the phone is, it’s gonna throttle way down under any heavy load, unless you keep it super cool.
The picture you're painting is far too simple. There are many metrics that play a role for different applications. A modern Nvidia card is magnitudes faster than any CPU and the M1 GPUs. A Nvidia A100 card has HBM memory with ~2TB/s bandwidth. On the other hand, there are areas where a ~5GHz intel CPU is competitive, or even older server chips with AVX can compete. So let's see what happens when Intel and AMD step to…
Both Intel and AMD have the major disadvantage of having (or, let's say, wanting) to maintain x86 backward compatibility - which means not only staying compatible with the almost 45 year old CISC instruction set of the Intel 8086, but also with the whole line of CPUs that came after it. All this ballast makes it harder for them to build an energy-efficient CPU. By contrast, Apple was able to just create a new CPU bas…
And then you try gaming and it is comparable to a Ryzen 7 4800H (45W)/ Nvidia GTX 1650ti (50W).
10+ times M2 performance as a discrete 200W card with dedicated memory and 100ish cores could be really compelling depending on the price point. That’s RTX 3090 territory, but much easier to cool etc.
Earlier quoted context omitted.
"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.
Is that more an indictment of ROCm immaturity or of PyTorch/TensorFlow unwillingness to support it?
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.
Earlier quoted context omitted.
But doesn’t your statement prove that there are decisions and things the user of a node can make which effect the end result? Therefore, is not just process node that matters.
Obviously you can choose not to aim for the best possible performance in order to reduce costs. But for the companies that are competing for the absolute best performance at any cost, which doesn't include Qualcomm, by far the biggest factor determining that performance is the fabrication technology.
Earlier quoted context omitted.
Both Intel and AMD have the major disadvantage of having (or, let's say, wanting) to maintain x86 backward compatibility - which means not only staying compatible with the almost 45 year old CISC instruction set of the Intel 8086, but also with the whole line of CPUs that came after it. All this ballast makes it harder for them to build an energy-efficient CPU. By contrast, Apple was able to just create a new CPU bas…
Do we know whether that x86 backward compatibility is all that problematic? If I’m not mistaken, it is only used as a “public API” even in current CPUs, and on a microcode level it doesn’t have as much relevance.
Earlier quoted context omitted.
For example: Decode. One of the things Apple CPUs keep being praised for is how wide they are. To be wide effectively and keep your execution units busy, you need a wide decoder. With aarch64 it is easy. Every instruction is 4 bytes on a 4 byte boundary. Want a 4-wide decoder? Ingest 16 bytes and copy-and-paste the same decoder 4 times. X86 instructions are variable-length: 1-15 bytes. And you do not know how long an…
And those bytes matter when most Intel CPU cores have only a few dozen KB of L1I cache. Interestingly, the M1 and M2 performance cores have a whopping 192KB of L1 instruction cache.