Functional Muti-threading

[janderson]

Daniel Keep wrote:
> janderson wrote:
>> [snip]
>>
>> What do you think?
> 
> "I think all the right thinking people in this country are sick and 
> tired of being sick and tired of being sick and tired.  I know I'm not, 
> and I'm sick and tired of being told that I am!"
> 
> Or something to that effect...
> 
> *ahem*
> 
> This is one of the things I've thought about quite a bit over the years. 
>  What you call "threadable" I call "pure", as in a pure function. 
> Basically, a pure function is one which has *no* side effects.  If a 
> function has no side effects, then it doesn't matter when it gets 
> executed.  The nice thing is that "pure function" is more well-defined 
> than "threadable" :3

I fear pure may be mixed up with pure virtual.  I don't like threadable 
either.

Naming aside.  I'm glad that I'm not the only one who has thought about 
this technique (means I'm probably not crazy).

It also brings up an interesting point.  There are probably other 
non-threadable operations that can occur on these "pure function"'s. 
For instance order of operations can be switched around (if that 
resulted in some optimisation).  Or the function could be silently 
rewritten to work on an array of inputs/outputs rather then a single 
output so it could take advantage of SIMD.

> 
> The idea comes from functional programming languages like LISP.  If 
> you're writing pure LISP, then all of your functions are pure, which 
> leaves LISP free to thread your program however it likes.

Neat, so there are already examples of this at work.  Any procedural 
languages that use it?

> I thought about suggesting that the compiler add a purity check in the 
> same vein as inlining: any function found (or marked) as pure could be 
> threaded off by the compiler without any adverse side-effects.

Exactly.  It may be possible to get the expressiveness of the syntax 
where we can specify functions as pure virtual ourselves.  However then 
  it would be impossible to generalize the syntax so that the compiler 
could add pure functions at it's will.

> Of course, I never did since this would be a huge amount of work.  Which 

I think if it only worked in a few cases to begin with and that got 
expanded as time went on, I'd be fine with that.

> got me thinking about other kinds of multithreading.  Which is why I 
> wrote my "future" implementation (not to be confused with "futurism" :P).

Nice work on the future implementation BTW...  The great thing about 
future is that you can still run other more complex threads at the same 
time and have "future" fill some of the idle gaps.

> 
> To be honest, I think we are more likely to see array operations *first* 
> (ie: a[] = b[] + c[] as an element-wise addition) than this stuff.  The 
> nice thing is that array operations can also be parrallelised (using 
> things like SIMD, or even multi-threaded SIMD on multi-core systems) but 
> much more easily.

Yeah, I was hanging out for this stuff too when Walter mentioned it a 
few years back.

...

Heres another con: It would make stepping though the code a PITA, unless 
you turned it off for debug.

-Joel