Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Re^2: Parrot, threads & fears for the future.

by Corion (Pope)
on Oct 23, 2006 at 12:16 UTC ( #580010=note: print w/replies, xml ) Need Help??


in reply to Re: Parrot, threads & fears for the future.
in thread Parrot, threads & fears for the future.

You stopped reading too soon, then. There is much parallelism which could be exploited by having (say) Perl6 constructs be natively parallel, for example the hyperoperators, and grep/map.

Also, having real, painless userspace "threads" (i.e. cooperative multitasking) would be a huge benefit too.

Your reaction is exactly the point that BrowserUk is trying to make, or at least how I interpret it - actually and transparently using and supporting threads is an important asset for a programming language. Having to manually implement IPC, like you have to do if you want to keep on using fork and still reap the benefits of parallelism is a pattern and hence a weakness in the language.

Replies are listed 'Best First'.
Re^3: Parrot, threads & fears for the future.
by Jenda (Abbot) on Oct 23, 2006 at 13:10 UTC

    You can only transparently paralelize map{} if the executed block is side-effect-free. Perl is far too dynamic for the compiler/optimizer to safely check that and you might very well want to have side-effects in your map{}s so you'd have to have two map{}s, a paralellisable one and a garanteed-to-be-serial one. It's one thing to paralelize a purely functional, side-effect free language and to paralelize something that may do whatever it bloody wishes. Everything comes for a prize, even freedom.

      Sure - but I'm not talking about doing that for Perl5, but postulating it for Perl6, where such stuff is still possible.

      What if there was a pragma for enabling parallelization? It could be use parallel, in the spirit of integer.
      my @list = ('aaaa' .. 'zzzz'); use parallel 'map'; # Just for maps my @ordlist = map ord, @list; # Defaults only # Probably something like any, all, map, grep, and maybe even sort use parallel; # Sort by last letter in parallel @list = sort {($a =~ /\w+(\w)/) <=> ($b =~ /\w+(\w)/)} @list; # This subroutine can operate in parallel use parallel 'foreach'; foo($_) foreach @list; no parallel; # disable everywhere else

        I think it would be safer to have a "parallel map" function instead. In either way the problem is that people would not normaly think neither about adding the pragma nor using the parallel map. Plus there is another problem. The question is not just whether perl may execute the map in parallel, but also in how many chunks. You would of course not want to create a thread for each and every element of the array/list especially if it's huge and the operation is simple. The number of threads you will want to use depends on the complexity and nature of the action you want to do with the elements - you will want more threads if you will spend most time waiting for a network response, you will want less if it's just computation ... So without knowing what's the operation, the implementation of the mapp will not know how to parallelize the operation to achieve good performance. So even though mapp is a nice interface to parallelization, you will want to be able to give it a few more hints to ensure it works well.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://580010]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (4)
As of 2021-06-16 18:25 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    What does the "s" stand for in "perls"? (Whence perls)












    Results (76 votes). Check out past polls.

    Notices?