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.'"

Comments

One endorsement down, one to go

[sgtsanity]

Now if AMD can get the endorsement of "The Carmack", they will really be happy.

Re:One endorsement down, one to go

[CaffeineAddict2001]

Carmack and Linus look very similar. I think they are actually the same person living a double life. He may fool you with that phoney norwegian accent, but I know the truth.

Re:One endorsement down, one to go

[pointwood]

Norwegian? Linus was born in Finland and speaks Swedish, AFAIK.

Re:One endorsement down, one to go

[GutBomb]

finnish/swedish accent actually, but whatever.

Re:One endorsement down, one to go

[MrResistor]

Whatever, it all sounds like "Mmmm, Bork! Bork! Bork!" to me... ;-D

Re:One endorsement down, one to go

[asv108]

I would have to say linus is probably the second best known computer guy by the general public with Bill G. being way ahead in 1st. Many businessmen know about linux these days.

Re:One endorsement down, one to go

[GutBomb]

is that not exactly what I said? There are a group of people known as Finlandsvensk. They are native to finland, however they speak swedish as thier main language instead of finnish, however thier accent can not be classified as sounding like swedish, hence the "Finnish/swedish" accent. Perhaps it would have been more descriptive to say a "Finlandsvensk" accent, but did you even know what a finlandsvensk was?

Re:One endorsement down, one to go

[fredrik70]

repeat after me:
shooting someone in the head - good, makes you go to heaven
tinkering with kernels - bad, gives you hairy palms ;-)

Re:One endorsement down, one to go

[Scudsucker]

So which one is the soap salesman?

Momentum

[crumbz]

To me this is an impressive endorsement. Given the overall support that AMD has given Linux over the years, it is great to see a little bit of that given back.

Cool. x86 through 2086!

Re:Momentum

[Anonymous Canard]

To me this is an impressive endorsement. Given the overall support that AMD has given Linux over the years, it is great to see a little bit of that given back.

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.

Re:Momentum

[Archfeld]

Well said...this is NOT a push for AMD but a push for interoperability of 64 bit devices.
The worst of possible outcomes would be Palladium on Itanium. New DRM hardware that requires all new code....a farking nightmare.

Re:Momentum

[0x0d0a]

probably because they don't have nearly the money or resources as Intel

You're going to have a very hard time convincing me that a major chip manufacturer can't afford to field a few compiler designers.

The problem with Hammer.

[Kenja]

is the same as the problem with OS/2. People dont want to re-write their applications for native support. I expect very few apps to be codeed for Hammer because its 32bit compatiblity is so good. An application devloper can write for old 32bit x86 and target Hammer and x86 at the same time. Just like devloeprs could once write applications for Windows 3.1 and have them run on Windows and OS/2. Not that the CPU wont do well, but I dont expect it to ever get the kind of support it wants.

Re:The problem with Hammer.

[GigsVT]

Yeah, that whole 16 bit to 32 bit transistion never happened either. People just didn't want to update their code.

Re:The problem with Hammer.

[iabervon]

But there are relatively few changes which need to be made to make a program run in 64-bit, and those changes don't cause problems with running it 32-bit. So people have the choice of their code running more slowly, but working everywhere, or running more quickly on Hammer, and running everywhere. Unlike with OS/2, you're not making two different versions for the different platforms, at the source level at least.

Of course, you're going to have to have Hammer-specific binaries to use 64-bit. But generating them is just a compiler issue, and software comes out for different processors all the time, when it doesn't require code changes.

Re:The problem with Hammer.

[dpilot]

But it's an even bigger problem with IA-64. At least Hammer will do a good job of running IA-32 code, which IA-64 doesn't. All Hammer needs is a 64-bit OS that can load both X86-64 and IA-32 code, and it's off and running. For that matter, all it really needs is to be available, because it'll simply look like a faster Athlon with no other changes.

There's a horse-race happening, because IA-64 is here and X86-64 isn't. But IA-64 is currently stuck squarely in the high-end server market where HP and Sun live. The real horserace is between price drops on IA-64 and announcement, availability, and uptake on X86-64. X86-64 is a natural for the workstation market, but it's got to get there and move into an unfamiliar setting dominated by boxmakers more familiar with Intel than AMD before IA-64 prices drop enough to make it viable, there.

Re:The problem with Hammer.

[GutBomb]

this was true when the pwerpc was the new kid on the mac block, but it ha been many years since this was the norm. It is very hard to find any software released since 1997 that has been compiled for 68k

Re:The problem with Hammer.

[roca]

If your code is already 64-bit clean, you can probably just recompile it and it will run on Hammer's 64-bit mode, probably faster than it was running in 32-bit mode.

So here's an upgrade path: first you buy your Hammer box and run your 32-bit Linux on it, just treating it as a faster Athlon. Then you upgrade your Linux to a 64-bit kernel, getting a speedup, but you can still run your 32-bit user processes. For the apps you have source for, you can recompile and run faster in 64-bit mode. Eventually people will start shipping Hammer binaries.

One interesting question is what the speed advantage (or not) will be for 64bit mode. Increased cache footprint of 64bit pointers vs 64bit math, extra registers and PC-relative addressing. Hard to call.

Re:The problem with Hammer.

[ivan256]

Actually, 150 Watts. And that doesn't count the waste in the per CPU power module, or the chipset and memory. You're talking ~5-600 watts for a single CPU system. Mmm.. Space heatery.

Re:The problem with Hammer.

[ivan256]

More has to happen then an IA-64 price drop. (Or more has to happen to cause an IA-64 price drop, depending on how you look at it.) IA-64 is a beast. It's a HUGE chip that drinks power. The system I used last used more power then any of my kitchen appliances except for the oven. That has to be fixed. The CPU with the fixin's has to cost less then just the power module probably costs right now. Then there's intel not letting anyone actually build systems with Itanium in it. They white box the systems, and let vendors rebrand them. That's not going to go over well forever. You have to wonder what intel is hiding that they won't let OEMs build boards and systems though... What dirty little secrets does Itanium hide?

The second problem is that it's proprietary. Yes, proprietary, just like Power 4 and PA-RISC. Intel bills it as open, but if you want open you should go Sparc, MIPS, Alpha (dead soon unfortunatly), or x86. Those are the architectures that have competitive vendors manufacturing the cores. People write all kinds of software for x86. Not just desktop applications. Itanium can't get that kind of support if only Intel makes it. You'll see X86-64 in embedded devices right out of the gate. There are manufacturers DROOLING over a low power 64 bit chip to stick in their storage boxes and database servers. You won't see Itanium in there.

You have to wonder wether there are two different companies over at intel. You've got the Pentium 4, which is basically driven by the marketing department, and is a huge marketing success, but the architecture is nothing to write home about, and generally lame in the innovation department. Then you have the Itanium, which is a big grown up microprocessor that was driven by the engineers, and is going to turn out to be a marketing failure. Oh well.

Re:The problem with Hammer.

[puetzk]

5-600W is a big range. How about some real numbers just for grins :-)

As viewed from my 650VA UPS (which will tell me the wall power consumption, including all losses in the PSU etc) my dual athlon (2xMP1600) +17" monitor sits at approx 400VA load. When the CPU's idle to C2 (most of the time) it drops about 80VA, and if the monitor sleeps it dropsanother 110VA or so.

So the fixed (ie PSU+HD+video+mobo+CPU idle) comsumption+etc is about 200VA, each CPU is about 40VA (different from C2 idle to max load), and the monitor is about 110VA.

Making the (basically reasonable, though not perfect) assumption that a switching power supply's power factor is close to 1 (shouldn't be far from that I wouldn't think) 1VA=1W. If the power factor is not one, then a VA is less than a watt (ie, all my numbers are too high in that case).

So it's a good heater, but not as bad as you feared. The lights in the room are using as much power as the idling computer, the computer edges them out during a good quakin' session :-)

Re:The problem with Hammer.

[dpilot]

...
I didn't say that dropping the IA-64 price was going to be easy, did I. I agree with all of the fundamentals you've mentioned. Plus, we already know some of Itanium's dirty little secrets, we've just become somewhat innured to the power, compiler difficulties, etc. ...
I have this ugly feeling that the marketplace no longer cares about open vs proprietary, just some people out on the Geek Fringe on places like /. and the like. ...
Of course there are, and it's probably way more than two. Pretty much any big company becomes that way after its Charismatic Leader leaves, if not before. But as for "driven by the engineers", I wouldn't necessarily give it that moniker. IMHO no engineer would have come up with a chip like that under his/her own judgement. Your own words, "IA-64 is a beast. It's a HUGE chip that drinks power." In some ways, it looks like an academia project that got Major Management Approval.

But it's driven by Intel, and this is the marketplace that complains about Microsoft's products, then turns around and sends their profits and stock prices up.

Re:The problem with Hammer.

[barawn]

I think you're missing the point: all you need is a compliant OS. Applications can become "compliant" on a case-by-case basis. A long mode OS can run non-long mode apps simply by clearing the L bit (cf. AMD's x86-64 whitepaper). This is basically identical to the way that the 32-bit stuff ran, except you don't have "standard 16-bit mode" available under a long mode OS. That's fine - the processor can still run the stuff, you just need to reboot. Perfect.

How long do you think it's going to be before Microsoft puts out a 64-bit Windows XP? Not long. Why? It doesn't take any time, and they get to charge people more money. Sounds like a Microsoft solution to me. Once you've got the thing running a 64 bit OS, then it's pick-and-choose 64-bit mode on an app-by-app basis.

Re:The problem with Hammer.

[barawn]

... and praying that the compiler doesn't introduce a thousand new bugs. Gee, that never happened before.

Sticking with x86 means that the old compilers will work as well as they did before, and are far less likely to contain bugs than being compiled by a totally new compiler.

Honestly, I don't see why it's that bad. Slowly but surely, they're eliminating the bad portions of the x86 ISA, and everything still runs. Starting from scratch means that you need to relearn all sorts of optimization techniques.

Re:The problem with Hammer.

[ivan256]

Sure, it was a dual processor system, and it used approx, 500 watts idle, and 600 watts at load. You could NOT use a 600va UPS, in fact, intel wouldn't let us put two systems on the same 10 amp circuit, and we had 1300va UPSs for each 2 processor system with monitor. The quads had two 20 amp power cords (the ones with the horizontal blades), and needed it's own 3000va UPS. You couldn't put two on the same UPS. That means the quad CPU systems used over 1500 watts of power at full load by your calculation (There was 16GB of memory in the systems, so it probably uses less then that in a lesser configuration). Can you say hair dryer? (BTW, the system required at least two of it's 4 800 watt power supplys to be in place to power up, so the estimation isn't that far off).

Unfortuantly, we finished our development and sent the systems back, so I can't take any measurements to give you exact numbers. You'll have to settle for my memory of the situation.

what a trashy article

[krog]

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.

Re:what a trashy article

[tcc]

Well I guess it depends on which point of view you are looking at it.

Carmack posts something here, you get instant linkage and stories out on most gaming sites pointing to that post.

Gates says something, everybody jumps on his speech and tries to analyse everything up to the point of what he had for breakfast, and his intentions for the next 20 years.

Jobs farts, mac users are all exited, etc etc..

The idea here is some people follow this stuff religiously, while for you it might be pointless for some others they really dig that stuff. Tabloid are way more crappy and unreliable than this story, and the worst? They sell like hotcakes.

To give you an example, I've found slashdot by a linkage of an amiga story. While I am not a Linux freak or "your rights online" active militant, I do have my own "tabloid" stories that I like to follow (like amiga stuff for example).

I've had the same reaction when I saw the article ("my, talk about far-fetched") but when you go and read the usenet post, it can make you think. If you don't care about linux and/or processors/os, well, you skip the story and move to the next, if you do like the hardware/OS scene, it makes a nice read, to get back to my idea, it tells you that if Linus wants the x86-64 to win, maybe they are designing the transmetta's next gen on that instruction set?, maybe this maybe that. Nevertheless, for people who like that kind of stories, it's a bit above the tabloid I'd say, because it's not a quote out of context and it's authentic.

my 0.02c.

Not surprising...

[tjansen]

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.

Re:Not surprising...

[Anonymous Coward]

Beside that, who cares for the CPU's instruction set? Nobody, except compiler designers and very few assembler programmers.

Umm, you are correct, but you have to keep in mind that Linus Torvalds is in that set of very few people. He may not be the one writing the compiler himself, but he is extremely close to the compiler-- he works on the operating system kernel, the one position that has to be most sensitive to obscure conditions of the microprocessor in order to optimise. Which is why he is weighing in on this subject.

Anyway, most of us have heard of Torvalds' fondness of hand-writable assembly language. (I.e., the huge portions of early Linux that were written in x86 assembly and C code which is written in such a way it may as well be assembly.. I had heard things indicating he had mostly grown out of that lately, though, now that non-x86 platforms are closer to his chunk of the kernel tree.. is that the case?) And i think we are all well aware of Linux's famed nonportability to non-GCC compilers due to dependence on obscure GCC bugs and nonstandard features. So, yeah. Linus may not be The Compiler Guy, but he will definitely have to be talking to the Compiler Guys on a regular basis, and he is in the group of people (the linux kernel development team) most likely to be the first ones to run into trouble with any new bugs which crop up in gcc. So he definitely has a good reason to have an opinion on this subject, especially given the subject increases compiler complexity so much that it is somewhat likely to increase the number of small compiler bugs that make no difference to you or i but huge amounts of difference to those persons who know what "spinlocks" are..

- super ugly ultraman

Re:Not surprising...

[Courageous]

Beside that, who cares for the CPU's instruction set?

A bit ironic, that remark. That's basically what the AMD guys decided when they went for X86-64: that the instruction set really didn't matter, and that it was implementation and good ole' Moore's Law that really counted. Meanwhile, when the instruction set doesn't matter, you've got Intel spending a cool $10 bill on theirs. So, I have to say, I find your remark quite amusing.

C//

Re:Not surprising...

[Courageous]

You missed the irony.

C//

Re:Not surprising...

[0x0d0a]

Beside that, who cares for the CPU's instruction set?

Me. I used the PPC and then the x86, and boy oh boy would I like to see the x86 catch up and stop using those freaking variable length instructions. They're annoying as hell when you're disassembling chunks of code.

Just wishing...

[Chexum]

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 :)

Re:Just wishing...

[gmack]

I think hes dreaming about 64 bit for the masses.
As would anyone else who has had to get 32 bit x86 to handle more than 4 gig of ram or tried and figgure out how to juggle the few registers provicded as efficiantly as possible.

I for one am also wishing for cheap 64 bit.

This is a bit ironic..

[Marx_Mrvelous]

Considering that Linus is almost fanatical about needing to "break" backwards compatibility in the Linux kernel in order to develop it as fast as possible.

Now he's supporting a CPU scheme that, well, doesn't break anything and may even sacrifice performance for that compatibility.

Re:This is a bit ironic..

[gmack]

That is _only_ true for module interfaces. In the past hes been very picky about changes that break userspace.

Re:This is a bit ironic..

[Dominic_Mazzoni]

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.

Re:This is a bit ironic..

[Jaeger]

Apple sucessfully moved their computers to an entirely new processor line ten years ago, when they switched from the 68000 series to the PowerPC. They did exactly what Intel and Microsoft are doing now: including an emulation layer to maintain backwards compatability. x86 programs, to the best of my knowledge, will run on 64-bit Itaniums.

Apple has done plenty of stupid things in the past (read Apple by Jim Carlton if you're curious), but sucessfully switching from 68000 series processors to PowerPC wasn't one of them.

Re:This is a bit ironic..

[HeUnique]

Screamingly fast? do you base your assumptions on what? Intel's PR?

I had the pleasure of working with Itanium one, and boy - compiling Linux kernel on it was SLOWER then one of my AMD's machine (700Mhz) with the same amount of RAM.

Let us see a real comparison between Itanium 2 and Sun's hardware, SGI, or Alpha (latest generation which are available now).

Intel's biggest problem right now that the market is very slow now. Do you really think that IT managements in corporations will rush to buy something totally new, not backward compatible to anything at those very high price tags? I hardly think so.

Don't forget - with Opteron you got %100 backward compatibility, which means a LOT to IT staff, and it would probably cost MUCH lower then Intel's prices..

Re:This is a bit ironic..

[HeUnique]

Sorry Jaegar, you're wrong..

Apple move from OS 7.x to 8.x (was that 7 to 8? or 6 to 7?) had a compatibility layer which could run most of your applications in a special layer (forgot the term).

What Intel gives you as a backward compatible is slower then Pentium III 600 Mhz. Show many any serious IT person who will buy Itanium 2 at those high prices with this compatibility.

Lets face it - with Linux the move is easier - there will be Linux distributions for Itanium 2, and the rest of the stuff which is not available there - you'll need to recompile (and fix some endianness issues - if there are) but when it comes to commercial applications or worse - Windows OS - you'll have to wait for the vendors to ship a special version, which will cost you a lot. Don't expect Back Office for Itanium 2 tommorow..

Re:This is a bit ironic..

[Veteran]

Switching to a new processor almost put Apple out of business. They had to run in place for years to get back to where they had been with the 68K series. Why do you think Apple was in so much trouble before Jobs rejoined them?

Only with the most recent series of Operating Systems is Apple actually ahead of where it was with the 68K, It could have done OS X years ago if they hadn't had to struggle to catch up to where they were.

Switching instruction sets is a big deal.

Re:This is a bit ironic..

[FattMattP]

But can't we just recompile?

Re:This is a bit ironic..

[roca]

That's partly because so much of the Mac OS had been written in assembly. That's no longer true for any important OS.

Re:This is a bit ironic..

[cant_get_a_good_nick]

Apple got PowerPC religion within the 7.1 series, actually going from 7.1 to 7.1.2. 7.0 was a huge jump. 7.1 fixed the massive amount of bugs in 7.0 (well a reasonable subset anyway). System 7 had things called System Enablers. Enablers were Apple's idea of separating the hardware specific parts of the OS into one file, and all the rest is universal. It sucked because then you couldn't have a universal system on a floppy (wow, you could get MacOS on a single floppy once? yes my son). You couldn't fit all the enablers on one floppy with the kernel, especially with the huge 7.1.2 enabler (see below).

7.1.2 essentially added support for PowerPC with a 68040LC Emulator. Very little of the OS was PowerPC then, they were just glad to get anything to work. Once that was kinda stable, then speed sensitive stuff went PowerPC native. I think Quicktime went first. There was something in each code segment that said whether it was 68040 or PowerPC. Each app could have mixed segments, as could the kernel.

Considering Apple added a whole new chip architecture, they're to be commended on how well it worked out. And they did it on the heels of a major upgrade 6->7 (yes, I'm sure they wrote 7.0 with PowerPC in mind, but there wasn't much time between 7.0 and 7.1 to get everything right). Sure 7.1.2 was shit, and it really didn't get together til 7.5 series (how 7.5.3!) but it was a whole new chipset that required changes to the kernel and code segment loaders and having all these segments talk to each other. And considering they had to do these with 60MHz (in the first 6100) PowerPC 601s, not exactly screamers. They did pretty well.

Re:This is a bit ironic..

[bero-rh]

I think it's not so much about backwards compatibility, and not as much "x86-64 is good" as "ia64 sucks".

I'm all but a fan of x86, but ia64 beats it at sucking, and x86-64 is at least a bit better.

Re:This is a bit ironic..

[Tony-A]

I'm all but a fan of x86, but ia64 beats it at sucking
Is that possible?

"Praying?" Hello? First Amendment?

[Anonymous Coward]

You might want to change the title of this story to "Hoping for Hammer to Win." Who's praying? Ever heard of the separation of church and state? Jesus.

Atheists are the last group of people who are still acceptable to oppress.

Re:"Praying?" Hello? First Amendment?

[hooded1]

Well actually, the first amendment is freedom of speech, so you are actually trying to justify your statement with evidence that actually supports the opposite of your statement.

Mountain out of a molehill

[Zooks!]

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.

Linus's Prayer

[markatwork]

Now I lay me down to sleep.... I pray Intel the IA-64 Instruction set to keep. But if Intel folds before I wake, I pray AMD picks up their stake (of the market).

(OK so the last part sucks, but still ....)

Re:Linus's Prayer

[Creepy]

What?!?

Sure you can! Which commandment does that break? Thou shalt not mock scripture? Haven't heard that one... must have been one on the tablet Moses dropped. I give you these 15... smash... 10... Ten Commandments!

Ok, it was funny until some holier-than-thou Anonymous Coward busted a couple of rounds in my ass. Psychotic fundamentalists...

good thing Cowards don't get mod points ;)

Re:Linus's Prayer

[Flower]

I prefer this prayer.

THIS IS MY KERNEL. There are many like it but this one is mine. My kernel is my best friend. It is my life. I must master it as I master my life.

My kernel, without me is useless. Without my kernel, I am useless. I must compile my kernel true. I must debug faster than the proprietary who is trying to FUD me. I must outperform him before he outperforms me. I will...

My kernel and myself know that what counts in this war is not the bogomips we reach, the cpus we scale, nor the filesize we achieve. We know it is the core dumps that count.

We won't dump.

My kernel is human, even as I, because it is my life. Thus I will learn it as a brother. I will learn its weakness, its strength, its modules, its vm, its #defines and its compile time. I will ever guard it against the ravages of binary modules and IP claims. I will keep my kernel efficient and ready, even as I am efficient and ready. We will become part of each other. We will...

Before God I swear this creed. My kernel and myself are the defenders of my PC. We are the masters of the proprietary. We are the saviours of my life.

So be it, until there is no proprietary, but Free!

Ok, ok, I admit it needs tweaking.

no AMD vs. Intel

[reverse flow reactor]

Maybe I misinterpreted the original post, but I thought that this had more to do 64-bit vs. 32-bit (and the limitations of a 32-bit platform) than it has to do with AMD vs. Intel.

The kernel compiles on so many different architectures, but with most of them being 64-bit (PPC, sparc, MIPS...). However, i386 is the dominant architecture by sheer numbers. To maintain crosss-architecture compatibility, the code has to support the lowest quality architeture (i386). By pushing towards a 64-bit architecture, the limitations of 32-bit can be left behind (oh yeah, but the nasty issue of backwards compatibility).

Unless I just misinterpreted the post.

Re:no AMD vs. Intel

[maraist]

Maybe I misinterpreted the original post, but I thought that this had more to do 64-bit vs. 32- bit (and the limitations of a 32-bit platform) than it has to do with AMD vs. Intel.

While we're extrapolating a lot from so little information, I happened to get the opposite impression. 32 -> 64 isn't that big of a deal for Linux since it's already readily available. The big issue is the uniform adoption of AMD's x86-64 or a rift in the x86 32/64 migration path. It would be horrible for the industry in general (not just Linux), if the application base was split between two high-volume 64bit implementations. I would love to see an x86-64 binary rpm work on both intel and AMD; thereby minimizing how maintanance issues.

Personally, I love the x86-64 memory architecture; it's more RISC-like, and begins to chuck away the old 16-bit mode legacy mutations. I get the feeling that Linus was excited by the new kernel-specific features in the archetecture, and thus would probably like to see that become the main-stream linux driver-set. Pure extrapolation here though.

My 10b

Irony

[jejones]

How ironic...the architecture of Dorian Gray, with endless bags on the side added over the past two decades (a long time in computer years)--only made to run reasonably by internally interpreting it on the fly into something decent and executing the result...and technically knowledgeable people are praying that the latest flogging of the dead horse is successful? I know, I'm guilty of it, too, because I want Intel to lose, but how strange that Intel's doing something right, namely starting over, is so universally deprecated (vide the "Itanic" nickname common on websites like The Register).

Re:Irony

[gmack]

Because they aren't doing it right. I used to like their idea too until I started to see the design.

They are planning for the high end only and demanding that things that are best known at runtime compilor. And they aren't even doing that consistantly. The result is a design that manages to be outrun by the Pentium IV and makes even the Athlon seem cool running.

It reminds me of how Microsoft handled Microkernel design where they managed to have the disadvantages of the micokernel combined with the disadvantages a monolithic kernel because they tossed anything speed critical(like video) into the main kernel(bypassing the Micokernel interface).

Re:Irony

[roca]

Starting over is only "right" if you replace the status quo with something better. Instead, Intel replaced it with something *worse*. If Itanium performed, geeks would be all over it. It doesn't.

Re:Irony

[rodgerd]

Actually, a trawl through comp.arch suggests that various luminaries are reasonably comfortable with Opteron - it's less an "x86 with bits bolted on" and more a "what would I do if I wanted a nice 64 bit CISC chip that happened to be compatible with ia32 instructions"; a number of older, cruftier bits of the ia32 have been deprecated.

So what's next Coke of Pepsi?

[Wizri]

Hey Linus,

What should I drink?

Thank alot,

Wizri,

Re:So what's next Coke of Pepsi?

[cthulhubob]

Isn't it obvious?

OpenCola is the soft drink you're looking for. Sparkly and refreshing, with an open-source recipe. OpenCola is simply the choice of a GNU generation ;)

Clarification

[KidSock]

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.

Re:Clarification

[roca]

Have you compared the die size of Itanium vs a Xeon or Hammer? Itanium is much larger --- and slower --- and more expensive. Who's wasting die space?

But hey, at least it's pure!

Re:Clarification

[Waffle Iron]

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.

Except that two CPU generations from now, Intel will have had to change the underlying architecture of the IA-64 chips to get performance improvemets, but they'll have to leave the instruction set compatible. So, they'll have a hardware wrapper around the IA-64 instruction set. And this wrapper is going to have to try and second-guess the output of those rocket-science IA-64 compilers and rewrite the results on the fly.

Why not just leave well enough alone and let the CPU rewrite code from today's simple, well understood compilers? The current x86 instruction set works like a bytecode VM. There's nothing wrong with that, especially since the IA-64 CPUs and compilers haven't exactly been blowing away the x86 chips in the performance area.

Re:Clarification

[akb]

larger

that's cause it can take up to 4MB of level 3 cache on die

slower

its not really aimed to compete in its current implementation. its released to let system makers, compiler writers, etc have a crack at it.

more expensive

volume and aimed at different markets

Re:Clarification

[Ralph Wiggam]

The parent poster went out of his way to say that IA64 was his choice in the "long term" and didn't mention Itanium once. He was talking about instruction set design, and you rebut with specific CPU implementation. Yes, Itanium is a giant monster of a CPU that will probably fail on most levels. But don't judge an instruction set based on the first implementation out of the gate. They'll get a lot better at it in the near future. The Pentium Pro was a big disaster (not a new instruction set, but new core). The engineers learned from that experience and came back with some damn fine chips.

-B

Re:Clarification

[T-Punkt]

The core of these chips like Pentiums are really RISC chips with hardware wrappers to implement the X86 instructions.

You can say the same about i386, i286, and even 8086 or any other CISC CPU. It's called 'microcode'.

Re:Clarification

[evilviper]

Does everyone remember a short while back when an insane C-Net article ran saying Mozilla was going to be a full office suite?

I was subscribed to that newsgroup, I was part of that thread... When the article heard round the world hit, I was just as disqusted. One comment that said other apps, such as StarOffice, should use XUL ended up turning into a small-scale because of some new overzelous C-Net reporter looking to make a name for himself.

Well, the point is, the news has always been, and will always be like this. Tech news or not, you never hear the truth. You hear wild exaggeration of facts, unsupported rumors that sound good, and generally anything but the truth. But the next day, people are back, watching the news, thinking it's completely accurate. (who still remembers the dozens of unsupported reports of public building all over the east-coast being bombed in the Sept.11th hysteria?)

Re:Clarification

[roca]

So, Intel didn't try to make a competitive chip? "Yeah right". If so I hope they gave a refund to anyone who tried to use it in a real system.

Itanium 2 is coming out now. Performance is a bit better but only slightly ahead of the Moore's law curve. Intel and HP don't dare compare it to a high-end Xeon, let alone a Hammer. Will Itanium 2, too, be written off as a "developer's chip"? Just how many generations are there going to be before it's ready to use?

> > more expensive
> volume and aimed at different markets

That, plus the massive die, explains why it's expensive, but they don't change the fact that it's very expensive.

Re:Clarification

[roca]

The Pentium Pro ran 32-bit x86 code very fast, much faster than its predecessor the Pentium. Not such a big disaster as the Itanium, which wasn't a clear improvement in any dimension over its competition, except for hype.

The Itanium 2 is faster than Itanium but not by much more than you'd expect from Moore's law. So just how many generations will it be before we're allowed to judge IA64?

Re:Clarification

[roca]

> that's cause it can take up to 4MB of level 3
> cache on die

That's nice. Yet with all that cache, it's still slower.

(In fact they need all that cache because the cache miss penalty in Itanium is absolutely horrific, since it can't reorder instructions in hardware. There's the real waste of die size.)

Re:Clarification

[Gumber]

Is it slower on x86 code, or slower when both platforms are running optimized native code?

AMD's kernel summit presentation

[awptic]

For anyone who has an hour and a half to spare... AMD (along with a few people from SuSE) made a great presentation on the X86-64 technology at the Linux kernel summit in Ottawa a little while back; the MP3 and OGG files are available at the sourceforge kernel foundry.

Not as much praise is it's made out to be?

[mwarps]

Linus seems to be more concerned with the wide-range functionality of the specific hardware than the "brand" of it. Making Linux work with x86-64 looks to be easier than making it work "properly" (eg with fully 64-bit page sizes, addresses, etc) with IA64. Then again, IA64 is so broken and slow, it really doesn't matter much in the grand scheme of things if they can make a little go a long way with the Hammer. These small deficiencies the counterpoint poster to Linus makes reference to don't seem to be necessary to make things work..

Regardless of who's winning the CPU war, it's nice to see that Linux is running on all the competitors.

Re:Not as much praise is it's made out to be?

[gmack]

That is the problem.. there *are* no 64 bit page sizes.. if there were Linux would support it a *lot* more efficiantly. What you really have is a 32 addressing range and the abillity to swap pages into the 32 bit addressing range as needed.

What we really have is EMS all over again.

Why is this so groundbreaking?

[Jeppe Salvesen]

I thought we supported this stuff for the other 64 bit processors? Aren't we fully 64-bit yet?

Misleading Headline...

[Tall Rob Mc]

We're not moving to a 64-bit index for the next few years. 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 (the size pressure on "struct page" is largely due to HIGHMEM, and gcc does fine on 64-bit platforms).

It sounds to me like he's praying for standardization of the 64 bit architecture, not the success of the AMD Hammer.

Re:Misleading Headline...

[Junta]

Yes, he's praying for standardization, using AMD's standards which is directly related to Hammer's success. Itanium was to be Intel's one and only 64-bit future, and only when faced with AMD's 32-bit backward compatible architecture did they design a fallback, the Yamhill, which would be compatible with the Hammer and legacy apps. The headline is *not* misleading at all, for once, he wants AMD's Hammer standard, not IA64.

It seems odd though. Putting aside market situation and prices to look at the pure technology aspect of it, IA64 is a better architecture, it isn't burdened with backwards compatibility. Especially with linux (which already works with IA-64, as well as most apps), there is little reason to hold on to the dated IA32 architecture, which inherits stuff from early 80s. I could see why MS would be on the x86-64 bandwagon (if users' upgrade paths force them to change architectures, they may be just as likely to go PPC as they would IA64), but not Linux...

It made sense when moving to 32-bit from 16-bit to keep backwards compatiblity, assembler was widely used back then out of necessity, and thus porting applications was non-trivial. Now, in an age where most everything is written in high-level languages, this is the perfect opportunity to start with a clean slate. Companies can easily recompile and do additionaly testing and earn back the money it cost to do so in short order, if their application is important to the market.... Of course all of this is from a technological standpoint....

The fact of the market is that Yamhill/x86-64 is the future of x86. Itanium was a nice dream and all, but when you look at the two platforms and the variety of software they support, the choice is clear. Not everything will be ported to IA64 and knowing that it is hard to justify the jump...

Re:Misleading Headline...

[barawn]

Actually, I think the reasoning probably came from the fact that Hammer is entering into the mainstream market (as an Athlon Pro, or whatever) rather than into the server-only market, like Itanium. Hammer really is going to be the first mainstream 64-bit chip. If Hammer really catches hold, then x86-64 specific OSs may come out (Linux will happen quickly, so quite a few servers will probably be running x86-64). At that point, they will not run on a P4, which still has a future ahead of it.

Yamhill is a P4 derivative, not an Itanium derivative (of course) - if x86-64 becomes market-important, then Intel will release Yamhill into the mainstream, and then the mainstream will be mostly x86-64, rather than IA32.

He's talking about market segments, not architectural benefits. He never said IA64 sucked.

Re:Misleading Headline...

[roca]

> look at the pure technology aspect of it, IA64 is
> a better architecture

No. There are better, cleaner architectures than x86 --- MIPS, Alpha, PPC. But IA64 is not one of them. Static scheduling simply doesn't give you the performance, not with today's compilers, not with tomorrow's, probably not ever. Some things really are done better in hardware.

Re:Misleading Headline...

[Junta]

True, but if if there *had* to be a choice between x86 and ia64, I would think ia64 would be better.... And your point is exactly why I don't get Intel's strategy. They sacrifice their head start and now get evaluated 'fairly' against competing architecturs like PPC, MIPS and Sparc. They control Alpha and PA-RISC is being flushed. MIPS is pretty much earmarked for embedded apps by the market now (Irix systems aren't doing well, are they?), so the 'major' players in the workstation/server arena are PPC, Sparc, and Intel architecture... All other things equal, PPC looks really tempting in particular....

Of course, MS could make all the difference, unfortunately....

Re:Misleading Headline...

[roca]

> if there *had* to be a choice between x86 and
> ia64, I would think ia64 would be better

IA64 cleaner than x86? Maybe, if you rip out its own x86 support a few generations down the line. But faster? No. If your shiny new architecture doesn't provide a major performance boost over the old architecture, I can't call it better.

Re:Misleading Headline...

[Sebastopol]

Companies can easily recompile and do additionaly testing and earn back the money it cost to do so in short order

What the heck are you talking about? Do you have any idea how difficult it is to support multiple hardware configurations? You don't simply build to binaries and go on your merry way: you DOUBLE your validation team, which is a HUGE amount of resources. Only if you have a really popular product and the resources do you target two specific architectures.

Reality is far, far more complicated than "companies can easily recompile."

IA64 is not mainstream because Intel intentionally priced it as a low-volume server product. Emphasis on 'intentionally'. Intel can't push ia64 mainstream b/c they would lose a very lucritive product. Plus it's a fact that no one outside of servers and high-end workstations needs 64-bits ... yet.

Re:Misleading Headline...

[Junta]

I work for a company that supports Windows, Irix, Aix, Solaris, and HP-UX. While it complicates QA, supporting n platfomrs does not require n times the amount of QA for one product. Especially if one is being aged out for another. Each additionally platform requires less additional QA than the previous, to a plateau. As much as companies love to spew the gargantuan cost of QA for multiple platforms, it is not nearly so bad as they say..

Re:Misleading Headline...

[Ben Hutchings]

IA64 is not mainstream because Intel intentionally priced it as a low-volume server product. Emphasis on 'intentionally'. Intel can't push ia64 mainstream b/c they would lose a very lucritive product.

I kind of doubt they intended to sell quite as few as they have done, though. Intel would be far better off selling tens of millions of them at a $10 profit rather than selling a few thousand at a $1000 profit, and I imagine they'll want to do that eventually. The reason they can't at the moment is that even at a low profit margin the price would be more than the mass market would bear.

Plus it's a fact that no one outside of servers and high-end workstations needs 64-bits ... yet.

But they could certainly use more than 32 bits for disk and file addressing, and 64 seems to be the next step up.

x86, why can't you just die?

[MORTAR_COMBAT!]

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.

Re:x86, why can't you just die?

[cmowire]

OTOH, it makes some sense to keep things the way they are.

Consider that the internal core of a perfect-new RISC chip and a x86-64 chip are more-or-less the same. x86-64 instructions come in, are translated to internal RISC code, and are then executed. The main difference is an extra translator and the register-renamer. But any architecture that lasts long enough will need such trappings, as it starts being used for things that nobody would have thought of when the designer thought the chip up.

Remember that, for a long time, the 286 instructions that aren't easily mappable to the RISC core aren't particularly efficent.

I used to think exactly the same thing as you are thinking now. I want a MIPS or Alpha inside, not Intel. But, given that 99% of programming is not done in assembley and the cost of adding a hardware instruction set translator is minimal compared to the difficulty and risks of switching instruction sets, the instruction set of a processor ceases to matter.

Re:x86, why can't you just die?

[roca]

Compare the size of the Itanium 2 die with the dies for AMD's Hammer chips. You will soon see who has the real muscle chip. (Hint: Itanium 2 will be FOUR TIMES larger than AMD's Clawhammer --- and it will still be slower.)

Getting rid of cruft is a good move if it lets you get higher performance. But IA64 destroyed that potential performance gain with several idiotic design decisions. That shiny new no-legacy instruction set may give you a warm feeling but that's all you get.

Now, Alpha was a nice architecture. If Intel had invested in Alpha the way they've invested in IA64, they would have left every other CPU in the dust. Too bad.

Re:x86, why can't you just die?

[Gumber]

Slower on x86 code, or slower when both platforms are running optimized native code?

Re:x86, why can't you just die?

[evilviper]

Dropping backwards compatibility shouldn't be done just for the sake of droping backwards compatibility. The Aplha was such a great processor because it was designed and engineered to be a great processor, including backwards compatibility wouldn't necessecarily have hurt anything.

The Alpha processor is incredibly elegant, partially because it is a RISC processor. Neither the AMD nor the Intel 64-bit processors have that advantage, so I don't see any advantage either way. Perhaps the AMD processor, with compatibility, could be a much cleaner processor than Intel's. Not that I'm making a claim either way. The single thing Intel has going for it, is it's theft of the Alpha. They at least had a chance to look at a good processor, and I hope they learned something from it.

You want to know which one I'll go for? I'll go for the one that runs the coolest, with the least power consumption. Speed is secondary, and the elegance of the processor is even further down the list.

Re:x86, why can't you just die?

[roca]

Both running optimized native code.

(Of course Hammer will rip Itanium to shreds running 32-bit x86 code. That's no contest at all.)

I'm extrapolating from the fact that Intel and HP don't dare to benchmark Itanium 2 against a current Athlon or Xeon, and I'm assuming that Hammer in 64-bit mode will be significantly faster than either of those.

Re:x86, why can't you just die?

[roca]

Oh, I'm also assuming that we're talking about real server workloads (integer heavy, unpredictable access patterns), not some easy regular floating-point workload like SPECfp.

Re:x86, why can't you just die?

[roca]

All modern x86 implementations are RISC inside. RISC really doesn't mean anything any more.

I agree that Alpha was very cool and it's very sad to see it killed.

Re:x86, why can't you just die?

[0x0d0a]

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 that all our old crap still works".

Amen, brother. I was so happy when I heard about IA-64, and then sure enough, AMD has to drag us right back down into IA-32 hell.

If AMD wins, it will be through short term gains, and means that life will suck more for us in the long run.

Re:x86, why can't you just die?

[dreamchaser]

How can you like the price and performance of a chip that isn't even shipping yet?

Re:x86, why can't you just die?

[Oestergaard]

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.

Why wait?

This rig is half a decade old:
$ uname -a
SunOS sol 5.8 Generic_108528-14 sun4u sparc SUNW,Ultra-1

Re:x86, why can't you just die?

[hawk]

>Alpha was pure, and a great architecture, IA64 is NO Alpha.

"I knew Alpha, and, sir, you are *no* Alpha."

:)

hawk

Re:This is FUD

[JPriest]

This is _exactly_ what Linus said

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

Re:nice

[be-fan]

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.

Re:Considering..

[binaryDigit]

AMD has 32-bit backward compatability and intel's does not

Sorry, wrong. The Itanic IS backwards compatible with 32bit x86 software. AAMOF, it's been beat up quite a bit about it's lackluster performance in this regard (though understandable from Intel's POV, since it's designed to replace the x86 ISA, not just be a faster x86 chip).

He's the one that made the daemons...

[RyanFenton]

...Thus, if we can conclude that he is praying to himself, it isn't a religious argument anymore. Thus, he'd absolved! :^)

Ryan Fenton

Re:Makes sense to me....

[binaryDigit]

but really, what advantage does it have on the high end not offered by Power, Sparc, PA-Risc, etc

Simple, the ability to run M$ operating systems (which the other chips no longer have). As long as M$ has it's weight behind the thing, then Intel will always have a significant advantage. Reasonable (though not stellar by any stretch) x86 compatibility also helps.

Market Split comming!

[3seas]

Don't you see it comming.....all the way down to hardware...on one side the DRM and such products and the other the open systems

And what Sir Linus says is gospel truth is it?

[Second_Derivative]

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*

Re:And what Sir Linus says is gospel truth is it?

[barawn]

You're right - from a theoretical standpoint. And, if all things were equal, IA64 should utterly rout x86-64.

However, things aren't that equal. First off, x86 has had a lot of work thrown into it, and the current processors are quite good at implementing x86: I doubt there's a huge architectural penalty anymore - you can build virtually identical PPC and x86 computers and compare them, and even though PPC is a much better architecture, it's not going to blow x86 out of the water. Yes, it's idiotic to have, for instance, a stack-based floating point implementation, but the P3 and Athlon both make FXCH free, so it's not that bad anyway, and the P4's SSE2 implementation isn't bad, so using SSE2 instead of x87 is a decent compromise.

Ars Technica (www.arstechnica.com) actually has a good writeup of why we should stop treating x86 as this bastard dog of an instruction set, although they mostly relied on the fact that we have a huge installbase of x86 software.

Honestly, I doubt x86 decoding seriously bloats the die that much - jeez, on a 0.13u process, how big would the original 8086 core be? Take a look at the die for a Hammer processor - x86 decoding doesn't take that much space.

Just wait and see, that's my answer. Let the benchmarks prove AMD or Intel wrong. Intel's really relying on the brilliance of compiler writers, whereas AMD's banking on tons of experience. We'll see who has a better strategy...

Re:And what Sir Linus says is gospel truth is it?

[roca]

> I do think the AMD architecture looks like a
> piece of shit.

You obviously don't know anything about it. In 64-bit mode Hammer gives you 16 general purpose registers (RAX, ..., RDI, R8, ..., R15) and 16 floating point registers (you are encouraged to do all FP using SSE2 and forget about the x87 crap). The GP registers are not overlaid (e.g., the 8-bit instructions access the bottom 8 bits of each register; AH,BH,CH,DH are not available). 64-bit mode is cleaner than x86 in other ways too.

> the actual platform is beautifully elegant

Unfortunately you can't run programs on the "actual platform". You can only run programs on the slow and expensive Itanium and Itanium 2.

Re:And what Sir Linus says is gospel truth is it?

[roca]

> using SSE2 instead of x87 is a decent compromise

In fact, it's significantly faster. Latest gcc has a switch to do this.

BTW, you're ignoring the fact that x86-64 is a significant improvement over x86, not just a 64-bit stretch. 8 new general purpose registers, 8 new SSE2 registers. It starts to look a lot like a real architecture, yet compiling to it is very little different from compiling to x86.

Re:And what Sir Linus says is gospel truth is it?

[0x0d0a]

Ars Technica (www.arstechnica.com) actually has a good writeup of why we should stop treating x86 as this bastard dog of an instruction set, although they mostly relied on the fact that we have a huge installed based of x86 software.

Who cares? You sorry that your bootloader is going to have to be rewritten? No, I didn't think so. So it comes down to apps in old operating systems.

DOS -- does anyone ever boot into true DOS any more? Just about everything is run in a compatibility box for Windows users. Just port that to IA-64 with an emulation layer. Performance already sucks, so it's no big deal. If MS manages to do *half* the job Apple did during the 680x0 to PPC transition (admittedly, a tough question) there won't be any problem at all.

BeOS -- Sorry, guy...

Windows9x/ME -- Die. I'm not sorry about it at all. Die.

Windows NT/2000/XP -- this line will definitely be ported to IA-64, and I'm sure there will be a compatibility environment. Quit whining.

Linux/BSD -- no problem at all. Just recompile. :-)

Honestly, I doubt x86 decoding seriously bloats the die that much - jeez, on a 0.13u process, how big would the original 8086 core be? Take a look at the die for a Hammer processor - x86 decoding doesn't take that much space

Why waste space at all that you could use for cache or something that would actually *help* performance?

Re:And what Sir Linus says is gospel truth is it?

[Znork]

So, the AMD architecture is a piece of shit, compared to doing 64bit stuff on 32bit x86?

Because, if you actually read the mail, rather than the ummm... 'challanged' intro, neither IA64 nor any other 64bit platform is mentioned. This is about IA32 vs AMD x86-64, not about IA64 vs AMD x86-64. So, yes, you and a whole lot of other people are missing something here.

Of course, that doesnt make as sensationalist a story.

Re:And what Sir Linus says is gospel truth is it?

[barawn]

I agree with you, although there may be a few certain situations where x87 is a better choice than SSE2 on certain processors due to non-parallelizability (is that a word?) of certain code. Hence the reason I said "decent compromise". If Intel had had the die space, I would've said have -both- a fast x87 unit and a fast SSE2 unit, and share what you can between them. But, eh.

I definitely agree with you that x86-64 is a significant improvement: that's why I'm confused why everyone thinks that it's impossible to extend an architecture and maintain backwards compatibility and still have an intelligent architecture. When I looked at x86-64, it looks half-decent: the old x86 cruft is hidden, and not even available in full 64-bit mode. My thoughts on this are heck, this is the way to go. Iterate this once, maybe twice more, and you'll have an architecture which competes with the best of 'em, yet is still fully backwards compatible.

Re:And what Sir Linus says is gospel truth is it?

[barawn]

It is not about the apps. It's about the toolchain, and the libraries. You said it yourself:

Linux/BSD -- no problem at all. Just recompile. :-)

But that implies a wealth of things: a working compiler that works as good and is as efficient as the old one, with as few bugs as possible. If you write the compiler from scratch, this is not going to be the case. It is not going to be as good and as efficient as one that's been worked on for an incredibly long time.

There's a wealth of information on this subject out there: take a look at AMD's presentations showing the progression of SPECint95 scores as improvements in CISC (x86) based designs completely eliminated the differences between architectures. You flat out do not get much of a performance boost from switching architectures: a well optimized design reduces any ISA to an optimal architecture.

Think about it this way. When you upgraded processors before in x86-land, the worst that could happen would be a really bizarre bug would show up that could cause strange things to happen, but for the most part, everything worked. See the F00F bug, the Pentium fdiv bug, etc. etc. If you switch processors and move from IA32 -> IA64, the whole damned OS could fall apart and not run straight from the beginning because of a compiler bug. It's an integration nightmare.

Man. Then when you think that IA64 puts a huge strain on compiler writers, it's no wonder that people look at x86-64 and say "that might not be a bad idea."

As for the die space argument you had at the end, cache is huge, decoding/translation is tiny. You're talking orders of magnitude difference here. Think about it in the reverse sense. If you had something that increased die size by, say, even 1%, and allowed backwards compatibility with absolutely tons of applications, wouldn't you do it?

completely misunderstood: out of context

[jpc]

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.

Linus: Size Pressure on "struct page" due to HIMEM

[coupland]

In shocking testimony uncovered by The Inquirer, Linus Torvalds has publicly stated that the size pressure on "struct page" is largely due to HIGHMEM! This ground-breaking statement was a crushing blow for HIGHMEM fans, but received applause from struct page supporters. More information on this ground-breaking revelation as it unfolds...

:P

Come as a suprise?

[peterdaly]

I know his words are a little out of context, but that's already covered enough here, so I won't go into that part of things...moving on...

I am the first to admit I don't totally understand the different 64 bit chipsets, that being said it comes as not suprise to me AMD has some advantages over the i64 offering. AMD has been blowing Intel away recently on many different performance levels. Intel has lost their quality advantage. Remember when people were taking a big chance buying an AMD machine back in the 486 days, or at least everyone thought so. You never hear about that now. A lot of the articles today tout the per megehertz speed advantage AMD holds over Intel. The gap has been so large lately AMD does the fake mghz labeling thing so comsumers can compare on a more apples to apples basis.

Maybe Intel's time has come and the monopoly is on the verge of being broken. I for one would welcome it.

-Pete

Re:Come as a suprise?

[Brian Stretch]

How could anyone in their right mind think that AMD and Intel do not compete has equals?

Because Intel can still scare the big OEMs into not offering AMD chips, or at least not offering, say, high-end AMD notebook configurations. The new Compaq 900US is a great improvement on this front (DDR SDRAM! Decent video chip! In stores now!), but it still only has a 1024x768 res screen.

Of course, the "white box" vendors have been gaining market share as a result of all this. Oops.

Now, with AMD converting nearly all of their Dresden fab to .13 micron Hammer production and UMC ramping up for Athlon production under contract, AMD will be able to supply enough chips for those OEMs to tell Intel to go fsck themselves if they threaten to cut off their chip supply or play other such games. "Volume is our vaccine", sayeth Jerry Sanders. Watch the fun and games begin in early 2003.

Re:Come as a suprise?

[Brian Stretch]

So what. This isn't illegal. Exclusive contracts are not illegal as a matter of course. They happen all the time.

I never said it was.

Proof positive that there is no Intel monopoly.

Near monopoly at the top-tier level?

The fact this is possible proves there is no monopoly.

There won't be very soon :-).

I know, Intel doesn't have a monopoly in the strict sense of the word (government sanctioned and all that). But they've been awfully heavy-handed, not to mention pushing garbage like the P4 Celerons on the market (ewww!), and it's going to be soooo much fun watching them get Hammered. AMD has for the most part responded properly, though their occassional lawsuits have been disappointing.

Re:Um...no....read this

[uradu]

> I hope x86-64 is huge, but if it's too expensive

More expensive than Itanium? Get real. Last week's eWeek had a good editorial on this. AMD has traditionally catered towards the consumer end of the market, and even if they go more upmarket they're likely to be consideraby cheaper than Intel's high-end offerings.

64 bit desktop is still overkill

[ehiris]

The only smart reason I see to go to 64 bit is when you need more then 4 GB of memory. The technology is not far enough yet outside the server/high end workstation market to require all that memory.

Maybe next generation windows will waste more of my memory so I will need a 64 bit CPU.

Re:64 bit desktop is still overkill

[pi radians]

You still only use 640k right?

Re:64 bit desktop is still overkill

[Courageous]

AMD knows all this. That's why K8/Hammer has higher IPC than K7/Athlon. It's the next-generation successor to Athlon, which is planned for obsolescence and will be retired to make way for Hammer, eventually.

C//

Re:64 bit desktop is still overkill

[Nicolas MONNET]

32 bits =~ 4gbytes of address space, minus housekeeping stuff, that means you can get at most 3gb on Linux for instance if I'm not mistaken.

I already have 1gig on this machine, and planning on buying more -- I need that shit to compile the latest big stuff. I'm soon to hit the limit. So yeah, I'd like 64 bits:)

Re:64 bit desktop is still overkill

[afidel]

The pc I built last summer has 1.5GB of ram, so this xmas I should be due for 3GB of ram in my new box. and by summer 2004 I should be at 6GB or more than can be sanely address with 32bit cpu's (yes there are the Intel 38 bit memory hacks but they are just that, hacks). This is of course just the naturaly progression due to Moore's law. Besides the more stuff in ram and not on disk the happier I am, my pc's get rebooted at most once every couple months (both home and work workstations, servers even less frequently of course) I like having all of my common programs open instantly.

Re:64 bit desktop is still overkill

[ehiris]

I wouldn't rely any of my data on a battery.
Not even a bad picture! :)

AMD and Intel

[Archangel Michael]

These companies are both broken. What needs to be done is for a sacrificial lamb in the form of a dual chip release. First you create a broken kludge upgrade 64 bit chip that is backwards compatable with X86 (the sacrificial lamb), while at the same time (on another design) stripping all the old outdated stuff and sticking LOADS of cache and other optimizations on the new chip, but with 100% compatable with the 64 bit extensions of the sacrificial lamb. This would enable THOSE with brains to move right to the new 64 bit chips while those W/O brains could remain backwards (compatable).

Re:AMD and Intel

[Archangel Michael]

FYI,

Itanium and Hammer are not 64 bit compatable chips, which was my point. Two chips with 64 bit processing that are 100% compatable at the 64 bit level, one backwards, one not.

Let's look at what happens here if Itanium fails.

[emil]

If AMD is successful in forcing Intel to adopt x86-64, great harm will be inflicted upon:

• HP-UX
• VMS
• Tru64 (what is left of it that is rolling into HP-UX)
• To a lesser extent, AIX-5L

While recent interviews with HP execs (on The Register) indicate that HP is taking some steps to "roll with the x86-64 punch," I sincerely doubt if HP can be convinced to port VMS to Opteron should it become necessary.

What is even more troubling for the Itanium is the fact that HP's compilers are faster than Intel's, but the HP compilers have not been released outside of HP-UX. The standoffish attitude of other ISVs (Dell, IBM, etc.) is not hard to understand given these circumstances.

You will also have noticed Microsoft's (now infamous) "leaked" memo on Windows-64 running on Opteron. Such a leak I believe has been carefully crafted to throw FUD upon all things Itanium. Furthermore, it is in Microsoft's best interests for Opteron to prevail, as such a victory will destroy not only DEC/Compaq's high end, but also HP (as much as HP-UX deserves to die, it should not fall to Microsoft).

If Intel and HP truly want Itanium to flourish, Intel must reduce the price immediately (to at least a SPEC-to-SPEC match with Athlon/Opteron, and possibly lower), and HP must release fast compilers under an open license.

If the Itanium market remains fragmented, AMD wins, and Microsoft's interests are advanced.

Who is Linus speaking for?

[colostomy_net]

Setting aside all the Linux kernel issues, Linus has a decidedly vested interest in the AMD part as Transmeta has already taped it out. So when he speaks of the kernel issues, keep in mind that his Transmeta stock options may speak loudly in his mind.

Re:Itanium and Opteron

[binaryDigit]

People constantly complain about the fact that x86 sucks - here's finally a chance to do something about it (ala the mac powerpc change) and everyone starts whining

Yes, one of the strengths and weaknesses of the Wintel market. With Apple, they control the whole show, so they can both dictate, but then be sure to fully (well, somewhat fully) deliver such wholesale changes. With Wintel, you have to get buyin from M$ first and foremost, and then what are the odds that M$ will go at it both barrels, uh not! They'll hedge their bets and support whichever arch. that pushes more copies of Windoze (which with either chip, means a new upgrade, hooray).

and microsoft will support

[johnjones]

oh and microsoft will support 4 64bit archs (-;

AMD -> x86-64
Intel -> IA64
?
?

to quote http://www

so what would it be surley not Alha as thats end of life and not PA-RISC

that leaves MIPS PowerPC and ?

regards

john jones

Re:and microsoft will support

[GoRK]

Windows NT used to be available for Alpha and PowerPC

I agree with the sentiment

[g4dget]

Intel's VLIW architecture is going to be a pain for compiler writers, greatly limiting the diversity of languages that's likely going to be available. It will probably do well on C and Fortran-based benchmarks, but whether it runs your or my code well is an entirely different question.

I don't particularly like the x86 instruction set, but unless we all switch to Alpha or SPARC, x86-64 makes the most sense to me.

Re:I agree with the sentiment

[BitwizeGHC]

I don't think the Itanium ISA will "greatly limit" any of our language choices. The way I see it, at the very least we have two choices:

1) Compile to C, and then compile the C to native code.

2) Compile to the .NET CLR, which by the time Itanium takes off will be the standard development platform.

Re:I agree with the sentiment

[roca]

Regarding 2), one huge problem for IA64 is that, being so hard to compile to, JIT compilers are very slow and that really hurts the performance of virtual machines.

Re:I agree with the sentiment

[dvdeug]

Intel's VLIW architecture is going to be a pain for compiler writers, greatly limiting the diversity of languages that's likely going to be available.

The major compiled languages are all attached to GCC, so if Linux/BSD get a decent C compiler for IA64, they will also get decent Pascal, Fortran, Ada, Java and Objective C compilers. Most implementations for other compiled languages are compilers to C. Most direct-to-assembly compilers only targeted IA32 anyway, arguably making it no great loss. JIT compilers will lose out, though.

In other news...

[GregAllen]

Linus passed gas yesterday.

Droves of geeks were seen wafting in his wake, hoping to get a whiff.

Must be a slow day for news.

Re:Well what I think

[Barbarian]

Something's wrong with your heatsink fitting, or there's no thermal paste, 60 C is really high for 1.150 Ghz with a 50 cfm fan.

The Other Lord's Prayer?

[randomErr]

Our Linus which art in Santa Clara, Hallowed be thy name.
Thy kernal come.
Thy will be done in desktops, as it is in servers.
Give us this day our daily rpm.
And forgive us our crons jobs, as we forgive our cron jobers.
And lead us not into temptation, but deliver us from Microsoft:
For thine is the kernal, and the power, and the glory, for ever. Amen.

Re:The Other Lord's Prayer?

[randomErr]

This is from who, oh yeah, an Anonymous Coward.

probably nothing to license

[g4dget]

In this article, the "Inquirer" wrote:

Intel would have to license the X86-64 code from AMD, a fact that might stick in its craw more than just a little.

I don't see why. Instruction sets don't generally seem to be protected by any law. Otherwise, AMD would have had to license the x86 instruction set, which I doubt they did (and if they did, Intel would be in a great negotiating position). Or the various IBM, PDP, and VAX clones would have had to license the respective instruction sets, which, again, doesn't seem to have been the case.

In fact, in their own article on the Transmeta use of x86-64, which they reference, they wrote:

Sources close to AMD said that Transmeta "licensing" the instruction set, which it did last May, meant no more than it had decided to work with the instruction set and there were no real conditions or limitations on use for X86-64 code.

That means that Intel - which as we reported here some time ago has a "skunkworks" preparing a 64-bit backup plan - can freely use the AMD instructions to make a processor, if that's what it chooses to do.

Seems to me that the "Inquirer" agrees that x86-64 doesn't require a formal license.

Re:probably nothing to license

[afidel]

While the classic x86 instructions were white room reverse engineered AMD decided with MMX,SSE and SSE2 that because the names of the instruction sets were trademarked and that it was really only for marketing purposes that they were adding support that they might as well just liscense them. Intel obliged and liscensed them at what were fairly decent terms, albeit a half to full generation behind the Intel products that featured them. Since for real applications it usually takes that long for people to learn/implement the new instructions it wasn't a big deal for AMD as by the time they were really on everyones must have checklist they were implemented and Intel got their PR/marketing win that made them all fuzzy. Intel did in fact liscense the X86-64 ISA from AMD even though they really couldn't be forced too because some MBA did risk analysis and decided that risk + potential lawyer cost liscense. Plus AMD gets legitimacy from having their bigger, more well known rival liscensing their tech.

32 bit CPUs are here forever

[willy_me]

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.

Re:32 bit CPUs are here forever

[swb]

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!!

32 bit CPUs may be here for a relatively long time after 64bit gets absorbed into the desktop, but forever? Even though a given embedded application may not *need* a 64bit CPU, economies of production and fabrication suggest that it may be *cheaper* to use a 64bit CPU as chip makers are likely to make more of them and less 32bit CPUs.

It's like B&W teevees -- I don't need a color TV in my kitchen, a B&W one would do, but I'll be damned if I can find one. It seems that they're all color.

Re:32 bit CPUs are here forever

[willy_me]

Even though a given embedded application may not *need* a 64bit CPU, economies of production and fabrication suggest that it may be *cheaper* to use a 64bit CPU as chip makers are likely to make more of them and less 32bit CPUs.

The economies of scale arguement actually work against you. You're assuming that there will be more CPUs for PCs then embedded devices. You're wrong, the embedded market is much larger then the PC market. For example, a person might own one PC. Great, but they also own a printer, digital camera, television, VCR, automobile,,, the list goes on. All these devices use embedded CPUs and don't require access to over 4gigs of memory. Since it costs more to make a 64bit CPU, these devices will continue to use 32bit CPUs. In this market, a price difference of a couple of bucks is enough to create a custom CPU. And will a TV perform better with a faster CPU? I think not.

Re:32 bit CPUs are here forever

[ocie]

I think you're both right. We see a lot of 8 bit cpus and a lot of 32 bit cpus, but 16-bit cpus are not as popular. I think that as 64-bit cpus become more available, they will be used in higher end applications, while the 8-bit cpus will be used in the lower end applications.

Re:32 bit CPUs are here forever

[stripes]

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.

Read IBM's own tech specs on the POWER4, it does the POWER ISA, PowerAS, and PowerPC. They are not mutally exclusave. The PowerPC added a bunch of single pression FP, and dropped (or made implmentastion dependent a bunch of DP and other stuff they didn't think a Mac needed). I think the PowerAS has some stuff for using *huge* address spaces (useful for a capability baised system), but I don't know that much about PowerAS.

I don't think any affordable Mac is going to use the Power4, but Apple could do it for a hig end server, something like the X serve, but maybe 5 times the cost (since the POWER4 CPU is thought to be about twice the cost of the existing X serve!).

I also have my doubts about IBM putting AltiVec into the POWER4 (the did licence it from Moto though), and some real doubts about whether Apple would build a high end system with an AltiVec-less CPU.

Re:32 bit CPUs are here forever

[Znork]

Yeah, but from what I got out of the mail thread the bitching is mainly about 64bit support on 32bit architectures. Something bound to always really really suck. You end up doing bugprone and annoying workarounds with memory segments and other crap.

32bit on 32bit is fine, 64bit on 64bit is fine, 64bit on 32bit sucks, 32bit on 16bit sucks, etc.

Re:Makes sense to me....

[binaryDigit]

Yes, but that didn't help out Alpha or PowerPC much

True, but it's not that having Windoze supports guarantees success, it's that not having the support would be fatal (at least in the case of Intel).

I wouldn't be surprised if Microsoft was also praying for x86-64 over IA64, first because it precludes having to risk a significant investment in supporting an additional platform

I don't think that this is as big of a risk as you might think. First, M$ already has experience porting their HAL to disparate ISA's. Second, Intel themselves would do much of the grunt work, M$ would just utilize their code (esp. their compilers). This is what they did with the RISC chips and this is what they used to do with their own development tools back in the early days (DOS). Third, given Linus' comment, what better way to stem the Linux tide than to beat it out of the gate on a "hot, new" platform? Esp. one geared towards the highend/server market, exactly where Linux is making inroads.

Linus: Praying for Hammer to Win?

[Anonymous Coward]

Why does Torvalds care about some rap crap 'singer'?

Re:Linus: Praying for Hammer to Win?

[sharkey]

"Watch your fingers. That CPU gets incredibly hot if you leave it plugged in."
"What? OWWW!!!"
"Can't touch this!"

Out of context

[p3d0]

This is entirely out of context. Linus says that there are some problems in Linux related to implementing certain 64-bit things in certain ways, partly because of gcc bugs, and so he said the equivalent of "let's hope x86-64 wins because then we don't have to think about it".

I wouldn't take this particular quote to be his definitive statement of preference for x86-64 over IA-64.

Re:Let's look at what happens here if Itanium fail

[cheezedawg]

*sigh*

Itanium is not competing with Hammer or any other chip from AMD. It would make no sense for Intel to reduce the price of Itanium to less than an unrelated product.

DEAR STEVE JOBS

[roca]

Please port OSX to Hammer and stick AMD chips in your Macs. You can save face by pretending it's not x86 (even though it will make customers happy when they can run WINE and VMWare on OSX). Your programmers will enjoy the relatively clean 64-bit mode. You won't face the risk of being the sole customer of your CPU vendor. Best of all, you will be able to make cheap Macs with competitive performance. I promise to buy one if you do it.

Sincerely,
Robert O'Callahan

Re:DEAR STEVE JOBS

[afidel]

Why? G5's possibly and G6's for sure will by 64bit as the Power ISA already has a mature 64bit mode. Besides Apple is probably going to IBM for their next PPC chip since it apears Ti doesn't have what it takes to do things fast enough. I don't think anyone would bet against IBM as being in business or being capable of making a great CPU.

Re:DEAR STEVE JOBS

[roca]

It's about CPU price/performance, and for that, you need volume. IBM's Power chips are fine but they don't ship in volume (nor do they need to; the price of the CPU doesn't matter so much in that market). On the other hand AMD will ship a lot of chips.

Re: The PPC eBook spec supports 32 and 64 bit CPUs

[willy_me]

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.

Re:Let's look at what happens here if Itanium fail

[rodgerd]

HP don't actually have much of a problem, because Itanium is basically HPPA 3.0 with a bunch of x86 emulation stuff tacked on. HP have, in effect, gotten Intel to underwrite the development of their next-gen RISC architecture and hype it as the next big thing.

In a scenario where Itanic is a failure (ie ends up in a niche as a midrange only CPU), HP-UX and VMS are in much the same position they were before - running on an expensive niche CPU.

AIX still has POWER 4/5, so IBM don't care.

The people who are screwed are the people porting their OS to what could become an HP-only chip.

General misunderstanding on IPF (IA64) pureness.

[leandrod]

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.

What Linus says is not as important...

[software_non_olet]

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!

Are X86-64 and IA-64 really competitors?

[timeOday]

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.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Let's look at what happens here if Itanium fail

[roca]

Yeah. For some reason server vendors are insisting on going with the more expensive, slower, hotter, non-x86-compatible CPU.

Re:General misunderstanding on IPF (IA64) pureness

[putzin]

True, but everyone knows itanium here, but not so much IPF.

And anyone who claimed that Itanium is "pure" was not too terribly well informed. Actually, what defines pure for a processor anyhow? I agree with your second statement.

As for three, I think the jury is still out. Wait for open source competent compilers to be released (say 5 releases of EPIC GCC from now) before anyone really makes a claim as to good v. bad here.

And finally, remember, desktop CPU's make up a very small percentage of total CPU's shipped. Motorola's biggest CPU customer is not Apple, but rather Motorola's Cell infrastructure and networking businesses. Then, they have other companies (Force, et al) reselling their embedded PPC chips as well. Intel makes a ton of embedded CPU's. These are the high volume chips that make their way into your cars, dsl routers, phones, cell switches, telephone networking equipment, and handheld comps that most take for granted. A huge chunk of processors shipped aren't even 32 bit (don't need more than 8 for many embedded apps!) so you're argument that RISC is bad doesn't really hold water unless the only CPU's used are desktop/server (less than 10% by some accounts of the total CPU market).

Au contrare

[emil]

PA-RISC binaries must run under an emulator on Itanium, at some performance loss over native binaries. This is a whole new platform, which HP is attempting to conceal from us.

Any business considering a move from PA-RISC to Itanium should also consider Sparc and Power since both of these established architectures have support, reliability, and scalability - points which are lacking or unproven on Itanium.

Re:Au contrare

[rodgerd]

It's a step HP were always going to take - that's they key point. HP's original plans for HP 3.0 called for the VLIW architecture that Itanic is based on. HP - and it's customers - will be no worse off it Itanium is not a popular desktop chip than they would have been if HP had sinply designed HP-PA 3.0 and made customers recompile or use emulation.

Re:Au contrare

[sl3xd]

I'll say this: If nothing else, at least you can see that the Itanium != Opteron competitor. The intended markets are so *completely* different... I finally gave up in apathy from the rabid responses from Opteron fans.

I suspect they aren't so much Opteron fans as they are cheap, and prefer to put up with poorly designed, inexpensive, rushed-design hardware; they are unwilling to fork over the extra cash for a computer with a better and more elegant design and architecture. (I'm not saying that the Opteron isn't an excellent piece of technology. I'm saying that if the same technology & effort that was spent on the Opteron went to something non-x86, things would be even better)

Another hallmark is they want Apple to release OS X for their cheap x86 hardware; somehow believing that it would be at least as stable on the horiffically diverse x86 (and its much more erratic (and often terrible) quality control, to say nothing of quality) than the tightly controlled & heavily tested hardware it currently runs on.

Even when shown the facts they don't want to believe that Apple is a hardware company first, and software second-- and when Apple allowed Mac clones, it almost bankrupted them.

64-bit vs 32-bit ... why not both?

[Skapare]

I haven't looked at the specs for today's crop of 64-bit processors. Since I started programming in C back in 1982, I've gradually weened myself off assembly language. By 1992 that was mostly complete (did a little Sparc assembly late last year). So I don't really have much motivation to invest time in understanding a new machine architecture from the CPU instruction perspective. Thus, I don't really know what today's 64-bit CPUs can, or cannot do in this regard ... but ...

What a good 64-bit CPU needs to be able to do includes:

• Have a complete 32-bit operational mode where everything can be done.
• Have access to 64-bit (and 128-bit if applicable) data operations while in 32-bit mode.
• Make it possible and easy for a kernel in 64-bit mode to handle virtual processes in either 32-bit mode or 64-bit mode selectable invidually by process (e.g. would not force them all to be running the same mode).
• Supporting 64-bit processes from a 32-bit kernel would be a nice touch, too, but not really essential.
• Be available in varying physical bus sizes for different scales of needs in different markets, such as 32-bit for embedded to small desktop, and 64-bit to high end workstation to server to number cruncher.
• Architecturally support even larger physical bus of 128-bit when times comes for that performance level to be market worthy.
• Support data fetch/store operations of all sizes 8-bit, 16-bit, 32-bit, and 64-bit. A size of 128-bit would be a plus.
• Fast byte order reversal instructions for all sizes.
• Statefully interruptable CPU instructions to support fast MD5, RSA, AES, and other crypto needs (the world is going to be doing more and more crypto, so get used to it).
• Statefully interruptable CPU instructions for codecs, including Ogg Vorbis.

Huh, where am I? Where's the light. Oh crap, it's 6:00 already. Where has the night gone. Damn, and I was having a good dream, too. Oh well, another dull day at work.

Re:General misunderstanding on IPF (IA64) pureness

[leandrod]

> desktop CPUs make up a very small percentage of total CPUs shipped

I know, but I do not care about the embedded market. The general computing market is the one who has a direct impact on the culture and the technology trends, since it subsidizes development of chips that, when miniaturized and their investment amortized, become the next generation embedded processors blueprints.

> your argument that RISC is bad

I never uttered that argument, because I believe RISC is the past and the foreseeable future. I did say that EPIC is bad, and I did imply VLIW is good only in a limited scope, but then VLIW and EPIC are not RISC.

Re:I worked on IA64/linux at Intel

[Yunzil]

The IA64 instruction set is much more innovative than the old x86. Linux in particular benefits from smart compilers

You misspelled "omniscient".

Hope this helps!

Wants Hammer to beat Pentium, not Itanium

[iabervon]

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.

x86 decoding

[Christopher Thomas]

Honestly, I doubt x86 decoding seriously bloats the die that much - jeez, on a 0.13u process, how big would the original 8086 core be? Take a look at the die for a Hammer processor - x86 decoding doesn't take that much space.

The real problem is that it adds extra stages to the pipeline, which does things like make branch mispredict penalties worse.

Re:x86 decoding

[barawn]

Definitely true. However, you sortof need to look at it in context. I'm grabbing things off the cuff here, so if I'm wrong, let me know. P4's pipeline stage is 20-stage or so. I can see 3 which are probably due to x86: 6-8, the allocate/rename stages. I don't even think you can fully blame those on x86, but whatever. So about what, 15% of the pipeline is due to x86? That's not a huge penalty to pay for backwards compatibility, really: 15% of your IPC? 3 clock cycles out 20? I'd be happy with that tradeoff.

Honestly, though, if you look at the P4's architecture, I'm not entirely sure that those 3 clock cycles are due to x86 cruft: I think they're there to feed the ever-hungry execution units. I really do wonder exactly how much of a penalty modern processors pay due to the x86 ISA. I really would doubt it's much at all.

Re:x86 decoding

[barawn]

Erm, OK, need to correct that a bit, mainly because the P4 is such a weirdo.

The P4's trace cache kindof eliminates the x86 translate penalty, because the trace segments for the long x86 instructions come from the microcode, rather than from a translation engine. In fact, if you think about it, you're really not hurt at ALL by having x86 here, because if someone wants to do one of these weird x86 instructions, well, they'd want to do it in your new ISA as well, and it'd be awkward there. The correct solution here would be "don't have the idiot programmer do that" but that's not the processor designer's fault, it's the compiler's fault for using such a clunky instruction (or the programmer's fault, for using a stupid assembly instruction).

Honestly, let processor designers go wild, and they'll come up with dozens of ways to fix a broken ISA, until it doesn't matter anymore that the ISA has stupid cruft in it, because only the "intelligent parts" remain. I think Hammer's a step in that direction as well, by increasing the number of registers, and by eliminating the x87 cruft in full 64-bit mode.

Re:This is FUD

[0x0d0a]

He wants hammer to succeed only so Intel will have to go 64 bit

This is kind of too bad, because from what I've seen AMD's Hammer has more x86 cruft than IA-64. Now I'll grant that Intel would love nothing more than to keep 64 bit architectures for servers for a nice long time and get a juicy enterprise business going (sticking consumers with a 32 bit architecture for years to come), but I don't know if I want AMD to end up on top, given their technology.

BTW, why the heck can't either AMD or Intel make a processor that doesn't give off enough heat to melt the ice caps? The Pentium III was a pretty good chip for a while, and then both camps decided to start dissapating huge amounts of heat again. I'd like to get a new processor, but I'm not going to get something that sucks down 70 watts, either, and takes a noisy fan and gets the whole case hot.

I always used to love the fact that Windows wasted so much memory and so many CPU cycles that by the time I had to get a piece of hardware for my Linux box, it was terribly cheap, driven down by commotitazation. However, it's now reached the point where people are trying to get CPU cycles even at the cost of a quiet, cool computing environment, which is not good.

Re:Let's look at what happens here if Itanium fail

[0x0d0a]

HP having good compilers? These are the same people with the *abysmal* C++ compiler, the one years behind everyone else?

Re:Wanna bet?

[afidel]

Sorry, but chip manufacture/design is core to what is left of IBM's hardware business. They need to be able to design things in a way that fits with the design goals of the AS400 and os/390 lineages, not to mention the SP line. I don't see any comodity CPU as offering that. Look at the top of the Supercomputer top500, IBM may not have the top spot but they have the lions share of the top 100. They also have the lions share of the fortune 100 backend operations. Now that the tech buble has burst IBM is still doing well because these large powerhouses of business did not go out of business and in fact are using their relativly strong positions to gain market share during this downturn. Many are doing that by doing more data analysis and improving customer relations, much of which is being powered by tradition backend big iron. I don't see IBM going to anyone else for CPU's unless someone else can do it both better and cheaper than they can for their needs. Right now someone may have one, possibly two of those criteria met, but no one has all three and I don't see it happening soon.

Re:Brasileiro?

[leandrod]

> Brasileiro?

Sim, yes, oui, ja, da, hai

Re:General misunderstanding on IPF (IA64) pureness

[0x0d0a]

many people who know more about this issue than me consider it to be too complex and full of bad trade-offs

And those people that know more than you know more than the highly-paid, best of the best cabal of chip engineers at Intel?

Re:General misunderstanding on IPF (IA64) pureness

[leandrod]

> those people that know more than you know more than the highly-paid, best of the best cabal of chip engineers at Intel?

What does being highly-paid tells, except that the employee happen to make his employer feel his indispensable?

"Chip engineers at Intel" were never "best of the best cabal". This were Digital Alpha, HP PA-RISC - most of them left already in the DEC and HP organizational culture debacle to join, among others, AMD -, IBM Power and assorted others.

Re:Let's look at what happens here if Itanium fail

[roca]

I was referring specifically to Itanium.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion

'Single pression FP'

[Cato]

Just wanted you to know that 'pression' is a draft beer in France - good to work some alcohol in there somehow :-)

Re:Let's look at what happens here if Itanium fail

[Shimbo]

HP having good compilers? These are the same people with the *abysmal* C++ compiler, the one years behind everyone else?

Thay have Compaq's compiler people too (or had actually). A lot of the folks who used to write the backend code for Alphas have gone to Intel to do the equivalent on the Itanium.

Re:Thats because...

[vidarh]

Linux already runs on several 64bit platforms, including IA 64, so that argument is bullshit.

Re:General misunderstanding on IPF (IA64) pureness

[Espen Skoglund]

You don't really have any idea of what you're talking about, do you? My experience shows that context switching between two threads is at least four times more expensive on a Pentium4 (and that's before trying to optimize the Itanium context switching code). Then there is the added benefit of having tagged TLBs on the IA-64, which removes the major performance hit when switching between address spaces/tasks on a Pentium based system.

Next, context switching from user-level to kernel-level seems to be way more inexpensive on an Itanium system compared to a Pentium 4 system. Basically, if one uses the Enter Privilege Code (EPC) instruction for doing system calls (no, Linux doesn't do this yet), there's no need to do anything exception/interruption like for entering/exiting kernel mode. This basically means that we avoid any pipeline stalls and flushes---the processor simply continues running with kernel priviliges.

If one enter the kernel due to an exception or interruption there will, however, be a bit more state which needs to be saved and restored. The large registers sets of the architecture pose almost no additional overhead here, though. The floating point registers need in general not be saved and restored on exceptions, and the register stack engine (RSE) ensures that most general purpose registers can be saved and restored lazily if needed.

In short, you seem to have no idea of what you're talking about, something which is clearly proved by your claim that running desktop environments incur a high number of context switches.

bah. Child's play . . .

[hawk]

>32bit on 32bit is fine, 64bit on 64bit is fine,
>64bit on 32bit sucks, 32bit on 16bit sucks, etc

Trivialities.

Now, 18-22 bit address spaces for 8080's and 6502's, *that* was impressive :)

hawk

no, no.

[hawk]

It's Bill Gates and RMS that are the same person. Haven't you noticed that "they" never appearin publc together? hmm?

:)

hawk

Re:General misunderstanding on IPF (IA64) pureness

[leandrod]

> context switching between two threads is at least four times more expensive on a Pentium4 (and that's before trying to optimize the Itanium context switching code)

Interesting, thanks for the info! Do you have any idea about how this aspect of IPF compares to typical RISC systems, like Sun SPARC III and IBM POWER64?

Re: What has the 4Gb limit?

[Ben Hutchings]

Some Intel processors use 36-bit physical addresses. Virtual addresses remain 32-bit, of course, so each process is still limited to something under 4 GB. The kernel has to fiddle with its own page table to address the whole of physical memory. This is the HIGHMEM kluge that Linus was talking about.

Re:Let's look at what happens here if Itanium fail

[sl3xd]

I think he meant go 32-way with a system that uses x86 processors, and is fully x86 compatible.

I know there are systems that are more than 32-way using x86 processors -- but they aren't x86 compatible at all.

Routing for Intel for once

[bill_mcgonigle]

Perhaps if ia64 succeeds, "developers" will actually learn what a cross-compiler is, and then maybe, just maybe, will figure out that it's not so hard to cross compile to other CPU architectures as well.

The blinders might come off and it might even spark some competition in the marketplace.

We can thusly be assured that x86-64 is the way of the future.

Re:General misunderstanding on IPF (IA64) pureness

[Espen Skoglund]

No, sorry. I haven't worked with these systems, so I can not really tell how well/bad they perform in this context.