As someone who has little idea about chip design: is there that much room for benefit purely from instruction set? i.e. if someone were to design the Optimum Instruction Set [and perhaps it'd have to be optimum in only some types of workloads at the expense of others?] and start building chips with it, how much advantage would they really have over, say, x64?
Maybe a good question to go alongside this: if two teams of equal capability with equal access to fabs, patents, etc were to both start completely fresh, one team making the best x64 chip they could and one team making the best ARM chip they could, how much difference would there be in speed and power-consumption between the end products?
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.
RISC vs CISC doesn't matter any more. I wrote an article (once featured on HN, when ARM first began making waves) that is basically "a crashcourse on CPU architecture for dummies" on my blog: http://neosmart.net/blog/2010/the-arm-the-ppc-the-x86-and-th...
The tl;dr of it is that today, the RISC vs CISC or ARM vs x86 debate doesn't really matter - that's just a question of what "APIs" (if you will) are exposed from the CPU. Internally, they're all approaching working the same way.
The thing is, CISC vs. RISC seems to be an ideological debate more than anything else. The only reason I suggested designing a RISC CPU is because a) ARM has made RISC for servers sexy again, and b) Intel already tried a CISC chip with Itanium, and another would scare vendors pretty badly.
The big difficulty I see is designing an instruction set, architecture and compiler which can show serious performance gains for workloads that matter. Making it easy for developers to come over from x64 while juicing the performance per clock would be a big win.
P.S. I'm not a CPU expert by any means. My understanding is that x86_64 has a big legacy overhead from implementing backwards compatibility with x86, and a goal of Itanium was to reduce the amount of the die dedicated to backwards compatibility. If anyone wants to correct me, feel free.
I don't think Itanium was CISC, they call it "EPIC" (explicitly parallel instruction computing: http://en.wikipedia.org/wiki/Explicitly_parallel_instruction...). The basic idea of this was to move logic about what could be parallelized from the CPU to the compiler, but this turned out not to work so well. In Donald Knuth's words, "The Itanium approach...was supposed to be so terrific—until it turned out that the wished-for compilers were basically impossible to write."
how much difference would there be in speed and power-consumption between the end products?
Probably not much right away, but over time, you'd see a real difference. One key issue is that x86 decode logic takes a substantial amount of engineering time to design in each generation. My spouse is a design engineer at a CPU maker and one thing I've learned is that there's a lot less automation than you'd think. Each new generation requires a bunch of dedicated engineering resources to make the extra-painful instruction decode work on a the new process with new performance constraints, etc. Decode is not something you can design once and then just reuse indefinitely; you take the NRE hit on every design cycle.
Actually I would think that instruction decoding is one of the few things you can reuse... that pipeline stage is typically not the performance limiter, and the instruction set only makes small changes each generation. When I was a chip designer that block usually got assigned to the least experienced team :)
Note that actual CPU designers spend a significant amount of time doing routing and other tasks that you might think would be completely automated. So while you might have a block of verilog code that specifies the RTL for your decode unit, and you can certainly reuse that, each new chip will require you to redo routing at different levels which will require lots of engineering time.
Spending time on that might be fine if x86 ISA was getting you a significant performance advantage, but since it is not, the extra NRE you blow on physical optimization of decode logic is just wasted effort that could be better spent elsewhere.
The biggest advantages ARM has over Intel are all probably memory related. x86 will tend to have have more memory operations for doing a given thing, and with x86's stricter memory model it will be harder to design a system with lots of outstanding memory operations. ARM's simpler decoding is also an advantage from a power consumption standpoint, if nothing else. These aren't huge, though, and I'd give ARM a maybe 15% advantage or so? But remember that all things aren't equal, and Intel has a big lead in fabrication techniques over everyone else, and lots of huge teams of chip architects.
I think a bigger issue though is high clock speeds forced on the industry for marketing reasons. Current pipelines are way way to deep, but they can never come down because that would decrease clock rates and lots of people have been trained into believing that clock speeds indicate performance. If Intel & AMD could convince the world to ignore clock rates, we'd get chips that had slightly higher throughput with much lower power consumption and slightly faster design cycles.
This was the case around the turn of the millenium, back when you had Pentium 4s that had over 30 stages in their pipelines. But those weren't really as good as AMD's less pipelined Athalon chips, and eventually Intel shifted from it's Pentium 4 lineage to the much more reasonable architecture derived from the Pentium 3, through the Pentium M, and then the Core architecture. These had around 15 pipeline stages, and despite their slower clocks the Core processors could out-preform the Pentium 4s. So the changes that you're saying could never happen did happen, and nearly a decade ago.
I think you're being downvoted because your premise is flawed; we're at an OK place with respect to pipe depth versus clock speed. As early as the Athlon line people began to realize that clock doesn't directly map to speed, and recently Intel's move to the i3, i5, i7 models really pushed consumers away from a clock-based definition of speed.
Anecdotally, I have an elderly neighbour who bought an i7 laptop, not because it was the higher number, but because her friend had told her that it was higher quality. Inadvertently, this tech-illiterate person had inferred that an i3 was somehow going to fail sooner or produce inferior results, because of the marketing Intel had performed. This kind of branding is far more powerful than Ghz nowadays, and it's a story that Intel more or less gets to make up. The only people technical enough to bother looking for a clock speed now probably understand all of the marketing jargon, more or less.
To return to the original point; Intel's marketing isn't dictated by what people want, Intel's marketing dictates what people want. They aren't trying to make higher clocked chips to convince people they're better. They have a dominant market position.
Every CPU designer I've spoken with thinks that pipelines are way too deep and clocks are way too fast, especially given memory bandwidth and latencies. So I don't see how we could be at an "OK place". Perhaps I've only spoken with ignorant CPU designers at Intel and AMD?
Obviously, technically sophisticated people understand that clock speed is not the sole determinant of performance, but a lot of people making purchasing or marketing decisions aren't that sophisticated.
I don't mean to disparage your sources, but if everyone in engineering at the two biggest desktop CPU designers thinks pipelines are too deep in current designs, we should be seeing a big change. I understand bureaucracy well enough, but I think if everyone at AMD knew how to magically improve their current design, they would have done it by now. At this point, marketing wouldn't hold them back from assuming a dominant position technically, especially not in the server space.
I've probably gotten in past my depth at this point, but it seems like the bigger complaint is memory latency and bandwidth. My understanding was that this was part of the move to on-die memory controllers and increasing levels of L2 and L3 cache.
if everyone in engineering at the two biggest desktop CPU designers thinks pipelines are too deep in current designs, we should be seeing a big change
No, not necessarily. If one company puts out a lower clocked product with equivalent performance but lower power, the other company will be able to crush them in marketing and sales. No system integrator wants to try and sell a 1GHz product to the public. No one wants to convince retailer marketers that a system clocked at half the speed of their competitors is actually just as fast.
Take a look at laptop ads and ask yourself why they mention clock speed at all. That number isn't really comparable across different product lines or generations within the same product line. But people use it as a proxy for performance, so the ads keep including it.
The graveyards are full of companies that put out better technology products than their competitors.
> No system integrator wants to try and sell a 1GHz product to the public.
AMD has pushed lots of low power parts for mobile, for integrated systems, etc. If AMD had the resources to produce a low power, slower clocked chip, why was Turion such a dog? AMD hasn't actually done very well in the mobile space historically, when they could have produced low-power Ultrabook-like designs. Hell, they could've made something like the new Chromebook and had no fans. Either there's a severe lack of vision, or this is actually much more difficult to implement with the x86 instruction set than you're lettingon.
> But people use it as a proxy for performance, so the ads keep including it.
People generally don't care about clock speeds at this point, and I don't know if they ever really did. I worked retail about 6 years ago, and customers had no clue about clock speeds. Frankly, they were mostly worried about hard drives and screen size.
> No one wants to convince retailer marketers that a system clocked at half the speed of their competitors is actually just as fast.
Retail is the tip of the iceberg. HPC is a big market, commodity servers are a huge market. Halving your power consumption in those areas would be massive, and would give AMD a real cash injection. But there's no silver bullet there. You may be slightly right, but you're massively overstating the benefits compared to the costs of implementing it.
> If AMD had the resources to produce a low power, slower clocked chip, why was Turion such a dog?
Because not even Intel can maintain two different architectures at once and stay competitive. AMD would surely go bankrupt before they could complete a major architecture re-design.
"No one wants to convince retailer marketers that a system clocked at half the speed of their competitors is actually just as fast"
They don't have to. Reviewers would shout from the rooftops that your new laptop/tablet does not feel hot when holding it and lasts significantly longer on a battery charge. Then, you market your devices by quoting the reviewers.
Even on a desktop, a cooler CPU has advantages. Put it in a smaller, quieter box, and advertise that.
I didn't downvote you, but there is research from Intel, IBM, and others showing that very deep pipelines (they disagree on the exact numbers) are indeed optimal if power isn't a concern (which it wasn't until ca. 2003). http://web.archive.org/web/20021211202017/http://systems.cs....
>they can never come down because that would decrease clock rates and lots of people have been trained into believing that clock speeds indicate performance
is a bold statement that is not likely to be true. Casual metrics of performance change, and I doubt there are many people confused as to whether they choose a 4GHz Pentium 4 over a lower clocked Core 2, much less something like a Xeon E5.
Perhaps people are not confused simply because those older processors are no longer sold. AMD certainly felt the need to fudge their frequency back in the K7 days (although megahurtz marketing may be specific to the desktop market).
Maybe a good question to go alongside this: if two teams of equal capability with equal access to fabs, patents, etc were to both start completely fresh, one team making the best x64 chip they could and one team making the best ARM chip they could, how much difference would there be in speed and power-consumption between the end products?