Hot from the over: Athlon XP2800 333Mhz fsb

[Dogbert]

Read @ AcesHardware !

[ZokesPro]

At least AMD isn't letting up, I'm glad to hear they are still in the race.

[RichL]

Nice.
I wonder how the SiS chipsets stack up against the NForce?

[K6-III]

I'm pretty confident that the NForce2 SPP-powered Epox 8RDA+ is to be my next board...

[luni]

Well as much as first nforce sucked (relatively speaking... it sure as hell wasnt what we expected) it seems that nforce2 will be THE chipset for new Tbreds .

Gotta love an AMD 2800+ system beating twice as expensive P4 RDRAM sys in half the benches

[Technoid]

When you think of the ugly things Nvidia does to make their grafikcards go 1-5% faster I really don't want a Nvidia chiped motherboard

[ZokesPro]

Surprisingly enough, Tom hasn't said anything bad about this cpu, he even proclaimed it as the "Performance Winner".

I thought that Intel bought him out!

[RC Agent]

Isn't this another one of those paper release by AMD?? I mean, c'mon, when will the DIY crowd be able to get purchase an AMD XP2800?? ANOTHER 2-3 months from today??

[K6-III]

Yup.....but I'm more interested in the lower-speed TBRED-B's anyway....should be just as overclockable....at a price I'd like more....

[BuddMan]

AMD is falling behind. Intel already has a 2.8 out and isnt' a 3GHz from them due out soon?

[superfly]

Well..At least they're trying....Shame it'll only be out in early 2003 though.

As far as the 3.06 p4 is concerned,it looks like the official release is in late october(25~27th),but i suspect that it'll still take a few more weeks after the anouncement before a decent quantity are actually available for purchase...

[luni]

Yes, sadly, AMD IS falling behind. It was clear from the start that P4s will reach much higher clocks than the current EV6 core, but (at least me) only lately realized that P4s offer comparable computing power per clock in many cases due to their superb prefetch unit and lower latency.

Think Hammer will either kill AMD or make it king of performance market for next 5 years, it all depends on them. They need to improve their prefetch unit dramaticaly and also make sure that the new core will be able to reach high clock speeds. I am a bit sceptic of this later thing, because all they can do now is 800MHz without supercooling, and if you guys recall, Itanium (ie. Merced) had similar problems and they were never solved. Since both are 64-bit parts I fear that Hammers will suffer from same fate.

Hope not, though.

[Ribbit]

Um, EV6 is the (still sorely missed) Alpha, I think you meant K7 or something. (Yes, I know they use the same bus and that bus is called EV6, but that has nothing to do with the core.)

[Warning]Going out of my depth here, and simplifying at the same time. (Was that sentence an oxymoron?) No doubt Wombat will immediately dive in here like some kind of....wombat....and start correcting me. Well bring it on Wombat, I like to learn. [/Warning]
I don't think you need to worry about Hammer having the same problems as Merced. For a start, Merced's transistor count and core are much larger than Hammer's. (Don't have figures handy.) They also execute code in very different ways. At a branch, Merced will take execute both paths in parallel until it knows which one it should have taken, while Hammer will try to predict which branch it should take and just execute that one path. So right there, Merced is doing twice as much work, half of which will be wasted, and so generating that much more heat.

[rugger]

Originally posted by Ribbit
Um, EV6 is the (still sorely missed) Alpha, I think you meant K7 or something. (Yes, I know they use the same bus and that bus is called EV6, but that has nothing to do with the core.)

[Warning]Going out of my depth here, and simplifying at the same time. (Was that sentence an oxymoron?) No doubt Wombat will immediately dive in here like some kind of....wombat....and start correcting me. Well bring it on Wombat, I like to learn. [/Warning]
I don't think you need to worry about Hammer having the same problems as Merced. For a start, Merced's transistor count and core are much larger than Hammer's. (Don't have figures handy.) They also execute code in very different ways. At a branch, Merced will take execute both paths in parallel until it knows which one it should have taken, while Hammer will try to predict which branch it should take and just execute that one path. So right there, Merced is doing twice as much work, half of which will be wasted, and so generating that much more heat.

I probably am not much more qualified to speak than you, but what the hell, here's my 2c

But Merced won't ever have to flush its pipeline due to branch mispredictions. But the Merced is a very different design to most other X86 cpus

My take on it is: IA64 seems to be aiming to solve many of the problems of current processors. (problems being memory access, pipeline stalls and branch mispredictions, relatively low IPC execution counts) However, this has resulted in a very complex and unwieldly designs at the moment, esspecially as very little experience has been accumulated in designing such processors. The software side of these processors is still lacking too, as compilers need to do a better job at parrellizing code for Merced's wide instruction path. There are probably 2 roads for IA64 to take. The first would be that the designs get better, the production processes catch up to the complex designs, and the software improves to the point that IA64 proccessors become the fastest processors around. The second would be that these things do not happen, and the IA64 project petters out and dies. (only to have the ideas revived again by the next chip maker searching for the holy grail of processor designs)

My take on the Hammer (X86-64). This is simply an extension of the X86 design to 64 bits, like the 386 extended the X86 design to 32 bits. While the addition of a few extra registers is a godsend to compiler and assembly developers, and the onboard memory controller will fix the problems athlons have had interfacing with memory quickly, at the end of the day, it is still a classical cpu design. It still has all the pro's and con's of most other processor designs. It is fast and easy to make. The compiling requirements are well understood and most compilers will generate fairly decent machine code for it. The complexity of the design is also well understood, and it should be possible for it to scale reasonably well (like the P4). However, it doesn't deal with problems like branch misprediction and fairly low IPC. It's a fairly predictable processor to produce, from a company that doesn't really have the resources to create something else.

Anyway, thats my opinion.

[Ribbit]

Originally posted by rugger


I probably am not much more qualified to speak than you, but what the hell, here's my 2c

You're qualified enough as far as I'm concerned. I'm not actually qualified at all

But Merced won't ever have to flush its pipeline due to branch mispredictions.

This is both true and false. It will also have to always flush the pipeline which took the other branch. On a 'classical' processor, that pipeline would likely have been doing useful work.

But the Merced is a very different design to most other X86 cpus

My take on it is: IA64 seems to be aiming to solve many of the problems of current processors. (problems being memory access, pipeline stalls and branch mispredictions, relatively low IPC execution counts) However, this has resulted in a very complex and unwieldly designs at the moment, esspecially as very little experience has been accumulated in designing such processors. The software side of these processors is still lacking too, as compilers need to do a better job at parrellizing code for Merced's wide instruction path.

The problem I see is that they've taken all those issues and landed them on the compiler, which can afford to be more complex and intelligent, but will always know less about what's going on than the processor. (It's the processor that runs the code, after all.) The processor knows at runtime what resources are being used at any given time, while the compiler can only take an educated guess. That's the best I can put it, I find it difficult to get my head very far around this stuff. Whatever the compiler can do at compile-time, a chip can be made to do at runtime, and do it better.

I remember someone (it might even have been on these forums) saying "the P4 is faster in a straight line, but the Athlon corners quicker". I predict that with IA64 and Hammer, that will become even more true. IA64 will be faster at black-box, brute-force tasks (video encoding, distributed.net-type challenges , simulations of large systems), while Hammer will be better at more dynamic tasks (AI, just about anything interactive, simulations of very dynamic systems).

My take on the Hammer (X86-64). This is simply an extension of the X86 design to 64 bits, like the 386 extended the X86 design to 32 bits. ....

Hammer also adds a couple of really handy addressing modes and makes memory management a bit saner, but yeah, it's really just a new-improved 64-bit Athlon at the end of the day. Not that that's a bad thing.

I should mention that Instruction Level Parallelism (ILP, which translates to IPC at runtime), is very difficult to extract from most code, however you try to do it. It just isn't there. Hence the rise of Symmetric Multi-Threading (SMT).

Anyway, thats my opinion.

And that's mine. I'm glad we had this talk