Slashdot Mirror
Linus: Praying for Hammer to Win
An anonymous reader writes "The boys at Intel can't be happy with the latest opposition to the IA-64 instruction set. According to this Inquirer scoop, Linus himself has weighed in, and it appears he's putting his eggs in the x86-64 basket. In the original usenet post, he goes so far as to say that 'We're ... praying that AMD's x86-64 succeeds in the market, forcing Intel to make Yamhill their standard platform.'"
it's an internet tabloid creating a mountain ("Linus himself is praying that AMD wins!") from a molehill (half a sentence in an unrelated USENET post).
crap story.
Cretin - a powerful and flexible CD reencoder
Not surprising... he works for Transmeta, and they licensed x86-64... So what else should he say?
Beside that, who cares for the CPU's instruction set? Nobody, except compiler designers and very few assembler programmers. And they already know x86 and the tools exist. So the only argument for Itanium can be performance/price. And ATM it looks like Opterons will be cheaper.
I see only Linus daydreaming about keeping x86 (the well-known and optimized standard bytecode at Transmeta, remember?), so that the 64 bit extensions get more widespread, thus "rest of us" can afford to get 64 bit architectures on this very same architecture we grown up with... On the other hand, it's a good goal :)
"Ten years from now, they could do it in a few seconds." -- The Racketeer of the Hellfire Club, 1993, Phrack 42
It's amazing that somebody could make such a relatively long article from what amounts to one sentence in Linus's email!
Reading the Linus's email it seems that he wasn't endorsing one way or the other. He was just hoping x86-64 became dominant since it would stave off some issues related to how pages were handled.
Apparently, if things go the Itanium route then some page related things get more complicated but that's it.
Nothing to see here. Move along.
--
"I'm too old to use Emacs." -- Rod MacDonald
First, this was not a USENET post. It's a message from the linux kernel mailing list that google is pumping into their groups.google.com database. Second, Linus is not saying he thinks Hammer is a better architecture. What he said in this message was that the current Linux page table implementation is not ideal for use with IA64 and therefore, for the sake of Linux servers everywhere, it would be better for Hammer to provail in the near to medium term future. I don't know his real position, but I would be very surprised if Linus though Hammer was a "better" architecture. X86 is an awkward instruction set that has been perpetuated by software designed to run on it. The core of these chips like Pentiums are really RISC chips with hardware wrappers to implement the X86 instructions. So it's just a waste if die space. IA64 is purer and a much better long term choice. Don't over analize a simple e-mail message from someone on lkml. These are not markedroid approved public service announcements.
it's funny how people ripped and ripped and ripped on Intel all through the 90s about keeping all their backward compatibility from 286 on through the P4. how people said they should cut the dead weight, etc.
well, now AMD is creating the kruftiest, heaviest, nastiest instruction set of backwards-compatible crud in the history of processor-dom. Intel comes out with a new, no-legacy 64-bit instruction set, and all of a sudden it is, "god, we hope AMD wins so all our old crap still works".
well anyway, here's at least one programmer who is looking forward to getting his mitts on a 64-bit chip which doesn't have layer upon layer of backwards compatibility, wrapped in an overpowered muscle-car of silicon. you'd think we would have learned our lesson with the Alpha, a much, much better chip than the x86 but no one adopted it. people scream and bitch and moan about supporting all the ancient krufty x86 bloat, but when it comes time, they stick with what is comfortable.
more than likely, Intel's 64-bit offering will follow the road of Alpha into technical superiority and market disaster. and we'll be stuck still supporting 286 instructions. way to go.
MORTAR COMBAT!
What endorsement is that? AMD has been utterly piggish with respect to open source. GCC still produces awful optimizations when targeting any AMD chip, and in fact has gotten worse between 2.9x and 3.x. Intel started out contributing pgcc when Linux was still in its infancy, and code output for Pentiums has gotten successively better. When bad optimization can halve your effective computation rate, that I think speaks volumes.
That said, I have to agree with Linus on this one. Itanium would be a disaster for free compilers, as heavily encumbered as it is by compiler technology patents. And when it comes down to it, I'm not all that certain I want my general purpose language compiler generating what is effectively microcode anyway.
IMHO of course.
--
BitTorrent in C -- LibBT
http://www.sf.net/projects/libbt
Now he's supporting a CPU scheme that, well, doesn't break anything and may even sacrifice performance for that compatibility.
Except that it's quite likely that an Opteron will be faster than an Itanium for most real-world tasks. At the very least it looks like it will be comparable in speed, and cheaper. If the Itanium really was screamingly fast, that would be different.
We're a lot more likely to make PAGE_SIZE bigger, and generally praying that AMD's x86-64 succeeds in the market, forcing Intel to make Yamhill their standard platform. At which point we _could_ make things truly 64 bits
He wants hammer to succeed only so Intel will have to go 64 bit and they can go all out 64 bit, this is not Linus picking the AMD camp.
usernet post here
Saying Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders.
Apple ... hardware is better
>>>>>>>>>>
Umm, Apple's hardware sucks. Most macs have a slow processor talking over a slow bus to slow RAM. Most of them also have slow graphics, using GeForce-4 MXs where comparable (pecking order not price) PCs would use GeForce 4 4200s. Apples integration and build quality might be great, but not its hardware.
A deep unwavering belief is a sure sign you're missing something...
I'm not some prodigal kernel developer, but I do think the AMD architecture looks like a piece of shit. You're really telling me that we want to have an architecture that operates in a 16, 32 AND 64 bit mode, that has tons of crufts and kinks from the 80's still in it and a paltry handful of registers that are all overlaid... A(H|L) -> AX -> EAX -> 64-bit AX? Why? what the hell would that be good for? just bloats the die by another order of magnitude I'm sure.
Intel's got a sound solution and they at least have the balls to finally give the cruddy old x86 architecture the heave-ho; ok they can't do it now but IA64's architecture does not require 8086 or IA32 to bootstrap it so both can be thrown out sooner or later. Regardless of what the actual metal might be, the actual platform is beautifully elegant next to x86 and will ultimately be a real asset in the future as 64 bit architectures become the norm, much more so than some short term gain that might be had by virtue of a superior implementation from AMD.
Maybe I'm missing something here (OK I'm not on the design teams for both processors so I certainly AM missing something here) but from this standpoint, it looks like this would be the one time when I want to cheer for Intel as opposed to AMD. Pity they had to botch the development cycle like they did. *sigh*
If anyone actually read the lkml context, the remark was entirely in relation to the flood of recent patches making everything on 32 bit platforms support 64 bit sizes. Once upon a time it was just files over 2GB, then it was block devices over 2TB, now it is all sorts of shit because vendors are selling 32 bit machines that support 64GB of RAM.
Now Intel of course just reckons that people should buy Itaniums if they want this (and apparently they did actually ship 250 of the Itanium 1...) but someone is buying these. Even though you have to use 32 processes in order to use the memory.
Clearly these machines should be 64 bit, thats what Linus was commenting on. Then we could leave at least some of the limits for 32 bit machines without complaints.
The other problem is non-atomic 64 bit ops on 32 bit machines, incrementing counters and such. This has caused quite a few problems recently.
Even if desktop PC's migrate to 64 bit in the next couple of years, you still have all the other embedded devices out there running on 32bit CPUs. There is no need for these devices to use a 64bit CPU - for these applications 8megs of memory is plenty, 4gigs is just crazy!! This is why 8bit CPUs (and even some 4bit) are still in production today and in much greater quantity then those 32bit CPUs found in desktop computers.
If linux is to be used in such devices, it'll have to support 32bit architectures.
PS, PPC chips are 32bits. IBM Power chips are 64bits but they are actually different from PPC chips. Code written for one doesn't run on the other - something the Mac rumor mongers simply don't understand with their "Apple is going to use a IBM Power CPU" bs.
I wouldn't take this particular quote to be his definitive statement of preference for x86-64 over IA-64.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
No, Motorola 8XXX chips are eBook compliant chips. The eBook specs support both 64bit and 32bit cores.
The is absolutely no reason to go with a 64bit CPU unless you have to do a lot of work with 64bit integers (unlikely) or you need greater then 4gigs of memory space (more likely). The eBook spec supports future CPUs for Macintosh computers that require lots of RAM (64bit) and future CPUs for the embedded market that require very little memory (32bit). Those CPUs that are currently available are 32bit CPUs.
And yes, there was the failed PPC 620 CPU but that never really made it out into any products so there haven't been any real 64bit PPC CPUs to date (although I'm sure they're coming.)
As far as Power chips running PPC code - I don't think so, although I could be wrong. From what I understand, the PPC601 was a transition chip to the PPC architecture. It was designed by IBM and able to run much of the Power instruction set - thus making Power applications easy to port. Then came the 603 and 604 CPUs designed by Motorola. They were much different from the original 601. This is all when IBM had great plans of the PPC architecture being able to do everything and taking over 8x86 - it didn't happen. From there, the architectures diverged with PPC going towards efficiency and Power going for, well, power.
To make a long story short, PPC can _almost_ run the Power instruction set of 1990 - or at least code is easy to port. However, the Power architecture was never designed to run the PPC instruction set. A Power CPU of today won't run a program compiled for PPC.
First, Itanium is the marketing name for the processor. The architecture is IPF, or IA64.
Second, it's anything but pure. It also has an IA32 (i386) compatibility mode, that kills any die size benefits of a new architecture, at least for the next few generations until IA32 really dies.
Third, even when it gets rid of IA32 compatibility, IPF may still be a pig: many people who know more about this issue than me consider it to be too complex and full of bad trade-offs, essentially stretching a good idea (VLIW) too far (EPIC).
There is the argument that RISC architectures are essentially better. Too bad IBM can't find its way to the general market, Motorola has only proprietary Apples as its venue, Sun falters in execution and forfeited popularisation, and Digital was killed by elitism.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
What Linus says is not as important as the fact that his words are spread and discussed all over the internet. That's proof that we don't have a one- or two-player game any longer (Microsoft plus Intel).
It's an important power-shift, which took place. Now four players decide the further development: two OS- and two CPU- manufacturers. And to avoid deadly risks they need to be compatible to each other.
Woopy! The market is getting back it's power!
Everything I've seen is that while the Hammer will be targeted (and priced) for the desktop, IA-64 is so big and expensive that it will be marketed only as competition to IBM and Sun processors for years to come. If this is true, IA-64 is hardly more interesting than some new expensive, incompatible processor from Hitachi or anybody else.
He has nothing against the Itanium (in fact, Linux runs on the Itanium perfectly well). What he's hoping for is that Hammer takes off so the non-Hammer x86 market dries up and Intel goes to an Itanium/Hammer product line instead of Itanium/Pentium. What he's worried about is 32-bit machines with large memory and disk.