If AMD never introduced 64-bit instruction set . . .

[pyjujiop]

The question being about the AMD64 instruction set, and not K8 as a whole...

Sometime after Core2 Intel would have developed a consumer oriented Itanium

And it would have been such a colossal POS that we'd all be running computers based on ARM or PowerPC now. And in any case, Core2 would have never existed in the form that it did without AMD64 being developed.

If AMD hadn't succeeded in getting x86-64 adopted, Intel would have rested on its laurels and probably just kept churning out faster, hotter and more inefficient Pentium 4's for as long as they could. Tejas never gets killed in this alternate universe. They only transitioned Dothan to the desktop because they had to, in order to compete with the A64.

 

[lamedude]

Would MS care enough about IA64 being a POS to port Windows to ARM or PowerPC and write a x86 emulator for it? I doubt Freescale could make a CPU that would significantly faster for MS to bother, not sure if IBM would be interested, and I doubt anyone would make a desktop ARM/MIPS CPU unless MS was on board. X86 would probably still be alive though since most desktop programs don't need 4+GB and PAE would let the OS use 64GBs. If MS wanted to stay in the server and workstation market they might be forced to though.

 

[ShintaiDK]

If people would look beyond their hate or love to certain companies. They would know that x64 is an utter disaster. While its debatable if IA64 was the right path for the future. It is certainly better.

x64 basicly extends our legacy hell by another 20-30 years. While x64 looks nice from a very shortterm prospective. its already showing its ugly head with its limitations and shortplanned design strategies.

One of the main benefits of IA64 is that you can expand the width of the CPus. FOr example as of now IA64 can go to 11 issue wide cores. While we are at 4 issue wide with x86/x64. And the last jump from 3 to 4 issue wide is marginal at best. This got a huge impact on singlethreaded performance. And ofcourse multithreaded too. But singlethreaded is and will be the most important factor. You simply cant multithread everything. And even if you do, you quickly get dimmishing returns by the amount of serial code. May I refer to Amdahls law on the subject.

Another issue is the scheduling. On IA64 you can use basicly as much compile time as you wish to superoptimize the instructionqueues for the CPU. While on x86/x64 you got a realtime scheduler that by design only can guess so well in realtime. Another issue is the powerbudget for the chipdesign. The scheduler is a very heavy burden there.

Its kinda hillarious that you can boot up your Ivy Bridge or Bulldozer and still run 8bit code. And you will continue so in all the time of x64. Waste....

While we can debate if IA64 is the right path or if something else is needed. Then there is a few certain factors tho. Its not ARM and its not MIPS. People that even believe ARM can compete with x86 needs a realitycheck.

MS mainly went by x64 for selfpreservation issues. It was directly compatible with the old x86 that MS sits 100% on. A new architecture like IA64 or something else would open a huge riskfactor for MS. Suddenly you didnt NEED Windows for a new beginning.

This is another example on where capitalism fails. When we got a thightly locked ecosystem like Microsoft with Intel/AMD. Nobody dares to take any risks at stay with stagnant, but backwards compatible technologies.

 

[Fox5]

If people would look beyond their hate or love to certain companies. They would know that x64 is an utter disaster. While its debatable if IA64 was the right path for the future. It is certainly better.

x64 basicly extends our legacy hell by another 20-30 years. While x64 looks nice from a very shortterm prospective. its already showing its ugly head with its limitations and shortplanned design strategies.

One of the main benefits of IA64 is that you can expand the width of the CPus. FOr example as of now IA64 can go to 11 issue wide cores. While we are at 4 issue wide with x86/x64. And the last jump from 3 to 4 issue wide is marginal at best. This got a huge impact on singlethreaded performance. And ofcourse multithreaded too. But singlethreaded is and will be the most important factor. You simply cant multithread everything. And even if you do, you quickly get dimmishing returns by the amount of serial code. May I refer to Amdahls law on the subject.

Another issue is the scheduling. On IA64 you can use basicly as much compile time as you wish to superoptimize the instructionqueues for the CPU. While on x86/x64 you got a realtime scheduler that by design only can guess so well in realtime. Another issue is the powerbudget for the chipdesign. The scheduler is a very heavy burden there.

Its kinda hillarious that you can boot up your Ivy Bridge or Bulldozer and still run 8bit code. And you will continue so in all the time of x64. Waste....

While we can debate if IA64 is the right path or if something else is needed. Then there is a few certain factors tho. Its not ARM and its not MIPS. People that even believe ARM can compete with x86 needs a realitycheck.

MS mainly went by x64 for selfpreservation issues. It was directly compatible with the old x86 that MS sits 100% on. A new architecture like IA64 or something else would open a huge riskfactor for MS. Suddenly you didnt NEED Windows for a new beginning.

This is another example on where capitalism fails. When we got a thightly locked ecosystem like Microsoft with Intel/AMD. Nobody dares to take any risks at stay with stagnant, but backwards compatible technologies.

X64 isn't all that bad.
Itanium gets away with ultra wide cores (and extensive compiler time optimizations) because its ISA was designed around that. Outside of Itanium, there aren't many general purpose architectures wider than the current x64 architectures. I don't think any ARM variants are as wide, and most PowerPC variants aren't.
The only visible penalty of x64/x86 at this point is that it basically requires an OOE chip to get good performance...except Atom somewhat proves that wrong. Atom isn't a fast chip, but it gets per clock performance on par with the Pentium 4, and it is at least competitive with the in-order ARM, MIPS, and PowerPC architectures.

You also can't ignore results....per core, x64 cpus are some of the fastest out there (if not the fastest), and Intel (and previously AMD) are quickly engineering in the advantages of other architectures. (mainly, multicore scaling)

 

[N4g4rok]

Its kinda hillarious that you can boot up your Ivy Bridge or Bulldozer and still run 8bit code. And you will continue so in all the time of x64. Waste....

I can't really say i agree. Proper legacy support is the only way the industry moves forward. You've never had a lot of luck with brand new technologies that force the old stuff off a cliff. Those eight bit instructions have no reason to be passed through a 64bit capable MMU as a full 32 or 64 bit address reference. The issue is locality. The OS is going to occupy the earliest parts of memory, and seeing as for most of startup time, it's going to be the only thing making changed to chache an main memory, and at a small scope at that. YOu could make the argument that 8bit instructions of a 64bit machine is a waste, becasue technically, for that picosecond, it is. But without the capability to run instruction smaller than what the platform supports, no one would have had any notion to adopt further.

One of the main benefits of IA64 is that you can expand the width of the CPus. FOr example as of now IA64 can go to 11 issue wide cores. While we are at 4 issue wide with x86/x64. And the last jump from 3 to 4 issue wide is marginal at best.

While eleven issue wide cores would be great for a small group of people, i feel like you would run into the exact same issue here. Better hardware, for some reason, has not immediately inspired better code. We can continue to throw more cores at the problem, but it won't improve performance by a margin greater than what we see today with 4 issue wide CPUs. Single threaded and multithreaded performance could increase, but if it were to be met with the same apathy modern systems are, it would be an expensive chip with a terrible performance/watt ratio. I don't know too much about the IA-64 architechture specifically, but a few minutes looking at its architecture diagrams just seem to point to a lot of problems that were never discovered because it was unpopularized.

This is another example on where capitalism fails. When we got a thightly locked ecosystem like Microsoft with Intel/AMD. Nobody dares to take any risks at stay with stagnant, but backwards compatible technologies.

True, but taking such risks in an emerging market (And one that changes so quickly that it can always be considered emerging) could sink companies left and right. THe business focused on customer support, data throughput, and reliability. Playing with technologies that leave legacy to the dogs throws out all three of those.

 

[ShintaiDK]

You also can't ignore results....per core, x64 cpus are some of the fastest out there (if not the fastest), and Intel (and previously AMD) are quickly engineering in the advantages of other architectures. (mainly, multicore scaling)

Thats simply an R&D issue. Use the same budget and processnode for IA64. And remove the RRAS features for bigtin that x64/x86 still only can dream about. And you see a whole new case.

 

[Cerb]

One of the main benefits of IA64 is that you can expand the width of the CPus. FOr example as of now IA64 can go to 11 issue wide cores. While we are at 4 issue wide with x86/x64. And the last jump from 3 to 4 issue wide is marginal at best. This got a huge impact on singlethreaded performance. And ofcourse multithreaded too. But singlethreaded is and will be the most important factor. You simply cant multithread everything. And even if you do, you quickly get dimmishing returns by the amount of serial code. May I refer to Amdahls law on the subject.

IA64 does in no way get around Amdahl's Law, though. x86 now has every bit as wide issue per thread as IA64. Itanium CPUs have wider issue per core, because they need it more, and they won't be reaching high clock speeds.

Another issue is the scheduling. On IA64 you can use basicly as much compile time as you wish to superoptimize the instructionqueues for the CPU. While on x86/x64 you got a realtime scheduler that by design only can guess so well in realtime. Another issue is the powerbudget for the chipdesign. The scheduler is a very heavy burden there.

No, x86 can use as much compile time as you wish to superoptimize the instructions for the CPU. When it matters, it is done, and works well, too. x86 CPUs hen also have a real-time dynamic scheduler, that will generally kick any in-order CPU's ass. Yeah, it gets big (but RISCs can do it smaller), yeah it gets hot (but RISCs can do it cooler), but it works well. Nothing has been able to make up for good hardware scheduling since the 60s, despite all the PHDhours put into making software do that work.

Its kinda hillarious that you can boot up your Ivy Bridge or Bulldozer and still run 8bit code. And you will continue so in all the time of x64. Waste....

It's not hilarious at all. Not everyone has source code and programmers handy. The company that made the software may not even exist. Replacing it may cost what they make in yearly revenue. RISC Unix was a small world back then, and it's a small world today. x86-64 making a clean break at 32-bit was a good one, and even that caused many programs to not run. Existing binaries matter to people that use computers as tools.

This is another example on where capitalism fails. When we got a thightly locked ecosystem like Microsoft with Intel/AMD. Nobody dares to take any risks at stay with stagnant, but backwards compatible technologies.

No, the market succeeded in doing the right thing. Even the P4 Xeons could beat Itanium, back in the early 2000s. x86 was, and still is, a superior ISA with a good overall HW/SW platform, despite all its apparent ugliness. x86 will likely not be the ruler of the mass market forever, but it has survived as such by being good enough, where competitors have been in some major way worse.

Thats simply an R&D issue. Use the same budget and processnode for IA64. And remove the RRAS features for bigtin that x64/x86 still only can dream about. And you see a whole new case.

No, I see PTBs that still want to use their old software systems. There's no RAS that Itanium has that anyone writing new software today needs. All the essential RAS features have made their way into Xeons and Xeon chipsets. Cheaper desktop x86 outperforms all comers, today, still.

Any ISA that may threaten x86 will exhibit the useful properties of x86, which will include hardware instruction scheduling, backward compatibility (even if implemented as forward-compatibility), and good old superscalar operation (at the ISA level).

For instance, a multiscalar ISA, either as overtly multiscalar, or superscalar w/ added microthreads, might be able to bridge the ILP/TLP gap our popular ISAs exhibit, yet still utilize hardware performance-enhancing features to their fullest (renaming, re-ordering, disambiguating). OTOH, Intel's RTM might be enough to take care of that with x86, given enough time for compiler and language support to mature.

 

[ShintaiDK]

Im not sure if I should take your post serious Cerb? Its filled with errors and wrong assumptions.

 

[Cerb]

Im not sure if I should take your post serious Cerb? Its filled with errors and wrong assumptions.

Such as? I would say your post makes many wrong assumptions as well, including (a) that software scheduling can beat hardware scheduling w/o PGO for a specific chip, (b) I$ is cheap, (c) everyone has the ability to recompile everything, and (d) that you need more RAS than x86 offers, if you aren't trying to port old software relying on those specific features.

- Amdahl's law is not limited to affecting one ISA.
- No compiler has yet been able to beat OOOE with a static non-profiled compile on an in-order CPU. I doubt they will anytime soon, either.
- Requiring PGO and the like for decent performance means it is fundamentally broken, for the mass market. Fine for Java, but not much else.
- People still rely on 20+ year old binaries for their businesses, some of which include pieces of code written in even older times. It is taking in excess of 10 years just to ween the world off of 16-bit x86 code, and that is still not fully weening users off of IA32. Unless the chip maker is willing to sped the money to reverse-engineer and translate every piece of old software correctly, and provide reasonable performance with the result, it will not succeed to replace x86.
- Itanium is only better than regular scalar ISAs at a very small number of things, like non-vectorizable FP.
- If you are building a new piece of software that will run on many computers, 99% of the time the most RAS you will need will be available in every Xeon or Opteron. Most of that 1% left over can be taken care of by high-end Xeons, with ECC registers, data poisoning, and RAM mirroring.

 

[ShintaiDK]

Such as your lack of knowledge about RAS features and usage. Or that your think that x86/x64 compilers can get you out of one of the biggest problems with x86/x64.

I dont think you realize at all that IA64 doesnt need a realtime scheduler at all because its done at compiletime. Something you cant do with x86/x64. Thats also why we saw the Mitosis project. Basicly wasting cores on guessing the right instruction sequence outcome to boost singlethreaded performance.

All those that run IA64, POWER or Sparc today dont care about x86/x64 being faster. Because x86/x64 cant lift the task at all. And in those segments you dont care about software or hardware cost.

Right now only 1 Xeon x86/x64 model even got MCA.

And for performance its kinda simple since its different processnodes and different developmenttimes. Haswell for example will be out while Xeons still runs on Sandy Bridge.

Amdahls law was about people having blind faith in multithreaded. You sit with an issue already with serialcode you cant fix on x86/x64.

x86/x64 is a dead wall. The only good thing about x64 is that you have to redo pointers from x86. Also why x64 ports are relatively rare. And why its easy to port from x64 to IA64 and others.

 

[Fox5]

Such as your lack of knowledge about RAS features and usage. Or that your think that x86/x64 compilers can get you out of one of the biggest problems with x86/x64.

I dont think you realize at all that IA64 doesnt need a realtime scheduler at all because its done at compiletime. Something you cant do with x86/x64. Thats also why we saw the Mitosis project. Basicly wasting cores on guessing the right instruction sequence outcome to boost singlethreaded performance.

All those that run IA64, POWER or Sparc today dont care about x86/x64 being faster. Because x86/x64 cant lift the task at all. And in those segments you dont care about software or hardware cost.

Right now only 1 Xeon x86/x64 model even got MCA.

And for performance its kinda simple since its different processnodes and different developmenttimes. Haswell for example will be out while Xeons still runs on Sandy Bridge.

Amdahls law was about people having blind faith in multithreaded. You sit with an issue already with serialcode you cant fix on x86/x64.

x86/x64 is a dead wall. The only good thing about x64 is that you have to redo pointers from x86. Also why x64 ports are relatively rare. And why its easy to port from x64 to IA64 and others.

AMD's opterons rarely had a process advantage on Itanium, and they generally beat it in performance.

X86 and x64 assembly is ugly and hard to program for. That's about its only limitation in the modern day. We have decades of compiler work for x86 that do a very good job in optimizing for the architecture, and the compactness of x86 code (due to being stack focused and variable length) makes far more efficient use of cache other than ARM with its various THUMB modes.
And for styles of programming that don't fit in well with the x86 ISA, SSE other extensions have their own register set and syntax and aren't really impacted by the x86 legacy.
X86 may not be the best architecture in every respect, but there's nothing out there that can be convincingly said to be better overall.

 

[Cerb]

Such as your lack of knowledge about RAS features and usage.

Xeons have gone as far as hot-swapping cards and memory, and ECC registers, the first two of which are only marginally useful (why aren't you shutting the computer down for a few minutes?). What RAS features does Itanium have that cannot be replaced with redundancy, if not supporting legacy software?

Or that your think that x86/x64 compilers can get you out of one of the biggest problems with x86/x64.

What big problem is that? I never said I think x86 compilers can get us out of some problem. I said that in-order uarches (and ISAs, in IA64's case) need compilers to be able to compete with out-of-order, and sometimes are stuck not being able to, without an undue amount of human attention on specific code paths, and then the improvements only apply when the tested profile matches the current data flow. Both in-order and out-of-order can greatly benefit from compiler improvements.

I dont think you realize at all that IA64 doesnt need a realtime scheduler at all because its done at compiletime. Something you cant do with x86/x64. Thats also why we saw the Mitosis project. Basicly wasting cores on guessing the right instruction sequence outcome to boost singlethreaded performance.

At the cost of how much bandwidth and power? It didn't improve performance enough to make up for generation x86 CPU improvements (and, ironically, can help x86, too: now, you can add helper threads, using ICC, though like with Mitosis, the benefits aren't as much as they thought they'd be). You do need hardware scheduling, because the compiler does not have enough knowledge, without profiling (which has its own issues), about the data flow of the program, to always offer good baseline performance.

All those that run IA64, POWER or Sparc today dont care about x86/x64 being faster. Because x86/x64 cant lift the task at all. And in those segments you dont care about software or hardware cost.

Then they aren't competing with x86, and won't (nothing wrong with Power, FI, unlike IA64, and certainly a PPC CPU could compete with x86 CPUs, but IBM just doesn't care to). IMO, if software and hardware cost don't matter, you are in a market long overdue for a correction.

Right now only 1 Xeon x86/x64 model even got MCA.

Even Intel desktop CPUs have had MCA for well over a decade. MCAR Is limited, specifically for the purpose of charging more, for the time being (which, for small niche markets that used to use Big RISC, I'm OK with).

Amdahls law was about people having blind faith in multithreaded. You sit with an issue already with serialcode you cant fix on x86/x64.

No, Amdahl's Law is about predicting parallel performance. Any given implementation of an algorithm will have nearly identical scaling results, limited by bandwidth and latency of the system. I don't need faith: I have reality. Not only do I have the reality in which multithreading does work, but so does everyone else. SPARC (T-series and Fujitsu's, specifically), Power, and Itanium, FI, rely even more on multithreading than desktops/notebooks and COTS servers, for good performance, and they have the bandwidth to keep all those threads fed.

x86/x64 is a dead wall. The only good thing about x64 is that you have to redo pointers from x86. Also why x64 ports are relatively rare. And why its easy to port from x64 to IA64 and others.

No, it's not a wall. It just keeps looking that way to people that wish it were. x86 wasn't going to be able to do superscalar execution. Everyone was going to get stuck at 1 IPC. x86 was too complex for effective OOOE. And so on, and so forth. It hasn't been perfect, sustained FP performance has generally lacked, and it can be lacking when sustained very high bandwidth/thread is needed, but even those faults are becoming less and less.

x86-64 ports are mostly rare because they aren't needed too often. If you don't need more registers, larger registers, or more RAM, there's no reason to do it, unless your IA32 executable is incompatible. For x86, where cost and compatibility matter, that's a fair compromise, to support a single binary.