in reply to Re^5: order of arguments evaluated
in thread order of arguments evaluated
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.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^7: order of arguments evaluated
by kscaldef (Pilgrim) on May 17, 2005 at 21:18 UTC | |
by BrowserUk (Patriarch) on May 17, 2005 at 21:40 UTC |