| William M. Klein 2004-10-03, 8:38 pm |
| "Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:p0rel0h7qmk9nohpn804k0ruo1i4r0ko0q@
4ax.com...
> On 26 Sep 2004 19:21:11 -0400, docdwarf@panix.com wrote:
<snip>
>
> No example will support the point that one can tell how fast code will
> run by looking at assembly language .. including z/Architecture.
> Optimization at that level is no longer in the hands of programmers;
> it now belongs to compilers, microcode and CPUs.
>
> If you're inclined, write a timing test that compares the speed of
> single-byte codes to six-byte words. Run it in high priority or on an
> otherwise idle machine. Repeat the loop a few million times .. enough
> to produce three stable digits of timer resolution. Run it a few
> times, using the lowest, not average, speed.
>
> I'll bet you'll find the speeds equal.
>
>
For some actual "timing" tests showing how various compiler options *and* coding
techniques impact IBM mainframe COBOL applications, see the "performance tuning
paper" available from:
http://www-1.ibm.com/support/docvie...uid=swg27001475
It includes statements such as:
"Performance considerations for BINARY datatypes using TRUNC(OPT):
using 1 to 8 digits is the fastest
using 9 digits is 75% slower than using 1 to 8 digits.
using 10 to 17 digits is 30% slower than using 1 to 8 digits.
using 18 digits is 1340% slower than using 1 to 8 digits."
which could be used by those "micro-optimizing" applications. HOWEVER, the same
document also states,
"Using the appropriate program design is another important factor in determining
the performance characteristics of an application. If an inefficient design is
used, then you are limited in the amount of performance tuning you can do to the
application. The biggest performance improvement you can make is to use an
efficient design. After the design is determined, then you can look at other
things such as efficient algorithms, data structures and data types, and coding
style."
--
Bill Klein
wmklein <at> ix.netcom.com
|