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

Intel

[Soporific]

I wonder what Intel has on the way to counter this?

~S

Re:Idiots...

[Slack3r78]

They have announced physical packaging changes scheduled about every 4 months until 2005.

Do you have a source on this? Everything I've read on the Athlon64s for months on end now has mentioned nothing but Socket 768. I have a sneaking suspicion that you're a troll, after all, I seem to recall Intel changing the P4 socket midway through the game. But I take it that's different because they're Intel?

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

About 64-bit gaming performance

[yourruinreverse]

This was only in 32-bit mode no less! I can't wait for 64-bit benchmarks come out!

The above seems to imply that game benchmark results will be better at 64-bit. Now, if those games needed access to many gigabytes of game data, that would be an entirely correct assumption.

Apart from the utter pointlessness of 64-bit gaming for the coming years because of the comparatively humble data requirements of current games, 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.

Re:About 64-bit gaming performance

[Anonymous Coward]

You forgot that Epic has already demoed 64-bit UT2003...

Re:About 64-bit gaming performance

[drinkypoo]

IBM had a RISC chip called the 801 way the hell back in time but never commercialized it, and so the ARM was the first RISC CPU that anyone was able to buy. I went hunting for dates once and wrote this writeup on E2 which has the dates of these assorted processors. The 801 is from 1979, the ARM2 in 1985 (ARM1 is also in 1985, but never commercialized) and ROMP in 1986. POWER happened in 1990. There is enough time between 801 and ROMP, and further enough time between ROMP and POWER, to ensure that each processor somehow advanced the others, if only because IBM was busy laying their share of the groundwork for how RISC processors and processors in general would work. IBM has always advanced the science of computer technology by at least their fair share, if not more.

Other interesting factoids for those too lazy to visit the link, or to wait for the page to load, though probably anyone who has drilled down this far will fire it up in another tab or window; The Motorola 68020 (1984) was the first 32 bit processor. The first general-purpose 16 bit microprocessor was the Texas Instruments TMS9900 in the TI 99/4(A), in 1976.

I know about AIX on the RT, I know that was the primary OS, but the fact is that the system tanked because it was mismarketed as a PC, though it's true it was priced like one, scaled up for performance. I managed to track down both AOS and BSD 4.3 (IBM and not IBM, as you apparently know) for my RTs.

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.

But is it representative?

[eddy]

While true, isn't the whole point of this "preview" to demonstrate the true Athlon64 performance without breaking the NDA by actually publishing Athlon64 benchmarks?

I'm guessing they have access to Athlon64 hardware, and simply "tweaked" the Opteron until ut produced similar enough results to be published as a "preview" -- Since those can be published. It's almost a little like what AMD did with their PR rating, which is officially based on the Thunderbird line, but everyone compare it to the P4 core freq. instead.

But yes, we have no idea of knowing how accurate these results reflect the final Athlon64 3200+ or whatever model they're previewing (am I the only person who got several pages without content in the preview?)

(everything above is pure conjecture)

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: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:Opteron Benchmarks, not Athlon 64

[WoTG]

The top end chip might be in the $600 dollar range, but the cheaper chips will be significantly less than that.

For comparison, the 1.8GHz Opterons are in the $460 range on Pricewatch. So the A64's will have to be somewhat lower than that in price. (Unless they skip 1.8 altogether)

Also, for many benchmarks, dual-channel memory isn't that important. What is most important with the A64's (and Opterons) for desktop application speed is the on-chip memory controller. This gives these chips dramatically lower latency. So, we can still expect the low end A64's to be good in many, many applications - including games, I think.

Re:Not an Athlon64, but an Opteron

[mjuarez]

It's not vaporware. You can buy it from a lot of places on the Net. See here for one:

http://tinyurl.com/mhn9

You can also find it in PriceWatch, at least 5 vendors offer it currently.

Will we have a library nightmare?

[r6144]

For optimal performance and compatibility, we need at least three sets of libraries: a pure 32-bit version (old apps have to run in 32-bit mode with a 64-bit kernel because the new instruction set is not entirely compatible with the old one), a "small" 64-bit version in which pointers are 32-bit in memory (so that most applications can get 64-bit and the extra registers, etc., without wasting memory on pointers), and a regular 64-bit version for the apps that really need the large address space. Seems that the nightmares of tiny/small/medium/large/huge/compact memory models in 16-bit x86 will come again.

Anyway, those running other existing 64-bit CPUs should be able to give some advice.

Re:64bit performance gains...

[p3d0]

Pointers inside objects occupy run-time memory from the *HEAP* -- i.e., they don't have any presence in the object file.

Duh, yeah. What's your point?

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.

Good point about r8-r15. However, the problem with needing REX prefixes for address manipulations is still a pure loss.

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.

Huh? Do you do compiler work? Surely you have seen methods with more than 128 bytes of local variables after inlining has occurred?

Besides, as compiler writers, we don't have the luxury to tell application developers to "just redesign your code".

I don't understand your linkage complaint -- the more parameters passed in registers, the fewer that will end up on the stack.

Forget the linkage complaint, it's bogus. I was thinking of a different parameter-related problem that is specific to the compiler I work on right now. It's not a general problem.