Comments on: The X=X+1 Issue

by: kavadias

Sat, 07 Jun 2008 20:23:44 +0000

Interesting!! Your definition of SUM(1) and SUM(I) is close to the definition
SUM(I,J) if (I==J) THEN RETURN J
ELSE RETURN { SUM( I, (I+J)/2 ) + SUM( ((I+J)/2)+1, J ) }

that is easier to parallelize. In this sense it might make easier for programmers to learn how to write parallelizable code. But this can be done all the same in imperative programming, although it may take some (more?) training, and is only because of the more abstract approach to “what” instead of “how” …
Other than that I’m very curious what you can make out of not using multiple assignment. My SUM(I,J) (implicitely) introduces a tree of intermediate variables that would help parallelization. This is because of recursion that is closer to parallelization of the devide-and-conquer style…

by: Christopher Moore

Fri, 06 Jun 2008 10:32:18 +0000

300 baud ???

Boy, your ASR33 was _fast_ ;-)

Mine was 110 baud :(

by: avagothen

Fri, 06 Jun 2008 09:49:01 +0000

Very nice idea on a very real problem.
Unfortunately, your recursive solution will not run any faster on a parallel machine as each iteration depends on, and so has to wait for, the result of the next before completing. Likewise, each iteration can only be spawned by the one before.

Any code inserted between “NEW_I=I-1″ and “RETURN…” could be run in parallel, but only if NEW_I isn’t (or can’t be) changed within that block. It would take some dandy compiler or interpreter to work out if/how to parallelise that.

Could such a piece of software be the solution to this whole problem? If so, the procedural/declarative distinction would become largely irrelevant. More likely, the programmer has to be smart, not the software.

On the plus side, it does abstract the problem by a level and gets people thinking about it. Hmmm…

by: gsmyth

Fri, 06 Jun 2008 01:04:24 +0000

Is multiple assignment bad in parallel computing? In parallel programming we would essentially look at what level of granularity we want to break down the data to be processed over the number of recursive loops to process and assign the computations to threads over various cores. The issue would be synchronising the partial results into a shared location and the synchronisation overhead in this case although necessary would slow the computation down. (assuming thread-safe libraries).
Or perhaps say a high level of granularity would be better and increase the time period between synchronisation points. This discussion may be useful to mention and further comment in the article.
Checking on metrics via sar or clock execution times will determine how well the granularity is performing.

by: mike miller

Thu, 05 Jun 2008 20:11:44 +0000

This seems fitting.

Hey Hey 16k.

http://www2.b3ta.com/heyhey16k/

Enjoy the video.

by: ruzam

Thu, 05 Jun 2008 16:05:49 +0000

I’m sure there will be more of a point to this later, but all you’ve demonstrated is recursive style vs non-recursive style which doesn’t have much of anything to do with imperative vs declarative style.

You’re SUM() example could be just as easily coded as a ’single assignment’ recursive function in any procedural language that support s recursion (in as few lines with as much programmer efficiency). But as you say “how the rules are executed is up the declarative language”. How the rules are executed is also up to the imperative language. Each coding method can be equally tuned (or broken) for parallel execution.

by: Tommy Phillips

Thu, 05 Jun 2008 15:41:37 +0000

Maybe it’s just me, or maybe it’s just a clumsy example, but it looks to me as if you are telling the computer how to do the sum. You are just telling it how using recursion rather than looping.

I’m not saying it’s completely equivalent, but it doesn’t seem to be clearly superior.

Not in this case, anyway.

by: fernandoaren

Wed, 04 Jun 2008 13:55:41 +0000

10 Neat.
20 And now you tell me there’s something else than BASIC
30 Geez.
40 GOTO 10