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

Re: Parrot, threads & fears for the future.

by jepri (Parson)
on Oct 24, 2006 at 16:38 UTC ( #580317=note: print w/ replies, xml ) Need Help??


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

While I was reading this thread, I had a sudden, blinding vision of the future.

Programmers will start long, boring flamewars claiming that people who don't know how to use thread() aren't real programmers and are using toy languges, in much the same way C programmers have been annoying Perl programmers over the lack of malloc() and pointer arithmetic. The discussion threads will continue as various camps make their points, occaisionally interrupted by somebody claiming inanely that when they were programming 50 years ago, nobody needed threads, and everybody built their own computers too. This state of affairs will continue until someone releases a language that is good and fun to program in and contains enough cool parallelising tools that everyone is happy. It might even be perl7.

Don't believe me? Scroll up

For my part, it's enough that I use a language where I can indicate that certain sections can be parallel and then the compiler can choose to use threads, forks or clusters. This language is not perl, incidentally.

___________________
Jeremy
I didn't believe in evil until I dated it.


Comment on Re: Parrot, threads & fears for the future.
Re^2: Parrot, threads & fears for the future.
by tphyahoo (Vicar) on Oct 24, 2006 at 18:21 UTC
      I didn't want to turn this into a language thread, but since you ask... it's Scheme.

      Now, Perl5 and threading... that's not a good combination. Perl programmers habitually use a lot of side effects. Any time someone writes code like $x =~ s/a/o/ the parallelism goes away (maybe). To write a parallel program, every part of it has to be written with parallelism in mind. That sounds fine, except that most CPAN modules aren't written like that, so each one has to be inspected by hand.

      And as someone noted above: even reading a perl variable can change it, and that's not counting what happens if someone hands you a list of Tie:: variables or objects or something like that...

      In Scheme, all I have to do is signal that a part of my code has no side effects and then my macros can do things like parallelise all the arguments to each function call*. I don't have to think about it any further.

      *I'm not saying that's a good idea, I'm just saying I can do it...

      ___________________
      Jeremy
      I didn't believe in evil until I dated it.

        In Scheme, all I have to do is signal that a part of my code has no side effects and then my macros can do things like parallelise all the arguments to each function call*. I don't have to think about it any further.

        I guess that's an ability that could be build into Perl6 (or even Perl5). That is, signalling that there are no side-effects.

        The interesting case is of course, what if the programmer tells the compiler that there are no side-effects, but in reality, there are? The programmer could be deliberately lying, or just not knowing the internals of the language implementation well enough to know (or it could be that in the implementation (aka compiler/interpreter/run-time environment) the programmer developed the program on, there were no side-effects, but there are in the implementation the program is actually run on).

        The idea of having parts that are side-effect free available for parallellization is great - but I rather have the compiler determine this for me than the programmer. (Of course, the compiler cannot determine this always, or else one could solve the halting problem. Unless the language is side-effect free to begin with.)

        Interesting, I started wanting to modularize my "parallel" bits after reading On Lisp. Common Lisp rather than scheme, but they're birds of a feather.
Re^2: Parrot, threads & fears for the future.
by BrowserUk (Pope) on Oct 24, 2006 at 19:02 UTC

    So, which is it?

    Erlang, Ocaml, Mozart/Oz, Clean, Rudy, D, Occam, Concurrent Haskell, Concurrent C... I have (and try to use after some fashion) all but the last three.

    And funnily enough, the existence of all those is (another) pretty good argument for why it is important to speak up now for good support of threading in Perl6 and its underpinnings.

    I don't see any flame war (with the exception of one named monk and one anonymonk--who could well be the same person.)

    I see an important debate to counter the "thread is spelt F-O-R-K" mentality that is so pervasive in the Perl, Parrot & Unix communities that are playing such a big part in shaping the future of my preferred language. Which, incidentally, happens to also be the subject and reason for existance of this place.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
      I haven't really had a good look at Perl6 yet so I don't want to make any comments as to how well it adresses threading.

      I was commenting that it's not the threads-forks-clusters that make a difference, it's being able to hint to the compiler that some code *could* be parallelised, and having a language that provides some high-level constructs when I want to force something to be in a separate thread.

      Programming thread pools and syncronisers and stuff feels very similar to programming low level functions in C - it focusses on what I want the computer to do, rather than telling it what I want to get. So I'm definately in the "future is parallel, but probably not threaded" camp.

      ___________________
      Jeremy
      I didn't believe in evil until I dated it.

        Programming thread pools and syncronisers and stuff feels very similar to programming low level functions in C - it focusses on what I want the computer to do, rather than telling it what I want to get.

        I utterly, totally, completely agree with that statement. Which is why I am so pleased to see that Perl6 has recognised the issues, has them covered, and already working!

        For (one possible flavour) of the underpinnings, that is not (yet) the case.

        So I'm definately in the "future is parallel, but probably not threaded" camp.

        There are a whole class of programs, somewhat characterised by the algorithms for which an entire class of specialist processor units (vector processors) have been built to deal with, that can benefit enormously from the multiple cpu/cores that are now becoming common place, but that require (or at least benefit enormously from) shared state, and cannot be as easily or as efficiently performed using processes (or clusters) as they can using threads.

        Whilst these algorithm are often described as being for scientific work, and more recently for graphical work (games & audio, for which graphics and sounds cards carry specialist GPUs & DSPs), those same and similar algorithms can also be used for much more mundane and everyday computing tasks once you have the processing power to utilise them.

        Three (recent, real-world) examples that have turned up or been referenced here at PM:

        1. Bioinformatics. Forking Multiple Regex's on a Single String
        2. Data mining Benign Web Miner.
        3. Statistical analysis for a web-baseed business. Want a million dollars?

        All three can be tackled using multiple processes (and by implication clusters), but all three have the need for, or can greatly benefit from, a feed back loop of status information and/or intermediate results to the parent execution context controlling the spawning.

        This can be achieved with processes via bi-directional IPC, but if done through pipes, sockets or message queues, the 1 to many/many to 1 reads and writes require both the parent and child to use non-blocking IO. That means every process also has to become a state machine. For clusters, the communications further involves the network and networking bandwidth, latency and topology issues

        This can be achieved through the file system, but that requires semaphores and/or file locking and non-blocking IO. Again, every process has to become a state machine. For clusters, the files will at some point be remote and so the networking issues are again a factor.

        A threaded solution needs locks, but in every other way is simpler, easier to debug and faster.

        1. No non-blocking IO, so no state machines required.
        2. No IPC, so no protocol delays.
        3. No fileIO so no disk locks, latency, contention or caching delays or issues.
        4. No networkIO, so no network latency, contention or topology problems.

        For that class of parallelisation problems for which shared state, or child to parent communications is either required or beneficial, no other solution comes even close to be as simple or efficient as threading.

        Once you remove the need for the application programmer to worry about locking, even at the penalty of some extra delays when using read-only references and the minor cost of a condition test on every access to shared data, the advantages far outweight the alternatives.

        I'm as yet undecided whether Software Transactional Memory (STM) is the right solution to taking locking out of the hands of the application programmer. Having done a fair amount of DB programming, including designing and writing the infrastructure for a unique, widely distributed, multi-transport, DB query mechanism, I've encountered the problems that transactions bring with them.

        If the granularity of the transactions is set too big, you kill your performance by blocking concurrent access and the costs of intermediate storage for rollback can get too high to manage.

        Set the granularity of the transactions too small, and the costs of rollback when it happens become prohibive, and/or you risk allowing the utilisation of out-of-date or rolled-back data.

        STM doesn't have the same issues of protocol and transmission latency usually involved with DB accesses, so this maybe a non-issue, but there is still enough doubt in my mind to cause me some concern.

        But got right, STM is one of several promising mechanisms for allowing the "big issue" with shared state to be taken out of the hands of the application programmer and clearing the way for simple, safe and ubiquitous threading.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
      I see an important debate to counter the "thread is spelt F-O-R-K" mentality that is so pervasive in the Perl, Parrot & Unix communities that are playing such a big part in shaping the future of my preferred language.

      "Do not try and bend the fork. That's impossible. Instead... only try to realize the truth."
      "What truth?"
      "There is no fork."
      "There is no fork?"
      "Then you'll see, that it is not the fork that bends, it is only yourself." --Allison

        "What you know you can't explain, but you feel it. You've felt it your entire life, that there's something wrong with the world. You don't know what it is, but it's there, like a splinter in your mind, driving you mad."

        "There is a difference between knowing the path and walking the path."

        "Free your mind."


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (9)
As of 2014-10-02 12:49 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    What is your favourite meta-syntactic variable name?














    Results (56 votes), past polls