Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (
More info?)
dkanter@gmail.com (David Kanter) writes:
>> Why do you assume clocks can't keep going up the way they did in the
>> past? Just because Intel reached a limit with Prescott, which may be
>> due to a lot of reasons other than "scaling is dead", you can't assume
>> the same is true for AMD, or Intel's other designs. I'm not making
>> any claims one way or another, just that you are drawing conclusions
>> on limited data. Certainly there's no evidence AMD believes it can't
>> scale MHz effectively in their 90nm process, and no reason to believe
>> that either Intel or AMD couldn't do so in their 65nm generation as
>> well.
>Well, their going dual core, that should be a clue.
That a logical fallacy. If in the transition from 130nm to 90nm and 90nm
to 65nm scaling became suddenly easier and they could get a 3x frequency
increase for each, would that mean that neither AMD nor Intel would go
dual core? I think the answer is an emphatic "NO WAY", of course they'd
still do dual core, and reap even larger performance benefits!
>> IMHO the bigger driver for dual cores is that smaller processes
>> allow for more transistors, and the easiest ways now to use those extra
>> transistors are for bigger cache or for additional cores.
>Let me give you a hint, 200mm^2 cores won't WORK in 90nm...
>You can spend transistors in many fashions:
>1. Improving the core
>2. Improving the cache
>3. Replicating the core
>1 causes problems if you use too much area. 2 is pretty inexpensive,
>from the area, defect and design standpoint, and 3 is inexpensive from
>the design standpoint (I suspect).
>Large area cores take too long for signals to traverse and are also
>problems from the yield stand point.
None of what you said refutes my point that dual cores were done due to
the additional available transistors, and have little or nothing to do
with whether scaling the clock rate is still working fine, has been
slowed down or has stopped entirely. No matter what was happening or
not happening with scaling, they'd do dual cores because the transistors
available allowed it and there wasn't any better/easier use of those
transistors.
>> That's probably one of the reasons why
>> Intel is increasing the cache size to 2MB, and moving to dual cores on
>> the desktop (since it is higher volume and can soak up more capacity)
>> before servers.
>Actually, IMHO that has more to do with heat and scaling issues
>driving the need for more cache and the inventory issues make larger
>die sizes more palatable.
>BTW, I believe that Intel will be releasing Dual core Xeons at the
>same time as dual core desktops.
Nope, latest info has them doing the desktops in Q3 2005, and the Xeons
in H1 2006. Given their recent slips I wouldn't put much stock into
those dates, of course...
>
>> This is in contrast to AMD, which is doing dual cores on the server
>> first, where the larger profit is, since they do not have oversupply
>> issues, but a much larger desktop die size could potentially lead them
>> into an undersupply.
>That's a good point, as dual core on the desktop would halve AMD's
>capacity. Maybe Intel should have thought about going quadcore...that
>would sure put some pressure on AMD.
>Did AMD state that they would release a dual core server chip before
>the desktop, or do they simply not intend to release a dual core
>desktop chip?
>Sorry, I stopped caring about the desktop market a while ago...
Yes, AMD has plans for dual core desktops in H1 2006, according to the
latest rumors.
>> Look for dual core desktop Athlon 64s to get
>> pushed forward if AMD starts having a lot of spare capacity (either due
>> to lower sales in the overall CPU market, or AMD's market share staying
>> stagnant or declining) If AMD's market share starts to shoot through
>> the roof, look for the dual core desktop Athlon 64s to get pushed back
>> to the 65nm generation.
>I doubt this will happen. Intel can easily push dual cores as a huge
>desktop advantage (twice as good). It will show up in benchmarks,
>unlike HT, which was just a blip. I would expect to hit ~30-70% gains
>on certain benchmarks, and also the systems will be more responsive
>since normal users have quite a few processes running at once.
Yes, Intel can definitely do that. But consider this: Right now AMD
is selling everything they can make, supplying a desktop market that's
growing slowly, and a server market that's growing quickly (easy to do
considering it was essentially zero 18 months ago) 90nm gives them
more chips due to the smaller die sizes, but they have to supply their
existing desktop market, fast growing server market, and plan to attack
the mobile market as well in 90nm. They may simply not have the capacity
to attack the dual core desktop market in any meaningful way until they
move to their new 300mm fab at 65nm in 2006. Sure, they might sell some
dual core Athlon FXs, since those are just Opterons with a different
pinout and they will be selling dual core Opterons next summer. But if
Intel moves aggressively to dual cores across their whole desktop range
by this time next year, AMD probably won't be able to answer.
It will be interesting to see how consumers perceive the choice between
a dual core CPU with each core running at 3 GHz or so, versus a single
core Athlon 64 5000+ running at 3 GHz or so. It'll come down to marketing
of course, and Intel always wins there, but the benchmarking war ought to
be fun. There will be some things that Intel will win going away but for
other things that don't parallelize as well AMD will totally dominate.
Even though Intel is dropping HT, at least for the new dual cores which
will not have HT enabled, it will have done its job as it got some
developers interested in threading their applications. More importantly
for Intel, they concentrated on making sure all the apps used for
benchmarks supported HT, which will help their showing with their dual
core CPUs next year. A dual core CPU released in 2001 would have looked
useless on the desktop benchmarks of the time, but now there is a lot of
multitasking built into most of the apps used for testing, courtesy of
Intel.
--
Douglas Siebert dsiebert@excisethis.khamsin.net
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety" -- Thomas Jefferson
Facebook
Twitter
Instagram