[Beowulf] Can Beowulf with Linux run all the desktop applications

[Robert G. Brown]

On Tue, 24 Feb 2009, John Hearns wrote:

> 2009/2/24 Robert G. Brown <rgb at phy.duke.edu>:
>>> In general, however, they will not run faster.  In order for an
>> application to run faster, it has to be written to run in parallel, and
>> most desktop applications are not.
>>
>
> Interestingly enough, my local Linux User Group recently had a discussion on the
> Reia language http://wiki.reia-lang.org/wiki/Reia_Programming_Language
>
> The 'threads' of the Erlang virtual machine can be migrated to other machines.
> Blue skying a little, if mechanisms like this were used for
> desktop-type applications they
> would be able to be load balanced across a cluster.

Except that nearly all desktop-type applications will run faster --
monolithically, on a desktop machine.  So much so that for most of them
a decision to parallelize or not requires, lessee, a one second pause
followed by "not".  Desktop applications with very few exceptions are
rate limited by the user, disk, network, other resources, and memory/CPU
in that order.  They are interactive, so most of what they are doing is
waiting for a user to type something or the next mouse click to come in
(with hundreds of thousands to millions of cycles of thumb-twiddling
between each keystroke).  From time to time they have to read or write
something to disk, which may be a latency hit (quite long at order
milliseconds for an uncached seek) or wait (on a heavily laden system).
Or to get something to or from the network, more like microseconds of
latency.  Or to get to a USB device, a camera, a printer.  Way, way out
there is CPU and/or memory, and that only if the application in question
is very graphically intensive, is e.g. a database or scientific
application or the front end of a numerical program.  In nearly all
cases a CPU bound desktop application is a game (or video or
entertainment) of some sort or or it's the kind of thing somebody MIGHT
actually invest the work in to parallelize or that parallelizes itself
"automatically" on a multi-core system by running in its own thread.

The other problem with automated migration of desktop task components is
that local memory and threads are fast, remote memory and threads are
slow.  The network is ALREADY the bottleneck in many desktop apps.
Sitting on machine X to run a GUI that goes over the network to machine
Y to do its work, which consists of using the network to go to website Z
to grab e.g. a movie and then render it on Y and then return the
rendered stream to X contains a lot of redundant, probably slow steps,
and rendering IS relatively CPU intensive.  It usually requires some
actual thought about design and scaling to determine if EVEN a CPU
intensive application benefits from parallelization; I'm not optimistic
that we're going to see desktop apps with parallel back ends anytime
soon and probably never automatically, although sure there will always
be a few things people take the time to parallelize right that clearly
benefit from it and where the benefit matters in human terms.

As it is, almost by DEFINITION parallelization of desktop apps doesn't
matter, in human terms, except that it would probably slow them down.

    rgb

>
> _______________________________________________
> Beowulf mailing list, Beowulf at beowulf.org
> To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
>

Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu