🚀 go-pugleaf

In article <1992Aug10.033525.5019@ntuix.ntu.ac.sg>,
eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) writes:
>
>ameline@vnet.ibm.com (Ian Ameline) writes:
><after he removed the redundancy concerning loops>
>:
>:       Proc2(IntParIO)
>:       OneToFifty *IntParIO;
>:       {
>:          if (Char1Glob == 'A')
>:              *IntParIO += IntGlob+9;
>:       }
>:
>:    Hardly typical of real programs, don't you think? Dhrystone has lots
>: of examples like this.
>What makes you think that real programs have no redundancy?

   I just contend that real programs don't have the same level of
it. I don't think I'd call this redundancy so much as code which
obviously does nothing. Dhrystone 1.1 does nothing. As optimizing
compilers become more sophisticated, they will realize this, and
Dhrystone will start giving meaningless numbers. (over 1/2 million
per second on a 33 mhz 486.) This will happen within 1 year. These
same optimizations will result in significant performance improvements
on other programs, but will be unlikely to improve their performance
by more than a factor of 2. It is more likely that improvements seen
given global interprocedural analysis across module boundaries
will result in improvements of under 50% on ispec.


>You argument against dhrystons is the presence of redundancy which can be
>removed by optimizing compilers.
>	If specmark is really free from such redundancy, then its result
>should not depend on compilers. But it does. So it must have redundancy like
>the dhrystone.
>	Because redundancy is deliberately put to improve readability of a
>program, I'll stick to dhrystone 1.1, not dhrystone 2.1, unless someone can
>conclusively prove to me that the distribution of redundancy in dhrystone 1.1,
>is way out from the distribution of redundancy in real programs like gcc.
   When I compare the improvement between optimization and no
optimization when compiling these programs, I see dhrystone improving
by a much greater percentage than gcc. A year from now, dhrystone will
be off the scale, and gcc is unlikely to improve by more than 50%.

   All I'm saying is that programs which don't actually perform any
work will not be useful benchmarks since optimizers will reduce them
to nothing.

   Readability is something else again. It could be argued that code
which performs no function can be misleading. One has to discern those
statements which influence the function of a program from those which
do not. Like any programming construct or method, redundancy can
increase or reduce readability -- it depends entirely on the skill of
the programmer. I would argue that a moderately skilled programmer can
write readable programs with only little redundancy. Certainly entire
statements or procedures which perform no function whatever are not
the mark of a skilled programmer, and actively impair readability.

Regards,
Ian.