🚀 go-pugleaf

In article <4hv05r$jaa@solutions.solon.com>
schwarz@a2.complang.tuwien.ac.at (Konrad Schwarz) writes:

|> In article <4hqedf$1m0@solutions.solon.com>, kanze@gabi-soft.fr (J. Kanze) writes:
|> |> In article <4hladl$4cr@solutions.solon.com> Andrew Dalgleish
|> |> <andrewd@axonet.com.au> writes:
|> |> 
|> |> |> Compare snippet 'A':
|> |> |> long	l;
|> |> |> for (l = 0L; l < 1000000L; l++) {
|> |> |>   /* Stuff before test */
|> |> |>   if (condition) {
|> |> |>     break;
|> |> |>   }
|> |> |>   /* Stuff after test */
|> |> |> }
|> |> 
|> |> |> To snippet 'B':
|> |> |> long	l;
|> |> |> {
|> |> |>   /* Extra braces to limit scope of bBreak */
|> |> |>   BOOL	bBreak = FALSE;
|> |> |>   for (l = 0L; !bBreak && l < 1000000L; l++) {
|> |> |>   /* Stuff before test */
|> |> |>     if (condition) {
|> |> |>       bBreak = TRUE;
|> |> |>     } else {
|> |> |>       /* Stuff after test */
|> |> |>     }
|> |> |>   }
|> |> |> }
|> |> 
|> |> |> Example B may evaluate "bBreak" a million times.
|> |> |> It is *possible* that "condition" never evaluates TRUE, 
|> |> |> so you've evaluated "bBreak" a 1,000,001 times for nothing.
|> |> 
|> |> If this is the case, I would suggest that you change compilers.  I can
|> |> imagine cases where the control flow would be complex enough that the
|> |> compiler might have problems simplifying it, but this is certainly not
|> |> one of them.

|> Digital Unix (OSF/1) on Alpha processors has had the best SpecInt and SpecFP
|> performance within the last half year.

|> The native C compiler does not simplify snippet_B to snippet_A
|> if ``condition'' is replaced by ``1 == sin (l)''
|> and ``/* Stuff before test */'' and ``/* Stuff after test */''
|> is replaced by ``printf ("%ld\n", l);''.

Then they are not using optimization techniques that have been known
for an extremely long time.  (I remember using a compiler which did
this back in 1979.)

There is possibly a chicken and egg problem here: C programmers don't
use this construct, because presumably, C compilers don't optimize it.
And C compilers don't put it high on the list of optimizations,
because it is little used.

Still, I really find that worrying about the code the compiler might
or might generate, until you have actual profiling results, is a real
waste of time.  I write my programs so that the work correctly and are
easy to maintain; I optimize only on an is needed basis.

--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, études et réalisations en logiciel orienté objet --
                -- A la recherche d'une activité dans une region francophone