65nm news from Intel

[Nick Maclaren]

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

I need to correct what I said - it was 2 years. March 2002.

Actually, I remember them being every bit as optimistic. Anyway,
such claims are worth almost as much as the hot air that carries
them.

I am holding my breath!

You have better lungs than I do


Regards,
Nick Maclaren.

 

[Nick Maclaren]

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

Even if that were so, it would give Prescott a lot more than a year
to hold the fort.

Anyway, once upon a time when knights were bold and press statements
were intended to convey information, "production" meant the delivery
of products, and "products" meant goods sold to ordinary customers.
At least in this context.

Yes, I believe that Intel (and IBM) will be able to make 65 nm CPUs
in early 2005, perhaps even late 2004. But small numbers of ones
made for testing does not constitute production in any meaningful
sense.

Regards,
Nick Maclaren.

 

[=?ISO-8859-1?Q?Jan_Vorbr=FCggen?=]

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.

A heat pipe is better at moving heat than any solid material, and quite
easy to use.

Dumping all those watts in the environment, absent water cooling, is more
of a problem. I'd rather not have several hundred watts heating the air in
my office, thank you.

Jan

 

[Nick Maclaren]

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.

I am afraid not. I haven't looked at them in detail, but a quick
glance indicates that they give the appearance of making the design
and coding of threaded applications easier, while not tackling the
most important problems.

But your last remark is correct. It isn't hard to separate GUIs
into multiple components, separated by message passing (whether
using thread primitives or not), and those are a doddle to schedule
on multi-core systems. And that is the way that things are going.


Regards,
Nick Maclaren.

 

[Nick Maclaren]

A heat pipe is better at moving heat than any solid material, and quite
easy to use.

Hang on - I never said that the silver heatsink was solid! It should
be silver for the conductivity and resistance to corrosion, but I was
assuming circulating water inside it. Sorry about omitting that
critical point :-(

Dumping all those watts in the environment, absent water cooling, is more
of a problem. I'd rather not have several hundred watts heating the air in
my office, thank you.

Or 1,000 of them dumping heat in my machine room ....


Regards,
Nick Maclaren.

 

[Ken Hagan]

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.

A data point. I'm doing nothing much except reading this group and yet
the XP performance monitor shows a queue of 7 or 8 threads ready to run.

I think applications like WORD and Excel already do things like spell-
checking and recalculation in worker threads. I don't find it hard to
believe that a typical Windows box would benefit from 4+ "processors".

 

[Joe Seigh]

But your last remark is correct. It isn't hard to separate GUIs
into multiple components, separated by message passing (whether
using thread primitives or not), and those are a doddle to schedule
on multi-core systems. And that is the way that things are going.

I'm not sure that the gui by itself is enough to justify a multi-core
cpu. And there are problems enough in multi-threaded gui, even apart
from deadlocks caused by inexperienced programmer mixing threads and OO
callbacks. Consider mouse events queued before but received after a
resize operation. The mouse coordinates are in the wrong frame of reference
and all wrong. Gui designers design as if the event queue was <= 1 at all
times.

What would more likely to utilize concurrency would be the database like
Longhorm filesystem that MS is supposed to be doing. Except that I don't
think MS has the expertise to do lock-free concurrent programming like that.
If they have, they've been keeping a low profile.

Joe Seigh

 

[Nick Maclaren]

|>
|> I'm not sure that the gui by itself is enough to justify a multi-core
|> cpu. And there are problems enough in multi-threaded gui, even apart
|> from deadlocks caused by inexperienced programmer mixing threads and OO
|> callbacks. Consider mouse events queued before but received after a
|> resize operation. The mouse coordinates are in the wrong frame of reference
|> and all wrong. Gui designers design as if the event queue was <= 1 at all
|> times.

Take a mouse event in an unrealistically simple design. This is picked
up by the kernel, and passed to the display manager, which converts it
into another form and passes it to the application. That does something
with it, passes a message to the display manager, which calls the kernel
to update the screen. The user does not see any effect until that has
completed.

At best, you have 4 context switches, 2 of which are between user-level
contexts, and it is common for there to be MANY more. Now, consider
that being done as part of drag-and-drop - you want the process to
happen in under 2 milliseconds (certainly under 5), or it will start to
be visible. That can be 1,000+ context switches a second, and some
of those contexts have large working sets, so you are reloading a
lot of cache and TLBs.

One of the advantages of a multi-core system is that you don't need to
switch context just to pass a message if the threads or processes are
on different cores. You just pass the message.


Regards,
Nick Maclaren.

 

[Anne & Lynn Wheeler]

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.

long ago and far away i was told that the people in beaverton had done
quite a bit of the NT smp work ... since all they had was smp (while
redmond concentrated on their primary customer base ... which was
mostly all non-smp).

 

[Stefan Monnier]

I think applications like WORD and Excel already do things like spell-

checking and recalculation in worker threads. I don't find it hard to

I also see a lot of background processes from GUI thingies on my Mac.
This sucks because it happens even for application that are currently
"idle". E.g. there are two other people "logged in" but currently inactive,
but they use up a lot of resident pages, thus making me page a lot more.
I suspect that with 10 users logged in at the same time and only 768MB of
RAM, the machine would be brought to its knees :-(


Stefan

 

[Russell Wallace]

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.

Indeed, I read awhile ago that someone actually did crank a P4 to 5
GHz with the aid of a custom-build liquid cooling system. Of course,
it was a "because it's there" personal project rather than a
commercial product.

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

Quite.

 

[Russell Wallace]

Dumping all those watts in the environment, absent water cooling, is more
of a problem. I'd rather not have several hundred watts heating the air in
my office, thank you.

For me, that would be an advantage: I need the heat anyway; it might
as well be doing useful work on the way. It's the cost of the system
that'd be a problem.

 

[Russell Wallace]

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.

We had exactly that argument 15 years ago with regard to parallel
processing on servers and supercomputers.

It won't surprise me in the least if 15 years from now, when the
conversation is about multiple cores in digital watches or whatever,
someone says "we had exactly that argument 15 years ago with regard to
parallel processing on desktops"

 

[Nick Maclaren]

We had exactly that argument 15 years ago with regard to parallel
processing on servers and supercomputers.

And 30 years ago. I wasn't in this game 45 years ago.

It won't surprise me in the least if 15 years from now, when the
conversation is about multiple cores in digital watches or whatever,
someone says "we had exactly that argument 15 years ago with regard to
parallel processing on desktops"

Nor would it surprise me. Raymond makes one good point, though he
gets it slightly wrong!

There is effectively NO chance of automatic parallelisation working
on serial von Neumann code of the sort we know and, er, love. Not
in the near future, not in my lifetime and not as far as anyone can
predict. Forget it.

This has the consequence that large-scale parallelism is not a viable
general-purpose architecture until and unless we move to a paradigm
that isn't so intractable. There are such paradigms (functional
programming is a LITTLE better, for a start), but none have taken
off as general models. The HPC world is sui generis, and not relevant
in this thread.

So he would be right if he replaced "beyond 2 cores" by "beyond a
small number of cores". At least for the next decade or so.


Regards,
Nick Maclaren.

 

[G]

|>
|> I'm not sure that the gui by itself is enough to justify a multi-core
|> cpu. And there are problems enough in multi-threaded gui, even apart
|> from deadlocks caused by inexperienced programmer mixing threads and OO
|> callbacks. Consider mouse events queued before but received after a
|> resize operation. The mouse coordinates are in the wrong frame of reference
|> and all wrong. Gui designers design as if the event queue was <= 1 at all
|> times.

Take a mouse event in an unrealistically simple design. This is picked
up by the kernel, and passed to the display manager, which converts it
into another form and passes it to the application. That does something
with it, passes a message to the display manager, which calls the kernel
to update the screen. The user does not see any effect until that has
completed.

At best, you have 4 context switches, 2 of which are between user-level
contexts, and it is common for there to be MANY more. Now, consider
that being done as part of drag-and-drop - you want the process to
happen in under 2 milliseconds (certainly under 5), or it will start to
be visible. That can be 1,000+ context switches a second, and some
of those contexts have large working sets, so you are reloading a
lot of cache and TLBs.

One of the advantages of a multi-core system is that you don't need to
switch context just to pass a message if the threads or processes are
on different cores. You just pass the message.


Regards,
Nick Maclaren.

Actually I wasn't even thinking about anything remotely as complicated
as that.

What I thought is that since XAML is declarative in nature, that an
"inexperienced programmer mixing threads and OO callbacks" (Joe's
comment) wouldn't really be doing the coding at all. It would be done
(and theoretically optimized) by the implementation that sits behind
it.

With respect to both threaded apps and GUI development, my only point
is that it's one possible benefit of the newer higher level
languages/tools. In fact I seem to remember the exact same case being
made a long time ago for things like the UCSD P-System... Whether it's
true or not I can't say.

 

[spinlock]

We are on track for mass shipment of a
billion(that's with a B) transistor die by '08.

We shall all now bow toward Santa Clara.

Moore Rules!!!!

 

[Nick Maclaren]

Actually I wasn't even thinking about anything remotely as complicated
as that.

Don't ever try to track down a bug in a GUI system, then :-( I was
not joking when I said that was unrealistically simple.

What I thought is that since XAML is declarative in nature, that an
"inexperienced programmer mixing threads and OO callbacks" (Joe's
comment) wouldn't really be doing the coding at all. It would be done
(and theoretically optimized) by the implementation that sits behind
it.

Grrk. I don't know XAML, but that sends shivers up my spine. It is
FAR harder to get that sort of thing right than it appears, unless
the language is designed to ensure that such parallelism cannot
create an inconsistency. And VERY few are.

With respect to both threaded apps and GUI development, my only point
is that it's one possible benefit of the newer higher level
languages/tools. In fact I seem to remember the exact same case being
made a long time ago for things like the UCSD P-System... Whether it's
true or not I can't say.

It has been claimed more often than I care to think, and I have been
inflicted with such claims since the 1960s. Yes, it is a possible
benefit, but it is rarely delivered. Such languages typically make
one of three errors:

Relying on the user not making an error - not one.

Being so restrictive that they can't be used for real work.

Being so incomprehensible that nobody can understand them.


Regards,
Nick Maclaren.

 

[AD.]

We are on track for mass shipment of a billion(that's with a B) transistor
die by '08.

We shall all now bow toward Santa Clara.

Moore Rules!!!!

Ummm... the 'lock' fell off your 'spin'

 

[Russell Wallace]

There is effectively NO chance of automatic parallelisation working
on serial von Neumann code of the sort we know and, er, love. Not
in the near future, not in my lifetime and not as far as anyone can
predict. Forget it.

At least as far as your typical spaghetti C++ is concerned, yeah, not
going to happen anytime in the near future.

This has the consequence that large-scale parallelism is not a viable
general-purpose architecture until and unless we move to a paradigm
that isn't so intractable.

And yet, by that argument there should be no market for the big
parallel servers and supercomputers; yet there is. The solution is
that for things that need the speed, people just write the parallel
code by hand.

If what's on the desktop when Doom X, Half-Life Y and Unreal Z come
out is a chip with 1024 individually slow cores, then those games will
be written to use 1024-way parallelism, just as weather forecasting
and quantum chemistry programs are today. Ditto for Photoshop, 3D
modelling, movie editing, speech recognition etc. There's certainly no
shortage of parallelism in the problem domains. The reason things like
games don't use parallel code today whereas weather forecasting does
isn't because of any software issue, it's because gamers don't have
the money to buy massively parallel supercomputers whereas
organizations doing weather forecasting do. When that changes, so will
the software.

 

[Grumble]

We are on track for mass shipment of a billion (that's with a B)
transistor die by '08.

Who's "we" ?

I have read that there will be ~1.7e9 transistors in Montecito.
Cache (2*1 MB L2 + 2*12 MB L3) probably accounts for ~90% of the
transistor count. Montecito is expected next year.

At 90 nm, please correct me if I am wrong, the chip would occupy
between 650 mm^2 and 750 mm^2. Is that possible?

We shall all now bow toward Santa Clara.

Whatever floats your boat.