Re: (OT) The desktop supercomputer has arrived!

On 29 Jun, 03:20, "Pete Dashwood" <dashw...@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:
<QUOTE>
Suppose you hire one person to clean your home, and it takes five
hours, or 300 minutes, for the person to perform each task, one after
the other," Vishkin said. "That's analogous to the current serial
processing method. Now imagine that you have 100 cleaning people who
can work on your home at the same time! That's the parallel processing
method.
</QUOTE>

You'd be amazed at the number of (sometimes quite senior) managers I have
encountered who believe that parallel processing or throwing more resources
at something is the answer to getting things back on track. Sometimes
(especially where a project was under resourced to start with), it certainly
can help, but there are people who believe it is the "magic bullet" for
everything.

I wouldn't be amazed at all. I have been the project leader on a
project where my management threw every possible resource (I counted
13 bodies by the end of the project) in an attempt to meet a deadline
agreed six months previously. Unfortunately, the users required an
increase in work load in associated projects which impacted my
project's work load by adding an extra 50%. Problem: agreed
(artificial) deadline likely to be missed. Solution: throw bodies at
the project. Result: I spent time DOING rather than LEADING and was
swamped with needing to organise work for others and explain to
newbies what the project was all about. We made the deadline (although
any reasonable management would have put the implementation date
back).

As an aside, when asked to plan the project I was asked "Can we
achieve the deadline" and the answer was "Only if we had started
yesterday!"


I've had people actually use the analogy:

"If one ship takes 3 days to cross the ocean, why can't 3 ships cross it in
one day?"

To be fair, the guy who trotted that one out was not the sharpest tool in
the box... He'd heard it somewhere and thought it was serious...:-)

My response at the time (and I am quite proud of it :-)) was:

"If a girl takes 9 months to have a baby, why can't 9 girls have it in one
month?"

He thought about it for a moment...:-)


Few managers seem to be aware that elapsed time can not always be
compressed by parallel streams. To be fair, I did once lead a project
where we cut the elapsed run-time of the subject system from 19 hours
to 11 hours by implementing parallel streams.


It is "simple" inasmuch as everything is reduced to a very simplistic level
(see the "cell" activity below). I don't think it necessarily presages the
demise of the programmer.

Obviously, my planting my tongue firmly in my cheek does not come
across too clearly when typing.


(Programmers are going to have too much fun implementing these approaches
for them to want to quit... What will presage and eventually lead to the
demise of the programmer is when we start combining biological and machine
intelligence,

Aah, a call for the 'Borg. I doubt if useful bio-mechanoids will be
available this century (or at all). I suspect it would be one thing to
create a robocop but quite another to put a living brain into an
interstellar spacecraft. Can you imagine the mind-numbing boredom of
monitoring the sensors in strict rote for the thousand years or so to
cross the gaps between stars?

to produce problem solving intelligence light years ahead of
where we are today. Smart organisms will write smart software that will
eventually get so smart it writes itself. ("A component that seees what
needs to be done and does it" as I mentioned here a little while ago).

Already being done in software. I did rather like Michael Crichton's
notion of nanobots which evolved a collective intelligence greater
than the sum of their parts (complexes of simple automata producing
complex behaviours).


FWIW: parallel processing is already a reality with multiple cores per
chip already in existence.

Yes, but there is still room for improvement. And you are predicating your
argument on the Von Neumann model of processing (a sequential series of
steps.)

Good old-fashioned procedural programming. Remember, I am not OO-
friendly.


<flight of fancy - unimaginative people should skip this>

OK I will (no, really, I did read it).



For example, if you consider a sorting algorithm as currently implemented,
it iteratively checks all (or some) of the items in the list before it can
put one away (please don't let's get sidetracked into a discussion of
tournament, bubble, asymetric and binary chops, balanced and unbalanced
merges, Fibonacci series and all the other wonderful stuff surrounding sort
technology (I have written a few sort programs in my career and don't need
instruction about anyone's favourite algorithm, thank you...If you really
MUST, start another thread :-)))

I thought that with the advent of the RDBMS no-one did sorts anymore?



It would take a large number of hits to ensure the list became sorted.

BUT, a Genetic approach would have each hit carried out by a single cell
which would be programmed to "die" if the compare went a certain way, or
"live" to hit again if it didn't. By the time all cells were "dead" the list
would be sorted.

Or maybe you could use software ants? (as used to solve the travelling
salesman problem).


(I have no idea whether this would actually work :-) It's just an idea I
came up with while musing on something else...) If I had some time I would
write an OO program that generated cell instances and see how long it took
to sort an arbitrary list, using the approach above... It would be fun to
do, but I'm too busy for fun at the moment :-( )

It would be interesting to see the results, too.


In fact, most heuristic solutions lend themselves easily to parallel
processing.

Consider a heuristic program that finds the way through a maze.

It comes to a juction and consults its heuristic ("rule of thumb" if you
like, for those not familiar with this type of programming...) which maybe
says "turn left". It does this, and comes to another junction where it
repeats the process. Eventually it either comes to a dead end or realises no
progress is being made, so it modifies the heuristic... "Turn left, but turn
right every second junction". The process is iterated and the results
analysed. Eventually, and it might take several trillion iterations, the
maze is traversed and the final heuristic represents the solution to
traversing it. (Note that there is no guarantee that this is an OPTIMAL
solution; for some problems it is good enough to have ANY solution...)

Now consider a Genetic approach to the same problem.

Cells make a random choice at each junction and record how far they got, by
building a DNA string which represents the turns they made. LLRLRLLRRRL
etc. The cells with the longest strings are the most "successful". These are
the ones from which the next generation are bred. The DNA strings can be
combined, compared, sliced, whatever... and a new generation is launched
which penetrates even further into the maze. Throwing several million cells
which randomly generate (mutate?) their own successive generations, based on
past experience, at the maze is likely to produce a succesful generation
that traverses it.

I think that you have just proven that old saying about an infinite
number of monkies writing the complete works of Shakespeare.

If you build selective breeding where cells with similar
DNA strings form the basis of each successive generation, the solution can
be achieved in a surprisingly short time.

Imagine if you had say, 1000 parallel processors all penetrating and
breeding simultaneously. A complex maze could be traversed in seconds.

You seem to be obsessed with breeding. A multitude of automata could
resolve the problem without resorting to breeding: throw the automata
at the maze, randomly turn at junctions, collect the automata that
successfully get to the exit, take the ones with the shortest track
and modify randomly before putting them back in the
maze...iteratively.


BOTTOM LINE:

Von Neumann was a genius, like Turing. Both of them saw mathematical
solutions to problems and gave us the means to extend their solutions (the
modern computer).

The modern computer was built by a GPO engineer out of telephone
switching circuits.

The next generation of computers will not use the same
processing models as the current ones. By 2020, 8 core processors will be
normal in personal computers.

Didm't Intel just announce an 8 core chip?

In the solutions above where cell generations have the capability to modify
themselves rapidly and randomly, solutions will be achieved by machines and
we will have no idea exactly how they did it.

THAT will lead to the eventual demise of the programmer (at least as we
understand the term today).

I can see the future holding some very interesting court cases. Who
would be responsible for artifical bio-intelligences killing people by
accident? Where would you hold deviant bio-intelligences and what kind
of punishments could you apply to the criminal bio-intelligences?
Also, would they be entitled to a tea-break every two hours and be
eligible to form unions? This isn't too far fetched as the European
Union is already considering "robot rights".

.

Relevant Pages

  • Open Letter to Peter Seibel [was Re: Lisp and software architecture]
    ... which other ones included the changed cell in their computation. ... the programmer looks at program state differently. ... calls to-be on new kids and not-to-be on kids no longer in the list. ...
    (comp.lang.lisp)
  • Re: A better SPU?
    ... When I spoke to the guys who designed Cell, ... programmer hostility --- a programmer visible mere 256KB, ... You would split the work buffer up into 3 areas, ...
    (comp.arch)
  • Re: A better SPU?
    ... it was so large and slowed critical paths so much, ... It was this decision that gave Cell its extreme ... programmer hostility --- a programmer visible mere 256KB, ... for managing threads on the SPE's, managing DMA transfers, etc. ...
    (comp.arch)
  • Re: A better SPU?
    ... When I spoke to the guys who designed Cell, ... load-store logic on a modern CPU was just horrifying, ... programmer hostility --- a programmer visible mere 256KB, ... It seems that standard definition H.264 encode requires only 2 SPEs, ...
    (comp.arch)