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

[afidel]

Yamhill. From all the rumors it is still alive and should the Athlon64/Opteron really take off expect Intel to come out with Yamhill, its own x86-64 chip. This will all but signal the end of IA64, it will at that point probably only be used for HPaq's large servers.

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

[gmack]

That had better be soon the Opteron has already outsold the Itanium during the last quarter. Mind you that says more about Itanium's popularity than it does the Opteron's.

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

[Anonymous Coward]

I call bullshit. IBM.com says that their Opteron system is not even available yet.

Also, their Itanium systems are big monsters start at $26,000, while the Opteron is a a dinky 1U thing starting at $3000. Of course the cheaper one is going to sell better.

Huh?

[eddy]

Huh? As far as is publically known, there is no such line of processors.

Well I'm hopefull.

[Harp3328]

I hope this means AMD will be able to compete on the high-end again. If I had a choice I won't buy intel.

Re:Well I'm hopefull.

[Anonymous Coward]

I hope that AMD actually starts getting some mainboard manufacturers that make server class boards. I don't have a problem putting an AMD processor into a server, I do have a problem with all the boards that the AMD attaches to.

Re:Well I'm hopefull.

[mjuarez]

Tyan and Arima already have dual motherboards out there. The Tyan K8W looks really nice for a workstation or high-end gaming machine. All 4P motherboards are not "available" per se, they're only should as complete systems. Check out Appro, Angstrom Computer or Racksaver for some 4P servers if you're looking for Opteron servers.

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.

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

[Anonymous Coward]

if you check the pricewatch link again, 1.8GHz Opterons (aka 244) are in the range of $675. you probably meant the 242, which is 1.6GHz

Re:Opteron Benchmarks, not Athlon 64

[WoTG]

144's are at $450. Probably best to compare A64 price to the single-proc. Opteron...

Re:Opteron Benchmarks, not Athlon 64

[mattdm]

I don't get why people are so excited about non-ECC memory these days. It's almost impossible now to buy a low-cost system that supports ECC, which I find quite peculiar. Sure, I understand that many people don't care if their computer crashes every now and then due to a random bitflip error, but it seems like there'd be enough applications where cheap-but-trustworthy-results are important to make a market....

Re:Opteron Benchmarks, not Athlon 64

[Anonymous Coward]

I recently built a machine, ended up with bad memory that didn't show up in any memory tests, it took me a lot of time and effort to confirm that it was the memory...had I bought it from a place that didn't have such a reasonable return policy, I'd have been screwed. ...ended up wishing I had built the system with high-end components like I usually have in the past (SCSI, ECC)...but the price difference is getting huge.

Re:Opteron Benchmarks, not Athlon 64

[Hoser McMoose]

All Athlon64 and Opteron machines will support it. This is a GOOD THING IMO. Fortunately Intel's newest chipsets also support ECC, though it's up to the motherboard manfuacturer to not fuck things up and break said support. (so, for example, Asus would probably make this work, but companies like Abit probably would not, much like how Abit's old 430HX motherboards never worked with ECC memory). In the case of the Athlon64 and Opteron, the memory controller is on-die so the motherboard manufacturer's would REALLY have to go out of their way to break this feature.

For some reason though people seem to consistantly confuse ECC memory and registered memory. The Opteron (and presumably the Athlon64 FX) required REGISTERED memory, not ECC memory. This is why the memory is slower and costs more. ECC is only a few dollars more expensive than non-ECC memory and has virtually no effect on performance (it adds a cycle here and there, but nothing significant at all). Registered memory is what costs twice as much as non-registered (aka unbuffered) memory and is a tiny bit slower.

Re:Opteron Benchmarks, not Athlon 64

[ottawanker]

I got the following prices by visiting a local computer store:

AMD Opteron Server Model 144 Processor $691.00
AMD Opteron Server Model 244 Processor $1069.00
AMD Athlon64 Processor (Pre Order) $639.00

There are no details listed for the Athlon64 as to speed, etc.. Also, prices are in CDN dollars. Convert to US and you get $498, $770, and $461, respectively.

Re:Interesting

[the_2nd_coming]

umm....are you daft!!!

AMD is the company that has the x86-64 line.

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

[sundling]

What you're not considering is that there is an
Athlon 64 that IS dual channel and that's the FX one. So expect it to be a bit better performance than Opteron because it will likely not require ECC memory.

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]

It's not a one way Opteron in that all Opterons have 3 HT (HyperTransport) controllers and all A64's only have 1

Re:Not an Athlon64, but an Opteron

[Anonymous Coward]

Wrong. The Opteron 1xx has only one HT channel -- or it would if it actually existed instead of being vaporware.

Re:Not an Athlon64, but an Opteron

[Anonymous Coward]

Is it just me, or has AMD's marketing gone insane? They have five different targeting a market where Intel has only two (and three times as many sales):

Athlon XP "Classic"
Athlon 64
Athlon 64 FX
Opteron 1xx
Opteron 2xx

versus

Pentium 4
Xeon

No wonder people are confused. Oh, there's also a rumor of a 32-bit crippled version of the Hammer, presumably for HP and other vendors that fear the wrath of Intel.

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

[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.

Re:Not an Athlon64, but an Opteron

[Anonymous Coward]

You forgot 2 Intel lines:
Itanium and Itanium 2.

Re:Not an Athlon64, but an Opteron

[Anonymous Coward]

I also left out the Xeon MP, the Opteron 4xx, and the Opteron 8xx (and Celeron, Duron, etc). Because those aren't options for the high-end desktop/workstation/small server markets.

Re:Not an Athlon64, but an Opteron

[Anonymous Coward]

On further checking, my post was based on hardware fanboy site info and was completely bogus. Thanks for the correction.

Re:Not an Athlon64, but an Opteron

[dpilot]

More to the point, you forgot Celeron.

If you want to complicate things more, you can bring up Pentium-M, but then of course you'd have to bring up the various flavors of Mobile Athlon, but then you'd also have to bring up the various flavors of Pentium-4.

As someone else mentioned, you also forgot Itanium and Itanium 2. If you want to bring up the differences between Opteron 1xx and 2xx you have to bring up McKinley, Deerfield, and Madison, and the plethora of cache options between them.

Or just give up. Realize that AMDs 64 bit line really isn't here in volume yet, and that's why it may look confusing. IMHO, it's approximately as mixed-up as Intel's.

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:Not an Athlon64, but an Opteron

[Hoser McMoose]

The reason why Opteorn boards with AGP and PCI-X slots are few and far between is because of the chipset used. AMD's 8000 Opteron chipset has three chips, an AGP tunnel, a PCI-X tunnel and a legacy I/O hub (AMD uses the term "hypertransport tunnel" as opposed to the old "PCI bridge" terminology of north/southbridge days or Intel's "Accelerated Hub Architecture").

So, if you want to use AGP, you just use the AGP tunnel. If you want PCI-X, you just use the PCI-X tunnel. If you want BOTH, than you need to use both chips, which is a little tricky since they can't be chained together (the legacy I/O hub can be daisy-chained to the far side of either, but it uses a narrower HT connection). Instead you have to either tie them to a second Hypertransport link on your processor (Opteron's all come with 3 hypertransport links) or you put the AGP tunnel on one processor and the PCI-X tunnel on the other processor in a dual-processor machine. End result is a rather tricky design, not only from a BIOS point of view but also simply getting all the traces to go to the right place on the board.

Fortunately boards DO exist that make use of both chips. Tyan's Thunder K8W is the only one I've seen that is (apparently) shipping, but I've seen pictures of an MSI board as well.

Unfortunately this will NOT be possible with AMD's Athlon64 chips (either the Athlon64 or the Athlon64 FX), since these chips have only a single hypertransport link enabled. If you want AGP and PCI-X on an Athlon64 system, you'll have to wait until another chipset comes out to support said features.

Ohh, a quick note about the AthlonXP in an Athlon64 socket rumors, my guess is that if such a chip exists, it will be a fully-functional Athlon64 with 64-bit mode disabled in the BIOS.

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.

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?

Re:64-benchmarks wont be good

[robbyjo]

If you read the article, the comparison is against Dual P4 Xeon. Some of the tests didn't enable any hyper-threading stuff (and thus it didn't take any advantage of the dualies. Opteron beat P4 by very high margin. Except for content creation & general usage stuff where the P4 wins. But take that with a grain of salt.

64-bit tests won't be fair to either side. It's like comparing apples to oranges. For me, I'm looking forward to see vis-a-vis comparison on programs that is optimized on either platform. For example: A program that is optimized on Itanium and Opteron and see how they fare.

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?

[Anonymous Coward]

Stop making crap up. I have a master's degree in microprocessor design and everything you just said is completely fabricated nonsense.

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?

[Anonymous Coward]

You want every single instruction to carry an extra bi to see if it's executable? How the fuck do you expect that to work?

Re:Will it be secure?

[cptgrudge]

My God, I *am* a geek.

We wouldn't have it any other way, Amoeba.

Re:Will it be secure?

[Anonymous Coward]

No. Executable bit on memory so instructions located on the stack could not be executed, preventing most of buffer overflow cracks.

Re:Will it be secure?

[Jage]

Mod up the parent. Unfortunately I have to say he got it right... It's all nonsense in grandparent.

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

Re:Will it be secure?

[Flower]

My understanding is that the Athlon64 will be able to do this in 64-bit mode. At least that is the information I'm getting from reading the OBSD archives and is the reason why my next PC will be an Athlon64.

Re:Will it be secure?

[wackybrit]

In addition to the above post, this feature also spells the end of buffer overflow attacks, since data and code are truly separated. Even if a sloppy programmer makes his data spill everywhere through a 'data' area of memory, it doesn't matter, it's not directly executable without copying it to 'program' memory first.

Re:Will it be secure?

[Jah-Wren Ryel]

No, you got it wrong and so did the AC.

Here, read up on self-virtualization for x86/ia32:

http://www.extremetech.com/print_article/0,3998, a= 20322,00.asp
http://os.inf.tu-dresden.de/~jn4/dip lom/lawton.txt

Re:Will it be secure?

[Weirsbaski]

Opteron has the no-execute-pages feature, so does Athlon64. On both cpu's, the feature can be enabled in PAE paging mode, so both 32-bit operating systems and 64-bit operating systems can use it.

Of course, the operating system has to enable the feature, and has to actively mark pages no-execute.

Re:Will it be secure?

[Anonymous Coward]

Hmm, haven't x86 processors *always* had the executable bit in the page tables? they were there 10 years ago when my company was writing a DOS extender, have they disappeared?

Are you sure it isn't the OS that requires modification? I remember recently reading an article on how one of the unixes was made 'safer' in such a manner.

Re:Will it be secure?

[steveha]

Perhaps that DOS extender was playing games with the segment registers?

Modern 32-bit operating systems (including Linux, *BSD, and Windows) all treat the x86 as a flat, 32-bit processor. The segment register features are not used. This discussion is about using the memory management unit to mark certain pages as non-executable.

steveha

Re:Will it be secure?

[Anonymous Coward]

"since data and code are truly separated"

What the FUCK!

Having data and code as one was one of the major design decisions of the x86 and all modern processors!

Re:Will it be secure?

[ChaoticLimbs]

Nerd.
wait,... I read your resume.
You are an accomplished nerd.

Re:Will it be secure?

[Peter Cooper]

I think he means separated in the sense that they reside in different areas of memory. One area, of which, can be set to be non executable (or, in this case, one can be set to executable, making the other non executable by default).

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.

Re:Semantics, maybe, but...

[Magic Thread]

Yeah, I meant to say IA64. Apparently the mods didn't realise it was an innocent mistake... Oh well. I have plenty of karma to burn.

Re:Semantics, maybe, but...

[Thing 1]

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.

Does this remind anyone else of the trick IBM tried to pull in creating the MCA specification? The industry moved on and created PCI, leaving MCA in the dust.

AMD appears to be doing the same thing to Intel now, and Intel's MCA is IA64. Intel wants to radically change things; however, the industry prefers evolution to revolution.

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...

[Anonymous Coward]

"support for larger system memory sizes. This won't help you in video games, but it will help you doing high end photoshop"

Bullllll-shite. Games are one of the most memory intensive applications.

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:64bit performance gains...

[doomy]

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)


How would this not help games? My "Republic : The Revolution" supports only systems with 512 MB of ram or more.

I think the cheaper the ram becomes the more we'd see programmers making unoptimized memory hogging games and thus games in general would become highly dependent on a large memory system.

Re:64bit performance gains...

[emmons]

How would this not help games? My "Republic : The Revolution" supports only systems with 512 MB of ram or more.

Because at the moment, games don't need much more than 512mb. Right now you can put up to 2 gigs in a 32 bit system. (More with SMP Xeon systems, but it's a hack that the OS and application have to support.) When games start needing more than 2 gigs then there will be an improvement with a 64 bit system and more ram.

Re:64bit performance gains...

[Jameth]

I am sorry that you are stupid.

Really, I am.

Re:64bit performance gains...

[shawnce]

Your wrong...

Either you will be using 32 bit addresses or 64 bits addresses and that depends on how you compile your code. It doesn't vary based on the amount of RAM in the system, it is locked in at compile time.

Re:64bit performance gains...

[timeOday]

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.

I think processors already have alot more than the addressable number of registers, which are used by dynamically remapping the addresses during execution. Sounds ugly, and doing it in the compiler will surely work somewhat better, but it decreases the performance increase we can expect.

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...

[sirsnork]

Actually the number you're thinking of is 4GB. Also the opteron/Athlon64's will improve 32bit apps in other ways when large amounts of memory is required. This happens because _EACH_ 32 bit app can access it's own 4GB of memory. The OS/kernel will not be in this memory so the app will have all 4GB to itself. Unlike any 32bit based system today where the OS/kernel will typically take 1GB for itself

Re:64bit performance gains...

[Toraz Chryx]

Number of photoshop images that I've seen topping 600MB (plus application + undo buffer) = lots
number of games that use >512MB of ram = not very many

Game devs would have to be frickin' idiots to assume everyone has 4GB of ram to run their game.

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...

[Omnifarious]

Since most applications do not need a 64 bit address range, will it be possible to still use all the juicy 64 bit number manipulation for 64 bit numbers but still keep 32 bit pointers for most things?

In fact, I think it will be at least 5 years, and probably a decade before the average application needs to use more then 31 bits of address space.

Re:64bit performance gains...

[Performer Guy]

1) Is NOT an inate property of a 64 bit processor. You could build a 32 bit processor with more registers.

2) is valid

3) True but almost no software I use does much 64 bit type processing.

4) You could do this with a compiler, it the instruction is slow, yu don't save die area because you need to support it in 32 bit mode.

You missed out the biggest winner, the massive cache on this processor, 1MB I believe, that's a big step up.

You put a cache that size on a 32 bit Athlon and you will see some big improvements.

I don't think it's right to say 64 bit is inherently faster, if your application needs it then yes, but for 32 bit class apps, 32 bit mode is faster.

Re:64bit performance gains...

[p3d0]

I wonder if it will be possible to use 32 bit pointers within the X86-64 isa?

In a word, no. If you want the extra regs, you get 64-bit addresses. You could always limit yourself to the low 4GB of memory, though. Then you could just omit the REX prefix from loads and stores of addresses, which would have the effect of zero-extending them while they are in regs, while also making the code a bit smaller!

Incidentally, they seem to have abandoned the terrible name "x86-64" in favour of the much more sensible "AMD64".

Re:64bit performance gains...

[Anonymous Coward]

> where the OS/kernel will typically take 1GB for itself

"Typically" is actually 2GB (default for Windows and Linux), which I think where the parent got his number from.

Re:64bit performance gains...

[akuma(x86)]

Those are good points. Let me now enumerate the disadvatages of 64 bits over 32 bits.

1) Your data caches will appear smaller (relative to 32 bit code) because your pointers are now twice as big in order to address that nice 64 bit space.

2) Since your ALUs needs to be twice as wide, they can't go as fast. The ALU path in a microprocessor is very speed critical and is often what dictates the maximum frequency you can run at.

3) Since your datapath is twice as large, you will inevitably burn more power.

4) The way x86-64 is defined, it complicates the x86 decoder thus reducing it's speed/power-efficiency.

It is not clear that 64 bits by itself will universally boost performance. As with most engineering problems, there are advantages and disadvantages and all factors must be considered.

The Athlon64 will be a good, high performance product, but don't credit the performance to the 64-bitness of it. It will be good because of it's microarchitecture (as opossed to it's ISA).

ISAs are way way way overrated. The provide at best a 2nd order effect on performance.

Re:64bit performance gains...

[Anonymous Coward]

You can easily do 64-bit math with any Pentium MMX or later processor. All these processors contain 8 64-bit registers and support several MMX quadword instructions.

PMOVQ - Move
PADDQ - Add
PSUBQ - Subtract
PAND - Bitwise AND
POR - Bitwise OR
PSLLQ - Shift Left
PSRLQ - Shift Right

P4's also support holding results from 64-bit multiplication via its 128-bit XMM registers.

Re:64bit performance gains...

[drinkypoo]

Most of it is ints? I thought something like 50% of the average executable was either a jump, a conditional jump, or a test...

Re:64bit performance gains...

[drinkypoo]

You can build a 32 bit processor with more registers, but you can't build a 32 bit x86 processor with more registers, it wouldn't be x86. It's just nice that they took advantage of their break from x86 and added more.

Any software which deals with data types larger than 32 bits will benefit from 64-bitness. This is most software. Even string operations will speed up, once your libraries are 64 bit.

You're right about the big cache being hugely significant of course, but it's not the only reason this thing is so badass.

Re:64bit performance gains...

[Jeff DeMaagd]

One thing to watch out for is that not all of the new chips will be 64 bit. There will still be a few performance grades, and the lowest and most common at the start will probably not run the new instructions, and I think will only run a single channel memory bus.

I am looking forward to seeing what systems come out, and also Intel's Prescott systems, so that the existing Athlons and P4s will come down in price.

Re:64bit performance gains...

[glitch!]

Since most applications do not need a 64 bit address range, will it be possible to still use all the juicy 64 bit number manipulation for 64 bit numbers but still keep 32 bit pointers for most things?

For programs that fit nicely in a 32 bit address space, perhaps you could designate one of the 64-bit registers as a base pointer, and store all the addresses as offsets? This may be cheaper than you think, since we now have 8 additional registers to play with.

In fact, I think it will be at least 5 years, and probably a decade before the average application needs to use more then 31 bits of address space.

Perhaps. On the other hand, for some applications it may be useful and convenient to map large files into memory (using mmap or equivalent) instead of the traditional file read/write methods. (This is a REALLY OLD idea, by the way.)

With using file reads and writes, the application has to allocate data buffers, do the reads and writes, and often maintain a cache of current or often used data. The read and write operations will probably require a memory copy between user and kernel space.

With memory-mapping a file, the OS and virtual memory system handles all the buffering and other details, and you can treat the file as one huge memory array. Just don't forget to msync() from time to time :-)

One big problem with mmap()'ing big files is that you run out of address space when the file is big. On a 32-bit CPU, this might be anywhere between 512MB and 4GB depending on the architecture and OS. With 64-bit address space, it may be possible (and maybe even customary) to map large and huge files for performance and convenience reasons.

Re:64bit performance gains...

[Anonymous Coward]

Linux default is 1GB.

Re:64bit performance gains...

[wayne606]

I don't know if there is an average application... Text editing has never needed it and never will, and scientific codes have needed it for the past 10 years. We are *way* past the point where the latest and greatest CPUs are any use to the average person (unless they play games I guess)

Re:64bit performance gains...

[Anonymous Coward]

Are you telling me 512 MB is small? It's large for a game, I find it hilarious that games are needing more and more memory now and here you're stating that 512 is enough. We are talking about 512 MB -- see .. That's like the MAX system memory most high end users have. Do you see where we are getting.

Well I guess you were trolling cause your post didn't make any sense (well maybe in your twisted logic it did).

Re:64bit performance gains...

[p3d0]

Well, it's hard to have MMX math coexist with x87 math because they use the same register file, and I think it's slow to move data from GPRs to MMXs, so I wouldn't exactly say you can "easily" do it, but yes, I suppose it can be done.

Anyway, I'm no expert on this because our compiler doesn't use MMXs yet. And regardless, 14 regs is still better than 8. :-)

Re:64bit performance gains...

[p3d0]

Or am I missing something?

Yes, you certainly are. To begin with, you're assuming that RAM gets addressed starting from zero, which it doesn't in some OSes. For instance, linux seems to put DLLs at around 0x2900000000, and the stack grows down from 0x7fffffffff, both of which are already out of 32-bit addressing.

But even simpler than that: suppose you only set aside 4 bytes for a certain pointer. Then suppose you do indeed wind up using more than 4GB of ram. The next time you call malloc, you'll get a pointer beyond the 32-bit address range. How do you store that in your 4 byte pointer?

Look at it this way: in today's 32-bit programs, if you only use less than 64KB, does that pointers only occupy 16 bits? I wish that were true, but it's not. Generally speaking, a pointer is a pointer, and a pointer must be large enough to address all of the memory that the program could possibly reach at runtime.

If you can make your scheme work, you could probably get a best-paper award at some conference some place. Personally I'd love to see something like this work, because it bothers me to use up 8 bytes for each pointer when we know statically that the machine only has 256MB of RAM in it. :-)

Re:64bit performance gains...

[p3d0]

For programs that fit nicely in a 32 bit address space, perhaps you could designate one of the 64-bit registers as a base pointer, and store all the addresses as offsets? This may be cheaper than you think, since we now have 8 additional registers to play with.

No, I'm pretty sure that would suck hard. Whatever addressing modes your CPU provides, you just lost one register. For instance, AMD64 provides [base + stride*index + offset] to access arrays. Your scheme could no longer access that in one memory reference; you'd need an extra add instruction.

On the other hand, for some applications it may be useful and convenient to map large files into memory.

You should see the alloc stream facility. It has performance at least as good as a whopping big memory-mapped file, but without eating a lot of address space. It's a nice interface; too bad nobody uses it.

Re:64bit performance gains...

[p3d0]

Don't be so sure about the cache. Bigger caches are slower. Make sure you know the cache latency before you claim a bigger cache is better.

Anyway, some Xeons have a 6MB L3 cache, so 1MB isn't a big deal.

Re:64bit performance gains...

[p3d0]

No, register renumbering doesn't help when you just don't have enough regs. Renumbering is to eliminate unnecessary dependencies between uses of the same architectural register. For instance, renumbering can turn this:

load r1
store r1
load r1
store r1

into this:

load r1
store r1
load r2
store r2

Then, all these stores can be reordered internally, which would have been prevented otherwise.

If you don't have enough architectural registers, then the compiler must insert spills to memory, and only store forwarding and data caches can help with spills. But caches are never as fast as registers, and you still have the instruction cache footprint of that spill code.

Re:64bit performance gains...

[Anonymous Coward]

You wrote "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.)"

People who have actually recompiled applications that I'm aware of report a 5-10% size increase. It appears that the greater number of registers in x86-64 mode mitigates most of the damage of the items you are talking about.

Re:64bit performance gains...

[ocelotbob]

I'd say that it's going to be 2 years until most home PCs are 64 bit for one compelling reason. Media. Even today, it's trivial to create a >4GB media file, especially with video, or audio with many, many tracks. Yeah, there are workarounds, but at the same time, it'll be much easier on the programmers, and lead to a much simpler debug process, if the design stage didn't include having to worry about an internal swapping mechanism for keeping track of an entire multi-gigabyte movie.

Re:64bit performance gains...

[Natalie's Hot Grits]

Nice points...

The only thing i can say about the pointer size is that the cache on the opteron is much larger.. The Athlon64 however I don't know the cache size, but I hope it will be somewhat larger than current Athlon XP systems.

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:64bit performance gains...

[Natalie's Hot Grits]

1) Is NOT an inate property of a 64 bit processor. You could build a 32 bit processor with more registers.

I never said you couldn't do this with a 32 bit processor, but in the AMD64 case, you must be in 64 bit mode to access the extra registers AMD put into the chip..

This is why you will get a nice speed improvement when your applications are recompiled to take advantage of AMD's 64 bit mode (and the OS needs to support it too)

For these reasons, in the case of AMD64 architecture, you will almost always get better performance in 64 bit mode even if you are only doing 32 bit integer math. Simply because more registers are available to the compiler.

The only case you would not get better performance is when your program is so trivial that all the data it is working on can fit in the legacy x86 registers. This almost never happens in the real world.

4) You could do this with a compiler, it the instruction is slow, yu don't save die area because you need to support it in 32 bit mode.

I am not 100% sure, but I believe while in 32 bit mode, the CPU also emulates these legacy functions. But I do not know for sure... Either way, it is cleaning up the ISA, which is a good thing for future processors that will not need high performance 32 bit modes.

I don't think it's right to say 64 bit is inherently faster, if your application needs it then yes, but for 32 bit class apps, 32 bit mode is faster.

32 bit mode will almost never be faster than 64 bit mode on the AMD64 architecture (only exception is if your application has so many [64 bit] pointers that you get a significant increase in cache misses) The extra registers alone will almost ALWAYS improve execution speed over 32 bit mode which only works with the legacy registers. The reason that 32 bit mode will not be any faster is because the 32 bit mode is only a subset of the instructions available in 64 bit mode, and thus must pass through the exact same pipeline for each instruction. For these reasons, I believe it is correct to say that 64 bit mode will almost always be faster, even on legacy 32 bit code. There are only a few circumstances where this isn't true, and you would probably have to create these circumstances yourself in a test case, which wouldn't be real world code.

Re:64bit performance gains...

[Natalie's Hot Grits]

It is not clear that 64 bits by itself will universally boost performance. As with most engineering problems, there are advantages and disadvantages and all factors must be considered.

I agree with all your points... But in this case, simply because more registers are available in 64 bit mode, performance will increase in most circumstances (the cache missing is one big disadvantage, but they tried to make up for it with larger 1MB cache)

I'm not saying that the 64 bitness of the CPU is making it faster, I was pointing out the benefits of switching from 32 bit mode on AMD64 to 64 bit mode on AMD64. In this comparison, the 64 bit mode will be faster most of the time.

Your points of the wider ALU's is right on, but since in 64 bit mode the clock will be the same as in 32 bit mode, this point only concerns me when comparing Athlon 64 with Athlon XP, which I am not. however, this does mean that it will be harder to scale the clock speeds of the Athlon 64, but hopefully the microarchitecture people will help in this area.

I believe fully in your responce about microarchitecture being key, but when comparing the same microarchitecture (athlon 64 vs athlon 64 in 32 bit mode) then the ISA does make the difference.

Re:64bit performance gains...

[Fembot]

Actualy talking of OO programing have sun released an optimised version of the JVM for Athlon64/Opteron/FX? Wouldn't that rather eat at their SPARC markets though??

Re:64bit performance gains...

[akuma(x86)]

I'm not saying that the 64 bitness of the CPU is making it faster, I was pointing out the benefits of switching from 32 bit mode on AMD64 to 64 bit mode on AMD64. In this comparison, the 64 bit mode will be faster most of the time.

If you are assuming an IA-32 compiled binary, then running in 64 bit mode gets you no advantage since you don't use the 64 bitness with an IA-32 binary.

Ok, so you are assuming that the app that you will run has been compiled for both IA-32 and x86-64 and you are making the comparison of 2 different binaries run in 2 differents modes on the same Athlon64...

If this is the case then it is not completely true that performance will always increase due to the pointer doubling issue. The caches will look smaller and the demand on memory bandwidth will be greater.

Now to the issue of increasing the number of architectural registers...

The advantage of more registers is significantly diminished in the presence of store-to-load forwarding that occurs in the processor hardware (in virtually all state of the art processors).

If you run out of architectural registers, the compiler will spill the excess to the stack. All of the registers that need to spill to memory are spilled to the stack via stores. In modern microprocessors, these stores write to a store forwarding buffer. Subsequent loads that need to read the stack will simply get their data from the forwarding buffer and not the memory system. These loads execute much faster because the data is in a local forwarding buffer and not a larger/slower cache, so they look more like register reads.

This is just one example of the many tricks that we computer architects play to get around ISA inconveniences.

There are even more elaborate tricks to get around this problem. You can completely eliminate both the spill-store and fill-load out of the critical path. If you are interested, do some research on "memory-renaming".

Re:64bit performance gains...

[Omnifarious]

I know about mmapping large files. My big problem with that is that you completely lose all control of when you take the latency hit for a disk read. But, you're right, there are some applications for which it would be a big help to be able to mmap truly huge files.

Re:64bit performance gains...

[Anonymous Coward]

I've spent a considerable amount of time porting x86 code to MIPS and contrary to my expectations the executable usually comes out about the same size. The savings from a bigger register file and a 4 register calling convention seem to balance any loss to wider instruction coding or the RISC nature of MIPS. The code just ends up having less register spilling and stack manipulation.

I've recently started using an embedded CPU with even more registers, a 6 register calling ABI and even wider instruction coding and again it all seemed to balance out.

The memory overhead from wide pointers looks like the only real concern. I can't see any 64 bit system shipping with so little memory that matters. The beauty of big register files is pointers don't get spilled very often making memory bandwidth a non-issue.

Re:64bit performance gains...

[Anonymous Coward]

> OO data tends to have a lot of pointers.

[ which will be twice as large on 64 bit systems ]

Well, nobody said you *have* to program according
to the OO paradigm ...

Patient: It hurts when I do _this_.
Doctor: Don't do it, then !

Toon Moene (current GNU Fortran maintainer)

Re:64bit performance gains...

[Carewolf]

Not directly, but a good compiler could emulate it. By making all pointers 32bit + base. The Base would have to be either a simple constant(like 0) or in a register, but there would still be more registers than in old x86 code.

Re:64bit performance gains...

[Anonymous Coward]

I don't see the benefit of 64-bit integers. I don't run scientific programs where my 32 bits isn't enough accuracy for what I want to describe, especially for integers (maybe it will speed up double calculations, but I use those rarely as well). I wonder if it will become an optimization to store two 32-bit integers into a 64-bit value and therefore be able to use pseudo SIMD type instructions... does anyone know if it already supports a set of SIMD instructions?

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.

Re:64bit performance gains...

[Performer Guy]

It is a big deal compared to existing 32 bit processors. Yes cache latency is important, but eliminating the cahe miss and therefore system memory latency is always a win., You don't stall the processor as often.

Re:64bit performance gains...

[p3d0]

Good points, except:

The memory overhead from wide pointers looks like the only real concern. I can't see any 64 bit system shipping with so little memory that matters.

For one thing, presumably people bought that memory because they want to use it. It's not like half their RAM is sitting around doing nothing, and will happily store those big pointers with no price and/or performance penalty.

But aside from that, this affects the whole memory hierarchy. It increases cache footprint. Even more important, it increases memory bandwidth usage.

And, to top it all off, we're comparing AMD64 executables against IA32 executables running on the same AMD64 machine. You'll get less data stored at each level of the cache hierarchy compared to IA32 code on the same box, so performance will suffer.

The beauty of big register files is pointers don't get spilled very often...

Yes...

...making memory bandwidth a non-issue.

No! First, spills don't need memory bandwidth, because spills read and write near the top of the stack, which is always in the L1 cache anyway. Second, memory bandwidth is almost always an issue on those server machines that needed the 64-bit address space in the first place.

Re:64bit performance gains...

[Performer Guy]

I tend to disagree. Yes data types > 32 bit will speed up but they do not dominate most applications. Sizeof for most common types is 32 bit or less. As for not exploiting x86, you should realize that the registers come from redefining the instruction set etc, you could do this with x86, you can add registers, and this has been done in the past. And SSE has 128 bit registers to operate on types as an indication of what's possible now by scaling performance on smaller types so if you're recompiling you can win anyway on existing x86 platforms.

This is what's rather confusing about the debate here, features added to these CPUs that have nothing to do with x86.

Re:64bit performance gains...

[p3d0]

True. On the other hand, if you replace a 256KB L2 cache with 1 cycle latency with a 1024KB cache with 2 cycle latency, that will help some programs and hurt others. It depends on their working set size; those with working sets between the L1 cache and 256KB will get slower; those with larger working sets will get faster.

Re:64bit performance gains...

[Performer Guy]

32 bit not being faster than 64 bit on the same CPU is NOT the point. It's what you could have done with 32 bit & the same die area with a 1MB cache and onboard dual channel memory controller extra registers etc and NO 64 bit support with a dedicated 32 bit CPU that is the valid comparrison of the relative merits.

Re:64bit performance gains...

[Performer Guy]

P.S. I meant "features added to the CPUs that have nothing to do with 64 bit computing", but the advocates of 64 bit computing are listing them as inate advantages of 64 bit CPUs.

Re:64bit performance gains...

[Natalie's Hot Grits]

32 bit not being faster than 64 bit on the same CPU is NOT the point

It isn't? It sure as hell is my point. And you replied to it. So you are making an OT point. in which case you deserve an OT moderation...

My origional post was CLEARLY stating performance enhancements going to 64 bit mode ON THE AMD64 PROCESSOR. It states that in the FIRST paragraph of my post. READ IT again.

If I was talking about 64 bitness over 32 bitness in general, on different architectures, then you might have a point. But I wasn't so you don't.

It's what you could have done with 32 bit & the same die area with a 1MB cache and onboard dual channel memory controller extra registers etc and NO 64 bit support with a dedicated 32 bit CPU that is the valid comparrison of the relative merits

On the same die area, they probably could have made a pimp ass 32 bit cpu that killed the P4. But they didn't. Insted they made a 64 bit CPU that had a 32 bit legacy mode, that killed the P4 in both modes. Nobody is going to recompile their programs to support those extra registers if they are still in x86-32 land. So you hypothetical CPU is pretty much worthless, and AMD64's CPU in 32 bit mode is effectively what you would be getting with this makebelieve CPU. (Its microarchitecture is almost identical to the Athlon XP, but with the 64 bit extentions added on top, extra cache, and on die memory/HT controller)

Re:64bit performance gains...

[n8_f]

No, you misread the original poster. He never said these were advantages of 64-bit chips in general, just the AMD64 implementation. You didn't read his post very carefully and assumed he was saying they were innate advantages of 64-bit CPUs.

Re:64bit performance gains...

[tigersha]

A somewhat off-topic question but since you seem to be a compiler guy...

How much more difficult is it to write a compiler backend for EPIC's VLIW architecture than for x86/64?

VLIW has always been very dependent on compiler optimizations to squeeze performance out of the chip. Is this realistic with modern optimization stages?

Re:64bit performance gains...

[p3d0]

I'm not a VLIW/EPIC expert by a long shot, and I'm not on the IA64 team, but as I understand it, they can generate pretty good code with a few tweaks to the traditional compiler stages, and a wicked instruction scheduler.

Re:64-benchmarks wont be good

[xSauronx]

wish they would have included benchies for the athlon64 at stock speeds.

Re:64-benchmarks wont be good

[kenneth_martens]

Intel's IA-64 emulates 32-bit unlike AMD's 64-bit chips which have 32-bit hardware. So we can expect AMD to beat Intel easily in 32-bit stuff.

If you had RTFA, you would know that the benchmarks compared the Athlon64 against Pentium 4s and Xeons, not against IA64. What the benchmarks show is that the 32-bit performance of the Athlon64 is on par or better than the best Pentium 4 processors, and is better than the current Xeons. IA64 is not benchmarked in the article.

The 64-bit performance of the Athlon64 is not being benchmarked in the article; it is the 32-bit performance relative to leading 32-bit processors that is the issue.

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...

Re:Interesting

[Slack3r78]

AMD is the company that has the x86-64 line.

But due to cross licensing agreements, Intel could build an x86-64 chip if they decided to, and in fact, there are rumors of a "Yamhill" project at Intel that is just that. Intel's still betting a lot on IA-64, but they're not quite crazy enough to bet the farm yet.

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

[scd]

Generally speaking, this is true. However, AMD has added more registers that can only be accessed when running in x86-64 mode. I think the register count goes from 8 to 32.

This could make a big performance difference if an application is compiled with these additional registers in mind.

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.

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:About 64-bit gaming performance

[Anonymous Coward]

"Apart from the utter pointlessness of 64-bit gaming for the coming years"

Quick! Someone send this post to Epic games. They are wasting money developing a 64-bit version of Unreal Tournament. If only they had consulted with this slashdot reader first they could have saved millions.

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:About 64-bit gaming performance

[Anonymous Coward]

They said they've done some testing, but AFAIK there's been no product announcement.

Whether games are released for AMD64 will depend on business factors, not the number of registers on the CPU.

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:About 64-bit gaming performance

[Anonymous Coward]

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

Re:About 64-bit gaming performance

[mjuarez]

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.

There is no "context-switch" delay. The processor takes exactly the same amount of time doing a context-switch at 64-bits than at 32-bits. Remember that the processor has to do a certain number of clocks per second, and it cannot "fall behind" or get delayed.

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.

If you read the article, you will have noticed that Opteron has an integrated memory controller. In this case, it means the controller was moving data at 2.0Ghz. This adds up to significant increases in performance in the benchmarks, as could be seen by the article.

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.

Absolutely true. It can be slower (just take a look at Itanium :-), but it shouldn't! Did you even read the article? In most of the benchmarks, the Opteron was even faster than dual-Xeons (although I'm not sure the benchmarks were fully using the additional processor) I didn't see a "performance hit" anywhere in the benchmarks.

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

Re:About 64-bit gaming performance

[dastrike]

In 64-bit mode on the Opteron/Athlon64, there are 16 64-bit GPRs available, RAX, RBC, RCX, RDX, RBP, RSI, RDI, RSP, which are the 64-bit extensions of the current IA32 GPRs, and R8 - R15 which are new for AMD64.

And there are 8 new XMM SIMD registers (SSE/SSE2) too: XMM8 - XMM15

Re:About 64-bit gaming performance

[MROD]

Yes, I did read the article. However, the benchmarks were done using the Opteron in its full 32 bit compatability mode. ie. it pretends to be a 32 bit x86 family chip and hence the overheads due to the extra register loads/saves to/from main memory don't apply.

You also state that there's no "context-switch" delay. I'm fraid you're mistaken as all processors have to copy out their register contents to memory and load those of the new process every time the operating system pre-empts a process and loads a new one in its place, otherwise the userland processes would see the CPU changing below them without them doing anything, which wouldn't work. It's the way multi-processing works. During the time in which the data is being written to/read from memory (be it cache or main memory) the processor is effectively idling waiting for the process to complete.

If you don't believe me, have a read of some 1st year undergraduate computer system design books. I'll try to look up some references if you would like?

Re:About 64-bit gaming performance

[MROD]

I agree that it's FAR less of a problem than it was in the past. However, seeing as more and more programs are being written with a large number of threads it can still add up to a significant performance factor, especially if the contexts are bumped from level1 to level2 cache or (God forbid) main memory as you then have lots of memory latency to worry about.

There is still the awful problem of pipeline flushing as well, though this is unlikely to change between 32 bit mode and 64 bit mode. I can't remember how deep the pipelines are on current ALU's but dumping and restarting an instruction pipeline can still steal excrutiatingly large numbers of cycles if someone gets it wrong.

Re:About 64-bit gaming performance

[mjuarez]

Totally agree with your post. I also believe you meant "multitasking" when you said "multi-processing".

The integrated memory controller should do away with any delay there could be because of doubling the registers. Remember that, even if you there are 32 registers at 64bits in the processor, this amounts to only 256 bytes. Granted, a context switch could be done every 10ms, but even then, during those 10ms, the processor has gone through 2 million clocks. This should be enough for copying 256 bytes around. Any additional delay by doubling the size of the registers should be negligible, IMHO.

Re:About 64-bit gaming performance

[MROD]

Yeah, I used the term "multi-processing" 'cos my OS lecturer during my MSc would do his nut if I used the term "multitasking" so I learned to use that term instead.

I used to use the term "multitasking" myself to describe the operation of a pre-emptive process-switching operating system before then.. when I used to program on the Sinclair QL in 68000 assembler.

Re:About 64-bit gaming performance

[Jahf]

Apart from the utter pointlessness of 64-bit gaming for the coming years because of the comparatively humble data requirements of current games

That's a chickenegg argument. Games today don't use more data transfer than the 32bit platform provides, but they -would- if they -could-. Data transfer has been a complaint of game architects since Quake II came out. They can't do it without alienating their customers until the hardware to support it is prevalent in the market. And honestly, that won't happen until Intel decides to support Yamhill -or- until a vast majority of new PC sales are based on the Athlon64.

So you're right, we still have years until there is a reason for 64bit gaming, but it is due to the hardware not being consumer level, not due to the people who make games.

Re:About 64-bit gaming performance

[Jahf]

forgot to convert my text properly ... chickenegg was meant to be chicken<->egg.

Re:About 64-bit gaming performance

[katz]

Why do you have to flush the pipeline?

Modern CPUs have HUNDREDS of registers internally. Context switching is just changing a single byte to specify another set of registers for a different thread.

Re:About 64-bit gaming performance

[Anonymous Coward]

You, and whoever modded you up as Informative, are complete idiots. There most certainly is a delay ina context switch, and it will be higher in new processors. That's because a context switch involves saving the current CPU state as the process sees it (basically all the registers and the PC) on the stack frame, and then loading in the next process's saved stack frame. As the Athlon64 has way more registers (2x?) than IA32, and they're twice as wide, there most certainly WILL be a difference between context switches on the two CPUs.

Re:About 64-bit gaming performance

[Anonymous Coward]

Well, if each process has 16 registers, it doesn't take very many processes before you start running out. I remember the ancient Sparcs we used to work on in university had 5 sets, and it was easy to tell when you've hit the limit.

Re:About 64-bit gaming performance

[MROD]

I must admit to not being totally up to date with all the modern processors, but from what I remember, surely this only applies to those processors which use register windows, lots of which have the registers in memory.

From what I understand, to be x86 compatible (as far as MMU OS operations are concerned) the processor has to act just like the old 386 with the OS doing all the context switch hard work in the interrupt code. Hence, the process is interrupted, the processor has to flush the instruction cache, jump to the interrupt routine which then copies out the process context to memory, loads the new process' context into the registers, sets the instruction pointer register to the right place and exits the interrupt routine and the processor starts reading and executing the instructions for the new process.

Re:About 64-bit gaming performance

[drinkypoo]

I love it when people act like you can use all eight "GPRs" in x86 as GPRs. Many operations depend on using a specific register, and that includes such mainstays as copies, and mathematical operations. In reality you have four true GPRs and four index registers... well, or considered another way, two long index registers. I know many instructions will let you use those registers for whatever you want, but not all of them will.

In other words... it's not a sane architecture. But presumably it was easy to implement the first time around, and now we're all paying for it. Sigh. If only the PC-1 had contained a MC68000. I once heard a story that said it almost did, but who knows if it's true. If anyone has information on that, I would be grateful.

Re:About 64-bit gaming performance

[be-fan]

It has to lok like its doing this, but doesn't have to do this :) A P4 has about 128 internal registers, and uses renaming hardware to present 8 to a given task. A given task may use more than 8 registers, where the CPU figures out ways to avoid spilling a register and doing a rename instead. Now, during a context switch, the CPU doesn't actually have to dump the full context of the processor out to memory. Most of the state gets buffered, either in the internal register file, or in one of the write queues. Also, I doubt modern processors flush the i-cache. The i-cache on the P4 is actually the trace cache, and flushing it would involve dumping about 8kb of traces that took a lot of work to make. In reality, its probably lazily replaced with new traces as the new process executes.

FYI> The big win with the AMD64 is not that the processor has more physical registers (it probably doesn't) but that its larger window of 16 GPRs enables the compiler's optimizer to do a much better job with register allocation.

Re:About 64-bit gaming performance

[IntlHarvester]

> If only the PC-1 had contained a MC68000. I once heard a story that said it almost did, but who knows if it's true

There's been several threads on this in alt.folklore.computer over the years, so check groups.google.com.

What I've read is that the IBM PC was designed from the beginning to be a CP/M-compatible machine, so it's not true. In fact, I don't think the 68K was even shipping in 1981.

The urban legend seems to come from fact that IBM was experimenting with something more like a Unix workstation at the same time.

The other urban legend is that the IBM PC was going to be based on the Atari 800 8-bit system!

Re:About 64-bit gaming performance

[drinkypoo]

Well back in the day IBM had an architecture called ROMP which came right after the PC/XT at least, and I think also the PC/AT. It was called the PC/RT, and gave approximately 386-level performance. I used to have a few of 'em, I gave them away, and lost nothing in the process. Apparently some people got BSD-4.3-lite running on them, and IBM also did this, and called it AOS 4.3. Not a bad little operating system. Apparently you could get it to use the most basic and stupid ISA IDE and Multi I/O cards, you know like the kind that we got way back in the day that weren't even plug and pray. Thank god. The kind with jumpers that cost ten bucks! Hallelujah.

Anyway I had two of the most powerful ones with the highest end ROMP chip, the model 135, with 16MB ram each, but this was in the age of the pentium 2 and they were too esoteric to bother with. Besides, ROMP begat POWER...

Re:About 64-bit gaming performance

[thisgooroo]

Besides, ROMP begat POWER... i wish this were true. IBM had a power like chip ready (internally) before ROMP. they had to switch to the ROMP because some divisions (esp. the mid range division with System 38) were afraid the other chip would eat into their market. which probably was a justified fear, but the effect of the decision to go with ROMP was that Sun could dominate the unix workstation market (with IBM's other chip this would have been much more difficult) and it was 386 type PCs that ate the mid range market

btw, th PC/RT mainly ran AIX. the BSD port (AOS) was done by the division that interfaced to academia (i forgot the name of that division) because many academic customers wanted BSD

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.

Re:About 64-bit gaming performance

[thisgooroo]

In other words... it's not a sane architecture. But presumably it was easy to implement the first time around, and now we're all paying for it.

there are a few reasons for that:

1. at that time memory was very expensive, and an ISA that minimized code size was highly valued, which accounts for the ISA that used many implied registers that didn't have to show up in the code itself

2.rumor has it that the register architecture was influenced by a paper that was published in the Communications of the ACM in the mid-1970s, where some ignoramus (who probably was about to lose tenure if he didn't get a paper published) "studied" the influence of register set size on the code quality produced by optimizing compilers (Intel sales people cited that paper continuously when somebody critisized the register set architectur during their sales talks). He experimented with the BLISS cmpiler (BLISS was a C like language with a compiler for the PDP-11), found a parameter in the register allocator that gave the number of general purpose registers, and compiled the same code several times varying this parameter. his findings were surprising to anybody who ever had played with compilers: increasing the number of registers from 1 to 4 (in steps of 1) gave significant performance improvements with each step. beyond 4 registers: nada. what he missed: because of the architecture of the PDP11 you really didn't have more than 4 general purpose registers, but the PDP11 could operate with all operands and results in memory. so the BLISS compiler had an extra pass before calling the register allocator where it was checking code for places where more than 4 registers were needed simultaneously and replace operations by memory to memory operations until the register need was reduced to 4. Apparently this pass didn't use the parameter used by the register allocator, so it wasn't exactly surprising that only playing with this parameter gave the published results results. so what we are suffering from is that intel based the desigh of the 8086 on some very sloppy research without checking its validity

Re:About 64-bit gaming performance

[amorsen]

I skipped the part about the 8 registers not being true GPRs, just to keep it simple. It just reinforces the point that going to the 64-bit mode is best, since all registers truly are GPR's there. As to the MC 68000, it was very new at the time of the first PC, and only available from a single vendor.

Re:About 64-bit gaming performance

[thisgooroo]

my point was that POWER owes much more to the 801 (thanks for helping me to recall the name) than to the ROMP. I really don't remember how much the ROMP owes to the 801 (afair it was developed in Austin for an office system and then was co-opted into serving as the processor for IBM's first unix workstation. my point was that while the POWER CPUs resembled the 801 quite considerably, there was very little similarity between the ROMP and either the 801 or POWER

i remember the TI9900 quite well (never gad a chance to work with it, but read the specs). it was quite a nice chip. too bad TI's marketing (and probably the fact that at the time technology hadn't advanced far enough for on-chip memory) prevented it from getting wider acceptanxe. the architecture was quite neat.

about the mismarketing: i tend to disagree with your assessment: if IBM would have come out early enough, they would have had a chance to sow up the unix workstation market. but due to internal squabbles (both the PC division and the mid-range division objected to its introduction out of fears that it would cut into their market) its introduction was delayed for a long time after it was ready (i know: we were using it internally for quite a while already). by the time it was introduced, it wasn't competitive with the Sun M68000 workstations and 386 based PCs any more

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.

When are the 64-bit benchmarks coming

[barole]

I have read so many reviews of opteron/athlon64 running in 32-bit mode under windows.

There is good opportunity right now for some site to stand apart from the crowd by doing a real review on a 64-bit version of linux. Does anyone know of any out there?

Re:When are the 64-bit benchmarks coming

[dbirchall]

How about this InfoWorld article from a month ago, which involved a dual-Itanium box running Red Hat Enterprise and three dual-Opteron ones, running SuSE?

Google can probably find you more, if you ask it nicely.

Re:Interesting

[dpilot]

Then it obviously can't be any good, can it?

Aren't the TRUE marks of quality on computers the 'Intel Inside' and 'Designed for Windows' labels?

For those who can't detect humor without emoticons, I took the 'Intel Inside' sticker from my company-issued laptop and put it on the company-issued wastebasket. The 'Designed for Windows 2000' sticker went on the urinal at the nearest restroom.

Not to truly disparage either product, but IMHO the marketing campaigns and especially pricing practices behind both stickers are counter-competitive and should be BANNED in both cases.

Re:64-benchmarks wont be good

[Rasta Prefect]

Intel's IA-64 emulates 32-bit unlike AMD's 64-bit chips which have 32-bit hardware. So we can expect AMD to beat Intel easily in 32-bit stuff.

Except that they're benchmarking against P4's, not Itaniums. P4's most definitely have 32 bit hardware. :)

Re:Processors of Mass Inflation

[Hekzen]

I just want to know how much it cost (the processor)...

Compilers

[Eric Ass Raymond]

And at least Intel would provide us with a native compiler.

The lack of a bit-banging AMD compiler has kept me away from AMD CPUs all the time.

Re:Idiots... No they're not.

[Anonymous Coward]

Duncan3 is another Intel troller. AMD has not announced any of these speculated pin griddings so far. They're just pulling this stuff out of the hat to discredit a system that isn't even out yet.

Let's just leave the speculation and stick to the facts when the CPU comes out.

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 Itanium vrs. AMD Opteron/Athlon64

[Anonymous Coward]

- EPIC is the name of the instruction technique (analogous to RISC/CISC), not the architecture, which is called IA-64.

- The comparsion as Opteron/P4, not Opteron/Itanium.

PS: Personally, I still don't accept the cheap name Itanium. I still think of it as "Merced" ...

Re:Intel Itanium vrs. AMD Opteron/Athlon64

[Nucleon500]

What are the real differences in architecture that make it this way? I'm kind of a "reinvent the wheel" type person, so I wonder whether AMD has had to make sacrifices to keep this compatibility. On the other hand, Linus seems to prefer AMD's design.

Re:Intel Itanium vrs. AMD Opteron/Athlon64

[sparrow_hawk]

Hmm... At $800 a crack (or between $500 and $700 for AMD chips, which are really better than their Intel counterparts) I think I'll stick with my old 533MHz Alpha box, currently running Debian... I love Linux. :)

Re:Intel Itanium vrs. AMD Opteron/Athlon64

[mjuarez]

Basically, they extended the x86 architecture again, like Intel themselves did 15 years ago when going from the 286 to the 386 architecture (16 bits to 32 bits). They maintained the current binary compatibility, while extending the registers to double their size, and make additional registers available. Intel completely ignored this possibility since going to Itanium was going to be "so much better". As we have seen, however, that was simply not true.

Of course, the whole exercise is moot if there is no software available to take advantage of the 64-bitness. Linux, as you mentioned, is already fully ported to 64-bits by several vendors (RedHat, Mandrake and SuSe), and you can compile your own 64-bit kernel yourself, should you so do desire, and if you have the proper hardware :-) Windows XP and 2003 will be available specifically for AMD64 (marketing name for x86-64 architecture) in late 2003. Betas have already been sighted in the wild.

So what's to like? Well, first of all, access to a contiguous 256TB virtual memory space, up to 1Tb of physical RAM, and obviously ability to process up to 64bits at a time inside the CPU. And, you can run all of your current software without a hassle. You can even install your current WindowsXP/Linux/whatever without a problem, and upgrade it later if you need to.

You can get the full gory details by downloading the Programmer's Manual for AMD64 from AMD's website.

Re:Idiots...

[temojen]

Hmmm...
At the rate I upgrade, that's not likely to be a concern...

XT->486->K6/2->Athlon

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

Re:But is it representative?

[captain_craptacular]

I read the article yesterday and got nothing for the all image pages. I'm on Mozilla 1.5b and wondering if it's not a Mozilla issue.

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

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.

... will not be here tomorrow

[Anonymous Coward]

All that, and in time for yule?! That's almost too good to be true.

Oh, wait.. it is too good to be true.

PS. "PNI new instructions" is redundant. Go play with your "CD compact discs"

Re:... will not be here tomorrow

[lightcycle]

Maybe it's "PNI is New Instructions"?

This was against a P4

[Sterling Christensen]

This was Athlon64 vs Pentium4... A Pentium 4 doesn't emulate 32 bit mode either.

Re:This was against a P4

[bhtooefr]

To be specific, it was an Opteron (1-way - same as Athlon FX, but not Athlon 64 - Opteron is for servers, FX is for enthusiasts/gamers, 64 is for home users) overclocked to 2.0 GHz (from 1.8 GHz), a dual P4 (3.06 GHz), a single P4 (3.06 GHz), an Athlon XP (forget the speed).

Re:This was against a P4

[Anonymous Coward]

Opteron is for servers, FX is for enthusiasts/gamers, 64 is for home users

Ah, the joys of market segmenting and advertising.

Opteron = a fully validated version
FX = works pretty well
64 = a dog

Re:Intel's response

[Eric Ass Raymond]

quad-Opteron TODAY

Really? Link me to a quad-Opteron mobo...

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:First Look at Windows XP 64bit for AMD64

[AntiOrganic]

Windows XP is sooo yesterday. I want to see an AMD64 version of Debian, then I'll be happy.

Re:First Look at Windows XP 64bit for AMD64

[Anonymous Coward]

Windows XP for 64 bit AMD is new, still in beta.

Re:First Look at Windows XP 64bit for AMD64

[mjuarez]

There is already a Mandrake, SuSe and RedHat versions recompiled for running at full 64 bits under AMD64. Debian should not be too-far off.

Re:First Look at Windows XP 64bit for AMD64

[Anonymous Coward]

I think it's safe to say that it will be a while before we hear folks complaining that 16 terabytes of memory isn't enough space.

Yeah, 16TB ought to be enough for everybody

Re:First Look at Windows XP 64bit for AMD64

[Lennie]

You can:

debian.org/ports/ia64/

Re:First Look at Windows XP 64bit for AMD64

[KefkaFloyd]

That's IA64, which is for the Itanic, not the Opteron/Athlon 64.

Re:Idiots...

[Anonymous Coward]

I take it that's different because they're Intel?

No, Intel changes their socket details all of the time, and it doesn't affect their sales in any significant way.

Reason is that very few CPUs are purchsed as "upgrades". In most cases, memory subsystems are improved so quickly that you hardly want a new CPU on an old board. Plus, OEMs like Dell have very low inventory and can transition to new mainboards/CPUs very quickly.

If AMD changes their packaging, that's neither here nor there.

Re:Intel's response

[Anonymous Coward]

Appro 4U Quad Opteron Server. That ought to contain one, don't you think?

Re:Intel's response

[Anonymous Coward]

http://www.newisys.com/products/4300.html
Might be a start...
/A Coward

Re:Intel's response

[Anonymous Coward]

Well here's a Quad-Opteron System from Polywell, its not a mobo, but the parent mentioned being able to buy a system not a mobo.

Re:Intel's response

[Anonymous Coward]

http://www.tempestcomputers.com/amd/jetstream-q4uo -rs/product-details.htm
http://www.opteronics.com /quad-opteron-server.htm
http://www.amdboard.com/ hn08290202.html

Does this mean I can finally afford a P4 HT system

[YoungBonzi]

Or will the Opteron not affect Intel prices?

Re:64-benchmarks wont be good

[afidel]

some of the tests didn't enable any hyper-threading stuff (and thus it didn't take any advantage of the dualies.

Actually depending on the competence of the authors that may have been very intentional and may have actually boosted the numbers for the XEON's. There are situations where HT will decrease scored because the context switches will be more expensive than any gains reached at the silicon level.

too much flash...

[starman97]

What an annoying page..
I turn off Flash to squelch their highly annoying
animated ads and none of their graphs show up.

Re:too much flash...

[Anonymous Coward]

Flash Click To View by Ted Mielczarek.

Flash content is replaced by a button "Flash click to view".

Then click on the squares that you'd like to view.

Re:too much flash...

[littleRedFriend]

What an annoying page..
I turn off Flash to squelch their highly annoying
animated ads and none of their graphs show up.

Just use the Mozilla Firebird browser and install the Flash click to view plugin. Like the name suggests, you won't see any flash unless you explicitly click the flash placeholder.

Opcode depreciation

[Anonymous Coward]

when using native 64 bit mode, certain legacy instructions of x86-32 are depreciated.

Interesting. What method of depreciation will be used? I've searched on the net for opcode depreciation, and I can't see any straight-line depreciation methods or even accelerated cost recovery systems that would apply here.

Re:Opcode depreciation

[anthonyrcalgary]

hmmmm

I can think of two things. I've no doubt it's been published, but I really don't feel like looking. If I'm wrong, someone will correct me.

1) They simply set up the microcode with assumptions that slow down old opcodes and speed up common ones.

2) Attempting to run one of those opcodes will trigger an exception that that's handled by software. This is done with some instructions on SPARC/Solaris.

Re:Opcode depreciation

[lewp]

Your comment's parent was making a joke about the use of "depreciated" rather than, what the grandparent likely meant, "deprecated."

To answer you anyway, in this case I believe the deprecated instructions are being emulated with the likely intention of them being removed at some arbitrary point in the future.

Re:Opcode depreciation

[Anonymous Coward]

-1 Idiot that didnt get the joke

Re:Opcode depreciation

[wayne606]

Ha ha. he meant deprecation. I get that one wrong myself

Re:Opcode depreciation

[Anonymous Coward]

Bet you're a real riot at parties, dickhead.

Re:Opcode depreciation

[Natalie's Hot Grits]

from dictionary.com....

deprecated

The words are the same, and I used it correctly wrt US English rules... In other countries, this might be different.

Re:Intel's response

[Eric Ass Raymond]

Ok, good try all of you.

Yet, none of these were mobos and as far as I could see the amdboard.com ad was not even a finalized product.

"Programs" such as FreeBSD, Linux, and WIN2003?

[Anonymous Coward]

I'm looking forward to see vis-a-vis comparison on programs that is optimized on either platform. For example: A program that is optimized on Itanium and Opteron and see how they fare.

"Programs" such as FreeBSD, Linux, or Windows 2003?

One small point.

[Anonymous Coward]

AGP will be phased out for the advent of PCI Express, which isn't the same as PCI-X.

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.

Will it be secure?-GF & Children.

[Anonymous Coward]

"The sad thing is I understood everything you just said.

My God, I *am* a geek."

No! The sad thing is you will not be able to pass that on.

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)

Yes, mother, PNI=Prescott New Instructions

[Glasswire]

If I wasn't redundant and just said, what fraction of /. do you think knows what PNI is?

Why shockwave-flash?

[Anonymous Coward]

I never bothered re-installing shockwave, because all it ever does is make advertising more obnoxious.

Is there a good reason why the benchmark graphics are in flash format?

Re:Processors of Mass Inflation

[Ewan]

About 500US Dollars I believe at launch (sept 23rd), I guess it'll come down nearer christmas as it moves into mass production.

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.

Re:20% Gain

[Nucleon500]

Screw binary games, can you imagine Gentoo on that baby?

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.

What I want to know is....

[Anonymous Coward]

...when did they come out with Anthlon64's? I want one.

Which suggests an interesting scenario

[fm6]

Well, Intel tried to impose tight pricing controls on a lot of its CPUs. Fortunately, they'd signed second-sourcing contracts with various other companies. They tried to get out of them, but AMD's lawyers were able to persuade the courts that A Deal's a Deal. A damned good thing, 'cause a lot of important changes have been fuelled by commodity-priced CPUs.

Now the relationship between AMD and Intel may be reversed. Of course, Intel doesn't have a second-source contract for the Athlon64. But what they do have is a non-backward-compatible 64-bit chip that cost a bundle to develop -- and that nobody seems to want.

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

[irritating environme]

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

I'm sure they have plan B's along the lines of AMD's approach, they just don't want to undercut the official stance of "everyone recompile for EPIC".

Their site!

[KevinIsOwn]

Their site hasn't been /.ed yet! These new processors must really work!

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:Idiots...

[sirsnork]

Athlon64 will be in 2 sockets. The AthlonFX which is the dual channel version will be 940 pin (moving to 939 later). This I can only assume is so the motherboard will be avaliable at laucnh since it will just be a single CPU Opteron MB (like the Asus SK8N). The standard Athlon64 will be in 764 pin and have a single channel memory controller. Obviously if the released the FX in this package they would need a whole new line of motherboards that supported dual channel memory.

Mod parent puppy down

[Anonymous Coward]

S'troll.

Re:Intel's response

[sirsnork]

We have sold a Quad Opteron system. So they do exist and work quite well. You can only buy them with chassis like this. The one we sold went for about $20k US and only had one HDD

Re:Yes, mother, PNI=Prescott New Instructions

[Anonymous Coward]

PNI="multiple penis instruction set" ?

One More thing

[Nazmun]

Most of the slashdotters already pointed out the other important stuff...

But I'd like to point out that the Itanium will not be competition for the Opteron in most cases. Itaniums are super expensive chips that run on servers and are totaly incompatible with x86 (32 bits or 64 bits) software unless it's in emulation mode in which it runs very slowly. If you were to run Itanium on x86 software then more then likely the opterons would easily win anyway.

Re:64-benchmarks wont be good

[jrwmd]

Hypertransport, 8gb memory, dual 64bit 2GH processors, PCI-X, runs all legacy software with out emulator.......has been shipping in bulk for 2 weeks and 100,000 sold in past 6 weeks - Apple G5

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

[fm6]

Good point. Too bad you posted as an AC, so nobody'll see it.

Re:Does this mean I can finally afford a P4 HT sys

[Anonymous Coward]

you can get a p4 with ht for around $160-180, look for a 2.6ghz with 800mhz fsb.

Re:64-benchmarks wont be good

[parkanoid]

That should read:

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)

Re:Idiots...

[Anonymous Coward]

Right.... just like AMD will release the A64fx with 940 pins, and then transition to 939 pins later, as in "midway through the game". Also, the regular A64 will have a 764 pin out, again, completely incompatible with 768. So, you were saying?

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:64-benchmarks wont be good

[Anonymous Coward]

And if YOU had read the article you'd know that no Athlon64 was used in this 'benchmark'.

Suggestion

[Anonymous Coward]

While you're waiting for those 64-bit benchmarks, why don't you take some evening classes in ENGLISH?

Re:Intel's response

[Anonymous Coward]

By the way, did you know Prescott, along with its mobile version Dothan, was delayed because it was dissipating almost 103 watts?

So? Sounds like a good reason to delay a product.

Why wait for Windows XP 64bit edition?

[slovin8]

SuSE demonstrated Quake III on its SLE8 for AMD64 over a year ago. http://www.suse.com/us/business/products/server/sl es/index.html

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.

Kent Brockman says...

[taradfong]

I for one would welcome our AMD overlords.

Re:64-benchmarks wont be good

[drinkypoo]

Or, to put it simply, hyper-threading gives you a second context (IE, a set of index registers and a flags register) and makes use of spare cycles in which it would not normally be doing anything in order to speed things up a bit. It would be nice if they added more than just one context, but since Windows XP Professional only supports two CPUs, it's a logical number.

Re:64-benchmarks wont be good

[ottothecow]

well it sounded like you read the article but you may need some Free Worksheets because you clearly missed the part where he said it was an opteron overclocked to the release speed of the Athlon64, but it was the FIRST with an agp enabeled nforce3 motherboard (AMD prevented their creation until launch of Athlon64). So if you want to see the stock speeds, there they are (close estimate) and if you want to see underclocked stock speeds without an agp graphics card, check out some nice opteron benchmarks.

Re:64-benchmarks wont be good

[Anonymous Coward]

And if YOU had RTFA you would have seen that the Athlon64 isn't benchmarked, either. Have a nice day.

how long to run this code?

[Anonymous Coward]

/* cc -g -o prog prog.c */
#include <stdio.h>
main()
{
unsigned long long barf = 0;
unsigned long long foob;

for(;;)
{
foob = barf;
barf++;

if((barf-foob)!=1)
{
fprintf(stderr,"barf=%llX,foob=%llX\n",barf,foob);
exit(-1);
}
}
}

This is good, but don't count on XP 64-Bit

[aelfwyne]

If the AMD64 version of Windows XP 64-Bit is as stripped down as the current Intel version... then don't bother considering what performance would be like there anyway... check here for a list of things *NOT* included in XP 64-bit:

http://www.microsoft.com/technet/treeview/defaul t. asp?url=/technet/prodtechnol/winxppro/reskit/prka_ fea_tfiu.asp

But I guess we can do without features like Media Player, POSIX Compliance, Power Management, Windows Installer, and more... I guess..... just to have a 64-bit OS...

Re:This is good, but don't count on XP 64-Bit

[Anonymous Coward]

Should all work, remember if they haven't ported something to 64bit, they can still ship the 32 bit component as long as the kernel is 64bit.

Besides, the current review versions have everything windows 2000 has so far.

it looks like intel is the ...

[rhino_badlands]

it looks like intel is the only one left playing the GHz game, both AMD and Apple/IBM are getting better performance at lower clock rates !

This is very interesting seeing that intel always says you need a higher clock rater for better performance, nice to see that every one is proving them wrong !

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

[thisgooroo]

10-15 years ago, everyone else in the industry thought x86 was a dead end.

not only then. the x86 architecture was a laughing stock from day 1. compliments to intel for eventually turning it into something almost useful. but intel finally came to realize that the only reason the architecture survived so long is the backward compatibility required because of binary release only software. with open source the architecture would be long where it belongs: in the dustbins of history

so far i had only one brief look at the opteron architecture, but my impression was that is is basically two CPUs on one chip (a pentium and the 64 bit processor) which from the register architecture are only remotely similar (i didn't check the instruction set). this is something that intel at least in theory should be able to do with the itanic as well (though afaik the itanic has a very high transistor count that might make it difficult)

Massive amounts of investement poured into RISC alternatives like Alpha and PPC.

the power pc development started almost 20 years ago (iirc, the RS6000 was released around 1990). sparc and mips preceeded it. motorola had the 88000 some time in the late 80s. and with similar clock speeds they tended to beat x86 machines easily in speed.

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:Shockwave Flash

[Chuck Bucket]

Flash is avail for Linux, but not for Linux on PPC - I'm on my iBook, so I can't even see the benchmarks! There's a gplflash, but I haven't gotten it to work with Moz in Gentoo yet.

P

Re:Intel's response

[Anonymous Coward]

You really are a shit-for-brains aren't you?

If there are no quad-opteron motherboards, what do you think are inside those systems? Quad Xenon motherboards? Two dual-opterons with a cable between the motherboards connecting up their respective hyptertransport buses?

Go home and practice that self-fellatio in private, because we sure don't need to see it here on ./.

Re:64-benchmarks wont be good

[Talez]

It's not really 2.0GHz Athlon64 though. Sure the megahertz may look the same but I can tell you now that extra FSB speed will be giving the core a modest speed boost over a "proper" 10x200 A64.

Re:64-benchmarks wont be good

[Slack3r78]

You'll notice that I mentioned that specifically. There are differences between the two chips beyond clock rate, hence why I said it'd give you a general idea, but nothing specific. =)

About the wattage...

[Kjella]

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.

I think this is where Intel went wrong with the PIV. Sure, the processor may scale to high frequencies, but the power usage increases exponentially (~n^2) with it. AMD is doing more with less, and they simply can't keep pushing up the watts, it's bad for power bill but most of all because of all the noisy cooling. If they don't want to start water-cooling their high-end stuff,they need to keep that down. The problem is, the only two ways that really work is either smaller process or processor redesign. Neither is easy...

Kjella

Re:About the wattage...

[sirsex]

To the first order, power increase linearly with speed, squared with voltage. P=CFV^2

History

[alexo]

> As to the MC 68000, it was very new at the time of the first PC, and only available from a single vendor.

The important part that you neglected to mention is that the second source for 808x CPUs was IBM itself, as they got the rights to manufacture them in exchange for the rights for their bubble memory.

Reminds me of something...

[Anonymous Coward]

Wow! It's like a G5 that can run Windows! In your face, Apple!

Re:64-benchmarks wont be good

[cyberformer]

Intel and AMD say that the Opteron and Itanium aren't competing with each other, but that isn't entirely true. Intel knows that saying the two are competitors would be the kiss of death for Itanium, because it would be an admission that they offer comparable performance. Likewise, AMD has no desire to go after the Itanium market, because right now there isn't a serious Itanium market.

Opteron and Itanium are both aimed at Unix servers, in particular those using 64-bit processors from IBM, HP and (especially) Sun. Indirectly, they are helping both Micrsooft and the open-source community, by pushing the replacement of proprietary Unix with Windows and (even more likely) Linux. Intel is currently doing very well in this segment, but that's with the Xeon, not the Itanium. Although it's only 32-bit, the Xeon's (relatively) low cost and ability to work with cheap commodity components make the tradeoff worthwhile.

The Opteron seems to offer the best of both worlds, but many big customers aren't yet ready to move to AMD. ("No one ever got fired for buying Intel!"). Intel is hoping that by the time they are, the x86 architecture will have run out of steam and Moore's Law will make the Itanium more competitive.

Re:64-benchmarks wont be good

[CrowScape]

Well, I only looked at workstation performance, where AMD64 did not "own" it just performed, on average, better than the P4. Considering I don't see 64bit aps that really need 64bit processing which the majority of people (including a great deal of power users) will use coming out in the next couple years, the 64bit performance of the AMD64 (and perhaps even the G5) may well be just a footnote to anyone not building a hundred+ processor supercomputer for a good long while. I'm going to wait for Prescott, see which is the better 32bit performer for the dollar, and then go with that. Then, a year or two later when it's time to upgrade my processor and mobo, I'll see what the state of 64bit is before I take 64bit performance into consideration.

I'm just looking at this from the perspective of a video editor. If you're a gamer, from the looks of it, rock on Opteron!

Re:64-benchmarks wont be good

[Anonymous Coward]

And it still doesn't run the games I play.

Re:64-benchmarks wont be good

[mabu]

Has anyone ever been fired for buying AMD? Inquiring minds want to know.

I have run Intel and AMD servers for years and AMD has never let me down, ever.

Re:64-benchmarks wont be good

[Anonymous Coward]

and it has an interface for girls too. Thank but no thanks. I'm noy gay.

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:64-benchmarks wont be good

[Anonymous Coward]

I actually read this this morning

You WHAT?? You actually read the article? Who the HELL do you think you ARE, posting on slashdot, reading articles like that?

Re:64-benchmarks wont be good

[Skuto]

It's worse than that. On all operating systems save Windows Server 2003 and Linux 2.6.x, enabling hyperthreading on a dual will _lower_ performance in most cases, because the OS cannot differentiate real from hyperthreading CPUs.

And yes, this is despite Windows XP being marketed as 'HT optimized'.

You don't need the hardware

[Lennie]

You can compile your own kernel yourself, should you do desire, and if you have the proper hardware :-)

Actually, you can probably crosscompile it, you don't need the hardware, you need the hardware to run it, that should be all.

Re:64-benchmarks wont be good

[Bedouin X]

Shame there is no 64-bit OS or applications for it. And I seriously doubt that it scales like a pair of Opterons. Though I welcome any evidence to the contrary.

my 2500+ @ 2.36 Ghz has Sandra PR rating of 3700+

[Anonymous Coward]

When A64 or Opteron gets above this level in a sigificant manner, I'll look at upgrading. Since it's faster than the best A 64 theres no reason to at the moment.

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

[AvitarX]

Maybe they didn't have any serious competition in the consumer market. So they figured they could do what they wanted, consumers would have to follow and they would have a credible server chip.

Now x86 is credible for low end servers and AMD is a very credible competitor. As time goes on x86 is (at least in the short to middle run) proving the nay sayers to be wrong and continuing to improve. AMD starting their techknowledgy more recently saw this. And said hay, if intel is not releasing high end x86 chips we can give it a whirl and snatch up some market.

WRONG

[MBCook]

WRONG. I've seen this page before, and it refers to the INTIUM versions of Windows XP. The x86-64 version should be almost exactly like the the standard x86 version.

The differences make sense if you realize that they are for the Intium, which is a server processor and not designed for desktop users. If you buy Intiums, you probably aren't using DOS and OS/2 programs. You probably won't be playing DVDs on your $20k server. And since it is a server, how often will you want to put it into "sleep" mode? You won't, so you don't need power management. It all makes sense.

I think you just didn't realize what you found. Don't worry, the version of Windows XP for the Hammer/Opteron/Athlon64/x86-64 will be just like the version that you'd be running on your x86 now.

Re:64-benchmarks wont be good

[Miguelito]

What I don't get is why they didn't just get a sample 2.0GHz Opteron to test with instead of OC'ing the 1.8 one.. they do exist... I should know, I've got a dual proc test box at work:
% grep MHz /proc/cpuinfo
cpu MHz : 1971.563
cpu MHz : 1971.563

For those that care... this box is still running in 32 bit mode (couldn't build 64 bit openafs client yet and we rely heavily on afs.. 1.2.10 client that came out since I tried appears to have the support now though). I did tests with programs like mp3 rips and the distributed net client benchmark. The dnet client was 28% and 74%(!) faster for the GARSP 5.13-A and DG-3 pipe tests respectively compared to a dual 3GHz Xeon box. And the dnet client has P4 optimized cores, but doesn't have opteron optimizations.

We've tested Itanium2's as well, and while their performance compared to sparc hardware is much faster, their 32bit emulation sucks rocks. And we haven't had comparable programs on opteron to compare with itanium yet (in 64 bit mode).

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

[Anonymous Coward]

Yeah, RISC development started longer than 10 years ago. However, it wasn't until the early 90s that Alpha and PPC were positioned in the "PC" market -- complete with ports of Windows, MacOS, OS/2, etc. That was done because DEC and IBM thought Intel was almost out of gas.

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

[fm6]

Now that makes sense. And it would be especially convincing to Intel people who were tired of iterating the Pentium.

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

[n8_f]

My understanding was that the Itanium was originally HP's idea. They knew they didn't have the resources to make it a viable platform, so they sold it to Intel and had them do most of the heavy lifting. I'd like to see some articles on the origin of the Itanium, it sounded like an interesting story.

Re:64-benchmarks wont be good

[Xenex]

"And I seriously doubt that it scales like a pair of Opterons."

Yeah, because AMD know so much more about scaling high-end systems than IBM do!

Re:64-benchmarks wont be good

[Bedouin X]

Thanks to your bulletproof evidence, I am a believer!! Go APPLE!!!

Err.

[Xenex]

I didn't even use the word "Apple".

Re:Err.

[Bedouin X]

Well this thread is about a chip made by IBM and primarily used by Apple.

Re:64-benchmarks wont be good

[Xenex]

"Shame there is no 64-bit OS or applications for it. And I seriously doubt that it scales like a pair of Opterons."

Thanks to your bulletproof evidence, I am a believer! Go AMD!