even today on an average computer one has this articulation: a CPU (with
a FPU perhaps) ; tightly or loosely connected storage (?ATA or SAN) ;
graphical capacities (terminal) : GPU.
It happens so that a reversal of specialization has really taken place, as
Brian Stuart suggests. These "terminals" you speak of, GPUs, contain such
vast untapped general processing capabilities that new uses and a new
framework for using them are being defined: GPGPU and OpenCL.
<http://en.wikipedia.org/wiki/OpenCL>
<http://en.wikipedia.org/wiki/GPGPU>
Right now, the GPU on my low-end video card takes a huge burden off of the
CPU when leveraged by the right H.264 decoder. Two high definition AVC
streams would significantly slow down my computer before I began using a
CUDA-enabled decoder. Now I can easily play four in parallel.
Similarly, the GPUs in PS3 boxes are being integrated into one of the
largest loosely-coupled clusters on the planet.
<http://folding.stanford.edu/English/FAQ-highperformance>
Today, even a mere cellphone may contain enough processing power to run a
low-traffic web server or a 3D video game. This processing power comes
cheap so it is mostly wasted.
I'd like to add to Brian Stuart's comments the point that previous
specialization of various "boxes" is mostly disappearing. At some point in
near future all boxes may contain identical or very similar powerful
hardware--even probably all integrated into one "black box." So cheap that
it doesn't matter if one or another hardware resource is wasted. To put to
good use such a computational environment system software should stop
incorporating a role-based model of various installations. All boxes,
except the costliest most special ones, shall be peers.
--On Friday, April 17, 2009 7:11 PM +0200 tlaro...@polynum.com wrote:
On Fri, Apr 17, 2009 at 11:32:33AM -0500, blstu...@bellsouth.net wrote:
- First, the gap between the computational power at the
terminal and the computational power in the machine room
has shrunk to the point where it might no longer be significant.
It may be worth rethinking the separation of CPU and terminal.
For example, I'm typing this in acme running in a 9vx terminal
booted using using a combined fs/cpu/auth server for the
file system. But I rarely use the cpu server capability of
that machine.
I'm afraid I don't quite agree with you.
The definition of a terminal has changed. In Unix, the graphical
interface (X11) was a graphical variant of the text terminal interface,
i.e. the articulation (link, network) was put on the wrong place,
the graphical terminal (X11 server) being a kind of dumb terminal (a
little above a frame buffer), leaving all the processing, including the
handling of the graphical interface (generating the image,
administrating the UI, the menus) on the CPU (Xlib and toolkits run on
the CPU, not the Xserver).
A terminal is not a no-processing capabilities (a dumb terminal):
it can be a full terminal, that is able to handle the interface,
the representation of data and commands (wandering in a menu shall
be terminal stuff; other users have not to be impacted by an user's
wandering through the UI).
More and more, for administration, using light terminals, without
software installations is a way to go (less ressources in TCO). "Green"
technology. Data less terminals for security (one looses a terminal, not
the data), and data less for safety (data is centralized and protected).
Secondly, one is accustomed to a physical user being several distinct
logical users (accounts), for managing different tasks, or accessing
different kind of data.
But (to my surprise), the converse is true: a collection of individuals
can be a single logical user, having to handle concurrently the very
same rw data. Terminals are then just distinct views of the same data
(imagine in a CAD program having different windows, different views of a
file ; this is the same, except that the windows are on different
terminals, with different "instances" of the logical user in front of
them).
The processing is then better kept on a single CPU, handling the
concurrency (and not the fileserver trying to accomodate). The views are
multiplexed, but not the handling of the data.
Thirdly, you can have a slow/loose link between a CPU and a terminal
since the commands are only a small fraction of the processing done.
You must have a fast or tight link between the CPU and the fileserver.
In some sense, logically (but not efficiently: read the caveats in the
Plan9 papers; a processor is nothing without tightly coupled memory, so
memory is not a remote pool sharable---Mach!), even today on an
average computer one has this articulation: a CPU (with a FPU
perhaps) ; tightly or loosely connected storage (?ATA or SAN) ;
graphical capacities (terminal) : GPU.
--
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
