TR Forums

I think the following question is a bit moot because I believe ARM will be the dominant CPU architecture of the future, not x86. But for the CPU architecture nerds in the audience, here is my purely intellectual question: From a strictly architectural / technical aspect (not involving Intel's licensing finagling and politics), would we have been better off if IA64 had become the dominant architecture versus the now ubiquitous x86-64? Why? Outside of the server environment, how would IA64 be superior or inferior? Discuss.

This question stays with me, and I wish I could answer it!

I thought the idea of IA64 was amazing- and we've seen VLIW work well in a number of other situations, including current AMD graphics cards. Really, I think Intel is keeping it alive for the day when Windows (or it's equivalent, from Microsoft or other) will run on just about anything. Then they just have to re-introduce it at lower levels.

To compare with x86, though, I really have no idea. x86 has exceeded my expectations and continues to do so unabated, so, I think a better argument would be to ask 'how does x86 compare to ARM, thermal envelopes, die sizes and transistor counts remaining the same?' I think then we'd have an idea of where to start.

Itanium2 workstations from HP are really cheap on eBay these days. I've always wanted something like a zx6000 or zx2600.

There's a problem with the VLIW approach though - namely it still wouldn't be able to scale down to compete with ARM because changing the number of execution units in a VLIW design necessitates a recompile of everything out there for acceptable performance. Scaling up would also be a bit hard - Intel just recently doubled the execution unit count from 6 to 12 on Poulson - and already everybody's wondering if enough people will care to recompile everything.

You certainly wouldn't want to buy a different version of Windows specifically compiled to maximize performance on Poulson. Closed source programs also would be less ubiquituous if IA64 would be the standard, since every variant of IA64 would need its own compiled version.

If Gentoo Linux were the standard OS of the world, I doubt anybody would notice a difference switching between x86 and IA64 though.

Well one of the big issues is software compatability, if they had gone with IA64 it would have caused serious issues for years. IA64 could run x86 software, but very slowly, along with there just being the server OS for it. Then the whole issue of drivers for hardware would have been a huge labor getting hardware to run in it. Adding to that would be IT professionals having to support 2 totally different and incompatable standards...not a good thing to deal with. Then on top of that, it would have taken many years for the change to filter down where everyone was on the new standard.

When you look at how long standards hang around, ISA slots were still floating around 15 years after they were introduced, PCI slots have nearly been around longer than that. PS/2 ports as old as they are, they still show up on boards. Total and complete change is not easy for the common man...Windows XP is still floating around 10 years later, that would be pretty much the same as still running DOS as your main OS when Windows 98 was out. Change takes a long time in hardware, and adding to the fact that it takes a long time to set up a new standard. That's why I don't see ARM dominating like everyone seems to think it will. What IT professional is going to want to beta test a completely new hardware that has no proven track record. On top of that, it being completely incompatable with the current hardware your responsible for.

I think the more interesting question is the one you set aside: why do you think ARM will become dominant over x86? (I could theorize my own list, but I'd be curious to hear someone else's.)

But, since I feel like I should weigh in on your question before substituting my own: I don't think life would be materially different had Itanium swept the personal computer space, but I also think there are technical reasons why it wasn't in the cards. Fundamentally, performance only matters so much, and a good compiler could make Itanium perform relatively well, IPC-wise. Higher clocks would have definitely helped too. That said, it is really, really hard to beat out-of-order superscalars on control-heavy, "irregular" code... which just so happens to be a large part of what most people run on a day to day basis. It would be a tough sell to the end user to say, "Sure your browser is 50% slower, but you can get 99.6% efficiency on a dense matrix multiply!"

Let me re-phrase the question. Disregarding all compatibility issues, recompile issues, etc. what would IA64 afford us that x86-64 doesn't? To be honest, x86-64 has been in a word, underwhelming, to me. Yes, it adds the ability to address larger amounts of memory and hard drive space, but beyond that my 64-bit CPU has just been another CPU. Beyond the addressing issue, I haven't found any real world examples where x86-64 has improved my computing experience. Would IA64 have given us anything that x86-64 doesn't? Anything noticeable by a user? Greater stability? Greater self-healing? Greater security (encrypt everything)? To me, speed is still the 'thing' that improves my computing experience but that is having diminishing returns since processors are so fast nowadays. Would IA64 have been better able to utilize these insanely fast processor speeds and how?

PrecambrianRabbit wrote:

I think the more interesting question is the one you set aside: why do you think ARM will become dominant over x86? (I could theorize my own list, but I'd be curious to hear someone else's.)

I think ARM will dominate because of its open licensing model (and lack of potential political manipulations, ala Intel), developer support, energy efficiency to performance ratio, its small thermal envelope and the fact that most processors are now capable and 'good enough' to run just about any application a modern user needs. Add Microsoft getting behind the train as well as a bunch of enthusiastic developers...Intel and AMD better start worrying. So between the open licensing model, the performance the ARM chips are now capable of, and the ability for Windows to now run on it, I believe we will see the long awaited dawn of the 'commodity CPU' where no one cares 'what's inside' since they're all pretty much the same and 'good enough'.

IMHO, Itanium was a solution in search of a problem. VLIW just wasn't a very good paradigm for general-purpose computing. It was neat for the guys who invented it, but for the rest of the computing world, it was an odd curiosity, because it couldn't respond to dynamic changes in workload the way a "conventional" speculative executing CPU did. There are only so many profiling runs and compiler guesses you can make when generating code. At some point, the work load deviates, sometimes drastically, form what was predicted, and a processor that requires all its guesses to be made in adavance does not adjust well to that sort of environment -- which, incidentally, is the normal computing environment.

It did well at highly specialized tasks precisely because they were highly specialized. If you can highly optimize for a very specific problem, you're likely to do a really good job at executing the workload for that problem. But that isn't how most general purpose applications end up running.

No, we would not have been better off. x86 is sticking around partly because of inertia, yes, but also because it's "good enough". Not only good enough to get most of our work done efficiently, but good enough to hold off the competition. Sure, there are definitely better designs out there (the DEC Alpha being one of them, prematurely retired), but are they so much better that they overwhelm the negatives of changing entire platforms. No, they haven't been.

I agree with you that mobile computing may change the landscape out from under x86 without anyone noticing at first. But it won't be a frontal assault. It will be a new paradigm rising up organically and eventually gaining so much momentum that the old simply fades in comparison.

bdwilcox wrote:

Beyond the addressing issue...

But that's actually a rather significant change. Can you imagine trying to use 8GB of RAM in PAE mode, where each program could only access a maximum of 3GB or so, unless it was coded to do weird addressing tricks? That's what you'd have if the addressing issue hadn't been solved with x86-64.

To put it another way, for most general purpose programs, computers would be "stuck" at a maximum of 4GB to this day, with no real hope of going further if we didn't have x86-64.

But there have been other subtle improvements that go along with it. Improved vector processing instructions (SSEx), hardware virtualization instructions, etc. I don't think you see as much improvement on the desktop because you don't push the margins. But imagine trying to run a server with 16 virtual machines running on it without 64-bit addressing and hardware virtualization assistance.

Likewise, I think you may be taking a "grass is always greener on the other side of the hill" look at Itanium. I think you would be quite underwhelmed with it as a desktop platform as well, where you to have the opportunity to spend significant time with it as a replacement.

Buub wrote:

bdwilcox wrote:

Beyond the addressing issue...

But that's actually a rather significant change. Can you imagine trying to use 8GB of RAM in PAE mode, where each program could only access a maximum of 3GB or so, unless it was coded to do weird addressing tricks? That's what you'd have if the addressing issue hadn't been solved with x86-64.

People have been running programs using PAE mode for several years with no real problems. It is called OSX, and to this day it still uses a 32-bit kernel and PAE mode by default. The only problem with running more memory in x86 Windows is non-PAE compatible hardware/drivers. Microsoft just decided it was such a mess that only server versions of x86 Windows would be allowed access to more memory. x86 Windows normally runs in PAE mode anyway since it is required for the NX bit. So in x86 Windows you have the problems of PAE mode just without the benefits. Apple got around the problems by coming rather late to x86 and supporting a lot less hardware.

Bombadil wrote:

Buub wrote:

bdwilcox wrote:

Beyond the addressing issue...

But that's actually a rather significant change. Can you imagine trying to use 8GB of RAM in PAE mode, where each program could only access a maximum of 3GB or so, unless it was coded to do weird addressing tricks? That's what you'd have if the addressing issue hadn't been solved with x86-64.

People have been running programs using PAE mode for several years with no real problems. It is called OSX, and to this day it still uses a 32-bit kernel and PAE mode by default. The only problem with running more memory in x86 Windows is non-PAE compatible hardware/drivers. Microsoft just decided it was such a mess that only server versions of x86 Windows would be allowed access to more memory. x86 Windows normally runs in PAE mode anyway since it is required for the NX bit. So in x86 Windows you have the problems of PAE mode just without the benefits. Apple got around the problems by coming rather late to x86 and supporting a lot less hardware.

That's rather over-simplifying things. For one thing, there's a limit to how much memory can be accomodated via PAE, and it's much lower than 64-bit addressing. For another, each application still has a 32-bit limit, unless it wants to explicitly support extra memory through a clunky page-based API (not the default).

And Microsoft moved to the standard being 64-bit OS for its servers for this among many other reasons. 64-bit apps simply are much easier to write, and much less clunky (read easier to maintain, less buggy), than page-based 32-bit apps.

OSX now defaults to 64-bit mode on newer hardware. The primary issue there was first, drivers, then when driver support matured, older 32-bit EFI "BIOS'". Older hardware with 32-bit EFI won't boot a 64-bit kernel. All the newer machines will.

Bombadil wrote:

People have been running programs using PAE mode for several years with no real problems. It is called OSX, and to this day it still uses a 32-bit kernel and PAE mode by default. The only problem with running more memory in x86 Windows is non-PAE compatible hardware/drivers. Microsoft just decided it was such a mess that only server versions of x86 Windows would be allowed access to more memory. x86 Windows normally runs in PAE mode anyway since it is required for the NX bit. So in x86 Windows you have the problems of PAE mode just without the benefits. Apple got around the problems by coming rather late to x86 and supporting a lot less hardware.

That's not really correct.

While it is true that you can take advantage of >4GB on a 32-bit architecture using PAE, it is far from optimal.

Each process is still limited to 2GB (3GB in some cases) of virtual address space. Unless an application is specifically rewritten to use the PAE/AWE APIs, it cannot access memory outside its virtual address space. The lack of a flat addressing model complicates the application code considerably, and has a negative impact on performance.

I'm curious myself, but people keep failing to answer the question. You keep talking about PAE and 64-bit and whatnot - when the question really was: does IA-64, as an architecture, actually offer us something more advanced than x86*?

Too much branch prediction (was that the right word?) came up as an issue where you need specialised, predictable applications to really get good performance, but other than that, no responses so far. Instead people are talking about whether x86 is "good enough" and drivers and OSX and... good lord Cindy what is this.

Meadows wrote:

I'm curious myself, but people keep failing to answer the question. You keep talking about PAE and 64-bit and whatnot - when the question really was: does IA-64, as an architecture, actually offer us something more advanced than x86*?

Too much branch prediction (was that the right word?) came up as an issue where you need specialised, predictable applications to really get good performance, but other than that, no responses so far. Instead people are talking about whether x86 is "good enough" and drivers and OSX and... good lord Cindy what is this.

Yes, exactly. 64-bit addressing is a moot point because both x86-64 and IA64 solve the problem. I'm more interested if there is some technical benefit IA64 would have graced us with if it had become the standard rather than x86-64. Expanded addressing is about all I've seen in difference between x86 32 and 64 bit; would IA64 have given us anything on top of the addressing issue that would have made its adoption more beneficial?

bdwilcox wrote:

I think the following question is a bit moot because I believe ARM will be the dominant CPU architecture of the future, not x86. But for the CPU architecture nerds in the audience, here is my purely intellectual question: From a strictly architectural / technical aspect (not involving Intel's licensing finagling and politics), would we have been better off if IA64 had become the dominant architecture versus the now ubiquitous x86-64? Why? Outside of the server environment, how would IA64 be superior or inferior? Discuss.

This is all guesswork, ballpark, etc, derived from the IA-64 Wikipedia page:

IA64 would be extremely inferior. The main problem is that the IA-64 instruction set is inherently parallel. By that I mean that the CPU has a large number of registers, and you can load up to six instructions to be executed at the same time. Even loops can themselves be parallelized. This feat is accomplished by having the compiler do most of this work, which includes special flags with the instructions themselves. The problem lies in the fact that (by my reckoning) even the compiler can't help you that much in this case, so this requires very special care in developing your applications. It might even mean that in order to take full advantage of the six-wide execution (or whatever it's technically called), one might even have to resort to lower level languages like C for pretty much everything in order to do the most optimizations possible. It's not the same as multi-threading, because even a single computing thread must be optimized to take advantage of that six-wide execution.

In simpler terms, regular programs (even multi-threaded ones) are dog-crap slow in Itanium. In fact, I'm betting that this is one of the reasons why it didn't "stick" as much as expected, even in the server arena.

However, had by some freak accident IA64 become the standard, then the upside would be that we might nevertheless have seen the multi-core revolution (evolution really) come sooner. Even though Itanium can execute six instructions (we're not talking about cores), at least different programming habits would have been borne out of necessity, closer to those needed to make a multi-threaded application.

So I guess that I think that we'd be better off if IA64 had been more widely used at its time, had it been an evolutionary step leading to the current multicore CPUs. If by market forces or something else, we had been "forced" to use IA64 wholesale, IMO then we'd be worse off instead.

Isn't GPGPU a threat to Itanium VLIW's performance strengths?

bdwilcox wrote:

Meadows wrote:

I'm curious myself, but people keep failing to answer the question. You keep talking about PAE and 64-bit and whatnot - when the question really was: does IA-64, as an architecture, actually offer us something more advanced than x86*?

Too much branch prediction (was that the right word?) came up as an issue where you need specialised, predictable applications to really get good performance, but other than that, no responses so far. Instead people are talking about whether x86 is "good enough" and drivers and OSX and... good lord Cindy what is this.

Yes, exactly. 64-bit addressing is a moot point because both x86-64 and IA64 solve the problem. I'm more interested if there is some technical benefit IA64 would have graced us with if it had become the standard rather than x86-64. Expanded addressing is about all I've seen in difference between x86 32 and 64 bit; would IA64 have given us anything on top of the addressing issue that would have made its adoption more beneficial?

I already addressed that in general. You're right I didn't go into real deep specifics, but I didn't think that was necessary.

No, for general purpose computing, IA64 is a disadvantage over "traditional" speculative execution super-scaler processors like x86-64.

We would not have been better off with IA64. Period. IA64 does and allows some really cool things, but those things have very limited scope and they're extremely expensive to implement in silicon. IA64 has about 100 general purpose registers. For tasks where you don't need more than a few general purpose registers, that's insane. IA64 is about high reliability, running massive numbers of parallel workloads, and running massive tasks that can be compiled effectively for EPIC (Explicitly Parallel Instruction Computing)

For the record, Itanium is not VLIW. It's EPIC. Its design was influenced by VLIW and it was supposed to address some of the shortcomings of VLIW.

It is called OSX, and to this day it still uses a 32-bit kernel and PAE mode by default.

Nope, that mode by default is actually long mode with most of the kernel running in compatiblity mode, unless you are running on an old Core Duo/Solo. Yes, it is so confusing that I wrote a blog article about it:
http://yuhongbao.blogspot.com/2009/09/m ... modes.html

If intel had tried to switch its desktop architecture to Itanium, we would all be using Macs now, probably with POWERPCs (yes, apple switched from 68xx to PPC and again to x86, but the architectural changes involved were less severe and they had a much smaller developer and user base, so they were able to transition relatively well with a combination of compilers and emulators).

Also, the current generation Tukwilla IA-64 chips run at up to 185W for a 1.86 GHz quad core chip, so it's not necessarily true that shifting to VLIW will automatically bring power savings.

All other points aside (Itanium is power hungry because they have giant caches), this is fundamentally an architecture question. What goes on inside the chip has very little resemblance to what the architecture specifies. An architecture (also called an ISA) gives you the freedom to change the guts, as long as the interface is static. The real question is: is it easier to design a fast, power efficient chip using a multiple issue VLIW architecture or a single issue instruction set like x86? What limits does the architecture impose on the internals of the chip?

NOTE: modern processors are multiple issue, out of order, speculative execution devices, but this functionality is not exposed through the x86 architecture. From the point of view of the compiler, all x86 processors are a 386 with some additional instructions and more address lines.

My position is that the fewer internal resources (registers, execution units, scheduling, cache design, etc) that are exposed through the architecture, the faster and more efficent the processor and compilers will be. It always sounds like a good idea ("what if the compiler could profile and predict branches???"), but in practice the additional complexity is not well used in general purpose code. Give the compiler a simple (I know some are rolling their eyes at me for calling x86 simple) architecture to target, maintain that compatibility however you must when designing the chip, but don't tie the chip designer's hands by exposing too much of the internals. The more you expose, the less you can change when a new idea or new process node makes the previously unthinkable, now cheap and easy.

bdwilcox wrote:

To be honest, x86-64 has been in a word, underwhelming, to me. Yes, it adds the ability to address larger amounts of memory and hard drive space, but beyond that my 64-bit CPU has just been another CPU.

What did you expect? The only thing that would revolutionise desktop computers would be in the data storage field, like if decent SSDs suddenly had the capacity and price of today's HDDs. The processor isn't an enormous performance bottleneck, it hasn't been for a long time.

It's like saying that ipv6 (or whatever ends up replacing ipv4) is an underwhelming change. Eventually it becomes necessary, it's not any sort of world-changing technology upgrade.

Eventually most desktop computer apps will make good use of the extra data crunching potential of 64-bit CPUs, but it's like how the Internet has changed in the last ten years - some elements have had radical upgrades, but many aren't that different.

The biggest drawback to adoption of IA64 would be a complete slowdown in innovation. Since Intel owns the license and would likely avoid licensing the technology to anybody else, everything we've been seeing in the x86 world (innovations from AMD, like single die multicore, integrated memory controller, breakneck moves to reduced manufacturing process sizes) over the last 7-10 years would either not have happened, would have happened more slowly, or would be much more expensive. I know you stipulated you weren't interested in licensing issues, but the simple fact is, competition between Intel and AMD over x86 is the single most important component in the equation of what kind of power and features we've got in our chips. No competition = stagnant technology development cycles. Period. The very reason why IA64 has failed is because AMD moved x86 into the space IA64 was designed to occupy, and did so in such a comprehensive way that IA64's few technical advantages were greatly outweighed and rendered moot.

I also agree with those who are questioning the emerging orthodoxy that ARM's architecture will supersede x86 on the desktop/portable (laptop, netbook) and server. Anybody saying this must be unaware that AMD already has a 3 watt dual-core x86-64 fusion chip right now, and will have it down to <1 watt as soon as 22 nanometer production commences. This is an out-of-order, dual-core APU (integrated Radeon 5000-series graphics logic) x86-64 chip! Arm is going to have be quite a bit faster and better at the same power envelope if it is going to persuade people to give up x86 compatibility for the same functionality and price. If not, ARM will suffer the same fate on the laptop-desktop-server as Intel's IA64 did trying to compete with AMD's x86 technology.

anubis44 wrote:

I also agree with those who are questioning the emerging orthodoxy that ARM's architecture will supersede x86 on the desktop/portable (laptop, netbook) and server. Anybody saying this must be unaware that AMD already has a 3 watt dual-core x86-64 fusion chip right now, and will have it down to <1 watt as soon as 22 nanometer production commences. This is an out-of-order, dual-core APU (integrated Radeon 5000-series graphics logic) x86-64 chip! Arm is going to have be quite a bit faster and better at the same power envelope if it is going to persuade people to give up x86 compatibility for the same functionality and price. If not, ARM will suffer the same fate on the laptop-desktop-server as Intel's IA64 did trying to compete with AMD's x86 technology.

Yeah, IMO ARM will dominate in areas where x86 compatibility is a non-issue (pretty much anything that doesn't run desktop/server versions of Windows). But on any platform where being able to run generic Windows apps is a desirable trait, x86 will likely continue to be the platform of choice for quite some time.

just brew it! wrote:

Yeah, IMO ARM will dominate in areas where x86 compatibility is a non-issue (pretty much anything that doesn't run desktop/server versions of Windows). But on any platform where being able to run generic Windows apps is a desirable trait, x86 will likely continue to be the platform of choice for quite some time.

ARM already does dominate the CPU world. There have been 15 billion ARM cpus fabbed. I don't have the numbers handy but I think Intel crossed the 3 billion mark not to long ago. That's not a really accurate picture of the market since intel's margins are so much higher but the fact remains ARM is everywhere. You PC itself likely includes at least one or 2 ARM cores, in your hard disk or network controller.

People are always complaining about the cruft of x86 but ARM has its own problems. Over the years there have been many versions of the ARM instruction set and different products implemented different portions of the standard. Even modern ARM cores like A9 have optional portions (the NEON SMID unit being an example that springs to mind). ARM also has 2 execution modes, ARM 32 bit and Thumb-2. Some ARM cores only execute Thumb-2, others do both. In many ways targeting a generic arm core is even more challenging than x86. With x86 you can at least compile for i386 and be sure it will run flawlessly and reasonably fast on everything made in the last 20 years. Intel and AMD both spend a lot of transistors, power and time making sure existing code runs well and taking advantage of the bulk of newly available performance doesn't require a recompile. No such luck with ARM when they roll out a new version of the ISA every 5 or 10 years.

Don't get me wrong; I love ARM cpus and the devices they power. I'm just not so sure ARM is in any way ready to be the cpu you pickup at the local computer shop and drop into your system to improve performance. ARM drives are not like the x86 world, you can't just go to the manufacturer website and get the newest version. Every SoC family uses different combinations of GPU, image processor, video encoder/decoder and so on. Since the drivers are not just available you're at the mercy of the OS maker to have support for your particular device. On top of that, every ARM SoC uses a slightly different and incompatible booting mechanism, which makes a generic OS image troubling at best.

Yea, PowerPC had CHRP to solve this problem.

mikeymike wrote:

What did you expect? The only thing that would revolutionise desktop computers would be in the data storage field, like if decent SSDs suddenly had the capacity and price of today's HDDs. The processor isn't an enormous performance bottleneck, it hasn't been for a long time.

This doesn't really speak to the question when you consider that EPIC was under development from 1989 forward, and the first Itanium processor was launched in the middle of 2001. For most of this time, x86 processors as we know them now did not exist. The original Pentium (P5) was released in early 1993 and the x86 GHz race only began around 2000 or so, at which point the first commercial Itanium processor was in its final development stages and the backend infrastructure (chipsets, compilers, etc.) were pretty much finalized. At the time, and especially before the GHz race, it really did look like a viable candidate for the next mainstream architecture.

anubis44 wrote:

also agree with those who are questioning the emerging orthodoxy that ARM's architecture will supersede x86 on the desktop/portable (laptop, netbook) and server. Anybody saying this must be unaware that AMD already has a 3 watt dual-core x86-64 fusion chip right now, and will have it down to <1 watt as soon as 22 nanometer production commences. This is an out-of-order, dual-core APU (integrated Radeon 5000-series graphics logic) x86-64 chip! Arm is going to have be quite a bit faster and better at the same power envelope if it is going to persuade people to give up x86 compatibility for the same functionality and price. If not, ARM will suffer the same fate on the laptop-desktop-server as Intel's IA64 did trying to compete with AMD's x86 technology

Everyone seems to forget that ARM used to be on the desktop, that it was originally designed to be on the desktop. You're right to question the orthodoxy.

ARM dominates the embedded market, but why people think that means they have some destiny to dominate the world is beyond me. Meanwhile, x86 has been pushing both ends of envelope. It isn't just beginning to delve into the embedded space, it's pushing upwards the higher-end server space these days. x86 is on the march towards ubiquity, not ARM.