Linus Has Harsh Words For Itanium

Anonymous Coward writes "As a follow up to the earlier story "Intel: No Rush to 64-bit Desktop"... In words that Intel are likely to be far from happy with, the Finnish luminary has stuck the boot into Itanium. His responses to some questions on processor architecture are sure to be music to AMD's ears. Linus, in an Inquirer interview concludes: "Code size matters. Price matters. Real world matters. And ia-64... falls flat on its face on ALL of these."" Of course, Linus works for a chip maker ;)

Comments

This is probably a troll, but...

[tunah]

Slang:

Mickey-mouse == poor quality, inconsistent

Outfit == organization, company.

Re:How to improve x86

[_typo]

but I think that makeing them ALL GP (even the older ones) would be good, and maybe bring up the number of registers to a good round 32 or something. Am I missing something glaring wrong?

Well, the only reason why the other registers aren't GP on x86 is that there are instructions that use them implicitly. If you don't care about these instructions you can use them as regular registers.

As an example the EDI register is used by the SCAS* instructions as a pointer to memory. If you don't care about the instructions that use this register like that you're free to do regular operations on the EDI register, it has no limitations on what you can do with it.

You're right to say that there are few registers though. Before I learned x86 I learned MIPS and there you got all the glory of 28+ GP registers. In the simple examples we did I never needed to push and pop from the stack.

Re:Code size?

[hpa]

Code size matters because *cache* isn't cheap. Worse, you can't make L1 cache arbitrarily fast without slowing down your chip big time.

Itanium2 is the fastest floating-point processor

[mrm677]

Check the latest SPEC CPU benchmarks. The Itanium2 has the fastest floating-point score and is no slouch in the integer tests either. It will improve. Linus will eat his words in a few years.

Inquirer does not do the post justice

[NullProg]

The read from theinquirer.net is all wrong. The slashdot story line is also wrong. It does not state at all what it implies. Here is the link to what Linus actually wrote:

http://www.ussg.iu.edu/hypermail/linux/kernel/03 02 .2/1909.html

Now, I agree with Linus on the PPC MMU issue. Can anyone tell me what he means by "baroque instruction encoding"? I have been doing x86 and 68k assembler for a long time, I have never heard of this.

Enjoy,

Re:Inquirer does not do the post justice

[cbiffle]

Probably (IANLT) he's referring to the various prefix encodings and variations for instructions. From my x86 manual, "Machine language instructions...vary in length from 1 to as many as 13 bytes. ...There are over 20,000 variations."

Now, granted, that rather large number probably includes different target registers, but compared to (to use your example) the 68k, the x86's encoding format is just -weird-:
16-Bit:
-An opcode. Either 1 or 2 bytes.
-Some flags and/or target register. 1 byte, optional
-Displacement. 0-2 bytes.
-Immediate. 0-2 bytes.

32-Bit:
-Optional address size prefix byte.
-Optional operand size prefix byte.
-Like above, but with 0-4-byte displacement/immediate and optional scaled index byte.

Now consider the fact that many opcodes implicitly reference registers. Decoding this instruction set by hand would be a royal bitch, and it's exactly the sort of configuration that RISC targeted for demise.
However, Linus makes a good point in the e-mail, which is (paraphrased) that the x86 encoding is basically a very good compression algorithm for its code. While the RISC machines that use 32 or 64-bits for every instruction may be more regular, their code does tend to be larger.

The ironic thing, in my mind, is that the IA-64's encoding is in many ways -more- baroque than the x86s! Instructions in bundles, bundles in groups (or is it the other way around? I never remember), flags at the end to specify how to interpret the instructions before -- it's an interesting take on VLIW, in that it doesn't specify the number of execution units, but YUCK. :-)

Re:How to improve x86

[be-fan]

What you're missing is that x86 chips have a ginormous amount of internal rename registers (128 in a P4). The bump to 16 *visible* registers in the Athlon-64 is to allow the compiler optimizer to give more information to the CPU about variable usage. I'm guessing that AMD found that more than 16 visible GPRs really didn't help the compiler's allocation routines any.

Re:Linus holding on to his security blanket?

[squiggleslash]

I just don't get RISC chips. Why they want to remove things that make programming easier is beyond me.

It's not stuff that "makes programming easier" that gets removed in RISC, its the more complex try-to-do-everything instructions which are a pain to implement in silicon and which ultimately can just as easily be done via a sequence of simpler instructions that may well, for a programmer who's actually programming at that level, be easier to understand.

Early on the chief advantage of the approach was that you could use the freed silicon for things like extra registers, and that's exactly the approach taken by Acorn (now ARM) and the PowerPC range. Would you prefer to have eight registers and a single byte copy-block instruction, or 64 registers and have to replace that copy-block instruction with (*gasp*) three simpler instructions?

(Actually, I guess that depends on how good your cache is. There's no such thing as a free lunch)

Re:But it's still a year away, isn't it?

[KewlPC]

64-bit code needs 8 bytes to hold every pointer. This will serve to eat up more cache and memory bandwidth, which are already major bottlenecks for any CPU.

The only thing this eats up is cache; because the system has a correspondingly wider data bus, there isn't a hit in memory bandwidth (unless the designers are trying to be cheap bastards and give a 64-bit CPU the same data bus width you'd use for a 32-bit CPU). And most 64-bit CPUs have a lot of cache.

And as for what kind of applications you potentially need several gigabytes worth of memory for, there's scientific processing and the like.

Re:But it's still a year away, isn't it?

[Waffle Iron]

The only thing this eats up is cache; because the system has a correspondingly wider data bus, there isn't a hit in memory bandwidth (unless the designers are trying to be cheap bastards and give a 64-bit CPU the same data bus width you'd use for a 32-bit CPU)

Ever since the 8086/8088 duo, the bus width of a CPU has been decoupled from its word size. For a long time, the external bus width of (non Rambus) 32-bit CPUs has been wider than 32 bits. This works because the memory unit fetches entire cache lines. The CPU designers could be less cheap bastards today and bring out 32-bit CPUs with 256-bit wide busses if they wanted to.

And most 64-bit CPUs have a lot of cache.

You could put a lot of cache in a 32-bit CPU. You could put a small cache in a 64-bit CPU. In fact, the biggest difference between high-end and low-end CPUs is just the size of their caches.

To be fair, the current Itanium has an enormous cache that uses the vast majority of the die size and dicates its price and power consumption. It's logic core really isn't that big. If you embedded an X86 core in all of that cache, you'd get a very fast chip. If you teamed up an Itanium core in a Celeron cache, you'd get Celeron-level performance. 64 bits has little to do with it; you're mostly paying for cache and bandwidth when you buy high end CPUs.

Re:But it's still a year away, isn't it?

[EvilTwinSkippy]

News flash...

The pentium architecture has been loading 64 bits of memory at a time since the PII. They have to because that is the only way the RAM has a chance in hell of keeping up with the processor. Basically they load 2 instructions at once, and have them execute at double the speed of the RAM. (That's also part of why you get such a kick in the pants when you optimize with the -mcpu=i686 flag in gcc.)

Re:Obsessive

[JWSmythe]

It looks like all the big Linux distributions have gotten together to support the IA-64 Linux development.. This was the first hit on search "Linux IA-64" on google.


http://www.linuxia64.org/

Working distributions date back from 03/2000

Straight from their page:

IA-64 Linux Distributions
# Caldera Systems (initial release 8/4/00) Download at ftp.caldera.com/pub/OpenLinux64
# Debian (initial release 8/10/01) Download at www.debian.org/ports/ia64
# Red Hat (initial release 5/17/00) Download at ftp.redhat.com/pub/redhat/ia64
# SuSE (initial release 6/13/00) Download at ftp.suse.com/pub/suse/ia64
# TurboLinux (initial release 3/13/00) Download at www.turbolinux.com/ia64.html

Their short list of representative companies include: Caldera Systems, CERN, Debian, Hewlett Packard, IBM, Intel, Linuxcare, NEC, Red Hat, SGI, SuSE, TurboLinux, and VA Linux Systems.

If you search their site, you'll see a few emails from Linus in their mailing list archives, so he's obviously involved at least to a degree (I couldn't imagine him not being involved). I dare say he's educated in the matter, and would know all the in's and out's of say putting together an OS. :)

I'm sure support will be included eventually.. Well, maybe not.. I know Linux will run on SGI, DEC Alpha, ARM (I'm running Linux on a Compaq iPaq with an ARM CPU), so maybe they'll leave it as a patch and let folks do seperate distributions.

I guess it's all in how widely used a processor is.. Not the average Joe has an SGI, Alpha, or Itanium at their house. (I'll keep quiet about the 150Mhz SGI Indy that we use as a doorstop).