Slashdot Mirror
AMD's 64-Bit Chip
EyesWideOpen writes "AMD is set to release a 64-bit chip early next year which will be completely backwards compatible with the Athlon line. The current 64-bit offering from Intel, Itanium, is an entirely new chip that has no backwards compatibility with its x86 line of chips (from the 8080 chip to the Pentium IV) and is designed only for high end servers. AMD's solution to this problem is the Opteron chip (product info) which will be in servers, desktops and laptops. Here is a wired article."
Hmm, I don't know about your experiences but I've found Intel's to be more reliable.
Ok so the AMD's have more performance, but they run hotter and are more liable to blow up (yeah ok, no evidence to back this up), The Intel chips jut seem to be built to more conservative tolerances.
Just my 2 cents I guess...
Running programs in a hybrid 32/16 bit environment puts a serious strain on the Windows OS: It crashes. Pure systems do not crash as often. I really wonder if the problem will be magnified in a 32/64 bit environment?
We're Doomed
Well, I suppose your reaction to this depends on your personal product loyalty (or possibly lack thereof). Basically, a CPU will inherently run slower if it is backwards compatible with a completely different architecture. What AMD needs is a chip that solely does 64-bit ops, like the Itanium. Now, I realize that this would require all programs to be recompiled/rewritten, but isn't that what PDA's require anyways? And I'm sure the conversion from 32-bit to 64-bit is a lot easier than 32-bit to Async (could someone familiar with that process verify/refute this?).
This is, in essence, what I'm saying: AMD should come out with 2 64-bit processors, only one of which natively supports 32-bit apps. Why? Otherwise Intel will absolutely rip AMD to shreds in the benchmarks test. Being a loyal AMD user, I don't want to see this.
IWARS.
People, in general, disappoint me. Politicians even more so.
Same here. Ratio of AMD failure is about 5x intel one.
But they do deliver more bucks for the bang. When they work.
...considered part of the x86 family? The first processor in that lineup is the 8086. I think the 8086 might've been source-code-compatible (to some extent) with the 8080, but you can't take an 8080 binary and run it on any x86 processor (emulation doesn't count).
20 January 2017: the End of an Error.
I found my Dual AMD box to be as good, if not better from a never going down standpoint. Same goes for my gaming boxes. After building a bunch of systems, however, I do have one major beef with AMD...
... Things are a little better these days because the quality heat sinks - with paranoid mode on - are less likely to crush a CPU than when folks were trying to strap a socket 370 heat sink on an Athlon, but I still feel like it is a crap shoot every time I have to remove the CPU. I end up trying to stay about the $100 mark for CPU's as a result. (Yes, the MP's cost me much more, and I was very nervous when I mounted them)
For the love of god, put a coat of nickel or something on the CPU!
I chipped a couple when rev 1 of the Chrome Orb came out. Fool me once
+++ UGUCAUCGUAUUUCU
>> very advanced VLIW-esque architecture
Ah, yes. EPIC. Explicitly Parallel Instruction Computing. AKA VLIW. EPIC is market-speak. Intel didn't want to admit that it was making a VLIW chip for two reasons:
1. There is only one company that has every sold a VLIW chip that actually worked, and that people bought: TI makes DSPs, where are VLIW. They make tons of money. They are the only ones that ever did it right.
2. There is only one company that has ever made a good VLIW compiler: TI, again.
Lets think briefly about how great EPIC is, using the two main selling points I remember from a presentation I saw on it a few years ago (sorry if my memory is bad, no coffee this morning, I'm not responsible).
1. Instructions are Explicitly Parallel. So, the compiler tells you that these two or four or however many instructions can be executed without worrying about data dependency. Terrific. Assuming that the compiler actually works, which is still an open question.
The only difference between this setup and what's in your Athlon or Pentium4 is that the looking-for-independence is done in hardware on your Athlon instead of by the compiler on your Itanium. This means that there is the *possibility* that EPIC does better at finding independence because the compiler *should* know more about the code when its in a higher level language. *Should*. Essentially, until the science of compilers takes a quantum leap or we start using programming languages that makes these things easier (correct me if I'm wrong, please), Itanium will be at most as fast as a superscalar processor that finds independent instructions on its own and does register renaming.
2. Predicates and conditional execution. While the whole notion of the predicate in EPIC is more complicated and complex than just conditional execution, its not entirely more useful IMHO, or at least that was my impression the last time I heard someone talk about it. Alpha has conditional execution. ARM has conditional execution. I can append checks to the condition codes in ARM assembly. I don't really understand why this is so nifty.
I've said it before, and I'll say it again. Resist the urge to think that whatever marketdroids tell you is new is actually good. Sometimes its not.
(If more knowledgeable people are lurking, please correct any errors I've made, but I think I've got this right.)
Outside of a dog, a book is a man's best friend. Inside a dog, its too dark to read.
The chipsets for AMD machines are often buggy.
"AMD came up with a simple solution ... when this mode bit is set ..."
I'd note that this is not a new solution, and possibly not a desirable one. The book "The Soul of a New Machine" describes the engineering effort at Data General c1980 to develop a new mini computer. I think it was a 32 bit design, and needed to be backwards compatable with the older 16 bit design. The chief engineer insisted that the compatability *not* be done by a 'mode bit'. I can no longer remember what the objections to a mode bit were. Can anyone comment?
Quattuor res in hoc mundo sanctae sunt: libri, liberi, libertas et liberalitas.
So in other words, both companies are doing most likely the same thing, though Intel is slightly more underhanded about theirs
;)
No, not at all. Two completely different paths. AMD's strategy is obvious. Intel otoh is a bit more complex. They want people (high end people that is) to move away from the commodity x86 chips (currently P4/Xeon) and to this new ISA. Why? Well, two primary reasons, the first one is a bit lost in the shuffle, the second one plain as day.
Firstly, you have to know the history behind the Itanium/Merced. It was conceived back when Intel still considered RISC to be a major threat and the likes of AMD were really no competition at all. So the thinking was that x86 would never economically scale up to the levels that RISC could, and therefore a complete departure was required to ensure that they kept the performance edge (boy howdy do times change!). Their primary goal was performance, x86 compatibility was an afterthought (and it shows). It wasn't until it became obvious that x86 compat. was important (and the surprising upramp in x86 clock rates) did Intel realize that they were going to have to put way more effort into x86 compat mode then they ever wanted to.
Secondly, and this is probably most important now given the huge advantage Intel has over rivals in the clock rate category, is the simple obvious fact that there are no IA64 clones. If Intel can convince the market to move to the new architecture, they will once again have free pricing reign over the market. They can also make sure that follow any clone activities much closer (i.e. the lawyers would follow the clone activity much closer). This my friends is the big buy. Once again, a sea all to themselves, once again massive margins (well ok, more massive margins). No niggling AMD nipping at your toes.
So, there you go, more than you ever wanted to know and probably care about.
No its not better.
In CPUs like the Athlon or Pentium, esoteric and rarely used previous generation features are microcoded and have little or no impact on critical path performance.
The ability to create a high performance processor while retaining backward compatibility is just a matter of design. The two ideas do not necessarily interfere with each other in terms of performance.
The x86 backward compatibility hierarchy is actually quite reasonable excepting for the lack of registers. "long mode" in x86-64 fixes precisely this problem.
With "fresh starts" we end up with garbage like "MIPS" (exposed branch delay slots, makes forward compatibility to deeper pipelined chips difficult if not impossible) or "Itanium" (so complicated, its hard to imagine how they will improve architectural performance over time) or "Crusoe" (an extremely "simple" architecture that cannot go toe to toe with its contemporary x86 brothers.)
In the end the better implementation wins. That is all.