Intel left outside | Hacker News Reader

Intel left outside

economist.com

45 pointscolinprince21 comments

This is actually an article about x86 and ARM processors, rather than Intel against ARM. If you're talking about companies, AMD is really the one playing catch-up. But I don't see x86 going away until Windows is gone, or until Windows becomes widely used on ARM processors (the next version of Windows will support ARM according to Microsoft).

Intel could start serious production of ARM processors if it wanted to (and Intel's XScale processors were/are ARM-based). It would be significant change, but Intel has the money and engineers to make it work. I'm sure Intel could incorporate its Tri-Gate transistors into an ARM design as well.

> Intel's XScale processors were/are ARM-based

Intel actually sold off their license and XScale IP to Marvell a few years ago. I'm not positive, but I think they'd have to buy a new Architecture License to get back into ARM.

According to this site, Intel retained the license as part of the sale.

http://www.reghardware.com/2006/06/27/intel_sells_xscale/

14nm, ARM, Tri-Gate would be interesting, and given Intel's competence in R&D they could easily leap-frog other ARM producers. The unfortunate thing is I don't see a new instruction set gaining new ground anytime soon outside ARM and x86 for consumer applications. I wonder what legal agreements Sun had in place for it's RISC based SPARC chips, and if it would have made sense for Intel to buy them to leverage their hardware division to make RISC chips for server and handset applications. (Also would've been interesting on the ZFS/SSD front.) (Of course Intel has never really be heavily dedicated to software, but buying Sun would've given them that power all at once.)

Yeah Tri-Gate on ARM and you have the best of both Worlds, they would have a great USP inside the ARM Market.

my heart stopped when I read the first 4 words, then the 5th word pulled me back to reality.

> Intel's XScale processors were/are ARM-based

That is right but the XScale processors were designed as network processors for layer2/3 switches. By today's standard XScale processors are very slow and outdated.

> or until Windows becomes widely used on ARM processors (the next version of Windows will support ARM according to Microsoft)

Color me skeptical. We were through this before, with PowerPC.

I would very much like to see ARM gain traction in the desktop market: the whole way the x86 works is quite inelegant (longer instructions decoded into a RISC-like 'microops').

Considering how small ARM is compared with Intel, they've done a fairly fantastic job.

Is one actually better than the other? I know very little about these things but it seems like ARM relies on a higher volume of simpler instructions at a faster clock rate vs x86 which uses fewer, larger, more complex instructions which take longer to execute. Don't you eventually get to a point where the only way to increase performance is to use more complex instructions?

I mean at some point Intel will be able to deliver x86 CPUs in ultra low power form factors. At the same time ARM CPUs will become increasingly powerful. Is it clear to those that understand these things that one architecture is going to be inherently better?

RISC vs. CISC boils down to CPU Designers vs. Compiler in terms of where the low level optimization happens.

One of the big arguments for RISC, as I am familiar with it, is that it allows the entire processor team to focus on making just a few instructions as fast as physically possible, rather than dealing with the truckload of instructions we have in a modern CISC processor. Or, perhaps in the ARM case, as efficient as physically possible.

This was only true some time ago, unfortunately. The technique used by both companies to achieve speed increases is called 'pipelining', which essentially means you can have a different instruction in each bit of the processor (so, the ALU, the instruction fetch, the memory unit are all doing different instructions). The problem with this is that pipelining only works on instructions that have a very regular format, and run in a similar number of clock cycles, and the only way to keep instructions heterogeneous is to not have very many of them!

Intel, however, supports a massive instruction set, with some hugely complex instruction. They do this by actually "compiling" their complex instructions on the chip to a format which looks a lot like ARM instructions, which they call micro-ops.

I would say that the ARM architecture is inherently better, because it does not waste all this silicon to do instruction translating, and you know exactly what is being executed on the processor, simplifying the job of the hardware designer, and allowing them to focus solely on performance (/power consumption/whatever), and allowing compilers to do instruction level fine tuning.

Practically x86 processors since a few generations back have been internally running on a smaller RISC-like microcode core. The x86 layer is there mostly for the dreaded compatibility (and to prevent compilers from optimizing directly into any RISC code ;))

Is Intel's microcode core better than other competing RISC cores? Is it really that Intel's process is that much better? It seems like it's unanimously the best, but it can't explain everything can it?

I'm having a hard time wrapping my mind around this. It almost feels like Intel has simply added a layer of abstraction. It isn't clear to me that this is a bad thing. Intel has the flexibility of changing that microcode core as they please without worrying about the need for everything to be recompiled if they think of a better implementation with a different instruction set. For very specialized low power devices ARM makes sense. For more complex systems I'm not so sure. You see a strong movement in software towards increasing levels of abstraction. Why would hardware be different?

Is that a fair assessment of the situation? Or am I missing something?

(longer instructions decoded into a RISC-like 'microops').

The thing is, in practice, this hasn't been true since 1985. Nobody actually uses the legacy instructions that are "decoded into RISC-like microops" except people writing 4K demos. In reality, ARM instructions are actually longer on average, and more complex on average. Nor is this a bad thing: it means that ARM IPC is more valuable than x86 IPC.

ARM's advantage is that their instructions are longer, more complex, and easier to decode: not that they're "simpler and more RISC-like". RISC, at least in its original sense, is as dead as a doornail.

What's Intel's advantage(aside from process)? And why hasn't there been a competitive ARM chip in the high performance market?

Intel's advantage:

1. Decades of experience, smart people, and good chip design.

2. Making a chip with Core i7-like power is hard, even an ARM. It'd probably be a totally new experience for most ARM chip designers, very expensive, and it might not even sell.

The way I think Intel can get competitive is by building a system on a chip. Think a cpu, gpu, and perhaps other cores on a single chip, consuming relatively less power. Nvidia is doing that with an arm cpu.

Intel does have a pretty good performing SOC with the CE4100 based on the atom cores, they just can't get the power under control for the handheld market. I think they're still losing against arm with the new process, though it surely closes the gap. http://www.anandtech.com/show/4029/the-boxee-box-review/3

Is it better performing than the older Atoms? My 1.6Ghz atom, with hyperthreading, is slower than my 1ghz Tegra2 arm, per core, and the arm is dual core. Depending on the benchmark the arm is up to about 50% faster on single core benchmarks. And the arm is lower power...

There are a number of different generations of atom cores and ARM cores of course. I don't have raw benchmarks, but my impression was that CE4100 at 1.2 was beating the previous gen of ARM at 1. D-link/Boxee was based on the tegra 2 platform and famously had to add 6 months to their development cycle switching to the CE4100 because the tegra 2 wasn't performing well enough for them - though I don't know the specifics there of what task wasn't performing well enough.

Reply on news.ycombinator.com