🚀 go-pugleaf

In article <2587@mindlink.UUCP> a269@mindlink.UUCP (Mischa Sandberg) writes:
>It's a pretty wretched development philosophy if MS has to
>document IN THE MANUALS that optimization will barf at
>trivial cases like
>        for ( i = 0; i < limit; i++ )
>                if ( x != 0 )
>                        a[i] = 1/x
>for x == 0 ( admittedly bozo code, but ...)

This only happens with the so-called agressive optimizations on; what 
the compiler does then is make brain-dead assumptions about loop-invarient code
(along with other things).  They give you the option of using
these optimizations if you haven't done things like that in your code.

Of course, when developing anything of substance, you can never be sure.
So leave "aggressive" optimizations filed under "stupid things microsoft
has done".  In my opinion, microsoft did this because it helped them
get better numbers on certain benchmarks.

On the other hand, their normal optimizations are fine.  You are mis-represent
what they are doing; what is this "outrageous abuse by compiler developers"?
They have simply said, with this switch on, we will relax a number of 
assumptions we normally make.  No one is abusing you.

craig
-- 
Craig Eisler, still hiding from the real world.
University of Waterloo, Waterloo, Ontario.

In article <1990Jul25.203325.15173@maytag.waterloo.edu> cgeisler@maytag.waterloo.edu (Craig Eisler) writes:
>In article <2587@mindlink.UUCP> a269@mindlink.UUCP (Mischa Sandberg) writes:
>>It's a pretty wretched development philosophy if MS has to
>>document IN THE MANUALS that optimization will barf at
>>trivial cases like
>>        for ( i = 0; i < limit; i++ )
>>                if ( x != 0 )
>>                        a[i] = 1/x
>>for x == 0 ( admittedly bozo code, but ...)
>
>This only happens with the so-called agressive optimizations on; what 
>the compiler does then is make brain-dead assumptions about loop-invarient code
>(along with other things).  They give you the option of using
>these optimizations if you haven't done things like that in your code.
>
>Of course, when developing anything of substance, you can never be sure.
>So leave "aggressive" optimizations filed under "stupid things microsoft
>has done".  In my opinion, microsoft did this because it helped them
>get better numbers on certain benchmarks.
>
>On the other hand, their normal optimizations are fine.  You are mis-represent
>what they are doing; what is this "outrageous abuse by compiler developers"?
>They have simply said, with this switch on, we will relax a number of 
>assumptions we normally make.  No one is abusing you.
>

Being a succesful contenter in the marketplace means finding the right balance:
finding every bug in complex programs probably means getting to market much
later than the users and the boss will tolerate.

The compiler writers at MicroSoft are probably restrained by the marketeers
at MicroSoft from labeling "agressive" optimizations truthfully.  "Unsafe",
"dangerous", etc., would be more honest labels for these forms of optimization.
I applaud those (few) honest companies that so label these options.

Actually, there is nothing inherently unsafe or dangerous about the agressive
optimization techniques.  They do demand more skill though, and the problems
in the released code are a function of the compiler writer's skill, aggravated
of course by market/competitive/schedule pressures.

Years ago I read a book on jogging.  At one point it addressed a common
question:  If excercise is healthy, why do we always see athletes on crutches?
The answer:  Normal excercise *is* healthy and it helps our body achieve its
maximum potential.  Almost always, when you see an athlete on crutches, it is
because that athlete gloried in seeing how much *beyond* his potential he could
get away with, and for how long.

Ralph Carpenter
Tektronix, Inc.
Beaverton, OR