[tracker1]

Given the new 128-core AMD server parts are on-par with ARM in terms of power efficiency and capable of more raw compute, it may even grow a bit.

I think there's lots of room for ARM, Risc-V and x86_64 in the future. There's reasons to support any of them over the others. And given how well developer tool are getting support across them all, it may actually grow a lot. I think the down side is a lot of the secondary compute accelerators, such as what intel is pushing and what the various ARM and Risc-V implementations include in practice.

The further from a common core you get, the more complex porting or cross platform tooling gets. Even if for big gains in some parts. For example, working on personal/hobby projects in ARM boards that aren't RPi is sometimes an exercise in frustration, with no mainline support at all.

[mlindner]

> I think the down side is a lot of the secondary compute accelerators, such as what intel is pushing and what the various ARM and Risc-V implementations include in practice.

I’m curious why this is a downside. The current trends in computing is that we’re long past the point of single threaded compute. The first step of that was multi processor and multi core and that’ll continue with more and more dedicated and specialized computing sub-processors. Energy prices are more and more becoming a major determining factor as is the area needed for cooling. By having more separated subprocessors you get both efficiency and easier ability to cool the parts.

[tracker1]

The specialized sub-processors are implemented differently, not always available, and not available 1:1 to compute nodes. If you're offering, for example, cloud compute... you can offer 4 cores pretty easily... but if there are 2 specialized sub-processors, then do you offer them, does this queue across all users/clients on that system or do you just block and pretend it doesn't exist. For Zen 4c, they're all general compute.

This means, practically speaking, you're only going to really have 1 host on a server that wants/needs these specialized sub-processors. Which means more space/heat/power for a single user/service. It's probably fine for some things, but far from ideal. This also doesn't get into software optimization and alternative paths where not available.

This gets far worse in the ARM space, as it seems every SOC does something different, which means it's often broken, or unusable if you're using a mainline OS/kernel and even then most software won't be optimized for it. At best, you can maybe playback 4k compressed video. At worst, you can't at all. Just speaking to the most common instance in that space, which is video compression, which is often built around closed drivers that mainline OSes (Ubuntu Server, Debian, etc) don't have in the box, and the vendor only supports a single version of a distro fork with no upgrade path.

[Incipient]

I'm not a hardware designer, so quite possibly wrong.

My understanding for the push for energy efficiency is not for cost reasons, but for performance and stability. At a certain power level, the chips just can't dissipate enough energy, especially on smaller nodes.

If amd could double the performance at double the power, they would.

Cost is obviously a marketing/client-value thing too.