AMD64 Preview

Araxen writes "Over at Anandtech.com they have an interesting preview of AMD's 64 bit processor on a Nforce3 mobo. The results are very impressive with the Anthlon64 beating out Intel's P4 best processor soundly in their gaming benchmarks. This was only in 32-bit mode no less! I can't wait for 64-bit benchmarks come out!"

Comments

Opteron Benchmarks, not Athlon 64

[ultor]

The benchmarks are from a 2ghz Opteron, not an Athlon 64. It is intended to give an example of the performance from the new chip. Unfortunately, upon introduction, only the Athlon FX, running on ECC memory will be capable of using dual-channel memory. And from what I've heard, this cpu will cost in the vicinity of $600+. The first non-ECC dual-channel platform will be introduced in 2004.

Not an Athlon64, but an Opteron

[doormat]

Anandtech is only comparing single processor Opteron performance against everything else, no infact, Athlon64 performance. The primary difference is that the Opteron has a dual channel memory subsystem, whereas the Athlon64 has a single channel system. This difference will have an affect on performance.

Re:Not an Athlon64, but an Opteron

[heli0]

There will actually be two lines at launch. The 940-pin Athlon64FX(1-way Opteron) will have dual channel DDR while the cheaper 754-pin Athlon64 will have single channel DDR.


Athlon64 Showing Up
Pricing for Athlon 64 leaks: 939 pin chip won't be compatible with 940 CPU

Re:Not an Athlon64, but an Opteron

[MBCook]

Your comment is somewhat missleading. There are TWO Athlon 64s being launched (or as Overclockers.com called them the "Opteron that's not an opteron but is an opteron" and the "operton that's really not an opteron" or something like that). Annandtech compared the equivelent of an Athlon64 FX, not an Athlon64. Here is the skinny:

Athlon64 FX
This is a 1xx opteron. It's still dual channel, and it uses ECC memmory (for now?). This is the "performance" part, the high end one. If we're trying to find who has the fastest CPU, this is the one to test. Their tests are quite valid for this, IMHO.

Athlon64
This is the "budget" Athlon64. It only has once memory channel, I don't know if it has ECC or not. Yes, this will be slower, but it will also be cheaper and the motherboards for it could be cheaper too (since it doesn't have that second memory channel).

So, I think that this is a very important article. Look how fast an Opteron/Athlon64 FX is compared to a P4. A 2 Ghz Opteron/Athlon64 FX is beating a 3 Ghz P4. This is all on a 32 bit os and software. When you run 64 bit software that knows about all the extra registers and can do 64 bit math nativly should it need to, the computer will be fast. Tim Sweeny (spelling?) said that native versions of UT2003 (or something) was running up to 20% faster on x86-64 without optimisations; just from going to 64 bit mode. And for most of us the fact that it can manage over 4GB of mem easily for now is only iceing on the cake.

AMD has a great processor. I can't wait to see more info on these things. The fact that it does so well in 32 bit mode is important since you currently can't get Windows for the processor (there is no x86-64 version of Windows out yet). If it was a great processor, but you were forced to get terrible performance if you bought one for 6+ months (becuase it wasn't good with 32 bit software like windows and what you run), would anyone buy it? This thing is faster today, and should only get faster when you run native software. I'm saving my pennies (and yes, I know it will take a lot of pennies ;).

Re:Not an Athlon64, but an Opteron

[sirsnork]

All Opterons are made on the same line, they all have the exact same core. They are then tested to see it the work in 8way, if not they are tested for 4way and if they fail that they are tested for 2way. In 2 way they only use 2 of the 3 HT cotrollers and only one talks to another CPU (the second connects to the HT controller). In 4way config the CPU's use 2 HT controllers to talk to CPUs and one of them uses the third to talk to an HT controller (in fact sometime they have 2 CPUs talking to HT controllers, one for PCI-X and the other for all the rest). Finally in 8way 4 of the CPUs use all 3 of their HT controllers and the 4 at the edges only use 2, but again some also have to talk to the HT controller(s) on the "outside"

Re:Not an Athlon64, but an Opteron

[Jeff DeMaagd]

I don't know how this fits with your listing, but it looks like there might be another derivative budget chip at or below A64 that might not have a 64 bit mode at all:


AMD to ship Athlon 64s as Athlon XPs

I do find it amusing that people are commenting how good something is or is not before the damn product has been released, particularly when there is so little hard information on what it will really amount to.

So far one difficulty I see is the lack of Hammer boards that have AGP _and_ PCI-X slots or at least 64 bit/66MHz PCI slots, and they commented on this in that review last I checked. I think part of the assumption was that because these systems are for servers, AGP isn't needed, or if AGP is needed, it was assumed that PCI I/O slots weren't that critical.

Re:Interesting

[Dun Malg]

I just wonder if it can compete with the Intel x86-64 line of processors.

Huh? There's no such thing as an "Intel x86-64" processor. x86-64 is AMD's solely implementation.

Re:64-benchmarks wont be good

[Slack3r78]

I actually read this this morning, and there are a couple of important things to note - the chip being 'previewed' isn't actually an Athlon64 - it's a 1.8GHz Opteron overclocked to 2.0GHz, which is the expected clock rate of the first A64, prorated at 3200+. It'll give us an idea of what to expect, but nothing too specific.

The other important thing to note is that the comparisons were mostly against P4s and an Athlon XP, with a Dual 3.06GHz Xeon thrown in for good measure, all 32 bit chips. And the 'Athlon64' owned most of the competitions, showing that its 32 bit mode is just as good as rumored. There were no Itaniums in the competition since, so only 32 bit modes can be compared here. However, if the A64 turns out to be as good in its native 64 bit mode as the 32 bit number might lead you to believe, the Athlon 64 looks like it very well could be a force to be dealt with.

Will it be secure?

[samjam]

When are some of these newer processors going to implement the executable permissions bit in the MMU so that the STACK can be NON-EXECUTABLE (ok I know some trampoline stuff needs executable stacks, well they can ask for it where needed by setting the executable bit for a small region)

And when are some of these new processors going to be fully virtualizable? I'm talking about PUSHF and POPF generating exceptions like directly setting the interrupt flag does.

Think how easy plex86 would be to run on a processor that did this properly?

Code-morphing Transmeta (come one!), AMD (maybe?) Intel (no chance?)

Sam

Re:Will it be secure?

[Amoeba]

The sad thing is I understood everything you just said.

My God, I *am* a geek.

Re:Will it be secure?

[MROD]

Not exactly.

Within the MMU look-up tables the memory pages can be marked as being executable or not. Hence, if a program tries to jump to memory in a protected page (ie. not marked as executable) it will cause an exception.

The current x86 MMU doesn't have this ability, unlike some processors such as the Sun UltraSPARC (though not any versions previous to this).

Semantics, maybe, but...

[Murdock037]

Intel doesn't have an x86-64 line of processors. They have an IA64 line of processors.

The two apparently aren't interchangable. There's a coming battle in which software companies have to choose between the two, or support both, which would be tough on both them and consumers.

Apparently, AMD's x86-64 set is easier to deal with, and more of a natural progression from where the processors are now. (It also apparently runs 32-bit code at rates comparable to 32-bit chips at the same clock speed.) Intel's IA-64 is a total reworking, and a bitch to work with, from what I've read.

In the end, it seems like the smart choice would be for everybody to toss their hat in with x86-64 (which means Intel would have to, as well, and essentially concede defeat and lose face); it probably won't happen, though, because Intel is Intel.

Check out this article at the Inquirer, which I've basically just paraphrased, but it does go into some interesting Windows 64 dealings.

64bit performance gains...

[Natalie's Hot Grits]

Before anybody starts talking about how little 64bit cpu's actually increase performance, let me tell everyone what 64 bit mode will actually bring to the table over the Opteron/Athlon64 32 bit modes:

1) more registers. This will get us fair performance increase from the start, as compilers will have more registers to work with when doing calculations on multiple pieces of data.

2) support for larger system memory sizes. This won't help you in video games, but it will help you doing high end photoshop, and other applications (provided you spend the money to get more memory put into your system)

3) native operations on 64 bit data. Typically, when someone wants to do operations on a 64 bit integer in a 32 bit CPU, you have to split up the work in software. Now with 64 bit registers, you will be able to do operations on 64 bit integers in the same time as it takes to do the same operation on a 32 bit integer.

4) when using native 64 bit mode, certain legacy instructions of x86-32 are depreciated. This is a cleanup for the x86 ISA, which in the past has contained literaly EVERYTHING that the previous generation of CPU supported. AMD's x86-64 ISA eliminates these legacy features and moves them into firmware emulation (don't worry, it won't degrade any modern 32 bit code, just terribly outdated stuff from the 386 days, which doesn't need 2GHz of power in the first place)

On top of these performance enhancements that 64 bit mode brings you, you get all of this just because you are using AMD's Opteron/Athlon64 CPU:

1) Dual channel DDR Memory interface, with memory controller on the die of the CPU. This reduces latency and improves memory bandwidth so dramatically that even Intel's off die memory controller can't keep up (this is why video games are so much faster on the amd64 platform than on athlon-32 platform)

2) HyperTransport bus to the south bridge, which will give high bandwidth access to the PCI bus, PCI-X, and other IO intensive controllers. Eventually AGP slots will be phased out for PCI-X slots which will be universal for both video, and other devices.

3) when using multiple CPU's in the same system, the new AMD-64 platform gives you dedicated memory bandwidth to each CPU installed. On the intel and athlon-32 platforms, all the CPU's in the system shared the same memory controller which runs either single or dual channel DDR anywhere from 266MHz - 400MHz.

Re:64bit performance gains...

[p3d0]

Nice summary. I would only add a couple of things:

• 64-bit math on IA32 requires register pairs. With 8 GPRs, one of which is reserved for the stack pointer, that means you can only keep 3 long-longs in registers. On AMD64, even if you dedicate another register to the frame pointer, you can still get 14 long-longs in registers: almost a factor of 5 improvement.
• The benefits from the memory subsystem will be offset by the fact that objects containing pointers will be twice as big as on IA32. That means objects could have twice the cache footprint and twice the memory bandwith requirements.

Re:64bit performance gains...

[timeOday]

The benefits from the memory subsystem will be offset by the fact that objects containing pointers will be twice as big as on IA32. That means objects could have twice the cache footprint and twice the memory bandwith requirements.

I wonder if it will be possible to use 32 bit pointers within the X86-64 isa? This would save memory on pointers but give you access to the extra registers, instructions, and one-whack 64 bit math (which should be great for encryption and compression, without using special mmx instructions).

I thought I remembered SPARC being able to do this, but it looks like SPARC programs must be compiled with 64 bit pointers to efficiently perform 64 bit arithmetic.

Re:64bit performance gains...

[p3d0]

I meant data objects, as in object-oriented programming. Not object files. OO data tends to have a lot of pointers.

Having said that, object files will be bigger too. I'm not sure where you're getting your 10-15%; have you actually checked? I don't have access to our AMD64 boxes right now so I can't take a look at the object files, but I think the difference could easily be more than that for object-oriented code, for a number of reasons:

• Probably 2/3 of the instructions in hot code will need a REX prefix, either because they use registers r8-r15, or because they manipulate addresses.
• Only mov instructions can use an 8-byte immediate. Anything else that needs an 8-byte immediate must load that immediate into a register first with a 10-byte mov instruction, possibly spilling whatever was in that register. We could be talking about 3 extra instructions totalling maybe 18 bytes on an instruction that used to occupy maybe 6 bytes. Class tests in a polymorphic inline cache are particularly affected by this. Also, relocations (ie. jumps between different DLLs) must be 64 bits because there's no reason to think DLLs will be loaded within a 32-bit offset of each other.
• Autos that are pointers now occupy twice as much stack space, making your stack frame that much less likely to fit within an 8-bit signed offset (ie. 127 bytes). That means you can't use [esp+12h] addressing to access your locals, but rather [rsp+12345678h], which requires three extra bytes (not to mention the Rex prefix). Highly optimized functions often have lots of variables, especially after inlining, and in OO code, lots of the variables are pointers, so this one could hurt.
• Similarly, the AMD64 linkage convention on Linux has 6 parameters passed in registers (while IA32 has none) which also makes the stack frame bigger. This can be mitigated by using a frame pointer, but if you don't dedicate a register as a frame pointer, than you need to access your parameters with the stack pointer (rsp), and the parameters are always at the largest offsets from rsp. Result: parameters are likely not to be reachable with an 8-bit offset from rsp.

If I had to estimate off the top of my head, I'd guess code would be more like 25% bigger, while OO data could be as much as 50% bigger. (Remember that each object contains a pointer to its class or vft, and many object fields are pointers.)

Re:64bit performance gains...

[Ninja Programmer]

Object code side with *NOT* be bigger -- it should be *SMALLER* if anything:

• Pointers inside objects occupy run-time memory from the *HEAP* -- i.e., they don't have any presence in the object file.
  
• The use of REX to access r8-r15 is the register based alternative to using a SIB byte, and offset for an [ebp+offset] encoding for directly accessing the stack. I.e., paying the cost of an extra prefix byte saves in both execution speed and actual code size versus the spill/fill style or direct stack based alternative.
  
• Auto areas that are larger than 256 bytes because they are filled with a bazillion pointers are indicative of more serious program design flaws (that people don't generally have) than the statistical potential of loss from using far offset values from it. This is an extremely marginal case at best.
  
• I don't understand your linkage complaint -- the more parameters passed in registers, the fewer that will end up on the stack.
  

Re:Intel's response

[Glasswire]

Prescott with PNI new instructions, 1Mb L2 cache clocking up to 4GHz and beyond, 800MHz front side bus and increased software support for Hyperthreading. (eg. 2.6.x Linux kernels know how to do HT scheduling much more efficiently)

Watch the Xmas benchmarks, that's when it matters...

Athlon64 will be in short supply

[afidel]

or so says Ars Technica. In addition most of the initial shipments will go to motherboard manufacturers for bundling with their boards. I really don't like the idea of that becoming common practice as that much purchasing power will mean tight pricing controlls. Read more Here.

Re:64-benchmarks wont be good

[Distinguished Hero]

How the frell did this get modded up? Please RTFA before commenting/modding.

The benchmark was against a P4 (as well as a dual Xeon), which runs IA-32 natively, not the Italium.

The A64 is a consumer chip, designed to be purchased and used by consumers. The Itanium processor costs more than a whole top of the line consumer computer. The A64 and the Italium are not targeted at the same market segment and neither is the Opteron, which is supposed to go up against the Xeon.

The reason everyone is looking forward to a benchmark of an A64 running a native 64-bit application on a 64-bit OS is that not only is X86-64 considerably cleaner than IA-32, but the A64 also has two times as many SSE2 and General Purpose registers, which should yield significantly better results than the A64 running in 32-bit mode (which is already outperforming the P4 in a lot of benchmarks).

By the way, before someone points out that the benchmarked processor is an overclocked Opteron and not an A64, AMD is currently planning on releasing a version of the A64 which is just a rebranded Opteron 1xx along with the single-channel version of the A64.

Intel Itanium vrs. AMD Opteron/Athlon64

[mjuarez]

Just to set some things straight:

- Itanium, Intel's 64-bit chip, uses a totally different architecture (EPIC) from the current Pentium x86 line of chips. This architecture is NOT compatible with x86, so that effectively you need a recompile for existing software work on Itanium. There is an EMULATION mode for x86 in Itanium, which is absolutely unusable according to various sources on the Net. You will DEFINITELY not want to run a game on it. Finally, prices for a low-end 1.0Ghz Itanium chip start at approx $800.

- AMD's Opteron/Athlon64 chips are compatible with everything you are running right now at 32 bits. You can install a complete 32-bit operating system in it, and everything will run just as today, albeit a little bit faster. There is no need for an "emulator". And, of course, you can already use Linux at full-64 bits, available from SuSe, RedHat and Mandrake. Also, Microsoft will release a 64-bit version of XP at the end of the year.

Marcos

Re:Intel's response

[mjuarez]

Of course, you can buy a dual-Opteron or even a quad-Opteron TODAY if you want, or you can wait until late this year to buy a Prescott system, which is not 64-bits nor multi-processing.

By the way, did you know Prescott, along with its mobile version Dothan, was delayed because it was dissipating almost 103 watts? For the record, Opteron is dissipating about 60 watts.

Marcos

Re:About 64-bit gaming performance

[amorsen]

a benchmark of 64-bit gaming performance (say, its 3D calculation or its AI plotting performance) would be mostly a waste of time, as you would see very likely only see an equalling performance at best.

This would have been the case if IA-32 was a sane architecture. Athlon64 in IA-32 mode has only 8 visible general purpose registers, whereas it has 16 in 64-bit mode. That makes 64-bit mode a win in almost all cases. Technically it would have made sense for AMD to introduce a new 32-bit mode, but it would probably have been bad for marketing.

First Look at Windows XP 64bit for AMD64

[rchatterjee]

GamePC is running a first look of Windows XP 64bit edition for the AMD64 (x86-64) architecture.

Re:About 64-bit gaming performance

[Ospeovedizer]

What you say is true, if the only improvement of AMD64 is 64-bit support. However, AMD64 also doubles the number of general-purpose and XMM (for SSE, SSE2) registers to 16 of each. This will make many programs run faster, as having 8 general-purpose registers is just not enough. Far too much time is given to swapping data into and out of registers on x86.
The additional registers is really what I like about AMD64. I couldn't care less about 64bit for now.

Re:64-benchmarks wont be good

[parkanoid]

Sorry, but Hyper-Threading isn't really used to "take any advantage of the dualies". From the intel page: "Hyper-Threading Technology is a form of simultaneous multi-threading technology (SMT) where multiple threads of software applications can be run simultaneously on one processor" (emphasis mine)

20% Gain

[MBCook]

IIRC, Tim Sweeny said that by recompiling one of the versions of UT (2003 maybe?) for the x86-64 platform without optimizations, they saw up to a 20% performance boost. Now if they were to optomize the code on top of that, they could probably get a little more.

So even for programs that don't need to use 64 bit math, moving them to the x86-64 platform can speed them up. It won't improve your typing speed in Word, but it can probably speed up most if not all your games if they are simply recompiled.

So why didn't Intel do this?

[fm6]

Basically, you're saying that this is an important incremental improvement over previous x86 processors. Which describes every new x86 processor right back to the 8088. So you have to ask: why did Intel abandon the incremental approach with the Itanium? It's locked them in as the dominant CPU maker since forever.

Re:So why didn't Intel do this? Politics

[fm6]

Intel has sunk a lot of money and time into the Itanium architecture, almost a decade's worth.

Well, that explains why they're pushing the Itanium now. But the real question is what they were thinking 10 years ago, when they committed so much to a non-compatible processor. They knew going in that developing the Itanium was going to gobble up a lot of resources. So much so, they had to bring in HP to help. Imagine a project that's so big that Intel can't handle it solo!

Perhaps somebody was bored with the whole Pentium architecture.

Re:So why didn't Intel do this? Politics

[Anonymous Coward]

10-15 years ago, everyone else in the industry thought x86 was a dead end. Massive amounts of investement poured into RISC alternatives like Alpha and PPC.

Perhaps Intel believed the conventional wisdom and felt they had to eventually drop x86.

no more 'next page' style, please ;-(

[TheGratefulNet]

here ( http://www.anandtech.com/printarticle.html?i=1856) is the printable (all continuous) version.

causing hit counters to go up artificially just to see 'next page' drives me nuts!

Re:So why didn't Intel do this? Politics

[afidel]

And conventional wisdom was correct. They just underestimated the power of the entrenched software library. Intel processors since the Pentium Pro have basically been RISC cores with a x86->RISC translator in front. This allows them to ramp up the speed of the core, even change core architectures while still running all the old code. It costs at the fairly small cost of the gates needed for the translation frontend. It has another advantage in that CISC operations take up less room in cache so you get much better utilization out of your expensive cache resources. Intel started the Itanium project for two reasons, HP needed a new flagship chip and they are a large enough customer to sway Intel, and two they were tired of Cyrix and AMD copying their designs so they were going to make a tightly controlled architecture where EVERYTHING was covered by patents and copyright, that way they thought they could have the whole pie to themselves. What they didn't realize is that while they are a big player the only reason people keep using their chips is that they have maintained that backwards compatability path, throw that away and Intel is just another chip maker and others like IBM, Motorolla, etc may look better.

AMD64 already has non-executable pages.

[tamyrlin]

Quoting the AMD64 Architecture Programmer's Manual Volume 2: System Programming:

"The NX bit in the page-translation tables specifies whether instructions can be executed from the page."

So non-executable pages are already present in AMD64.

Not just more memory, more address space

[Namarrgon]

Obviously for some high-demand apps, having >4 GB of memory is a Very Good Thing. But for some apps (especially under Windows), a 64 bit processor can be bring another big benefit to the table: a full 64 bit address space. Obviously this is needed for more memory, but even with only 2 GB of RAM, a Windows app that uses large contiguous areas of memory can run into serious address space fragmentation long before they run out of memory.

In Windows, you only get 2 GB of address space for your process (WinXP & expensive Win2K Server versions can give 3 GB, which helps). Into this address space is loaded your executable code (including all system DLLs) and your stack (by default 1 MB of address space is reserved for every thread), and these tend to be scattered around a bit, which breaks up the available address range considerably.

Now if your app needs to allocate large (200+ MB) areas of memory, how many of those do you think you can get from a 2 GB RAM machine? Not enough :-) In fact you may find that as little as 50-60% of your available RAM can be allocated into large chunks, and all the rest is only available as countless smaller fragments. The larger the contiguous RAM blocks you want, the less of them you can allocate.

With a 64 bit CPU, there's no more problem. The MMU can map scattered pages of your available physical RAM to any contiguous section of the massive 64 bit address range, and you can utilise all the RAM you have in any size chunk you wish :-)