AMD's "Trick" for Summer 2006

Jawed said:
According to this article the link is 64bits in each direction (concurrently):

http://www.digit-life.com/articles2/mainboard/ddr2-800-am2.html

right near the bottom in the section "Instead of a conclusion".

Quite a damning article.

Jawed

Given the serious weaknesses in the memory subsystem (L2 cache as well as the actual DDR2 controller) that this article reveals, as well as other performance issues that have been around for a while (half-width SSE units, in-order load/store units, non-shared L2 cache, no SMT support), it looks like there are right now plenty of things AMD could do with their processor to help performance even before adding a huge L3 cache or funny coprocessors or other big stuff like that.
 
Last edited by a moderator:
crypto1300 said:
Can anyone explain why AMD has not implemented a 256-bit wide bus to L2 cache yet?

The PIII had it years ago, and as far as I can remember the Athlon 64's are still using a 128-bit wide bus.

The P3 L2 cache was indeed 256 bits wide, but it could only transfer data every other cycle --> it is only 128 bits wide in practice.
 
dizietsma said:
The trick is reducing the price of the FX-62 to a third of what it is at the moment to match Conroe

http://www.hkepc.com/bbs/news.php?tid=604489

and still get beaten.

AMD has a trick up it's sleeve but Intel is busily sawing the arm off at the shoulder.

AMD has been on the gravy train for too long, if Intel can produce enough T6's and T7's then they are going to have to bleed all the way into 2007.

The gloves have finally come off.

Lets rumble.


Personally I am very excited about this. It pissed me off that they both just kept such high prices for so long. Finally I may be able to afford a decent processor again. *rubs hands in glee*
 
crypto1300 said:
Can anyone explain why AMD has not implemented a 256-bit wide bus to L2 cache yet?

Because it isn't needed ?

L2 delivers critical word first, so latency is as good as it gets. The only situation where a wider L2 pipe would make a difference is when you have back-to-back L1 misses. This is quite common in synthetic tests that specifically tests L2 bandwidth (ie. thrashes L1 on purpose), but is rare in the real world.

Reviewers rely on the synthetic tests to infer architectural differences and they therefore conclude that AMD's processors are deficient, while in the real world it makes fuck all difference.

Of course if (when) AMD is to beef up the SSE units to do full 128 bit width ops/loads+stores, the bandwidth requirements will go up and we'll likely see a wider L1<->L2 bus

Cheers
 
arjan de lumens said:
In-order load/store units, non-shared L2 cache, no SMT support), it looks like there are right now plenty of things AMD could do with their processor to help performance even before adding a huge L3 cache or funny coprocessors or other big stuff like that.

I think the OOO load+store handling is by far the most significant improvement they'll introduce in K8L.

The wider SSE units (with decoder support to actually sustain throughput) will give a good solid boost in media processing.

I'm wondering if they'll change their cache architecture when going to 3 on die levels from exclusive to an inclusive design. At least I'd expect the L1+L2 which are "personal" to each core to be inclusive, otherwise you'd have to query a whole bunch of tags every time a core misses a cache.

Cheers
 
From my own article:

It's highly unlikely, however, that 2006 has seen the last round in AMD's barrel fired since the company will need to counter Intel's forthcoming Conroe-based Core 2 Duo lineup; how small or powerful the market perception of this chambered salvo will be, however, is another issue in and of itself.

:cool:
 
It'd be highly impressive if AMD had a chance to compete against Intel's 65nm designs before they themselves move to 65nm. I still have high hopes that AMD will compete well against Conroe, I just doubt they'll be able to do it at Conroe's launch.
 
Gubbi said:
I think the OOO load+store handling is by far the most significant improvement they'll introduce in K8L.

Johan De Galas suggest this might bring a ~10% integer performance advantage over current K8's in an artical from a few weeks ago, you obviously know your way around K8's architecture, would you agree with that figure as ballpark accurate (obviously dependent on AMD's specific implementation).
 
Shogun said:
Johan De Galas suggest this might bring a ~10% integer performance advantage over current K8's in an artical from a few weeks ago, you obviously know your way around K8's architecture, would you agree with that figure as ballpark accurate (obviously dependent on AMD's specific implementation).

Depends on the workload, in some I think it will bring more. It is similar to what Intel has done to the P-M architecture and that jumped 25% on SpecINT. I'd expect similar gains from K8L.

Cheers
 
ZioniX said:
AMD's "Trick" is likely to be that: AMD readying four by four socket
That's kinda wierd....I guess it's an attempt to bring dual-processor systems to consumers? But still, something smacks as being very, very strange about this rumor. We know that AMD is moving to a larger socket and quad core before long, so why bother going with dual-processor?
 
That sounds like a Chinese-whisperised version of the rumour that AMD would introduce their first quad-core processor by gluing two dual-core dies together on a single package (ie. the same thing Intel did when they first went DC). It's more complex for AMD because their memory bus doesn't allow them to simply plonk extra loads on it.

It doesn't really make sense to introduce some sort of bastard hybrid new socket.
 
nutball said:
That sounds like a Chinese-whisperised version of the rumour that AMD would introduce their first quad-core processor by gluing two dual-core dies together on a single package (ie. the same thing Intel did when they first went DC). It's more complex for AMD because their memory bus doesn't allow them to simply plonk extra loads on it.
They'll probalby connect them through HT

nutball said:
It doesn't really make sense to introduce some sort of bastard hybrid new socket.
I'm guessing it will be AM2, with the second chip hanging off the side on HT

Cheers
 
ZioniX said:
AMD's "Trick" is likely to be that: AMD readying four by four socket

It doesn't make much sense: It would be quite expensive with two CPU's and special motherboard with high watt-demands on top af it. And how many applications/games would benefit from four cores? Very few outside some specific benchmark-like apps.

If I want four cores, I would get two Woodcrest's and a dual cpu mobo instead. But hey - that is just me...
 
LeStoffer said:
It doesn't make much sense: It would be quite expensive with two CPU's and special motherboard with high watt-demands on top af it. And how many applications/games would benefit from four cores? Very few outside some specific benchmark-like apps.

If I want four cores, I would get two Woodcrest's and a dual cpu mobo instead. But hey - that is just me...
Well, you can get 4 cores per socket... so 8 per 2S, 16 for 4S .... ;)
It will be for server/enthusiast I guess... just in order to be able to claim "victory"... same damage control Intel used to claim "first dual-x86-cpu in socket" ....
 
Gubbi said:
They'll probalby connect them through HT


I'm guessing it will be AM2, with the second chip hanging off the side on HT

Yeah, but this will to some extent negate the advantage that Opteron has had over Xeon up to now, ie. multiple independent memory busses, one per socket. The secondary pair of cores would be very much second-class citizens, not having their own memory bus. Four cores sharing a single memory bus could present some real scalability issues if your problem doesn't fit in L2 cache.
 
Back
Top