From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <1322FA0842063D3D53C712DC@192.168.1.2> References: <21493d85b69b070fed0a4f864eb5325a@proxima.alt.za> <57928816a76e769327ca134d7e28bd06@bellsouth.net> <20090417171154.GA2029@polynum.com> <1322FA0842063D3D53C712DC@192.168.1.2> Date: Fri, 17 Apr 2009 16:07:40 -0400 Message-ID: <3aaafc130904171307l22102297wb507df265afb2476@mail.gmail.com> From: "J.R. Mauro" To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] VMs, etc. (was: Re: security questions) Topicbox-Message-UUID: e37173be-ead4-11e9-9d60-3106f5b1d025 On Fri, Apr 17, 2009 at 2:59 PM, Eris Discordia wrote: >> 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, a= s > 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. > > > > > Right now, the GPU on my low-end video card takes a huge burden off of th= e > 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. > > > > 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 ch= eap > so it is mostly wasted. I can't find the link, but a recent article described someone's efforts at CMU to develop what he calls "FAWN" Fast Array of Wimpy Nodes. He basically took a bunch of eeePC boards and turned them into a single computer. The performance per watt of such an array was staggeringly higher than a monster computer with Xeons and disks. So hopefully in the future, we will be able to have more fine-grained control over such things and fewer cycles will be wasted. It's time people realized that CPU cycles are a bit like employment. Sure UNemployment is a problem, but so is UNDERemployment, and the latter is sometimes harder to gauge. > > I'd like to add to Brian Stuart's comments the point that previous > specialization of various "boxes" is mostly disappearing. At some point i= n > near future all boxes may contain identical or very similar powerful > hardware--even probably all integrated into one "black box." So cheap tha= t > it doesn't matter if one or another hardware resource is wasted. To put t= o > good use such a computational environment system software should stop > incorporating a role-based model of various installations. All boxes, exc= ept > the costliest most special ones, shall be peers. > > --On Friday, April 17, 2009 7:11 PM +0200 tlaronde@polynum.com wrote: > >> On Fri, Apr 17, 2009 at 11:32:33AM -0500, blstuart@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. =A0But 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) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://www.kergis.com/ >> Key fingerprint =3D 0FF7 E906 FBAF FE95 FD89 =A0250D 52B1 AE95 6006 F40C >> > > > > > >