in reply to Re^2: order of arguments evaluated
in thread order of arguments evaluated

The benefit is that an optimizing compiler can choose to do whatever is fastest.

And, yes, some people do care about that sort of thing.

Replies are listed 'Best First'.
Re^4: order of arguments evaluated
by BrowserUk (Patriarch) on May 17, 2005 at 07:38 UTC
    The benefit is that an optimizing compiler can choose to do whatever is fastest.

    If I had said C programmers that might be true, but I didn't.

    I assert that there is no situation whereby a Perl programmer will benefit from this (performance wise or otherwise).

    The performance benefit is derivable in C code, because it allows intermediate values of some variables types to be retained in registers longer than might otherwise be the case. This is possible because the value of some of C's intrinsic types fits entirely within a cpu register. None of Perl's intrisic types do.

    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".
    The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.
[reply]
[d/l]

      It's certainly possible to benefit from it. For example:

      my $a = 5;
foo(0, $a+1, 2, $a+3);

      [download]

      Can be optimized by a massive reordering of the computation. Two of the subexpressions can be evaluated at compile time!

      More generically, your view of compiler and runtime optimizations is too narrow in my view. It's more than just registers. It's entirely possible that operations might be reordered to improve cache coherency, or for other considerations.

      Updated to remove one objection below: added "my"

[reply]
[d/l]

        Again, in C I would agree with you, but not in Perl (5).

        For a start, what if $a is a tied variable?

        Storing 5 to it does not mean that FETCHes will return 5, or even the same value on both occasions.

        With off-line compilation, it would be possible for an optimising compiler to make that determination and do subexpression elimination, but in Perl?

        It's entirely possible that operations might be reordered to improve cache coherency, or for other considerations.

        It is a theoretical possibility, but practical in an interpreted language? Even an interpreter that has JIT would be hard pushed to realise such optimisations and Perl5 doesn't.

        How much benefit can an individual process garner from re-ordering the subexpressions within a single statement to maximise cache coherency?

        What happens to any benefits (which I seriously doubt exist) from maintaining cache coherency when it is sharing the cpu with say a browser charged with stretching or shrinking a .jpg that has been given badly chosen width/height attributes?

        Maintaining cache coherency can yield performance in processes that have uninterupted use of the processor, but in preemptive multitasking environnments those benefits derived by extremely laborious and careful hand coding or hugely complex analysis compilers are completely negated every 200ms (or similar) when the OS swaps tasks. Perl 5 has no way to realise such benefits.

        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".
        The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.
[reply]
[d/l]

In Section Seekers of Perl Wisdom