Chip Designers Recall the Big AMD-Intel Battle Over x86-64 Support (tomshardware.com) 47
Tom's Hardware reports on some interesting hardware history being shared on X.com:
AMD engineer Phil Park identified a curious nugget of PC architectural history from, of all places, a year-old Quora answer posted by former Intel engineer [and Pentium Pro architect] Robert Colwell. The nugget indicates that Intel could have beaten AMD to the x86-64 punch if the former wasn't dead-set on the x64-only Itanium line of CPUs.
Colwell had responded on Quora to the question "Shouldn't Intel with its vast resources have been able to develop both architectures?" This was a marketing decision by Intel — they believed, probably rightly, that bringing out a new 64-bit feature in the x86 would be perceived as betting against their own native-64-bit Itanium, and might well severely damage Itanium's chances. I was told, not once, but twice, that if I "didn't stop yammering about the need to go 64-bits in x86 I'd be fired on the spot" and was directly ordered to take out that 64-bit stuff. I decided to split the difference, by leaving in the gates but fusing off the functionality. That way, if I was right about Itanium and what AMD would do, Intel could very quickly get back in the game with x86. As far as I'm concerned, that's exactly what did happen.
Phil Park continued the discussion on X.com. "He didn't quite get what he wanted, but he got close since they had x86-64 support in subsequent products when Intel made their comeback." (So, Park posted later in the thread, "I think he won the long game.")
Park also shared a post from Nicholas Wilt (NVIDIA CUDA designer who earlier did GPU computing work at Microsoft and built the prototype for Windows Desktop Manager): I have an x86-64 story of my own. I pressed a friend at AMD to develop an alternative to Itanium. "For all the talk about Wintel," I told him, "these companies bear no love for one another. If you guys developed a 64-bit extension of x86, Microsoft would support it...."
Interesting coda: When it became clear that x86-64 was beating Itanium in the market, Intel reportedly petitioned Microsoft to change the architecture and Microsoft told Intel to pound sand.
Colwell had responded on Quora to the question "Shouldn't Intel with its vast resources have been able to develop both architectures?" This was a marketing decision by Intel — they believed, probably rightly, that bringing out a new 64-bit feature in the x86 would be perceived as betting against their own native-64-bit Itanium, and might well severely damage Itanium's chances. I was told, not once, but twice, that if I "didn't stop yammering about the need to go 64-bits in x86 I'd be fired on the spot" and was directly ordered to take out that 64-bit stuff. I decided to split the difference, by leaving in the gates but fusing off the functionality. That way, if I was right about Itanium and what AMD would do, Intel could very quickly get back in the game with x86. As far as I'm concerned, that's exactly what did happen.
Phil Park continued the discussion on X.com. "He didn't quite get what he wanted, but he got close since they had x86-64 support in subsequent products when Intel made their comeback." (So, Park posted later in the thread, "I think he won the long game.")
Park also shared a post from Nicholas Wilt (NVIDIA CUDA designer who earlier did GPU computing work at Microsoft and built the prototype for Windows Desktop Manager): I have an x86-64 story of my own. I pressed a friend at AMD to develop an alternative to Itanium. "For all the talk about Wintel," I told him, "these companies bear no love for one another. If you guys developed a 64-bit extension of x86, Microsoft would support it...."
Interesting coda: When it became clear that x86-64 was beating Itanium in the market, Intel reportedly petitioned Microsoft to change the architecture and Microsoft told Intel to pound sand.
Nobody looked good after all was said and done (Score:4, Insightful)
N/T
Re: (Score:1)
You're saying AMD looked bad in this situation?
ia64 was the gold-plated toilet no one wanted (Score:2)
Re: (Score:2)
For servers, yes but I don't ever recall seeing Itanium in a laptop.
Intel really only got serious when Jobs asked for a 64bit roadmap out of the Pentium M mobile architecture after IBM stalled on a PowerPC G5 laptop.
Re: (Score:2)
Intel tried to own the processor market by fiat (Score:5, Interesting)
But failed to control the entirety of the stack.
It is telling that Intel, even that early (along with HP), was trying to leverage their assumed dominance to dictate standards, even when their customers wanted something different. Is it any surprise that in the face of that attitude, mobile abandoned intel to adopt ARM, as did Apple, specifically over power consumption?
Re:Intel tried to own the processor market by fiat (Score:5, Interesting)
HP had the alpha too the fastest RISC processor in the world and far easier and cheaper to make for the far more expensive and inferior and overclocked/hot and terrible to write for Itanium. Intel was too scary.
Again this shows politics wins not actual competence. I am greatful we have AMD. I shudder to think if IA64 won out if AMD did not exist or we would still be using 32 bit x86 with 4 gigs of ram to this day and be back to 2014 performance levels still.
Re:Intel tried to own the processor market by fiat (Score:4, Informative)
Do you mean PA-RISC? Alpha was always a DEC product.
Re:Intel tried to own the processor market by fiat (Score:5, Informative)
Yes, but weird enough, there was a time when HP sold and supported Alpha machines but they didn't own the intellectual property -- which had already been sold by Compaq to Intel before HP had bought Compaq.
Re: (Score:3)
HP bought compaq which bought DEC and they inherited the Alpha. HP killed it to appease Intel and promote Itanium instead.
Re: (Score:2)
Alpha wasn't far easier to make and was very difficult to scale since a lot of its design was done by hand (hence the speed) and as the CPUs grew in complexity, that was not feasible anymore.
Re: (Score:2)
Re: (Score:2)
Not the bus system, but the bus protocol - my guess is, since some of the former DEC engineers ended up at AMD, they simply used what they knew best. And it was only for a few years, just for the 32 bit K7 architecture.
Re: (Score:2)
Re: (Score:2)
As I said, EV6 has been replaced after a very short time - merely 5 years. Hypertransport has lasted three times longer and its successor is based on it.
Re: (Score:3)
Again this shows politics wins not actual competence.
I'd argue the opposite.
Itanium was the hot new thing. It implemented all the latest theories on the future of chip design. People were excited about it because they expected it to be great. No one knew it would suck until there was actual chips in use. Once it became clear that it was bad, people ran away from it fast.
Re:Intel tried to own the processor market by fiat (Score:4, Informative)
Everyone knew it would suck because it required hand-tuned assembly to perform well. Compilers suck at optimising for VLIW architectures. On top of that, the Itanium didn't reorder instructions, which means you needed to re-optimise your applications for each successive microarchitecture if you wanted to keep the execution units busy. Intel promised that JIT compilers were going to make everything rosy, and all your applications would be running on .NET or Java. But the trouble is, JIT compilers are even worse for architectures that require crazy optimisation because it has to be done on-the-fly. You can't make a chip that depends on some magical compiler technology being right around the corner.
Re: (Score:2)
Moving optimizations to software was a dumb no brainer. Hardware acceleration is obviously supperior.
Re: (Score:2)
Intel had one team designing Itanium at the same time as another team was designing the Pentium Pro.
The Pentium Pro tried to improve performance by reordering instructions in the CPU at runtime. While this is cheap to do in hardware now, it required a ton of extra silicon at the time and made the chips very expensive to make.
The Itanium tried to improve things by relying more on the software side, hoping a simpler chip design and better software would be ideal.
At the time, it wasn't at all clear which appro
Re: (Score:2)
Even at the time, it was pretty clear which would win in the long run. It's not like VLIW and explicitly parallel instruction sets hadn't been tried before. The AT&T DSP16 is an early example of an explicitly parallel instruction set - you can simultaneously issue a multiply, an addition, a ROM access, a RAM access and two address updates. Intel had the i860 VLIW processor which was only really successful as a DSP running fixed workloads (e.g. the accelerators on the TrueVision Targa/Vista, SGI Reali
Re: (Score:2)
Kinda cool (Score:2)
to see confirmation of what once seemed mythical, in that there was always the rumours being spouted. You know, 640 KB is more than enough. ;)
Re: (Score:2)
For a processor able to access only 1 MiB of address space (some of it which had to be reserved for memory-mapped devices like video cards), 640 kiB memory was indeed more than enough.
Re: (Score:3)
A whole lot of developer tools settled on "x64" to both shorten things and to avoid the politics of siding with a CPU maker.
If you want to target a 64 bit x64 platform in Visual Studio, the build target is "x64".
Re: What is "x64 Itanium" ? (Score:5, Interesting)
With the .Net architecture the underlying hardware is less important.
But I can imagine that the management of Intel had a wtf moment when AMD dropped their x64 processor and even more so when Microsoft told them off.
Unfortunately Intel lost their momentum again so the 2010's didn't see much performance increase.
The PA-Risc was 64 bit already in the 1990s but the pricing and marketing was server/workstation and not consumer. It could have been fun if HP actually had made a home computer based on that, but it was the wrong era.
Re: (Score:2)
With the .Net architecture the underlying hardware is less important.
Show me a physical .Net CPU. Until then a real CPU still has to translate and execute .Net code. So if anything it makes the underlying hardware more important due to the additional overhead.
Unfortunately Intel lost their momentum again so the 2010's didn't see much performance increase.
Hard to claim momentum when your competitors have the same underlying problem: Materials.
Pretty much all of the advances in CPU hardware since then have been tweaks around the edges due to the things getting too hot to operate any faster. (At least without substantial cooling systems that are impractical for consume
Re: (Score:2)
The worst of the speculative execution bugs date back to the 90s and the Pentium Pro. They weren't even really mistakes at the time. Turns out that adding multiple cores to the mix made some prior decisions become problematic. Things like the exact order of memory accesses didn't really matter when you could only run one task at a time, but with multiple cores and threads per core, it becomes problematic.
Re: (Score:2)
Eh, .NET in the real world is mostly done via ahead of time compiling to the target architecture. And it's becoming increasingly more common to do that by converting the .NET code to C++ and then compiling that. .NET's nice in that C# is often nicer to work in the C++, but the underlying runtime hasn't really changed anything.
MS did not love it (Score:5, Informative)
I was part of the team at SUSE that AMD hired to do the Linux port to x86-64. They (the AMD guys we worked with) told us that they did reach out to Microsoft, but was basically told to go away.
What they didn't answer was whether AMD would have hired SUSE to do this, if MS had done the port.
But it did turn out very well. We had a complete, native port for the chip when they got the first prototypes of the chip, and it just worked right away. They were ecstatic :)
Re: (Score:1)
AMD asked M$ to port the Linux kernel to run on AMD64 native? Early 2000s ... lets see ... SCO vs IBM ... red cape to bull ... M$ must have nearly exploded in a fit of indignant rage!
Re: (Score:2)
Re: (Score:1)
Sique, you are completely correct. Sorry if that wasn't clear.
Somewhat confusing... (Score:2)
To recap: Intel's focus on Itanium over x86-64 was a strategic decision that ultimately backfired. AMD capitalized on this by developing and documenting their 64-bit extension for x86, which quickly gained industry support. Intel, meanwhile, was reportedly working on "Yamhill," a secret pr
mistake in the summary (Score:4, Informative)
"x64-only Itanium line" - NO! That was called IA64. It had nothing to do with x86, relied heavily on compiler optimization for decent performance, and was to provide compatibility to x86 using emulation only.
I do recall an early IA64 system with a Linux distro (probably RedHat) on there, it was godawfully slow compared to the x86 systems we were used to, let alone Alpha systems. Much of that slowness was probably due to suboptimal optimizations, but still... I'm not unhappy I never saw another IA64 system, and curse the decision to discontinue Alpha in favor of Itanic.Then again, some of those former DEC engineers working on Alpha ended up with AMD and created x86-64.
No (Score:2)
Intel could not have beaten AMD to the x86-64 punch. The Mr. Colwell comment indicates (when read between the lines) that he used the AMD's x86-64 specification, which predates the real products by quite a bit. Making something compatible to your competitor's blueprints doesn't make you first in the game.
Of course, AMD arguably understood back then that gaslighting Intel to support x86-64 was in AMD's best interest.
Re: (Score:2)
It doesn't seem like you know what gaslighting is. It doesn't mean outmaneuvering someone, which is what AMD did. They didn't have to tell Intel any lies, only the truth was required: The new instruction set was immediately popular and Intel had the choice to either compete with it or follow AMD's lead.
Re: No (Score:2)
I mean, even with its popularity, the success of AMD64 was not yet guaranteed without Intel on board. For most users, 32-bit was enough. 64-bit was mainly needed in the server space, and Intel had a strong presence there. Intel could chose to fight, and force its loyal partners to use Itanium. Last but not least, back then Itanium still had a chance of fulfilling its promises and succeeding. I used "gaslighting" instead of "convincing" or "nudging", which use was indeed incorrect, but the point stands. AMD
Re: (Score:2)
even with its popularity, the success of AMD64 was not yet guaranteed without Intel on board.
Linux and Windows supported it. Intel could get on board or watch the boat leave.
Last but not least, back then Itanium still had a chance of fulfilling its promises and succeeding.
It was obvious from very early on that it would not. Intel needed to have a compiler that at least delivered decent performance ready when the system shipped. They did not, and one never materialized. It was always hopelessly slow for abusively large amounts of money. The only people who might have an excuse for buying an Itanic system, and I mean only, were the ones who needed an upgrade path from something running DEC UNIX or
Re: No (Score:2)
Okay, let's close this discussion. I only want to ask, what were the problems with K6? It had floating point and MMX (if little slow), and IMHO it had decent compatibility with the basic instruction set. I used K6 back then, and I can't remember having any serious trouble with it. Did you mean Cyrix 6x86, by chance?
Re: (Score:2)
Okay, let's close this discussion. I only want to ask, what were the problems with K6?
You had to run K6 specific patches for a lot of software (mostly games) as a result of IIRC a FP issue, not enough precision or something. This was a bad problem to have because FP had become very important recently and Intel was doing very well at retiring lots of flops. It was fixed in later models (I believe the K6/2 solved it) but the original needed a lot of compatibility patches. I had K6, K6/2, and K6/3+ machines. I did also have a Cyrix chip briefly, that was slower and also required patches, but di
Re: (Score:2)
No, but intel could have made an x86-64 spec of their own had they chosen to, and had it come out first it's likely it would have been adopted and amd would have implemented it themselves later.
IA64, too bad (Score:2)
I think if IA64 "won", we would be in a better place now, but people always want to buy on the cheap. Ignoring quality all the time.
x86 vs x86-64 (Score:2)
Depending on your actual program, the x86-64 code can be up to 10% larger. It is (and it was not) a slam dunk victory for the 64 bits extension for x86.
The 64 bits extension has many advantages in many other metrics, but code size is not one of them.
(but Intel was originally a memory company, so code that uses more memory should have been a wake up call of their legacy roots)
Intel & AMD cooperation (Score:1)
This time around Intel and AMD are going to work together. Is this old news to Slashdot (Oct 15)?
https://www.tomshardware.com/p... [tomshardware.com]