CASTalk.com

In article <e210d2-12f.ln1@vimes.paysan.nom>,
Bernd Paysan <bernd.paysan@gmx.de> wrote:

The net result is that a dual-core Opteron is probably $10 more expensive to
make than a single-core Opteron ($20 at most). Do you expect AMD to sell it
for $10 more? I rather expect three digit figures.

Initially.

I am expecting dual-core chips to start hitting the cheaper end of the
market in 2006, though they probably won't hit the sub-$1000 machines
until 2007.


Regards,
Nick Maclaren.

Bernd Paysan <bernd.paysan@gmx.de> wrote:

The net result is that a dual-core Opteron is probably
$10 more expensive to make than a single-core Opteron
($20 at most). Do you expect AMD to sell it for $10 more?
I rather expect three digit figures.

Irrespective of the production costs, the low-end market
for DC may not exist right away, as it is dependent on
Mr.Bill making good on his promise, in the future, to
count licenses by sockets ("CPUs") and not by cores.

Windows XP Home Edition may permit HyperThreading today,
but is strictly single-"CPU". Core 2 of a DC CPU wouldn't
be turned on (which wouldn't stop some unscrupluous OEMs
from selling and hyping a DC PC anyway).

When is MS planning to ship a DC-capable XP Home?
Will they also post a patch for existing XP Homes?
<http://www.microsoft.com/licensing/highlights/multicore.mspx>
doesn't say. MS doesn't commit to a specific release
date. They are, of course, famous for missing such
dates anyway.

Until retail PCs in common configurations (i.e. Windows)
can use DC, there's little point in anyone starting a price
war to drive DC chip prices down to that range.

--
Regards, Bob Niland mailto:name@ispname.tld
http://www.access-one.com/rjn email4rjn AT yahoo DOT com
NOT speaking for any employer, client or Internet Service Provider.

In article <opslfs0xjtft8z8r@news.individual.net>,
Bob Niland <email4rjn@yahoo.com> wrote:

Irrespective of the production costs, the low-end market
for DC may not exist right away, as it is dependent on
Mr.Bill making good on his promise, in the future, to
count licenses by sockets ("CPUs") and not by cores.

How about the low-end of the server market, which does not use Windows
XP Home Edition? Lots of Linux there, too.

-- greg

Irrespective of the production costs, the low-end market
for DC may not exist right away, as it is dependent on
Mr.Bill making good on his promise, in the future, to
count licenses by sockets ("CPUs") and not by cores.

Greg Lindahl <lindahl@pbm.com> wrote:
How about the low-end of the server market, which does not
use Windows XP Home Edition? Lots of Linux there, too.

Indeed, but is the volume enough compared to XP Home,
so that it would affect pricing decisions? Linux (and
FOSS generally) is likely affecting software pricing models,
but has Linux to date influenced any hardware pricing models?

Of course, all of this may be moot, as the real DC price
driver is AMD vs. Intel. There could be some stunning
differences between performance, speed grades available,
yields, thermals, 64-bit uptake, etc., that make MS
licensing and Linux considerations irrelevant.

With the GHz wars behind us (at least temporarily), we
eagerly await the imminent DC wars.

--
Regards, Bob Niland mailto:name@ispname.tld
http://www.access-one.com/rjn email4rjn AT yahoo DOT com
NOT speaking for any employer, client or Internet Service Provider.

Bernd Paysan wrote:

Klaus Fehrle wrote:

Actually, a dual-core CPU is more expensive to fab than two single-core
CPUs. Semiconductor-economies are often counter-intuitive.


Nah, the answer is "it depends". Packaging in a 940 pin ceramics PGA package
with thermal heat spreader is expensive, so if you make a dual-core CPU
with that package, you can be significantly cheaper than two single-core
CPUs.

Silicon itself is rather "cheap" (the raw silicon price for an untested
Athlon64 or Opteron should be somewhere around $20, depending on cache
size). Yield is a question - and a well-kept secret. If you have a yield of
60% for a single-core-CPU (assume the cache has good yield due to
redundancy), the yield of a dual-core is too small, less than 30%. However,
usual production yield should be rather in the >90% range, so a dual-core
wouldn't give you such a bad hit. You'll see that on the next process
transition: my bet is that the dual-core CPUs will show up later.

Testing mostly is a function of pins*time. A dual-core CPU can run the
time-consuming test code just as fast as a single-core CPU (the speed paths
to be evaluated can run in parallel). So the testing cost of a dual-core
CPU is roughly the same as of a single-core CPU.

The net result is that a dual-core Opteron is probably $10 more expensive to
make than a single-core Opteron ($20 at most). Do you expect AMD to sell it
for $10 more? I rather expect three digit figures.

Well, I do follow you to "it depends". The only way to make dual-core
dies manucaturable is a design for a joint production (allowing to make
use of silicon not passing all tests for the target product for lower
grade products - dualcore with lower cachesizes, and singlecore
products).

In terms of yields, look at the wafer processing capacities of Intel (or
AMD, which is easier to calculate) and the volume of CPU they make with
it. A quick back of the envelope calculation easily falsifies the myth
of overall yields >90%. Yield-figures of >90% do exist though, but these
are line yields for layers. Opteron has polysilicon plus nine
interconnect layers. (!) So, this process would hardly be manufacturable
without making a lot of Athlon64 and Sempron products from dies failing
to pass all tests to qualify for Opteron despite redundancy mechanisms
used. (HTT, L2-cache, registers). It is only because a design for
manufacturabilty as described above is utilized.

Now, based on that, the question how much one die qualified to package
an Opteron from really costs needs considerations what it would cost to
fab the byproducts on another process. This cannot be done on the back
of an envelope, but needs modeling. I do not have process data at hand,
but for a careful estimation it is a three-digit figure. Btw pretty much
the same for a mature 130nm process and for a juvenile 90nm precess for
now.

Bottomline again: Semiconductor-economies _are_ often counter-intuitive.

K.

Bob Niland wrote:

Windows XP Home Edition may permit HyperThreading today,
but is strictly single-"CPU". Core 2 of a DC CPU wouldn't
be turned on (which wouldn't stop some unscrupluous OEMs
from selling and hyping a DC PC anyway).

AFAIK AMD is planning to make the DC CPU appear to be HyperThreading to
Windows XP (probably enabled/disabled in the BIOS). They know Microsoft
well enough.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

In article <opslfuf0sift8z8r@news.individual.net>,
Bob Niland <email4rjn@yahoo.com> wrote:

Greg Lindahl <lindahl@pbm.com> wrote:
How about the low-end of the server market, which does not
use Windows XP Home Edition? Lots of Linux there, too.

Indeed, but is the volume enough compared to XP Home,
so that it would affect pricing decisions?

That depends on whether you think they're different markets or
not. AMD thinks it's different: the chip called "Opteron" doesn't go
into machines that run XP Home. Intel thinks it's different, too.

Linux (and
FOSS generally) is likely affecting software pricing models,
but has Linux to date influenced any hardware pricing models?

Now you're missing the point and asking a completely different
question.

-- greg

Greg Lindahl <lindahl@pbm.com> wrote:

That depends on whether you think they're different
markets or not. AMD thinks it's different: the chip
called "Opteron" doesn't go into machines that run
XP Home. Intel thinks it's different, too.

Do we know there won't be DC Athlon64's and Pentium
whatevers for the retail mkt?

I suspect that multi-processor is about to go
mainstream, once all the stars are aligned.

For some time, Intel didn't think 64-bit belonged
on the desktop.

--
Regards, Bob Niland mailto:name@ispname.tld
http://www.access-one.com/rjn email4rjn AT yahoo DOT com
NOT speaking for any employer, client or Internet Service Provider.

In article <opslfz3wwuft8z8r@news.individual.net>,
Bob Niland <email4rjn@yahoo.com> wrote:

Do we know there won't be DC Athlon64's and Pentium
whatevers for the retail mkt?

I suspect there will be, at some point. But the people who can get an
actual benefit from dual core today are the people in the server
market, especially Opteron servers, due to their superior memory
bandwidth. I suspect the typical low-end Opteron server is going to
move from being 2-way today to 4-way tomorrow, with performance a bit
lower than today's single-core 4-way Opteron due to memory bandwidth
issues, but with compelling price/performance.

-- greg

On 2005-01-30 19:08:10 -0600, Bob Niland <email4rjn@yahoo.com> said:

Greg Lindahl <lindahl@pbm.com> wrote:

That depends on whether you think they're different
markets or not. AMD thinks it's different: the chip
called "Opteron" doesn't go into machines that run
XP Home. Intel thinks it's different, too.

Do we know there won't be DC Athlon64's and Pentium
whatevers for the retail mkt?

Intel and AMD appear to be split here. Intel's dual-core "Smithfield"
is apparently a desktop chip ("Pentium"), not a server chip ("Xeon").
AMD is doing the opposite, by releasing the first dual-core K8 as a
server chip ("Opteron").

--
Wes Felter - wesley@felter.org - http://felter.org/wesley/

Nick Maclaren wrote:

In article <msqdnas2a9_FX2bcRVn-tw@metrocastcablevision.com>,
Bill Todd <billtodd@metrocast.net> wrote:

And multiple processors on a single chip can communicate with each other
with far lower latency than multiple separate cores (and their
associated caches) can.

Less true. Low-latency chip-chip isn't hard to achieve - just a
major hassle and correspondingly expensive.

Hmmm. IIRC Itanic's load latency to its humongous L3 on-chip cache is a
hair under 10 ns. Split up said cache across multiple chips cooperating
on the same task and I think you'll find that maintaining similar
latencies to the remote components is more than just a 'hassle': even
an architecture optimized for this like Opteron's introduces more than
this much *additional* latency for each 'hop' (EV7's overhead is even
higher, though of course the architecture is also much more extensible),
and shared-bus-structured architectures are even worse.


That is an almost entirely different matter.

Perhaps it is different from the statement you had intended to make.
But it is not different from the context you were responding to, without
qualifying that response to narrow its scope.

....

What I said was true - what you imagined that I said is false.

No: what you said was false, though what you imagined you said may have
been less so. You responded "Less true" to a statement about *both*
inter-CPU and (the inexorably related, if one cares about performance at
all and desires cache-coherent operation) inter-cache communication.

Multi-core processors are a natural for multi-threaded or multi-process
server applications. For workstations, often at least somewhat so. For
typical PC use (gaming possibly excepted) not much use at all, if for no
other reason than that existing single-core processors are already far
more than adequate at handling typical PC tasks.

Untrue. They are seriously inadequate.

Please provide examples of *typical* PC tasks (gaming excepted, as I
noted above) which are not already addressed quite adequately by even
the current mid-range desktop processors.


Mouse, keyboard, screen and window management under load, especially
when combined with heavy I/O, networking or memory-intensive background
work.

You've merely cited typical operations which current processors manage
entirely adequately save in the presence of some hypothetical load that
makes them unable to. But you have not presented any examples where
such a load *itself* is common (hence creating some actual usability
issue), hence have not addressed the challenge I posed.

Better luck next time.

E.g. using the typical ghastly modern GUI to a Web system. It

isn't JUST the network and the Web server that is the problem.

Before responding, please look back at the REST of what I said.

I already did the first time I encountered it. Perhaps you'd be
well-advised to do so as carefully: you appear to be having some
difficulty understanding what you purport to be responding to.

Since this may be another case where you have as little knowledge of
what you're talking about as you did about Unix file systems a few years
back, I won't waste any more time responding unless you actually come up
with something coherent in the way of substantiating your position.

- bill

In article <oYGdnWRzsrVwL2DcRVn-pw@metrocastcablevision.com>,
Bill Todd <billtodd@metrocast.net> wrote:

That is an almost entirely different matter.

Perhaps it is different from the statement you had intended to make.
But it is not different from the context you were responding to, without
qualifying that response to narrow its scope.

What I said was true - what you imagined that I said is false.

No: what you said was false, though what you imagined you said may have
been less so. You responded "Less true" to a statement about *both*
inter-CPU and (the inexorably related, if one cares about performance at
all and desires cache-coherent operation) inter-cache communication.

Please read what YOU said again. I was attempting to correct your
misapprehension that the latency will necessarily be larger with
multiple-CHIP solutions, as distinct from multiple-CORE ones. That
is quite simply wrong - the main issues relate to the number of cores
far more than the number of chips.

Fast, multi-chip solutions are a real hassle and add quite a lot of
cost, but need add relative little latency. All you need is a large
number of thick wires between them and suitable layout ....

Also, on the last point (snipped), YOU may not get irritated by the
delays in GUIs, but millions of people do. Even modern hardware isn't
fast enough to deliver the expectations of ghastly modern software.
That was perhaps the main drive for very fast CPUs (previously MHz,
possibly moving to cores, possibly not) on laptops and desktops.


Regards,
Nick Maclaren.

Greg Lindahl wrote:

In article <opslfz3wwuft8z8r@news.individual.net>,
Bob Niland <email4rjn@yahoo.com> wrote:


Do we know there won't be DC Athlon64's and Pentium
whatevers for the retail mkt?


I suspect there will be, at some point. But the people who can get an
actual benefit from dual core today are the people in the server
market, especially Opteron servers, due to their superior memory
bandwidth. I suspect the typical low-end Opteron server is going to
move from being 2-way today to 4-way tomorrow, with performance a bit
lower than today's single-core 4-way Opteron due to memory bandwidth
issues, but with compelling price/performance.

-- greg

I agree. Probably not a question of if, but when.
With respect to price/performance, frankly I am a bit puzzled currently.
I see a compelling p/p ratio in favour of Opteron today already; what I
don't see is AMDs architecture penetrating the commerdial segment at a
rapid pace in corporate use. While I am well aware of inertia and
business considerations in many ways standing in the way of a fast
transition, frankly all this is not really enough to explain the current
stagnation. So, what i am getting at is the actual benefit you mention.
Unfortunately I have very little insight into the various segments of
low-end commercial serverspace. All I have is some anecdotical reports
on typical loads which are reported to be below 10%, and very rarely go
into the double digits of load. Just as a hypothesis from this, could it
be that the performance criteria for most of these segments is really as
irrelevant as in Desktopspace currently?

K.

Rodrigo Augusto Barbato Ferreira wrote:

Hi all,

can anyone point a good paper (preferably published) that explains
why multicore chips seems to be the tendency for next generation
microprocessors?

Thanks in advance,
Rodrigo

You might want to take a look at some of the classical papers my the

Doug Burger group at University of Texas at Austin. He published a few
papers with respect to optimal pipeline depth and clock rate. The
primary problem is how do u increase clock frequency
(1) Pipeline depth (2) Technology
(1) is ruled out because apart from ur cache problem u also have the
problem of interconnects which also take a few cycles to transmit
through the processor. Hence the basic point is i cant increase my clock
so what do i do !! and the idea is to integrate more cores into thre
processor.