Re: (OT) The desktop supercomputer has arrived!


"Alistair" <alistair@xxxxxxxxxxxxxxxxxxxxx> wrote in message
news:1183055262.728505.150930@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On 27 Jun, 04:17, JB <hong...@xxxxxxxxxxxx> wrote:
http://www.physorg.com/news102087207.html

A prototype of what may be the next generation of personal computers has
been developed by researchers in the University of Maryland's A. James
Clark School of Engineering. Capable of computing speeds 100 times faster
than current desktops, the technology is based on parallel processing on
a
single chip.

jb
--
Using Opera's revolutionary e-mail client:http://www.opera.com/mail/

<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'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...:-)

Of course, three ships CAN cross the ocean in one day, IF they are
travelling three times as fast as the one ship...

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...:-)

I then walked him through the overview of the Project Plan which noted
dependencies and resources and showed WHY simply putting more people on it
wouldn't help. (We were waiting for delivery of disk drives which were
delayed coming from the manufacturer. He applied pressure at high level and
cut the delay. That more than anything else, got us the desired result.)


Now suppose that the algorithm used requires that 298 steps be
processed in strict sequence and that only two items can be performed
in parallel. Total savings would be 1 minute and that is one of the
problems with parallel processing - the extremely limited amount of
work that can be carried out in parallel.

I did like the statement that programming would be relatively simple
(compared to what?). Perhaps this presages the demise of the
programmer.

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.

(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, 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). I
don't see this before the '60s of this century, but there are others who see
it sooner.)


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.) That's how we do things currently, so fair enough.

However, there are other ways of processing which are emerging and just
starting to be understood. (Some of them are evolving from approaches that
have been well understood for decades, but we never had the processor power
to make them viable. Now we do...) Genetic Algorithms and Functional
Programming are just two examples of approaches that would use parallel
processing to HUGE advantage over the VN model.

<flight of fancy - unimaginative people should skip this>

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 :-)))

But consider an approach where the list was hit pseudorandomly (the
algorithm would ensure that all list entries were eventually covered, at
least, say, three times - "What I tell you three times is true" - Lewis
Carroll), and the candidate to be inserted was simply placed over or under
the point where the list was hit, depending on candidate rank. A single
compare per hit, but the process would need to iterate until the list was
sorted. ("Simple" as noted in the discussion above.)

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.

(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 :-( )

The point is that with a parallel processing system, such a sort could have
multiple cells hitting the list at the same time. (You could theoretically
have almost as many cells hitting the list as there were list entries at any
given moment).

So, three ships COULD cross the ocean in one day... :-)

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. 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.
Compare this with the VN approach which might take several minutes or even
hours.

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 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. More importantly, the ways in which we
approach problems will be more diverse and machine intelligence will start
to become a reality. (I believe it will evolve out of "expert systems" which
we are already seeing in some fields. Expect these fields to
broaden...Computers can already provide almost instantaneous solutions to
some problems that a Human Expert would take days to do.)

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).

</flight of fancy - unimaginative people should skip this>


Pete.


.

Relevant Pages

  • Re: How do lispers do their GUI programming anyway?
    ... I started programming lisp in May 2007, spent two weeks reading the first chapters of PCL, stumbled across cells on c.l.l pretty much right away, found cells-gtk soon after, and by now my current project relies heavily on cells. ... The hard part for me was to fully understand that cells is /active/ state propagation, whereas methods provide /passive/ propagation (I have always been a fan of keeping state in as few variables as possible. ... So far I have not done anything with cells (or with lisp, for that matter), that I could not have done with java or C++. ... For a routined programmer things will look differtently. ...
    (comp.lang.lisp)
  • Re: Lisp and software architecture
    ... what do you have to say to my points about Cells being the long-sought Silver Bullet? ... If I /need/ X, I will bang on it and support groups and even read documentation until it works. ... The alternative is for the programmer to carry that burden: "Oh, gee, I just changed X. ... I hesitate to mention the entire constraints research programme which continues to today, because they IMO went a bridge too far with multiway and partial constraints and ended up with unprogrammable systems. ...
    (comp.lang.lisp)
  • Kenny, did you write this article?!? (Cells)
    ... it is up to the programmer to remember to ... 'Cells' ... cells: sensors and effectors. ... changes and effectors execute changes. ...
    (comp.lang.lisp)
  • Re: A critic of Guidos blog on Pythons lambda
    ... explained what Cells is above. ... some slot (Lisp lingo for "member variable") can be computed. ... frees the programmer from having to recompute slot values since Cells ... You specify a function that calculates the value of an attribute. ...
    (comp.lang.python)