15 Nov
2007
15 Nov
'07
4:22 a.m.
On Tuesday 13 November 2007 17:28, Chuck Guzis wrote:
On 13 Nov 2007 at 16:56, Roy J. Tellason wrote:
I don't have anything here nearly that fast. This is a 500 MHz machine, and
my _server_ is a K6-200. I have a few other boards that I need to test, and
set up some newer stuff, but mostly I'm a ways behind the bleeding edge...
Well, my admittedly limited experience with
stuff is that the "main"
processor isn't doing much of anything while it's waiting for I/O to
complete anyhow, or at least that's what my perception has been. Now
I'll be the first to admit that my perceptions are very much skewed
toward the 8-bit micro and crudely-done DOS-based end of things, so
maybe I just need to get a good hard look at how some other stuff is
done.
Well, why have a multi-gigahertz CPU if you're not going to do
computationally intensive things with it? A lot of graphics and
multimedia is very computationally intensive in today's world, even
with gigaflop GPUs. In the CDC 6600, I should probably say that Seymour
Cray rigged things to
give the *appearance* of 10 PPUs. Core back then was 1 microsecond and the
CPU used it interleaved by a factor of 10, so a cycle time of 100 nsec was
possible. The "10" PPUs all shared a common ALU--each had its own 1
microsecond 4Kx12 bit memory, P-counter and accumulator, and each took a
turn in the "barrel" so that each appeared to be an independent CPU. Access
to central memory (60 bits wide) by the PPUs was obtained through what was
called the "read-write pyramid" where up to 5 CPU words could be in various
stages of assembly or disassembly. It was very slick.
Since some really fast static RAM parts are out there these days (stuff that
can be pulled off old 386 and 486 boards ferinstance) maybe I can play some
of those sort of games with some 8-bit parts that have comparatively long
cycle times... :-)
And yes, in its day, the 6600 was considered to be a
computational
"monster" that used a lot of the tricks we use today to speed up CPU
execution. Slow functional units were segmented (early pipelining),
there was a read-ahead cache for instructions, so it was possible to
keep small loops entirely in cache, and elegant scheduling method was
used to control instruction scheduling. And the instruction set
itself was very simple; some refer to it as very RISC-like.
There was a lot of clever thought and a lot of elegance in early hardware and
software that seems sadly lacking in more current stuff. My recent comment
about WordStar's so apparently seamless switch from all-in-memory to using a
bunch of disk space I commented on recently being one example. I have
patched the living hell out of the copy of ws.com I used, doing all sorts of
stuff to it -- because I could! :-) Sure it took some doing, but these
days a lot of knowledge of that sort seems to be just about lost
completely. :-(
All this with core and discrete transistors, yet.
Yup...
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, ?a critter that can
be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin