(OT) The desktop supercomputer has arrived!

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/

On 27 Jun, 04:17, JB <hong...@videotron.ca> 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>

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.

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

"Alistair" <alistair@ld50macca.demon.co.uk> wrote in message
news:1183055262.728505.150930@m36g2000hse.googlegroups.com...
> On 27 Jun, 04:17, JB <hong...@videotron.ca> 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'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.

On 29 Jun, 03:20, "Pete Dashwood" <dashw...@removethis.enternet.co.nz>
wrote: 
>
> You'd be amazed at the number of (sometimes quite senior) managers I have
> encountered who believe that parallel processing or throwing more resource
s
> at something is the answer to getting things back on track. Sometimes
> (especially where a project was under resourced to start with), it certain
ly
> 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 i
n
> 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 leve
l
> (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 ch 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).

> 
>
> 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 sor
t
> 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 li
st
> 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 tu
rn
> 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, b
y
> building a DNA string which represents the turns they made. LLRLRLLRRRL
> etc. The cells with the longest strings are the most "successful". These a
re
> 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 cell
s
> 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 modif
y
> themselves rapidly and randomly, solutions will be achieved by machines an
d
> 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".

On Fri, 29 Jun 2007 14:20:37 +1200, in comp.lang.cobol you wrote:
 

The common response is:

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

But the reality is somewhere in-between.    In the house cleaning, you
can have one person sweeping each room, but you can't have 10 people
washing the sink without getting in each other's way.    We can all
get up from the table together, bring our dishes to the sink - but
then we have to back aside and let one person start washing - and
someone else can start drying.   This drying works because we are
doing a well-known task and we know that each dish can be handed off
to the dryer before the next dish is washed.   If we are washing
enough dishes for the next place setting, we keep a count - and wash
one more dish if the dryer drops one on the floor.

So how do we turn this into programming?

Read a transaction - hand it to the check the balance routine - hand
that to the calculate interest routine - hand that to the create bill
routine...     Periodically check to make sure those routines are
fairly caught up and no (dishes/bills) are dropped - and we need to
know what to do if one is.   Restarts aren't trivial.

But we do have a kid of parallel processing.  The scheduler verifies
that bills and inventory can be run together and runs these two jobs
at the same time.    All that we need to know is that one won't effect
the results of the other.

"Alistair" <alistair@ld50macca.demon.co.uk> wrote:
> <hong...@videotron.ca> 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>

Hello Alistair, how are things in the UK? :-)

Where I see parallel processing helping on PCs is in two areas, running
multiple applications simultaneously and multithreaded applications (e.g.
graphics and video processing). My most common backup task involves burning
two separate DVDs. I haven't had much success burning two DVDs at once using
single core CPUs, but my dual core Athlon X2 works well. It's also useful to
burn a CD/DVD and be able to continue working without concern you will cause
a problem on the burn.

For most PC applications the primary bottleneck is disk I/O, and a
beneficial upgrade is striped (RAID0) drives. My primary PC boots to one
RAID0 2x 74GB 10,000 RPM drives, and has another RAID0 2x 320GB 7,200 RPM
drives. When I build my next PC, I plan to have one RAID0 4x 320GB or 500GB
drives, and possibly a quad core CPU. Striping can multiply the disk I/O
performance almost by the number of drives. But the drives should be
identical, or at least the same size, or you will waste storage space on the
larger drives. To boot to a RAID0 it must be implemented on the system board
or the disk controller, but Windows can do a software RAID0 on non-boot
drives. Just remember that RAID0 is about volume size and speed, not
reliability. If one RAID0 drive fails, you lose all the data, and an array
of n drives is n times more likely to suffer a drive failure than 1 drive.
Backup, backup, backup! But if you "feel the need, the need for speed", this
is a good way to go. :-)
--
Judson McClendon      judmc@sunvaley0.com (remove zero)
Sun Valley Systems     http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."

On 29 Jun, 16:02, "Judson McClendon" <j...@sunvaley0.com> wrote:
> "Alistair" <alist...@ld50macca.demon.co.uk> wrote: 
>
>
> Hello Alistair, how are things in the UK? :-)
>

Wet! Wet! Wet! Despite global warming the weather is er than
normal for this time of the year and much wetter than normal. We have
just had the wettest June (on record I think) and will probably have
the wettest start to July with 50mm of precipitation expected. My home
town is built on the side of a hill but it has been known to flood
here with torrential rain.

Good to see a response from you Judson. I do enjoy the emails, and I
liked the Globalization definition. However, where is the response to
my request for a repeat email detailing how to get multiple ftp
downloads under windows?


> Where I see parallel processing helping on PCs is in two areas, running
> multiple applications simultaneously and multithreaded applications (e.g.
> graphics and video processing). My most common backup task involves burnin
g
> two separate DVDs. I haven't had much success burning two DVDs at once usi
ng
> single core CPUs,

I have noticed that copying from one CD player and writing to another
directly doesn't work under XP either.

> but my dual core Athlon X2 works well. It's also useful to
> burn a CD/DVD and be able to continue working without concern you will cau
se
> a problem on the burn.

That is worth remembering.

>
> For most PC applications the primary bottleneck is disk I/O, and a
> beneficial upgrade is striped (RAID0) drives.

Don't you lose the equivalent of one disk to the OS for Raid use?

Alistair wrote:
>
> Wet! Wet! Wet! Despite global warming the weather is er than
> normal for this time of the year and much wetter than normal.

"Despite"?  :)  Some might call that evidence to the contrary!

(sorry - couldn't resist...  Besides, it's already an OT thread...)

--
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
~     / \/ _ o     ~          Live from Albuquerque, NM!          ~
~     _ /\   |     ~                                              ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ Business E-mail  ~ daniel @ "Business Website" below            ~
~ Business Website ~ http://www.djs-consulting.com                ~
~ Tech Blog        ~ http://www.djs-consulting.com/linux/blog     ~
~ Personal E-mail  ~ "Personal Blog" as e-mail address            ~
~ Personal Blog    ~ http://daniel.summershome.org                ~
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~

GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ !O M--
V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e h---- r+++ z++++

"Who is more irrational?  A man who believes in a God he doesn't see,
or a man who's offended by a God he doesn't believe in?" - Brad Stine

On 30 Jun, 14:53, Alistair <alist...@ld50macca.demon.co.uk> wrote:
> On 29 Jun, 16:02, "Judson McClendon" <j...@sunvaley0.com> wrote:
> 
> 
>
> Wet! Wet! Wet! Despite global warming the weather is er than
> normal for this time of the year and much wetter than normal. We have
> just had the wettest June (on record I think) and will probably have
> the wettest start to July with 50mm of precipitation expected. My home
> town is built on the side of a hill but it has been known to flood
> here with torrential rain.
>
> Good to see a response from you Judson. I do enjoy the emails, and I
> liked the Globalization definition. However, where is the response to
> my request for a repeat email detailing how to get multiple ftp
> downloads under windows?
> 
>
> I have noticed that copying from one CD player and writing to another
> directly doesn't work under XP either.
> 
>
> That is worth remembering.
>
>
> 
>
> Don't you lose the equivalent of one disk to the OS for Raid use?

I am a firm believer in global warming. After all, who wants to live
in the maritime climate we experience in England when you could live
in a warmer transitional climate such as found in France? However, I
do not jump on the global warming band-wagon to explain 'blips' of bad
weather, unlike the journalists.

On 30 Jun, 14:53, Alistair <alist...@ld50macca.demon.co.uk> wrote:
> On 29 Jun, 16:02, "Judson McClendon" <j...@sunvaley0.com> wrote:
> 
> 
>
> Wet! Wet! Wet! Despite global warming the weather is er than
> normal for this time of the year and much wetter than normal. We have
> just had the wettest June (on record I think) and will probably have
> the wettest start to July with 50mm of precipitation expected. My home
> town is built on the side of a hill but it has been known to flood
> here with torrential rain.
>
> Good to see a response from you Judson. I do enjoy the emails, and I
> liked the Globalization definition. However, where is the response to
> my request for a repeat email detailing how to get multiple ftp
> downloads under windows?
> 
>
> I have noticed that copying from one CD player and writing to another
> directly doesn't work under XP either.
> 
>
> That is worth remembering.
>
>
> 
>
> Don't you lose the equivalent of one disk to the OS for Raid use?

Looks like I posted to the wrong message.