ARM isn't nearly as interesting given the strides both Intel and AMD have made with low power cores.
Any scenario where SoundWave makes sense, using Zen-LP cores align better for AMD.
Apple isn’t going to switch back to AMD64 any time soon. Cloud providers will switch faster if X64 chips become really competitive again.
EDIT: Haha, I was going off our workloads but hilariously there are some HPC-like workloads where benchmarks show the Graviton 4 smoking a 9654 https://www.phoronix.com/review/graviton4-96-core/4
I suppose ours must have been more like the rest of the benchmarks (which show the 9654 faster than the Epyc).
I've always heard it's cooling capacity. I'm also pretty confident that's true
The limit is power capacity and quite often thermal. Newer DCs might be designed with larger thermal envelopes, however rack space is nearly meaningless once you exhaust thermal capacity of the rack/isle.
Performance within thermal envelope is a very important consideration in datacenters. If a new server offers double performance at double power it is a viable upgrade path only for DCs that have that power reserve in the first place.
Any pointers regarding that? How does the computing power to watts ratio look these days across major CPU architectures?
“IT Home News on October 13, @Olrak29_ found that the AMD processor code-named "Sound Wave" has appeared in the customs data list, confirming the company's processor development plan beyond the x86 architecture”
I think that means they are planning to export parts.
I think there still is some speculation involved as to what those parts are, and they might export them only for their own use, but is that likely?
AMD does not have any product that can compete with Intel's N-series or industrial Atom CPUs, which are designed for power consumptions of 6 W or of 10 W and AMD never had any Zen CPU for this power range.
If the rumors about this "Sound Wave" are true, then AMD will finally begin to compete again in this range of TDP, a market that they have abandoned many years ago (since the AMD Jaguar and Puma CPUs), because all their resources were focused on designing Zen CPUs for higher TDPs.
For cheap and low-power CPUs, the expensive x86-64 instruction decoder may matter, unlike for bigger CPUs, so choosing the Aarch64 ISA may be the right decision.
Zen compact cores provide the best energy efficiency for laptops and servers, especially for computation-intensive tasks, but they are not appropriate for cheap low-power devices whose computational throughput is less important than other features. Zen compact cores are big in comparison with ARM Cortex-X4, Intel Darkmont or Qualcomm cores and their higher performance is not important for cheap low-power devices.
[1]: https://learn.microsoft.com/en-us/windows/arm/arm64ec-abi
imho. (!)
i think this would be great!!
personally i totally understood why AMD gave up on its last attempt - the A1100 opterons - about 10 years ago in favor of the back then new ryzen architecture:
* https://en.wikipedia.org/wiki/List_of_AMD_Opteron_processors...
but what i would really like to see: an ARM soc/apu on an "open"*) (!) hardware-platform similar to the existing amd64 pc hardware.
*) "open" as in: i'm able to boot whatever (vanilla) arm64 linux-distribution or other OS i want ...
i have to add: i'm personally offended by the amount of tinkering of the firmware/boot-process which is necessary to get for example the raspberry pi 5 (or 4) to boot vanilla debian/arm64 ... ;)
br, a..z
ps. even if its a bit o.T. in this context, as a reminder a link to a slightly older article about an interview with jim keller about how ISA no longer matters that much ...
"ARM or x86? ISA Doesn’t Matter"
> * https://chipsandcheese.com/p/arm-or-x86-isa-doesnt-matter
Some people, for some strange reason, want to endlessly relitigate the old 1980'ies RISC vs CISC flamewars. Jim Kellers interview above is a good antidote for that. Yes, RISC vs CISC matters for something like a simple in-order core you might see in embedded systems. For a big OoO core, much less so.
That doesn't mean you'd end up with x86 if you'd design a clean sheet 'best practices' ISA today. Probably it would indeed look something like aarch64 or RISC-V. So certainly in that sense RISC won. But the win isn't so overwhelming that it overcomes the value of the x86 software ecosystem in the markets where x86 plays.
Could be a revival but for different purposes
https://chipsandcheese.com/p/evaluating-the-infinity-cache-i...
So I went out looking for an ARM-based server of equivalent strength to a Mac Mini that I could find and there's really not that much out there. There's the Qualcomm Snapdragon X Elite which is in only really one actual buyable thing (The Lenovo Ideacentre) and some vaporware Geekom or something product. But this thing doesn't have very good Linux support (it's built for ARM Windows apparently) and it's much costlier than some Apple Silicon running Asahi Linux.
So I'm eventually going to end up with some M1 Ultra Studio or an M4 Mini running Asahi Linux, which seems like such a complete inversion of the days when people would make Hackintoshes.
- Low power when only idling through events from the radio networks
- Low power and reasonable performance when classifying objects in a few video feeds.
- Higher power and performance when occasionally doing STT/TTS and inference on a small local LLM
But, wouldn't it make more sense for amd to go into risc-v at this point of time?
But.. ..why? Of all things, I would have expected the webcam to not be cpu-related..
Cameras used on x86-64 usually just work using that usb webcam standard driver (what is that called again? uvcvideo?). But these smartphone-land cameras don't adhere to that standard, they probably don't connect using USB. They are designed to be used with the SoC vendor's downstream fork of Android or whatever, using proprietary blobs.
Performance per watt is increasing due to the lithography.
Also, Devon’s paradox.
... the rest is history.
Traditionally x86 has been built powerful and power hungry and then designers scaled the chips down whereas it's the opposite for ARM.
For whatever reason, this also makes it possible to get much bigger YoY performance gains in ARM. The Apple M4 is a mature design[0] and yet a year later the M5 is CPU +15% GPU +30% memory bandwidth +28%.
The Snapdragon Elite X series is showing a similar trajectory.
So Jim Keller ended up being wrong that ISA doesn't matter. Its just that it's the people in the ISA that matter, not the silicon.
[0] its design traces all the way back to the A12 from 2018, and in some fundamental ways even to the A10 from 2016.
I would need some strong evidence to make me think it isn't the ISA that makes the difference.
We will see how big improvement is it's successor panther lake in January on 18A node
>I would need some strong evidence to make me think it isn't the ISA that makes the difference.
It is like saying that Java syntax is faster than C# syntax.
Everything is about the implementation: compiler, jit, runtime, stdlib, etc
If you spent decades of effort on peformance and ghz then don't be shocked that someone who spent decades on energy eff is better in that category
Basically, x86 uses op caches and micro ops reduces instruction decoder use, the decoder itself doesn't use significant power, and ARM also uses op caches and micro ops to improve performance. So there is little effective difference. Micro ops and branch prediction is where the big wins are and both ISAs use them extensively.
If the hardware is equal and the designers are equally skilled, yet one ISA consistently pulls ahead, that leads to the likely conclusion that the way the chips get designed must be different for the winning ISA.
For what it's worth, the same is happening in GPU land. Infamously, the M1 Ultra GPU at 120W equals the performance of the RTX 3090 at 320W (!).
That same M1 also smoked an Intel i9.
Stuff like this, https://www.amazon.de/-/en/Microsoft-Corporation/dp/15723171...
For me personally I’d love it if this made it to a framework mainboard. I wouldn’t even mind the soldered memory, I understand the technical tradeoff there.
Chip manufacturers need to focus on making power-efficient, high-performance workhorses. Apple figured this out first and got frustrated enough with Intel, who was more preoccupied with vendor lock-in than with doing the one thing they were supposed to do: developing best-in-class chips. The jump from x86 to M1 completely destroyed Intel’s reputation on that front. Turns out all those incremental changes over the years were them just moving deck chairs around. AMD was just tagging along and did not offer much more than them. They too got sidelined by Apple’s move. They never were much better in terms of efficiency and speed. So them now maybe getting back into ARM chips is a sign that times are changing and x86 is becoming a legacy architecture.
This shouldn’t matter. Both Apple and Microsoft have emulation capability. Apple is of course retiring theirs, but that’s more of a prioritization/locking strategy than it is for technical reasons. This is the third time they’ve pulled off emulation as a strategy to go to a new architecture: Motorola 68000 to PowerPC to x86 to ARM. Emulation has worked great for decades. It has broken the grip X86 has had on the market for four decades.
Why have both to run native arm64 code? Nearly anything you'd want is cross compiled/compilable (save some macOS stuff but that's more than just CPU architecture).
My understanding is that ARM chips can be more efficient? Hence them being used in phones etc.
I guess it would let you run android stuff "natively"?
Or perhaps you imagine running Blender in x64 mode and discord in the low wattage ARM chip?
They will be very happy.
128-bit LPDDR5X-9600 is about 150 GB/s, that's 50% better than an Orin NX. If they can sell these things for less than like $500 then it would be a pretty decent deal for edge inference. 16 GB is ridiculously tiny for the use case though when it's actually more like 15 in practice and the OS and other stuff then takes another two or three, leaving you with like 12 maybe. Hopefully there's a 32 GB model eventually...
mgh2•6h ago