5 ms·

yeah, no. Tooling support, driver support and general Optimization matters. So does platform maturity. You don't want your phone to run x86 (and it won't for a

by dtx1 3y ago

yeah, no. Tooling support, driver support and general Optimization matters. So does platform maturity. You don't want your phone to run x86 (and it won't for a while) and though possible its a pain to deal with an arm server at the moment because some random library you use just won't be compatible. And If single threaded performance matters, ARM is behind by a decade.

circuit10 3y ago
Having an Oracle Cloud Free Tier ARM VPS it’s surprising how much just works, I think the only thing I couldn’t run was Chrome Remote Desktop (yes, I want to remote into my VPS sometimes, for example it’s the easiest way to leave a GUI program running in the background without leaving my PC on) and only a few other things needed extra steps. But it’s probably a lot different on desktop or if you’re running different types of programs
- wolf550e 3y ago
  Some libraries have x86 SIMD code but no ARM SIMD code, so benchmarking real world use cases you compare SIMD vs scalar code and x86 is much faster. Server side libraries for ARM are a less mature situation than x86.
rektide 3y ago
We don't know, is the only good answer. We haven't done much trying in the past 10 years. Intel's Lakefield was doing quite well in the tablet/MID space. It also had the disadvantages of both comparatively ancient Atom-esque cores- far worse than Intel's new E cores-and a massive massive huge Skylake core. Oh and a replayed decade old desktop iGPU too. ARM is no longer behind by all that much on single threaded. On geekbench a m2 can do 1916 points, a 7950 2300points. Slightly bigger gap on Cinebench, 1580 Vs 2050. A big part of the gap here is almost certainly the Hz being so different. We just don't know. There's old beliefs we have held but we had so little evidence for these biases then. X86 rarely tried to be really tiny, had so much more to learn if it was to succeed. ARM rarely tried to be big, and has been learning. There's scant evidence there are real limiting factors for either.
hedora 3y ago
These benchmarks suggest arm has been at single threaded performance parity on server since 2020: https://www.anandtech.com/show/15578/cloud-clash-amazon-graviton2-arm-against-intel-and-amd/5 https://www.anandtech.com/show/15578/cloud-clash-amazon-grav... (Apple Silicon blows them away on laptops, of course.)
- tyingq 3y ago
  I imagine some of the remaining gap might be places where inline ASM or things like SIMD, AVX, etc, exist. Where there's been more years and a larger set of people optimizing that ASM for x86/64 servers.
  - GeekyBear 3y ago
    > the remaining gap might be places where inline ASM or things like SIMD, AVX, etc, exist This was one of the takeaways back in 2017 when Cloudflare sampled Qualcomm's very early Centriq ARM server chips. > At Cloudflare we use an improved version of the library, optimized for 64-bit Intel processors, and although it is written mostly in C, it does use some Intel specific intrinsics. Comparing this optimized version to the generic zlib library wouldn’t be fair. Not to worry, with little effort I adapted the library to work very well on the ARMv8 architecture, with the use of NEON and CRC32 intrinsics. In the process it is twice as fast as the generic library for some files. https://blog.cloudflare.com/arm-takes-wing/ https://blog.cloudflare.com/arm-takes-wing/
kaelinl 3y ago
This isn't the point of the article. The article is commenting on CPU design: area efficiency, power efficiency, design cost, etc. They're proposing that the reason x86 CPUs have historically beat ARM CPUs in performance, and the reason ARM CPUs have historically beat x86 CPUs in power efficiency, has nothing to do with the design of the ISA itself. You could build an ARM CPU to beat an x86 CPU in high performance computing, or vice versa. They're saying that the format of the instructions and the particular way the operations are structured isn't the driving factor. Instead, it's just a historical arteract of how the ISAs were used. In other words, yes, there are plenty of ecosystem reasons that these two (and potentially, more) families of chips are better for some things vs. others, but if the two companies swapped their ISAs 30 years ago we might see exactly the same ecosystem just with different instruction formats.
- Jasper_ 3y ago
  Yeah, ARM's big advantage is that they are willing to make absolutely zero margin on chips, which allows them to play both ends of the spectrum. They can make Celeron-tier chips that don't take any power and practically given away for free and use that as evidence of ARM's superiority in things like the M1 and supercomputers. Even as Intel is declining, it still makes way, way more money than ARM does. If Intel wanted to play in the lose-money business, it could make something to kick the pants off of ARM's chips. It just would rather not.
- IshKebab 3y ago
  I'm not sure I buy that. x86 chips have targeted laptops for decades, yet they were absolutely walloped by Apple's ARM chips. IIRC a big part of that is that the ARM ISA has 2/4 byte instructions whereas x86 can be crazy sizes which made it easier for Apple to have 8 instruction decoders. At least that's the best theory I heard for why it is so fast.
jsheard 3y ago
> You don't want your phone to run x86 (and it won't for a while) It's easily forgotten but there were Android phones which used Intel x86 processors, such as the early Asus Zenfones. They didn't stick though.
- kelnos 3y ago
  I think that's the point, though: why didn't they stick? Was it a price/performance/power issue, which would point to ARM being somehow "better" on those dimensions, or was it something incidental, like production availability, or even just perhaps a lack of desire at Intel to aggressively pursue that market?
  - amluto 3y ago
    At least some of the attempts in question had, ahem, interesting ideas for how to combine baseband and AP on one chip. (x86 has a truly atrocious thing called SMM (“system management mode”). It is not directly exposed to anything except firmware and malware, so it could be changed in backwards-incompatible ways without breaking existing software, but for some reason neither Intel nor AMD seems willing to do so. For desktop and server workloads, this isn’t really a big deal. For something like an iPhone, it would be a major non-selling-point. Also, x86 interrupt latency is awful, and this is an ISA issue. x86 cannot currently compete in any application where this matters. FRED may improve this if the implementation is good enough.)
- rsaxvc 3y ago
  You could even get an AMD chip in your XPPhone https://www.umpcportal.com/products/XPPhone/XPPhone https://www.umpcportal.com/products/XPPhone/XPPhone :p
- eloisant 3y ago
  The biggest issue is that ARM was already king, so x86 was an exception that wasn't always accounted for. So there was occasional incompatibilities and no real benefit to balance them.
dehrmann 3y ago
It sounds like Atom could have found a home in phones.

by dtx1 3y ago

circuit10 3y ago

Having an Oracle Cloud Free Tier ARM VPS it’s surprising how much just works, I think the only thing I couldn’t run was Chrome Remote Desktop (yes, I want to remote into my VPS sometimes, for example it’s the easiest way to leave a GUI program running in the background without leaving my PC on) and only a few other things needed extra steps. But it’s probably a lot different on desktop or if you’re running different types of programs

wolf550e 3y ago
Some libraries have x86 SIMD code but no ARM SIMD code, so benchmarking real world use cases you compare SIMD vs scalar code and x86 is much faster. Server side libraries for ARM are a less mature situation than x86.

rektide 3y ago

We don't know, is the only good answer. We haven't done much trying in the past 10 years. Intel's Lakefield was doing quite well in the tablet/MID space. It also had the disadvantages of both comparatively ancient Atom-esque cores- far worse than Intel's new E cores-and a massive massive huge Skylake core. Oh and a replayed decade old desktop iGPU too. ARM is no longer behind by all that much on single threaded. On geekbench a m2 can do 1916 points, a 7950 2300points. Slightly bigger gap on Cinebench, 1580 Vs 2050. A big part of the gap here is almost certainly the Hz being so different. We just don't know. There's old beliefs we have held but we had so little evidence for these biases then. X86 rarely tried to be really tiny, had so much more to learn if it was to succeed. ARM rarely tried to be big, and has been learning. There's scant evidence there are real limiting factors for either.

hedora 3y ago

These benchmarks suggest arm has been at single threaded performance parity on server since 2020: https://www.anandtech.com/show/15578/cloud-clash-amazon-graviton2-arm-against-intel-and-amd/5 https://www.anandtech.com/show/15578/cloud-clash-amazon-grav... (Apple Silicon blows them away on laptops, of course.)

tyingq 3y ago
I imagine some of the remaining gap might be places where inline ASM or things like SIMD, AVX, etc, exist. Where there's been more years and a larger set of people optimizing that ASM for x86/64 servers.
- GeekyBear 3y ago
  > the remaining gap might be places where inline ASM or things like SIMD, AVX, etc, exist This was one of the takeaways back in 2017 when Cloudflare sampled Qualcomm's very early Centriq ARM server chips. > At Cloudflare we use an improved version of the library, optimized for 64-bit Intel processors, and although it is written mostly in C, it does use some Intel specific intrinsics. Comparing this optimized version to the generic zlib library wouldn’t be fair. Not to worry, with little effort I adapted the library to work very well on the ARMv8 architecture, with the use of NEON and CRC32 intrinsics. In the process it is twice as fast as the generic library for some files. https://blog.cloudflare.com/arm-takes-wing/ https://blog.cloudflare.com/arm-takes-wing/

kaelinl 3y ago

This isn't the point of the article. The article is commenting on CPU design: area efficiency, power efficiency, design cost, etc. They're proposing that the reason x86 CPUs have historically beat ARM CPUs in performance, and the reason ARM CPUs have historically beat x86 CPUs in power efficiency, has nothing to do with the design of the ISA itself. You could build an ARM CPU to beat an x86 CPU in high performance computing, or vice versa. They're saying that the format of the instructions and the particular way the operations are structured isn't the driving factor. Instead, it's just a historical arteract of how the ISAs were used. In other words, yes, there are plenty of ecosystem reasons that these two (and potentially, more) families of chips are better for some things vs. others, but if the two companies swapped their ISAs 30 years ago we might see exactly the same ecosystem just with different instruction formats.

Jasper_ 3y ago
Yeah, ARM's big advantage is that they are willing to make absolutely zero margin on chips, which allows them to play both ends of the spectrum. They can make Celeron-tier chips that don't take any power and practically given away for free and use that as evidence of ARM's superiority in things like the M1 and supercomputers. Even as Intel is declining, it still makes way, way more money than ARM does. If Intel wanted to play in the lose-money business, it could make something to kick the pants off of ARM's chips. It just would rather not.
IshKebab 3y ago
I'm not sure I buy that. x86 chips have targeted laptops for decades, yet they were absolutely walloped by Apple's ARM chips. IIRC a big part of that is that the ARM ISA has 2/4 byte instructions whereas x86 can be crazy sizes which made it easier for Apple to have 8 instruction decoders. At least that's the best theory I heard for why it is so fast.

jsheard 3y ago

> You don't want your phone to run x86 (and it won't for a while) It's easily forgotten but there were Android phones which used Intel x86 processors, such as the early Asus Zenfones. They didn't stick though.

kelnos 3y ago
I think that's the point, though: why didn't they stick? Was it a price/performance/power issue, which would point to ARM being somehow "better" on those dimensions, or was it something incidental, like production availability, or even just perhaps a lack of desire at Intel to aggressively pursue that market?
- amluto 3y ago
  At least some of the attempts in question had, ahem, interesting ideas for how to combine baseband and AP on one chip. (x86 has a truly atrocious thing called SMM (“system management mode”). It is not directly exposed to anything except firmware and malware, so it could be changed in backwards-incompatible ways without breaking existing software, but for some reason neither Intel nor AMD seems willing to do so. For desktop and server workloads, this isn’t really a big deal. For something like an iPhone, it would be a major non-selling-point. Also, x86 interrupt latency is awful, and this is an ISA issue. x86 cannot currently compete in any application where this matters. FRED may improve this if the implementation is good enough.)
rsaxvc 3y ago
You could even get an AMD chip in your XPPhone https://www.umpcportal.com/products/XPPhone/XPPhone https://www.umpcportal.com/products/XPPhone/XPPhone :p
eloisant 3y ago
The biggest issue is that ARM was already king, so x86 was an exception that wasn't always accounted for. So there was occasional incompatibilities and no real benefit to balance them.

dehrmann 3y ago

It sounds like Atom could have found a home in phones.