Re: MISC-d Digest V97 #28
- To: MISC
- Subject: Re: MISC-d Digest V97 #28
- From: jfox@xxxxxxxx (Jeff Fox)
- Date: Wed, 23 Jul 1997 18:10:19 -0700 (PDT)
Dear MISC readers:
There have been some comments in MISC recently about future chip
speeds. I thought I should pass on what Chuck has been saying about
this since last fall. Chuck has been saying that although he has
seen an increase in transistor speed with each reduction in geometry
the transition from .8u to .5u micron may not yield any increase in
speed. The reason for this is that .8 may be run at 3 or 5 volts
while .5u may only be run at 3v. The reduction in voltage causes
a reduction in speed similar to the increase in speed from the smaller
geometry. This step will result in a smaller and lower power chip
however. This means .5u will not let Chuck break the 1G barrier.
I have heard elsewhere that .5u can be 3v or 5v, but the indication I
got from Chuck was that he is not expecting to see .5u running twice
as fast as .8u because it was also going to be running at 3v
instead of 5v. Also the characterization of these processes as
.8u or .6u or .5u is somewhat misleading. The .8u process from HP
has some parameters about the same as some other's .6u processes.
iTV is negociating with companies that can provide access to even
smaller and more sophisticated fabrication processes that would
provide more speed and access to large amounts of on chip memory.
As people have noted here before the on chip memory is needed to
make full use of the CPU and coprocessor speed on these chips.
>We have heard of the stories of internet packages that
>can archeive limited graphical service withing 640k, why not. I would
>like to here Jeff's veiw on this, how much space does the ITV box code
>take up for what services?
Yes, we can run with 1Mx4 or 256kx4 DRAM chips. With the smaller chips
we have 256k 20 bit words, or 640k bytes of memory. We could get by
with less if we had to. The biggest single requirement is video memory.
Even in 384x482x15 NTSC composite some 60k words are needed by the
video output coprocessor.
Our CPU code is very dense. 4os provides us with a multi-threaded
Forth environment with a dynamic memory manager with garbage collection,
GUI with support for the video coprocessor, support for the on
chip keyboard and serial i/o coprocessors, video interrupt and real
time clock support, flash memory support, and TCP/IP networking code.
I don't have permission to disclose too many details of our code, but
I like to point out that our GUI requires one K word of memory for code
executed by the CPU. The video coprocessor requires 60k words of
video memory for the display, but the CPU code is only 1K. I like to
compare this to the executable code in other GUIs.
>> I am also looking forward to the F21. But notice how much has occured
>> interim, especially the advent of Beowulfs, and 1 Gbit ethernet. Mass
>> production makes even inefficient monster hardware ridiculously cheap, a
>> large handicap for MISC.
I think we are out of sync, but I like the lead in.
One of the changes I am pleased with is the fall in memory prices. The
cost of an F21 node is starting to look like it could be ridiculously
cheap to me. We know that if it is produced in large quantity F21 could
be really cheap. Since it only requires memory to make a node the nodes
can be really cheap. My low end estimate for an F21 node is now about
like buying a happy meal for a kid. How many "ridiculously cheap"
Beowulf nodes can one buy for that kind of bucks? Anyone care to speculate
on the minimal cost of a node with the fastest possible Pentium, motherboard
chipset controllers, cache, DRAM, pcb, and multiple high speed ethernet
controllers?
I read up on Beowulf computers on the web. These are nothing more than
workstation farms using Pentium PCs and multiple high speed ethernet
connections. It is very much like the idea behind F21.
I would not say that Beowulf computers are ridiculously cheap! The spec
says they should have the fastest Pentium available, 256k cache, 32M
DRAM, and multiple high speed ethernet controllers per node. So
although we are talking about similar performance per node compared to
an F21 system we are still talking about a HUGE price difference, like
maybe 100 to 1! When comparing two systems where one is 100x more
expensive I would hardly call the more expensive one ridiculously cheap.
And of course there is the issue of software bloat. It is bad enough
to have to pay for all the extra memory to hold all the extra software
needed to meet the Beowulf spec, but I think the real problem with
bloat is the bizzare idea that virtual memory will solve the problem.
We all know that we give up an order of magnitude in performace when
we have too much stuff to keep on chip and must go to external memory.
We also know that we give up another order of magnitude when we have
too much stuff to keep in cache (or high speed memory) and must go to
slower memory. We also know we give up several more orders of magnitude
when we have too much stuff to fit into memory at once and must
page it in and out of disk memory. You know when you are forced to give
up many orders of magnitude in performance because of bloat you really
do notice it.
Beowulf computers use Linux and X so the bloat factor may not be quite
as bad as it is with some other OS and GUI, but I really don't think
X will ever fit into 1k of memory.
Then there are other things like active messages on F21 vs conventional
message passing on Beowulf to get the parallelism. Layers and layers
of software inserted below the application's parallelism will also
be a factor. That high speed network connection gets wasted when
you build a parallel system on top of conventional message passing
on top of ethernet.
>Question? how hard (extra equipement) would it take to drive
>ethernet off the F21 chip.
There are people looking into ethernet on MISC chips, but that is
about all I can say about it.
This Saturday Skip Inskeep, John Rible, and Chuck Moore will be doing
presentations at the SV FIG meeting. Skip will talk about the tethered
development environments that he has done for i21 at iTV. John will
talk about Rochester, and Chuck will talk about how he has added Forth
to OKAD among other things. You never know what else Chuck might cover.
I like to hear his talks so I can find out what information he has
released publicly so I know what I can safely say about work at iTV.
I will try to attend so that I can post an unofficial transcript to
the MISC list.
Jeff
Jeff Fox
jfox@dnai.com Ultra Technology Inc.
http://www.dnai.com/~jfox/