On Jul 16, 2005, at 1:27 AM, Gerhard Postpischil wrote:
Joe Zitzelberger wrote:
What was hyper-efficient last year might not be today. Many of
the 'efficiency' tricks that programmers have used for decades
are now actually hinderances.
Depends on what we're talking about. LA r,0 vs. SLR r,r probably is
irrelevant these days. LA r,0(s) vs. LA r,0(,s) isn't.
And atrocities like LH r,=H'5' rather than LA r,5 are still timely.
My take on the best approach is to first write source that is
clear and understandable by other humans. Then, once it is
written and tested, to use profiling tools to determine where the
efficiency concerns actually are. Usually, they are not where
programmers would have 'expected' them to be.
I consulted at a government agency where I found code that's very
clear and easy to understand:
TM flag,1
BZ label
NI flag,255-1
label .....
(As an aside, this program took nearly 24 hours of CPU. We moved
two instructions and caused it to run in two minutes).
Perhaps the underlying root is clarity of mind, or clarity of
purpose. I once wrote some code (about 80 lines) to patch HASP,
only to have it fail if the printer ran out of paper. Later on I
found code from Waterloo to do the same thing, in a different
module, consisting of three lines!
We're in agreement on the profiling, but not on 'unexpected'
locations. Do you have any specifics in mind?
Your comments about "LH r,=H'5'" being an atrocity is certainly on
the mark. But for 99.99% of the time it truly doesn't matter. With
branch prediction, speculative execution and multiple execution units
that exist in todays processors, many of the less intensive
instructions are effectively 'free' -- that is, they take no apparent
time to execute as the various possible results have been pre-
calculated.
One specific that jumps out at me is people who spend any time at all
tuning block sizes. As if somehow they are smarter than the OS or
that anything but the largest possible block size on z/OS is ever
worth using except in the case of real-time, unbuffered output.
Another would be the irrational fear of the Cobol verbs SORT, INSPECT
and SEARCH. These three got bad reputations for poor performance
when first introduced -- IBM followed the first make it run, then
make it run fast development approach. Even though IBM's initial
performance problems have long been corrected, you will still find
people that insist on custom coding replacements as needed to
'improve performance'.
These two common expectations have been non-issues for many years now.
My on personal best surprise moment was probably the discovery that
LE storage management was about a tenth the overhead of OS storage
management.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
