Re: RFC: Implicit Parallelization Pragma

[Anonymous Monk]

I would see the benefit of this fine-grained multi-threading only if we had massively parallelised CPU architecture as well (e.g. one of those funky asynchronous chips with many many pipelines). Not only that, the OS has to allow the individual process itself manage its own threads in a very very lightweight way.

Right now, however, even on multi-core processors, the OS still has to do a fair bit of work to establish and tear down a thread. Unless perl maintains a pool of threads that can be near-instantly reused for tiny tiny tasks, this is not too useful as a pragma.

Nonetheless, functional programming is a tasty tasty concept that I wish had more real-life applicability in my work.

[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.

[hardburn]

These things are coming. The marketdroids from IBM/Intel/AMD/etc. are throwing around numbers like 512-core CPUs. Wheather that will come remains to be seen, but in any case, such a language feature would need to be implemented and tested now for it to be stable by the time multi-core processors are common.