65nm news from Intel

In article g9WYc.3239$OQ6.1732@trnddc09, "Raymond" writes:
| This is just extra publicity for what has already been
| known for months, ie the drive to 65nm is on a fast
| pace, things are looking good, much more straining of
| silicon, better internal power management, etc. The really
| exciting transistor designs will happen at 45nm, using the high-k
| interconnects. Though that's still three years away. And there
| is interesting research going on at 15nm, for the next decade.

Oh, really? I did a quick Web search, but couldn't find when
the comparable announcement was made for 90 nm. I vaguely
remember mid-2001, which was a little matter of 3 years before
90 nm hit the streets in quantity.

If my recollection is correct, it isn't looking good at all for
65 nm, as the passive leakage problems are even worse. Mid-2007
for mass production isn't what Intel are hoping for (or claiming),
but IS what ITRS are predicting ....

I shall not be holding my breath for 65 nm; you are welcome to
hold yours for it :-)


Regards,
Nick Maclaren.

Nick Maclaren wrote:
If my recollection is correct, it isn't looking good at all for
65 nm, as the passive leakage problems are even worse. Mid-2007
for mass production isn't what Intel are hoping for (or claiming),
but IS what ITRS are predicting ....

If you read the article, the statement is that leakage is dealt with to
a degree by straining the silicon lattice. I don't know how much that
changes things, but they want us to think it solves the problem (which
it probably doesn't).

I thought 2005 was too soon for 65nm, but that's what I read. That
Pentium 4 will be shipping in 2005 on 65nm. Which, thankfully, gives
that embarrassment that is Prescott just one year of life.

Alex
--
My words are my own. They represent no other; they belong to no other.
Don't read anything into them or you may be required to compensate me
for violation of copyright. (I do not speak for my employer.)

"Raymond" wrote :

[cut]

reaping the full potential of 2+ cores. 2+ cores may end up like
the 386, full of potential but not enough software support.

yes, like all the rest of SMP boxes, obsolete and unsupported ...

Pozdrawiam.
--
RusH //
http://randki.o2.pl/profil.php?id_r=352019
Like ninjas, true hackers are shrouded in secrecy and mystery.
You may never know -- UNTIL IT'S TOO LATE.

In article ,
Alex Johnson writes:
|
| If you read the article, the statement is that leakage is dealt with to
| a degree by straining the silicon lattice. I don't know how much that
| changes things, but they want us to think it solves the problem (which
| it probably doesn't).

One of the most reliable sources in the industry has told me that
it doesn't. Yes, it helps, but only somewhat.

| I thought 2005 was too soon for 65nm, but that's what I read. That
| Pentium 4 will be shipping in 2005 on 65nm. Which, thankfully, gives
| that embarrassment that is Prescott just one year of life.

If you believe that ordinary customers will be able to buy 65 nm
Pentium 4s at commodity prices in mid-2005, I have this bridge for
sale ....


Regards,
Nick Maclaren.

On Tue, 31 Aug 2004 02:41:55 -0400, Tony Hill
wrote:

However the new 90nm fab process has maybe thrown this automatic
assumption of much higher clock speeds into question, at least for the
time being. Intel's still having trouble getting the "Prescott" P4 up
to 3.6GHz and have pushed back the release date of their 3.8 and
4.0GHz P4 chips multiple times.

As I understand it, you could indeed hit, say, 5 GHz with a 90 nm
process (and Prescott's design - longer pipeline, etc - indicates
Intel were hoping to do just that), except that the chip would melt?

--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.

In article ,
(Russell Wallace) writes:
| On Tue, 31 Aug 2004 02:41:55 -0400, Tony Hill
| wrote:
|
| However the new 90nm fab process has maybe thrown this automatic
| assumption of much higher clock speeds into question, at least for the
| time being. Intel's still having trouble getting the "Prescott" P4 up
| to 3.6GHz and have pushed back the release date of their 3.8 and
| 4.0GHz P4 chips multiple times.
|
| As I understand it, you could indeed hit, say, 5 GHz with a 90 nm
| process (and Prescott's design - longer pipeline, etc - indicates
| Intel were hoping to do just that), except that the chip would melt?

I am pretty sure that Intel could cool the chip, even at that speed.
A factory-fitted silver heatsink, with high-speed water-cooling to
a heat exchanger in front of a large and fast fan, bolted into a
heavy chassis, should do the job.

As a demonstration of virtuosity, it would be excellent. As a
system to sell in large numbers, perhaps not.


Regards,
Nick Maclaren.

"Nick Maclaren" wrote in message
...

In article g9WYc.3239$OQ6.1732@trnddc09, "Raymond" writes:
| This is just extra publicity for what has already been
| known for months, ie the drive to 65nm is on a fast
| pace, things are looking good, much more straining of
| silicon, better internal power management, etc. The really
| exciting transistor designs will happen at 45nm, using the high-k
| interconnects. Though that's still three years away. And there
| is interesting research going on at 15nm, for the next decade.

Oh, really? I did a quick Web search, but couldn't find when
the comparable announcement was made for 90 nm. I vaguely
remember mid-2001, which was a little matter of 3 years before
90 nm hit the streets in quantity.

If you read exactly what Intel said after they achieved 90nm
SRAM, they weren't anywhere as rosy as they are now with
65nm.

If my recollection is correct, it isn't looking good at all for
65 nm, as the passive leakage problems are even worse. Mid-2007
for mass production isn't what Intel are hoping for (or claiming),
but IS what ITRS are predicting ....

I shall not be holding my breath for 65 nm; you are welcome to
hold yours for it :-)

I am holding my breath! :-)

"Nick Maclaren" wrote in message
...

In article ,
Alex Johnson writes:
|
| If you read the article, the statement is that leakage is dealt with to
| a degree by straining the silicon lattice. I don't know how much that
| changes things, but they want us to think it solves the problem (which
| it probably doesn't).

One of the most reliable sources in the industry has told me that
it doesn't. Yes, it helps, but only somewhat.

| I thought 2005 was too soon for 65nm, but that's what I read. That
| Pentium 4 will be shipping in 2005 on 65nm. Which, thankfully, gives
| that embarrassment that is Prescott just one year of life.

If you believe that ordinary customers will be able to buy 65 nm
Pentium 4s at commodity prices in mid-2005, I have this bridge for
sale ....

What they're saying is first production in 2005, and high volume by
2006, perhaps even high enough to overtake that of 90nm.

"Raymond" wrote in message news:g9WYc.3239$OQ6.1732@trnddc09...

What's not known is exactly how Intel is going to design
the silicon. How are the multiple cores going to work, especially
with the one bus? Even more significantly, how are applications going
to benefit from the 2+ cores; are they going to have to explicitly
code multiple-threading to benefit, which afterall ain't easy to pull off,
or will the feeding of the multiple cores be handled effectively by the
compilers,
or may be even the OS? I see that Intel has released a thread checking
tool, hopefully MS incorporates something like it in their next Studio.

Every version of Windows based on NT (NT, 2000, XP, Server 2k3,
Longhorn, etc) has gotten progressively better at utilizing multiple
CPU's. MS keeps tweaking things to a finer level of granularity. So
minimally, a single threaded application could still hog 1 CPU, but at
least the OS underneath will do it's best to make use of the other
CPU.

Also, I suspect your comments about languages are true when it comes
to C/C++. But the newer languages like Java, C# and VB.Net make
working with threads MUCH easier. I'm not exactly sure what MS could
"incorporate in their next Studio" that could possibly make it any
easier to write multi-threaded managed code. And with alot more of
Longhorn written itself as managed code, inculding the new Avalon/XAML
UI stuff, I suspect that even traditional message driven GUI code will
make better use of multiple cores. Of course the cynics will claim
that amounts to Windows yet again sucking all possible power out of
even the latest & greatest hardware, but I guess that's inevitable.

IMO the bigger debate will be: Do I go for a faster single core or
slower dual core CPU? All things being equal (including cost), I think
a dual core chip has to be clocked slower and/or have less cache???
Not confusing the market will be a real challenge if that's the case.

"G" wrote in message
om...
"Raymond" wrote in message
news:g9WYc.3239$OQ6.1732@trnddc09...

Every version of Windows based on NT (NT, 2000, XP, Server 2k3,
Longhorn, etc) has gotten progressively better at utilizing multiple
CPU's. MS keeps tweaking things to a finer level of granularity. So
minimally, a single threaded application could still hog 1 CPU, but at
least the OS underneath will do it's best to make use of the other
CPU.

Also, I suspect your comments about languages are true when it comes
to C/C++. But the newer languages like Java, C# and VB.Net make
working with threads MUCH easier. I'm not exactly sure what MS could
"incorporate in their next Studio" that could possibly make it any
easier to write multi-threaded managed code. And with alot more of
Longhorn written itself as managed code, inculding the new Avalon/XAML
UI stuff, I suspect that even traditional message driven GUI code will
make better use of multiple cores. Of course the cynics will claim
that amounts to Windows yet again sucking all possible power out of
even the latest & greatest hardware, but I guess that's inevitable.

IMO the bigger debate will be: Do I go for a faster single core or
slower dual core CPU? All things being equal (including cost), I think
a dual core chip has to be clocked slower and/or have less cache???
Not confusing the market will be a real challenge if that's the case.

I like the idea of at least 2 cores for desktops, as long as it's implemmented
well. There is enough multi-threading and multi-tasking going on today
for some real benefit, but won't be even close to x2 performance. Beyond
2 cores, I don't see much benefit adding more cores for desktops, not today,
and not tomorrow, nothwithstanding a lot more intense use of multi-threading.
I just don't see how the OS, or any compiler, can possibly deal with the main
logical
issues involved in sychronization and concurrency, automagically turning an
otherwise
mostly STA program into a multi-threaded one. .NET has some nice features for
multi-threading, but other than the garbage collector, they don't run by
themselves.
It's still up to the developer to handle the logical issues involved, and
debugging
them is still quite a challenge.