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

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"

Replies are listed 'Best First'.
Re^6: order of arguments evaluated
by BrowserUk (Patriarch) on May 17, 2005 at 18:40 UTC

    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]

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

      I added a "my". Now the compiler can determine that it isn't tied.

      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?

      There are no browsers running on my servers. Moreover, I have control over everything that is running

      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.

      In that 200ms, I may have served hundreds of requests. I'm quite willing to take an optimization that is useful on 99% of requests and doesn't hurt on the other 1%.

[reply]
        I added a "my". Now the compiler can determine that it isn't tied.

        It could, but if the "compiler" is Perl5, it won't.

        I'm quite willing to take an optimization that is useful on 99% of requests

        You'll be waiting a long time for it if you are expecting your Perl scripts to benefit from it.

        What http server are you running? Does it use forking or threading? Either way, every inbound request is blowing any coherency in your cache.

        Are you shelling out to run your Perl scripts or using mod_perl? If the former, bang goes your cache every cgi request. If the latter, no benefits are possible unless you are only serving a single page.

        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]

In Section Seekers of Perl Wisdom