Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Re^18: Why is the execution order of subexpressions undefined?

by BrowserUk (Pope)
on Apr 14, 2005 at 23:58 UTC ( #448023=note: print w/replies, xml ) Need Help??


in reply to Re^17: Why is the execution order of subexpressions undefined?
in thread Why is the execution order of subexpressions undefined?

This node falls below the community's threshold of quality. You may see it by logging in.

Replies are listed 'Best First'.
Re^19: Why is the execution order of subexpressions undefined?
by Anonymous Monk on Apr 15, 2005 at 02:42 UTC
    If the execution order is defined, then there is no ambiguity about what can be run in parallel, and when they must become synchronised.
    Undefined evaluation order is a requirement for parallelization. By definition. Take for example...
    $c = $a + $b;
    If the '+' operator always evaluates the left argument before the right argument, that means they can't be run in parallel.
Re^19: Why is the execution order of subexpressions undefined?
by Tanktalus (Canon) on Apr 15, 2005 at 00:27 UTC

    You said:

    for my $i ( 1 .. $n ) { $results[ $i ] = $db->getLocalData() * $lwp->getRemoteData(); }

    The db object and the $lwp object can both run in parallel. The EOD is on the results, not the method calls.

    I'm trying to wrap my head around this. How can they both run in parallel when the order of evaluation is well-defined? What if one argument has side effects affecting the other? If the two functions are evaluated in parallel, then they will end up with different results. For example:
    for my $i (1 .. $n) { $results[ $i ] = somefunc1($i) + somefunc2($i); } { my $data = 0; sub somefunc1 { my $i = shift; $i += $data++; sleep(1); $i; } sub somefunc2 { my $i = shift; sleep(1); $i *= $data++; $i; } }
    Here I'm just faking out your local/remote data retrieval, but with a dependancy between them. Based on EO, we must wait for somefunc1 to return before executing somefunc2 (or vice versa, depending on the definition of EO). This has become a completely serialised task - there is no way that we can parallelise it.

    If, however, EO remains undefined, we place the ball firmly and explicitly in the developer's court. We are saying, "we, the compiler, make no guarantees about the order in which we evaluate expressions, or even if they are to be evaluated if we can prove their value is useless (e.g., 0 * foo(), if we know that foo returns natural numbers, as per its perl6-style prototype), or even that there will be an order if we can do it in parallel - if your code cannot handle this, it is up to you to use explicit synchronisation points (aka ";") to delineate where you want me to synchronise my calculations." Yes, you need to use temporary variables to store intermediate values. However, nothing says that this intermediate value can't be optimised away, as long as the compiler can guarantee that synchronisation point between executions, in the order that you specify.

    In fact, I would love to see perl6 go the other way - and allow me to say "for this block of code, execution order is whatever you want." And then inside that, other blocks that say, "Well, treat this as sychronised." Or something like that. For example:

    parallel { clean_up_tmp_dir(); serial { $data = read_value_from_db(); $data += read_value_from_lwp(); }; serial { my $other_stuff = fib(3) * fib(8); do_something($other_stuff); } };
    And have /tmp cleaned up in one thread, db and lwp reading done in a second thread, fib(3) in a third, fib(8) in a fourth, and do_something with fib(3) * fib(8) in a fifith. All because execution order is undefined. That would be cool. (Writing a caching, parallelisable fib() would be an interesting task, too, methinks.)

Re^19: Why is the execution order of subexpressions undefined?
by Anonymous Monk on Apr 15, 2005 at 00:06 UTC
    Helloooooo. Erlang variables are single assignment. That's the whole point.

      And? I didn't suggest otherwise. I mention Erlang as a counter to the monads fudge of Haskell.


      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?
        But that's the whole reason evaluation order doesn't matter in Erlang. And lack of that feature in Perl is exaclty the cause of all your problems.
Declarative Parallelism, Re^19: Why is the execution order of subexpressions undefined?
by Anonymous Monk on Apr 22, 2005 at 19:45 UTC
    I don't think that threads scale well compared to declarative parallelism.
    In my opinion, the rough comparison between threads and declarative parallelism is that of manual memory allocation and garbage collection.
    You can make manual allocation faster and more efficient, but it costs extra for each piece of code you write. With garbage collection, it just works. The nutshell is that using a bunch of threads to gain parallelism is wasteful overhead on a single cpu, and actually holds you back when you have more cpus than threads.
    A 'single core' Cell cpu actually has nine cpu cores, and the Cell roadmap for the future goes up to sixty four 'single cores' on a single die. How can you use any kind of explicit threading to deal with 576 cores on a single die? What if it's actually a four socket motherboard with 2304 cores?
    Declarative parallelism isn't threads, and it's not coroutines, but it does let your code take advantage of multiple cores to the limit of your algorithm. More detail is in the thread A Fundamental Turn Towards Concurrency on lambda-the-ultimate.org.
    -- Shae Erisson

      That's a very interesting article. Thankyou.

      I agree that explicit threading is not the way of the future. I also think that neither native threads nor "user" threads are either, individually, sufficient to make good use of future architectures. I belive a combination of the two, and transparency is required.

      For why and how, please contact me via the email on my homepage.


      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?
Re^19: Why is the execution order of subexpressions undefined?
by Anonymous Monk on Apr 15, 2005 at 03:07 UTC
    I have looked (quite hard) at Haskell, and as Autrijus has shown with Pugs, in the right hands and for the right type of project, it is an amazing language.

    However, there are aspects of it--particularly relating to efficiency...

    Since when is Haskell less efficient than Perl? Maybe you need to try GHC.
      C:\ghc\bin>ghc -V The Glorious Glasgow Haskell Compilation System, version 6.2.2

      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?
        So then you're going to show us a piece of code which is slower in Haskell than in Perl?
Re^19: Why is the execution order of subexpressions undefined?
by graff (Chancellor) on Apr 18, 2005 at 08:20 UTC
    I'm not sure how long this horse has been dead, but it seems to still be taking quite a beating... I have to put in a few licks regarding this comment of yours:
    It's not a complicated or extravagant request:

    Please make the language definition such that the compiler will do things in a predictable, defined sequence so that I the programmer can choose how I want them done. Even if the result is a tny weeny bit less efficient than it might be--which it never will be in Perl.

    If I understand your request -- in terms of the OP that started this thread -- you would like to be able to write something like this:
    my $rv = func( $i, ++$i, $i+2 );
    and have it produce a consistent result every time, which is always equivalent to one of the following:
    # either this: $rv = func( $i, $i+1, $i+2 ); $i++; # or this: $rv = func( $i, $i+1, $i+3 ); $i++;
    Obviously, we can't have it both ways. I'm not enough of a language design expert to speculate on how hard it might be implement the kind of ordering definition you seem to be looking for; let alone how hard it might be to document (i.e. clearly explain for programmers of various skill levels) what the chosen ordering turns out to be for all the kinds of situations where this is an issue.

    But the problem for me is that the initial expression, taken by itself without an external rule of interpretation, is inherently ambiguous. Whichever rule is chosen to make this statement unambiguous, it will be a relatively arbitrary choice. And I'll need to see and understand the documentation for it in order to figure out what that initial expression is really doing. (update: either that, or else I'll just have to experiment with it to see what it does)

    The same issue comes up for me in cases where execution order is already well defined, like  $i*$j/$k*$l; -- sure, evaluation is simply left-to-right, and most languages are the same in this regard, so nobody should have any trouble with this. But I would still prefer to place the terms in an order that would be unambiguous regardless of the EO rules, and/or add some parens just to be sure. It's a small price to pay for clarity, given that the language is intended as much for human readers as for machines.

    So my objection to your request is: why add arbitrary rules to the language, if the intent is simply to provide a consistent result for ambiguous expressions? IMHO, it would be better to be clear about what constitutes ambiguity in the language, and avoid it.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (3)
As of 2021-06-14 02:14 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    What does the "s" stand for in "perls"? (Whence perls)












    Results (60 votes). Check out past polls.

    Notices?