When will the Intel "real" quad-core processor come out?

David Kanter wrote:
> On Jan 29, 7:17 am, Yousuf Khan <bbb... RemoveThis @yahoo.com> wrote:
>> L3 doesn't need to have as low latency as lower-level caches. It's also
>> probably not as heavily accessed as the lower-level caches.

> I think I need to be more clear. What do you mean by 'design
> flexibility'? And what do you mean by less performance critical?

As I just said above, L3 is less latency sensitive, therefore you can
place it in places far away from the cores without much increase in
latency.

As for "performance critical", again it just means that it has higher
latency therefore it's likely going to be accessed less often. Anything
found in L3 will likely be copied directly into L1 first, which will
then eventually migrate back down to L2 again. So they're not going to
need to access the L3 that often once it's found in L1 or L2.

>> In fact, L3 might be ideal for the experimental caches like AMD's ZRAM,
>> or Intel's FB-RAM.

> ZRAM was developed by ISi. What is FB-RAM? Is that Intel's version?

Yes, that's what I wrote about in the thread, "Intel is doing ZRAM too".
It means Floating-Body RAM. It's a form of RAM that uses the capacitive
properties of SOI. Of course in Intel's case, since they don't use SOI,
they will need to convert bulk wafers into SOI in certain areas first.

>> Neither of those have the low-latency of SRAM, but
>> SRAM's latency increases the larger and larger it gets, so at
>> sufficiently large enough sizes, the two technologies' latencies might
>> equal out.

> There certainly will be a point where a denser cache is faster,
> despite using 'slower' technology. It all really depends on your
> interconnects.

Yeah, at some point a high latency, high capacity cache might still be
useful simply because a lot of data will be found within it, even if
it's not the fastest cache you could possibly have.

>> If ZRAM comes online for
>> AMD soon enough, then a 16MB ZRAM L3 can be substituted for a 2MB SRAM
>> L3, without much increase in real-estate.

> Your numbers are a little off. The ZRAM folks claim that really at
> best you can get a 5x improvement in density, not 8x. Secondly, I
> have yet to see any actual proof of this, especially for high
> performance caches. Thirdly, it's not clear how flexible AMD's L3
> controller and interface is; there's a limit to how much it can
> manage. Also, AMD would probably want to redo several aspects of the
> uarch to support a larger L3 cache. I suspect that AMD might do some
> inhouse trials of ZRAM using barcelona, but I think if they were going
> to change, they'd do it during a die shrink or uarch change.

I never said that 16MB ZRAM is identical in size to 2MB SRAM, I just
said, "without much increase in real-estate".

Anyways, I'm not saying we'll see a ZRAM L3 in the upcoming Barcelona
generation of Opteron. I think there will likely be a few more
generations yet before we see it.

Also recently, ISi made a new breakthough in ZRAM which they call ZRAM2.
This new version is much easier to deal with, because it's much easier
to read its state than the ZRAM1. AMD also has a license for this form,
so I don't know if they're going to go with ZRAM1 or 2, but if they go
with ZRAM2, it might require more validation. But ZRAM2 is apparently
also able to scale better towards smaller processes, so it provides a
bit of future-proofing.

Yousuf Khan


--
There is no failure, only delayed success

David Kanter wrote:
> On Jan 29, 7:42 am, Yousuf Khan <bbb....RemoveThis@yahoo.com> wrote:
>> In Intel's case, the main advantage of the shared L2 is not so much that
>> the shared cache allows two cores to share each other's data, but
>> that it allows them the flexibility to allow a single core to take over
>> the whole L2 cache for itself on an as-needed basis.

> I think in the *real* world, that's less important. For single
> threaded benchmarks, it is an advantage. But sharing your cache is a
> huge advantage for stuff like specjbb, tpcc, or real world stuff where
> you have data sharing between processors.

Depends on whose "real world" you're talking about. In PC applications,
the ability to share data is mainly useless, single-threaded performance
still rules the day. In servers, sure, shared data between threads is
useful.


> If you look at the time it takes to acquire a lock from another
> processor across the FSB (or even HT) versus from a shared cache,
> you're talking an order of magnitude or more quicker.

In the case of HT, it's not so much locking the data that takes time, as
it is in copying the data from the remote processor over the links to
your own local processor cache that matters most.


>> This gives a large
>> advantage in single-threaded performance. I don't think data sharing
>> between cores is that much of a big deal yet for anybody.

> Not really. There's quite a few people who think otherwise...

Different work definitions.


>> AMD's shared L3 cache may not be able to act in the same way as Intel's
>> shared L2 to increase single-thread performance

> Sure it will. It will decrease HT/memory accesses. That's a big win.

Which is what I think I had said just below that:


>> , since it will likely be
>> a slower path to the core. However, the shared L3 will likely reduce
>> cache-coherency inter-processor traffic, as cores will search their own
>> L3 first before sending out a message to another processor over the HT
>> link. This is good for server applications, if not so much for PC
>> applications.

> I fail to see the distinction between the two situations (C2D and
> Barcelona).

The Barcelona's shared L3 will be used mainly for "shared data between
cores" purposes, but not for "single-threaded overdrive" purposes. The
C2D having a shared L2, each of the cores accesses that L2 directly, so
therefore any single core can take over larger portions of the L2 as the
need arises, thus increasing single-thread performance, overdriving it
if you will.

The cores in Barcelona will not be reading anything directly in from L3,
it will all be first read from L3 to L1. The cores only ever read
directly from their own L1 or L2 in the AMD64 architecture. So in
Barcelona you can't simply have a core allocate a large portion of the
L3 if it needs to increase its single-thread performance. Granted,
something like that effect can occur but only in slow domino-effect
stages, as data overflows each lower-level cache and gets ejected into
the next higher level cache. Eventually after enough overflowage, a
really busy AMD64 core might be able to take over the entire L3 for
itself, just like a really busy C2D core could take over the full L2 for
itself.


> In each cache, the last level of on-die cache is shared between
> multiple processors, providing a performance advantage (usually).



I don't think in AMD64 there is a direct linkage between the cores and
the L3 cache. The cores only directly control L1 and L2, but L3 might be
an automatic catch basin for data that's overflowed those first two
caches. I could be wrong on this, and there might be a direct read pipe
from L3 to each core. In current AMD64, there is a similar mechanism
with the onboard memory controller. Data that has to be fetched from
system RAM is never read directly from the memory controller into the
core; instead it is read into the memory controller which then passes it
onto the L1 which then passes it to the core. The core may also
occasionally read directly out of the L2, if data is not found in L1.

Yousuf Khan


--
There is no failure, only delayed success