There is an excellent talk titled "Things CPU architects need to think about" from Stanford's ee380 class. Go to http://www.stanford.edu/class/ee380/ay0304.html and pick the Feb 18'th entry (click on the old school icon on the right). It will play with vlc on Linux and Windows Media Player on Windows.
Although the talk is from 9 years ago, the material covered is still very relevant today. It is also quite funny. One of the things talked about is the processing of instructions and chaos theory, including non-intuitive stuff like inserting delays to make things run faster!
It should be noted that x86 processors haven't executed x86 instructions since the early nineties. They are translated into risc like micro-ops. The translation takes a very small fraction of the die area and it gets smaller which each generation of chip/process.
The difference between x86 processor implementations and ARM is that x86 try to get the greatest throughput possible. This is done via techniques like having multiple execution units and executing instructions in parallel where possible (known as ILP and typical values are 2.1), executing instructions out of order where it doesn't make a difference to the results, executing multiple instructions in stages concurrently (pipelines), having tracking for branches to better predict if they will be taken, speculative execution of both parts of a branch at the same time and throwing away the one that turns out not to be taken, complex memory machinery to keep code and data flowing, high clock speeds for the die as a whole, and even higher ones for parts if not all in use and the list goes on. This is not a requirement of x86 implementations but is what most of them do. Intel goes very far down this road, AMD not quite so far, and some implementations like Atom do barely any of it.
ARM processors generally do none of that. It keeps them smaller and simpler, which means lower performance and less power.
For your final paragraph, the instruction set is largely irrelevant. While x86 does have some warts, ARM does too (eg condition codes). The thing you left out is compilers as they generate the code to be executed. Roughly speaking the answer is the winner will be whoever has the better compilers. BTW Moore's law predicts transistor doubling per area every 18 months which most paraphrase as performance will double every 18 months. Someone did a study on compilers and found that compilers double performance about every 18 years!
Because ARM execution has been so simple for so long (eg no concurrent execution of instructions) the compilers haven't mattered that much. In a maximum performance world they matter a lot more, especially with instruction scheduling. And of course most programs would have been compiled a while ago, and probably use conservative optimisations (more aggressive ones can introduce bugs). With Itanium Intel had the idea of making the chip 6 way parallel and let the compiler figure out how to use that (ie smart compiler, dumb/simple chip). It didn't really work.
Indeed, although not to quite the same degree as x86 implementations. They are also dual issue so you'll only get a maximum ILP of 2 although that likely won't hurt that much. I was going to include a bibliography but the post was long enough!
Cortex-A15 and Apple A6 are the high-end now. Cortex-A9's are so small and (relatively) cheap that they throw 4 of them on $20 tablet SoCs even for applications that don't really benefit from many cores.
Although the talk is from 9 years ago, the material covered is still very relevant today. It is also quite funny. One of the things talked about is the processing of instructions and chaos theory, including non-intuitive stuff like inserting delays to make things run faster!
It should be noted that x86 processors haven't executed x86 instructions since the early nineties. They are translated into risc like micro-ops. The translation takes a very small fraction of the die area and it gets smaller which each generation of chip/process.
The difference between x86 processor implementations and ARM is that x86 try to get the greatest throughput possible. This is done via techniques like having multiple execution units and executing instructions in parallel where possible (known as ILP and typical values are 2.1), executing instructions out of order where it doesn't make a difference to the results, executing multiple instructions in stages concurrently (pipelines), having tracking for branches to better predict if they will be taken, speculative execution of both parts of a branch at the same time and throwing away the one that turns out not to be taken, complex memory machinery to keep code and data flowing, high clock speeds for the die as a whole, and even higher ones for parts if not all in use and the list goes on. This is not a requirement of x86 implementations but is what most of them do. Intel goes very far down this road, AMD not quite so far, and some implementations like Atom do barely any of it.
ARM processors generally do none of that. It keeps them smaller and simpler, which means lower performance and less power.
For your final paragraph, the instruction set is largely irrelevant. While x86 does have some warts, ARM does too (eg condition codes). The thing you left out is compilers as they generate the code to be executed. Roughly speaking the answer is the winner will be whoever has the better compilers. BTW Moore's law predicts transistor doubling per area every 18 months which most paraphrase as performance will double every 18 months. Someone did a study on compilers and found that compilers double performance about every 18 years!
Because ARM execution has been so simple for so long (eg no concurrent execution of instructions) the compilers haven't mattered that much. In a maximum performance world they matter a lot more, especially with instruction scheduling. And of course most programs would have been compiled a while ago, and probably use conservative optimisations (more aggressive ones can introduce bugs). With Itanium Intel had the idea of making the chip 6 way parallel and let the compiler figure out how to use that (ie smart compiler, dumb/simple chip). It didn't really work.