I've read threads here about both AMD and Intel bringing out new "real"
quad-core processors for 4+ socket servers in a few months. I am
looking at a machine with 2 real quad Xeon processor. Does anyone know
approx. how long am I looking at - am I looking at March? June? Fall?
December? of 2007?

Apart from this forum, where can I find more information on this
timeframe issue?

Thanks for any reply.

phuile wrote:
AMD won't have quad cores till the second half of this year AFAIK.
Intel already offers quad Xeon DP systems.

How about they have been available since November?

DK

* David Kanter:
OP If you mean single die - i.e. not two dual-cores put together - the
answer seems to be not until next year. Though as DK indicates, just
because the current ones are not single die, doesn't mean that they're
inferior.

--
Derek

Yes, I am talking about the "real" quad, not 2 dual core put together.
I am asking because I was in a discussion on another thread in this
forum and happened to read that some people are prepared to wait for
the "real" quad from Intel. The reason being that AMD will have them
coming "soon" and Intel shouldn't be far off if they want to compete. I
am just consdering whether I should wait or just go ahead with the
currently quad Xeon. That's why I am wondering whether anybody knows
about the time frame.

phuile wrote:
Well, the answer seems to have been updated recently: not till sometime
in 2008, _after_ Intel has converted to 45nm!

http://www.tgdaily.com/2007/01/27/in...enryn_details/

For Intel with a shared L2 cache, it may not be as easy to redesign it
to accommodate 4 cores rather than just 2. AMD will only have a shared
L3 cache, which is not as performance critical as an L2 cache, so some
design flexibility might be available there.

As for the advantages of a real quad-core vs. dual-dual-cores, we really
won't know the answer to that until AMD launches its real quad-core. So
far people think it won't make a difference, but AMD is claiming that
Barcelona will be upto 40% faster than Cloverton. Pretty much what Intel
claimed Conroe would be over Athlon 64 before it got launched; back then
people were skeptical, but it turned out to be true. AMD might hold
similar aces up its sleeve. We can assume that AMD will implement all of
the same architectural improvements to its cores that Intel did to make
Core 2 so good, so at the very least it will equal Core 2. Then AMD will
have a shared L3 cache between the 4 cores, which should pool common
data among all 4 cores rather than 2; the shared L2 cache worked wonders
for Core 2 over Athlon 64, it was probably worth over 50% of the overall
improvement by itself. Also although Core 2 is a superb computational
engine, it's definitely not state-of-the-art at I/O throughput (i.e.
Hypertransport vs. front-side-bus). It's masking its I/O deficiencies
with big caches at the moment. The I/O throughput equation also includes
communications between processors in a multiprocessor system. When they
scale up over two processors, the FSB is a bottleneck.

Yousuf Khan

--
There is no failure, only delayed success

On Jan 22, 6:50 pm, "phuile" <phu... (AT) yahoo (DOT) ca> wrote:
Can you explain to me exactly what the difference is? It sure seems
like most software doesn't know the difference.

Yes, well, some people also stored up tons of canned food for Y2K.
That just made them crazy...

What makes you think that Intel "needs" an integrated solution? The
only questions that a user should care about are:
1. What is the performance for the applications I care about, or
performance generally?
2. What is the power dissipation?
3. How much does it cost?

Having four cores on a single die is a way to improve performance.
However, it has drawbacks. You cannot bin the parts to match on
frequency and power dissipation. It is inherently more expensive to
produce, because larger dice have lower yields.

Using a multichip package has some advantages and disadvantages as
well. It is lower performance for multithreaded applications, but can
be higher performance for some single threaded applications, since the
frequencies will be higher. The reason that frequency will be higher
is that you can choose the two dice that go into the MCP, and pick so
that they are both really fast, or both slow. It's also probably 10x
cheaper to developer a new CPU with a multichip package than with a
new project.

Only zealots really want to portray it as a black and white issue.
AMD doesn't have the technology to do a multichip package so they have
been spending a lot of effort to get people to believe that "only
integrated quad cores are real quad cores", which is bunk. AMD's
performance will scale better because of the choices they made, but it
is balanced out by being somewhat more expensive in other ways.

If your workload isn't multithreaded, then it won't even matter
anyway.

Intel won't do four cores on a die for another 1.5-2 years. It really
depends on what your application is, most applications simply don't
have 4 threads, so you're better off buying the fastest dual core you
can get.

DK

On Jan 27, 10:06 pm, Yousuf Khan <bbb... (AT) yahoo (DOT) com> wrote:
Absolutely.

This sentence really doesn't make much sense. How is there design
flexibility from having a shared L3 versus a shared L2 cache? It's
really all the same.

AMD is claiming that it will be 40% faster in SPECfp_rate than
EXISTING clovertown processors. Between now and then clovertown could
increase in clockspeed...imagine that. I bet on average the two
products will be about even, with AMD winning on FP and numerical
workloads, and Intel winning on more integer stuff.

You could assume that, and you'd be wrong. AMD already stated that
they are not doing full LD/ST reordering, and they are only reordering
loads around other loads. That's much easier to do, and provides less
of a performance benefit.

Besides, any changes that AMD made to Barcelona were set in stone
around 1-2 years ago.

That's really easy to model though. The problem with Intel's quad
core is that there is duplication between the different L2 caches, but
it probably isn't that bad.

Can you back that statement up by data? Those numbers seem
ridiculously high.

DK

On Jan 27, 11:51 pm, The Kat <n... (AT) katxyzkave (DOT) net> wrote:
Yup. It becomes an issue when you have one CPU in the package trying
to write, while the other CPU is trying to read or write.

It's not ideal, but it is a lot cheaper and easier to do, and I think
both Intel and AMD make the appropriate choices for their respective
situations.

DK

David Kanter wrote:
But L3 can be:
a) slower (latency wise)
b) concurrency is less (L1/L2 handles much more traffic that just L1)

IOW -- it's easier to share slower L3 than faster L2.


But up to now AMD does virtually none of that while Intel did that stuff
(LD/LD) since P6. So finally AMD picks that long hanging fruit with
performance improvement associated with that. This sole thing should bring
performance up by 2 speedgrades.


The problem is bus load. Coherency traffic is exposed on CPU's FSB and
occurs at FSB speed.


rgds
--
Sebastian Kaliszewski

David Kanter 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. Since 4
cores accessing the same memory would require more traffic management,
which adds latency, the fact that the cores are relying much less on the
L3 than L2 will result in less weighted-average latency increase.

In fact, L3 might be ideal for the experimental caches like AMD's ZRAM,
or Intel's FB-RAM. 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. Intel is talking about a 16MB SRAM L3 cache in some future
quad-core processor (assume Nehalem), at 45nm. 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.

Yousuf Khan