Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Some is turned off but some still has to be dealt with (variable instruction lengths for example).

Intel tried to compete in mobile for a long time and failed even with a better manufacturing process.



> Some is turned off but some still has to be dealt with (variable instruction lengths for example).

Modern x86_64 processors don't actually natively execute x86 instructions, they translate them into the instructions the hardware actually uses. The percentage of the die required to do that translation is small and immaterial.

> Intel tried to compete in mobile for a long time and failed even with a better manufacturing process.

Intel didn't understand the market.

I recently bought a new phone. On paper it's twice as fast as my old phone. I imagine that's true but I can't tell any difference. Everything was sufficiently fast before and it still is. I never use my phone to do anything that needs an actually-fast CPU. I have no reason to pay additional money for a faster phone CPU. But I do notice how often I have to charge the battery.

These are not atypical purchasing criteria for mobile devices, but that's not the market Intel was chasing with their designs and pricing, so they failed. It's not because they couldn't make an x86 CPU for that market, it's because they didn't want to, because it's a lower margin commodity market.


Faster cpus become more power-efficient cpus because they can race to sleep. So you really do want to pay more for that cpu, but not for the compute performance but for the battery life.

https://en.wikichip.org/wiki/race-to-sleep


That's assuming the faster CPUs use the same amount of power. It's possible for a slower CPU to have better performance per watt. This is often exactly what happens when you limit clock speed -- performance goes down, performance per watt goes up.


> Intel tried to compete in mobile for a long time and failed even with a better manufacturing process.

They didn't fail because of performance, though, they failed because of app support & lack of a quality radio. The CPU performance & efficiency itself was otherwise fine. It wasn't always chart-topping good, but it wasn't bad either.


Agreed - CPUs (at the end at least) were fine. Also they were probably looking for bigger margins than were available.

General point is that I think that Arm has a small architectural advantage due to lack of cruft but that other factors are usually more important - e.g. the resources and quality of team behind implementation.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: