Slashdot Mirror
Intel Quietly Adopts AMD's x86-64
HishamMuhammad writes "The rumors reported earlier at /. are confirmed. The latest offerings in the Pentium 4 family now support AMD's x86-64 architecture, even though Intel is not willing to admit it very openly, by using cryptic names like EM64T and (gasp) IA-32e.
(The naming issue was discussed on lkml, and the consensus there was to use 'x86-64,' even though sometimes AMD refers to it as 'AMD64'). Intel's FAQ admits their implementation is basically compatible with x86-64, except for the minor differences that have always set Athlons and P4s apart. It's about time Intel jumped on AMD's bandwagon, since its homegrown 64-bit architecture seems not to be doing
very well."
The primary reason seems to be that the dashes and underscores in x86-64 and x86_64 would have caused havoc with much of thier package management software.
EM64T also known as 64 bit memory extensions, have been in the P4 Spec back to the Willamette Days, they have simply "Turned them on" (Heard from an Intel Channel Conference)
Sure, you can't build a $1500 Itanium box, but at the same time, the second fastest computer in the world is powered by Itanium processors. So is the fifth. AMD Opterons power #17.
in early 2005 Anandtech
Back on December 26, 2002, Robert X. Cringely stated this would happen.
If someone says he and his monkey have nothing to hide, they almost certainly do.
Yes. At least with AMD's implementation. I am not sure about Intel's. AMD64 runs x86-32 natively. IIRC there are two modes (one mode has 2 submodes). There is legacy mode, which is pure 32 bit x86 with standard registers, and then there is long mode which can either operate in legacy submode, which can run 64 bit code or 32 bit code, but is limited to 32 bit address space and registers, And then there is 64-bit mode which runs 64 bit code with all the added registers, but cannot run 32bit code.
Viral software licensing is not freedom, it is in fact GNU/Socialism.
This is in addition to Intel performance-enhancing compilers.
You mean those compilers that AMD uses for their benchmarks?
When performance matters, you need an end to end solution. Intel delivers. However, AMD might be able to benchmark well with 64bit apps as soon as they use Intel's updated compiler.
For those that don't know. Most all of the AMD64/Opteron bencharks were done with the Intel compiler in 32bit mode.
depends. AMD has better memory architecture for once. Generally kicks ass on most loads vs. a Xeon.
Sounds like an Intel commercial. All we need is the annoyning bing, bing, bing, bing at the end. Hyper-Threading is really a poor-man's dual core. So why would anyone need Hyper-Threading when you actually have dual-core in the next 6 months? SSE3 is actually useful, and as it has been pointed out, is coming very soon to AMD64.
AMD processors will soon have SSE3 and don't have much need for HyperThreading to make use of idle execution units as does Pentium 4. The highly efficient Pentium M doesn't need it either.
AMD had a 1+ year head-start distributing reference materials and winning developer mind-share. They're not likely to lose their advantage anytime soon, especially as Athlon64 is faster than current EMT64 chips in 64-bit mode, is cheaper, and runs cooler.
You can expect developers to write code that works on both architectures, it'd be unwise to release something which didn't run well on AMD's chips.
http://developers.slashdot.org/article.pl?sid=04/
or was it when they started shipping 64 bit Prescotts?5 &tid=118&tid=137&tid=126
http://slashdot.org/article.pl?sid=04/08/06/00025
Just because it shows up on the Register it is now news again.
I don't know why this is news, but Intel already had support for AMD's 64 bit extensions in Prescott. It was hacked in late in the game so, as you would expect, does not perform well. However Intel does not expect 64 bit apps to take off for a while so they aren't overly concerned (we still don't have a 64 bit app from MS). If you want to talk about raw performance in 32 bit mode, latest AMD tends to beat out intel in many benchmarks. But if you look at realistic usage models and the benefits of hyperthreading you might find that the Intel architecture better suites your needs. Checkout the hyperthreading video example on TomsHardware if you doubt the benefits.
If the big advantage of these new 64-bit processors is nominally found in servers, then AMD will clean house because their systems scale and perform VERY well in the server role compared to Intel. Sure, you may not be able to tell the difference between AMD and Intel on the desktop, but for most types of server loads, there is no contest. The Opterons are very, very good server systems, and for many types of loads e.g. database servers, they run rings around Xeon processors for a very low cost.
Unless Intel matches a very competent ccNUMA and I/O fabric to their EMT64 cores, they will not be competitive where it matters.
Well, no...it gives you more GP registers. Applications for x86-64 Linux usually show about a 20% speedup.
Plus the extra memory addressing does have it's uses...you'll see.
Intels Itanium was a real improvement it gave you 64-bit but it also gave one so much more.
Yep...more cost, more die size, more cache, more code bloat, more compiler problems, and more headaches. By all means, enjoy! ;-)
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
Intel has been forced to follow AMD quite a bit recently, Rambus, 64bit, NX bit (no execute bit). It isn't really a big suprise. One thing people don't realize is that Intel is large enough, with enough market share and infrastructure that it can hold on to a lot of the market segment despite the fact that AMD might have a very high quality part. Look for intel to try and start leading again with the next generation of chips.
The Intel guy has a point. Most people have no use for a 64-bit address space, at least for right now. Indeed, increasing the address space can actually slow things down.
It is only the fact that the AMD64/x86-64/whatever design also happens to add more general purpose registers that makes it useful for every day computing. Of course, you can have more registers without having a 64-bit address space, but that's too complex for most people. So "64-bit is better" wins out.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
No, they're model numbers. Way back when, a court ruled that you can't trademark a model number like 80486, and AMD could keep selling 80486 processors. So Intel responded by calling their 586 the Pentium which is trademarked.
FreeBSD's port is also amd64. Same with NetBSD and OpenBSD. This is nothing new. There are other reasons why Debian is using amd64 as well. Two of their target platforms (NetBSD and FreeBSD, see here) use amd64 internally, as listed above.
Your hostility is unfounded. What other distro bothers to deal with so many architectures? Debian is all about consistency -- packages are rewritten as much as is needed to properly fit them into the debian system and have them properly pass the massive debian-policy. The underscore as a field separator in filenames is part of this. Package management software found on any debian machine doesn't depend on any particular file naming scheme at all (though the ftp-masters scripts probably do). This fact alone convinces me that you have never bothed to use or understand Debian. Or is it that you couldn't? However, all of this doesn't mean that Debian will accept a name which undermines decisions that have already been made, like that of using an underscore as the field separator in filenames which actually tell something to users. Why people who don't use Debian often feel hostile to it is beyond me. The project aligns as much with the open source movement's ideals as any other, and more so than most.
Actually, AMD didn't use the complete model numbers. Their clones were called the Am386 and Am486. Just guessing, but the use of the short numbers instead of the long (386 vs 80386) probably didn't help Intels case.
"AMD had that whole package cracking issue with the heatsink, though."
Pre-AMD64 Athlons did not have a heatspreader. This actually improves thermal transfer between the CPU and the heatsink.
If you install your heatsink carefully, it shouldn't be a problem. You have to be careful, but it's not like you don't have to do that with Intel CPUs too.
According to that same Wikipedia article, Compaq and Samsung funded a private company called Alpha Processor Inc.
It looks like that list, especially the Sparc and the S/390, was made by someone not all that familiar with the system/processor families and perhaps used their Google-fu to find a bit of info on them. While Sparc is technically handled through Sparc International, most of us know it as Sun's technology (it is) and they are the main user's of it. S/390 is just IBM's System/390 platform (zSeries might be what they are calling the latest systems on the S/390 platform).
It's much worse than that, unfortunately. The bounce buffers must be allocated in the low memory (below 4G for sure), and the only way to ensure that is to allocate them at boot time. Linux kernel does it with the SWIOTLB buffer. You can specify the size at boot, but after that it's fixed. If DMA ever requests more memory than the buffer has, the kernel will panic (apparently latest 2.6 kernels have some more graceful way to handle it, but in any case DMA requests cannot be fulfilled once there is no memory for bounce buffers). On the other hand, SWIOTLB memory effectively disappears from the system.
So, if you have a nice gaming system with 256MB video card, you may need at least that much memory just for bounce buffers, or more: I'm not sure what the exact requirements are, but I've seen EM64T boxes which would be stable only if SWIOTLB is twice the size of video RAM. Half a gig of RAM not available to the system. So at least for gaming boxes, buy AMD64, don't buy EM64T.
I think Intel is quietly adding support for the x86-64 architecture due to the fact that Microsoft will soon release a version of Windows XP that will fully support the x86-64 architecture. I believe that the target ship date of this new release is some time in the first quarter of calendar year 2005.
Not entirely .. The real purpose of SMT (the general name) is to reduce the need for complicated multiple dispatch engines. A CPU has lots of functional units on board, and it's hard to keep them all busy. Multiple dispatch helps, but is hard to design, and often requires new compilers to really shine. SMT helps too, but is easy, and works fine with existing code. This is why Sun added 4-thread SMT to their latest chips rather than make them bigger and more complicated like everyone else did (Intel, AMD, and IBM).
Not that this wasn't entirely predictable.
Though I hear Microsoft has standardized on AMD64--
But you wouldn't know it from their blogs.
All I know about Bush is I had a good job when Clinton was president.
There are pictures floating around comparing 130nm single core Opterons to 90nm dual core Opterons. A dual core die produced on the smaller process is about the same size as a 130nm single core die, meaning they should cost about the same amount of money to produce, per chip.
Intel did overlook one important aspect. They do not honor the NX bit. AMD Opterons and AMD64 CPUs do. That is one very big difference for alot of people.