Re^2: RFC: Implicit Parallelization Pragma

[BrowserUk]

...the OS has to allow the individual process itself manage its own threads in a very very lightweight way.

Win32 already has this ability, they call them fibers.

As well as being ideal for creating pools of "units of execution", they also lend themselves to various other useful programming techniques.

For example, you can make any two pieces of code act as coroutines almost trivially.

What is lacking currently is a suitable Perlish API that would allow application programmers to make use of them. It might be possible to layer a Win32-only API on top of threads, but it would be so much better if, in typical perlish fashion, Perl provided an API for threads that abstracted the underlying implementation of any particular flavour and was flexible enough to allow extension for things like fibers on those platforms that support them.

Rather than the current model which follows one platforms outdated and restrictive model to the letter, and attempts to force-fit that model on all other platforms and implementations.

[frankied]

Win32 already has this ability, they call them fibers.

Fibers will not help with parallelization. They are essentially a fancy incarnation of C's setjmp/longjmp functions. An application can change its execution context with fibers, but it cannot schedule fibers in parallel on multiple CPUs.

[BrowserUk]

I was only addressing that which I quoted:

...the OS has to allow the individual process itself manage its own threads in a very very lightweight way.

However, if the machine has multiple cpus, then separate threads can run concurrently on separate cpus. Any or all of those threads can become an association of fibers. The scheduling of the threads will be managed by the system, but within any given thread, control of which fiber of the set of fibers associated with that thread is cooperative under control of the program logic.

[Anonymous Monk]

Well, while being an interesting part of Win32 API I've never seen before, fibers ultimately don't do anything towards the original article topic. My phrase on the process managing its own threads was probably not worded well.

I've seen Sun papers on their research of async CPUs and it looks mighty interesting. Essentially, they view the CPU as a farm of really tiny specialized units, which are not synchronized to a single clock signal. As I understood, a processing thread (either a separate process, or whatever) can lock, say, the ALU for 5ns to do a division, while two other threads do memory loads (each being, say, 2ns). Anywho, it's supposed to be different from Pentium's way of parallellizing instructions in that there is no central clock pulse that everything marches to. Interesting stuff...

Now, if the OS supports hundreds of thousands of threads and is run on a big soup of such asynchronous CPU tidbits, there is possibility for micro-threading. At that stage, yes, the interpreter would do very well by being able to very quickly allocate and tear down these tiny parallel tasks automatically.