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!"

Zzzzzz......

[Bowling Moses]

Another preview? We've been seeing bloody previews for the last two freaking years. Wake me up when it hits the shelves in volume and has broad based software support for 64 bit mode.

Re:About 64-bit gaming performance

[mjuarez]

The above seems to imply that game benchmark results will be better at 64-bit.

With a little tweaking and register optimization, they will be better. You have double-sized registers, and much more general purpose registers. In tight inner loops, being able to complete a loop in 10 vrs 20 clocks makes a hell of a difference.

Now, if those games needed access to many gigabytes of game data, that would be an entirely correct assumption.

We are getting to that point. I believe Doom 3's textures are approaching the gigabyte size, and you need many of those at the same time on memory to be able to correctly display a level. Of course, even if it was not necessary, being able to load up ALL textures to memory will make the game so much more playable. In general, if the RAM is there, gaming companies will find a way to use it to make the game better/faster.

Marcos

Re:Intel

[mjuarez]

This will all but signal the end of IA64, it will at that point probably only be used for HPaq's large servers.

Yamhill was rumored since 2000. The rumors appear to be true, but Intel has been denying it ever since.

The problem is that they committed themselves to Itanium for 64-bits. And, in doing that, they also committed SGI, HP, IBM and a number of other vendors. These vendors will NOT be happy if Itanium is obsoleted later on. HP alone has probably invested more than $1 billion in porting their HP/UX and Tru64 software to Itanium architecture, and there are even some customers that have made the full switch. (I'm not talking small shops here, I'm talking huge corporations which replaced their main servers with Itanium hardware).

I believe that, eventually, Intel will release a Yamhill-type of chip, but not after they get battered to death by the press and technical community out there for not releasing an equivalent-to-Opteron processor. But that will probably not be at least until the end of 2004 or beginning of 2005. So AMD has at least a full year for itself to gather momentum. Which I believe it will.

Re:Intel

[afidel]

Actually IBM doesn't care, they have sold WAY more Opteron systems than Itanium systems despite the fact that Itanium has been out for about 20% the length of time that Itanium has. Besides which their real 64bit chip is the POWER series. They are already performing initial work on the POWER6 and some research on stuff to include in the POWER7 even though the currently shipping generation is the POWER4. SGI is irrelevant these days so the only big player attaching their horse to Itanium is HPaq and they were doing it because they hoped it would pay off by reducing the cost of development of their chip used for their high end systems like the Superdome. In that sense Itanium has already reached its goals for HPaq, even if Intel never gets volume pricing on the chip Intel has already subsidized HPaq's development efforts =)

Re:Intel's response

[Anonymous Coward]

The parent of your original post talked about getting a quad-opteron system today in compairason to getting a prescott system which will not be available for a while. You attempt to shift the argument to the availablity of quad mobos is an attempt to change the subject to the availability of a niche product (most people buy quad systems not build them), i might as well ask you to prove that 8-way Xeons are available for purchase yet only accept proof in the form of a readily purchaseable 8-way Xeon mobo while disregarding any purchaseable OEM systems.

Re:About 64-bit gaming performance

[MROD]

Hmm.. you say that having bigger and more registers is going to increase the speed of programs..

Well, this may be true if the only code running is the game and doesn't transfer double the data from the memory to process (64bits rather than 32).

However, what happens when the operating system does a context switch or some other exception occurs? The latency from saving the processor context is going to go way up as you have to save far more data to memory and then load the same large amount of data in for the new context.

If you double the size of the registers and double the number of registers (and possibly add to the size of the CPU's other program registers) you suddenly quadruple the amount of data which has to be changed over. On a system with many threads and processes running this can add up to a significant deficit.

Now, if your programmers decide that they want to work on 64bit wide data instead of the 32bit they used to on the old system, you suddenly find that your processor is having to move double the amount of data around there system.. You have to hope that any increases in memory bandwidth the engineers included are enough to cater for this.

I think the main thing I'm trying to say is that 64bit computing isn't necessarily faster than 32 bit computing. Indeed, because some of the overheads can be double or quaduple, it can be a performance hit.

Sorry for possibly raining on your parade, but that's how the cookie crumbles.

Re:64bit performance gains...

[barawn]

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.


Except that pointers make up only a small fraction of the code footprint of an executable - most of it is ints, which still are 32-bit by default on x86-64. In general you can easily minimize the number of pointers in code by doing math (i.e., with 32-bit ints) on one base pointer.

The estimate is that code size will increase by about 10-15% on x86-64. Considering that the L2 cache is 1MB, as opposed to the standard size of 512k nowadays, it's a net win. Presumedly in the future they'll increase the cache size even more.

Re:About 64-bit gaming performance

[katz]

Your analysis is detailed and insightful, and at one time was a big issue. However, today's sheer clock speeds and superscalar pipelines render it far less of a burden. How fast does your OS switch contexts? every few milliseconds? "iostat" on my 1.0 Ghz Athlon t-bird says 351 cs/sec; 1.0/351 ~= 2 ms execution time per context. This is enough time for even the >>tightest>miniscule compared to the time tight loops have at their disposal. This, coupled with the fact that context switches are so carefully and constantly streamlined to be as efficient as possible, make this context switch--which was an impediment at one time--insignificant now.

Roey

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.

Re:But is it representative?

[Slack3r78]

(am I the only person who got several pages without content in the preview?)

I read this article this morning long before it hit slashdot and didn't have that problem. What it likely was is that several of the pages were nothing but images (charts) and poor anand was suffering a slashdotting when you tried accessing them. Hence, nothing came up. Might want to try again when the frenzy dies down some.

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 :-)

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.