[Beowulf] Which is better GNU C or JAVA (for network programing)

Jim Lux James.P.Lux at jpl.nasa.gov
Wed Jan 21 12:24:50 EST 2004


At 04:44 PM 1/21/2004 +0100, you wrote:


>- if you ever dreamt about goodies from LISP without having to deal
>   with Lots of Silly Idiotic Parenthesis, these dreams come true in
>   tcl

Surely you ment Lots of Idiotic Silly Parenthesis (after all, isn't LISP an 
acronym)

And, pulling some old Intel i/PSC documentation off the shelf (what is an 
Intel i/PSC but the ancestor of a modern Beowulf... 8 MHz 80286 CPU (with 
an optional 80287), Ethernet for interprocessor comms (the venerable 
82586), Xenix as the base OS)..

I find a whole raft of stuff advocating CCLISP for all sorts of things: 
battle management, dining philosophers problems, optimizing loads of 
livestock and produce across a river in a small boat, all using stuff like 
"message passing", node streams, etc.  Even such useful stuff as "Sorting a 
List of N elements" using things like the Sample sort of Felton, Karlin, 
and Otto.

Lest we get too enamored with CCLISP, there's also:
(roll of drums)
"Concurrent Prolog"
(Crash of cymbals, choir of angels)

Having not actually looked at anything in Prolog for the last 15+ years, I 
thought it would be interesting to repeat a short program here. (I have no 
idea if it would work, since I don't recall CP Syntax)

quicksort([X|Xs],Ys):-
   partition (Xs?,X,Smaller,Larger),
   quicksort (Smaller?,Ss),
   quicksort (Larger?,Ls),
   append(Ss>,[X|Ls?],Ys).
quicksort([],[]).

partition([Y|ln],X,[Y|Smaller],Larger):-
   X>=Y|partition(ln?,X,Smaller,Larger).
partition([Y|ln],X,Smaller,[Y|Larger]):-
   X<Y|partition(ln?,X,Smaller,Larger).
partition([],X,[],[]).

append([X|Xs],Ys,[X|Zs]):-
   append(Xs?,Ys,Zs).
append([],Xs,Xs).

There is a scribbled note (not in my handwriting) that mentions the following:
- => indicates communications
name? => readonly variable, process waits until there is a value in the 
name before proceeding (presumably this is some sort of barrier sync?)

----------

In all of this, they make the very appropriate comments along the lines of: 
sure it's horribly inefficient, but, you've got:
a) tons of computer power potentially available (I mean, you could have 128 
of those 8 MHz 286's spinning away)
b) you've got a moderately transparent way to distribute the load across 
those processors without worrying too much about subtlety
c) human hours expensive|machine hours cheap
d) The computers WILL get faster, so don't agonize about CPU resources too 
much.. time and the market will improve performance per dollar or wall 
clock hour much faster than toiling  over a hot keyboard ekeing out 
algorithm tuning improvements.  Spend your time on better high level 
algorithms to solve "your problem".

Hey, this was in 1986,1987 or so.. In the last 15 years, I don't think much 
has really changed, philosophically.







James Lux, P.E.
Spacecraft Telecommunications Section
Jet Propulsion Laboratory, Mail Stop 161-213
4800 Oak Grove Drive
Pasadena CA 91109
tel: (818)354-2075
fax: (818)393-6875

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



More information about the Beowulf mailing list