Optimizationg (was: "Goto statement considered superfluous" (was: If you we

"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* co
ding
techniques impact IBM mainframe COBOL applications, see the "performance tun
ing
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 determi
ning
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 cod
ing
style."

--
Bill Klein
wmklein <at> ix.netcom.com