Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?

Re^4: [OT]: threading recursive subroutines.

by BrowserUk (Pope)
on Feb 03, 2011 at 10:30 UTC ( #885956=note: print w/replies, xml ) Need Help??

in reply to Re^3: [OT]: threading recursive subroutines.
in thread [OT]: threading recursive subroutines.

I did say up front that my interest in this is not directly related to Perl. Leastwise not as it stands with Perl 5 and iThreads. The overheads of the Perl5 function calls (including ties), combined with those of iThreads, make this a non-starter as a realistically usable bolt-on to Perl 5.

However, I do have notions and bits of code for a 64-bit only interpreter that demonstrates highly efficient function & method call performance that would, if I ever get around to implementing it, allow for transparent parallisation.

The concept is not dissimilar to GCD or the Erlang SMP VM.

In effect, every function/method call is actually queued (with is arguments as closures), to a central queue, rather than executed immediately, and immediately returns a future.

One (or more) interpreters per core are instantiated at start-up, and they loop over the central queue executing the coderefs with closures in turn as they come off the queue.

The futures contain a monotonically increasing 'sequence number'. The queue is effectively prioritised according to these sequence numbers.

Everything--numbers, strings, code-blocks (functions and methods, but also the bodies of if statements etc.)--are object references. Objects carry being-read and being-written flags.

Any method requiring write access to an object will be requeued if that object is being read or written. Any method requiring read access will be requeued if the object is being written.

The problem child is currently recursion.

There is much that is yet to be explored.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
  • Comment on Re^4: [OT]: threading recursive subroutines.

Replies are listed 'Best First'.
Re^5: [OT]: threading recursive subroutines.
by Corion (Pope) on Feb 03, 2011 at 11:43 UTC

    I think that this trampoline approach makes sense and would well mesh with asynchronous IO and "green" (userspace) threads as Coro implements them:

    Once your central code dispatcher (GCD) runs out of idle CPU cores/worker threads, it doesn't dispatch function calls by launching a new native thread but suspends the currently executing context and switches to another context using the method that Coro employs, switching out the (relevant part of the) C stack for another. This would basically be transparent to the main code, except for the drawback that parallel execution means more race conditions. When using Coro alone, you don't get nasty race conditions, because there is no parallel execution of Perl code. But you're not worse off than with plain threads.

    The small problem that remains is that threads and Coro are unlikely to mix well. Coro itself claims that it is not iThread-safe, and I have little doubt that this is a false claim. and I have no reason to believe otherwise. I presume one of the more interesting problems will be how to move one coroutine context (basically a copy of the C or Perl call stack) across thread stack boundaries without messing up too many things. But maybe reusing the ideas (and clever macros, and development research) of Coro gives enough foothold to implement transparent switching between green and native threads.

    Update: Clarified sentence about my impression how badly Coro and threads interact.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://885956]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (6)
As of 2017-05-29 01:16 GMT
Find Nodes?
    Voting Booth?