🚀 go-pugleaf

kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:

>fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
>
>|> kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:
>
>|> >Normally, the format string in production code
>|> >will not be a string literal, but rather something read from a
>|> >configuration file, dependant on the locale setting.
>
>|> That has not been my observation.
>
>Are Australians as unaware of the existance of the rest of the world
>as Americans are?

Certainly not! ;-)

Nevertheless, almost all of the programs I have seen produce messages
in only one language.  This includes programs such as gcc (and indeed
almost all of the GNU programs); CHRIS (a now million-line COBOL
personell/payroll program that I worked on about 7 years ago); the
Mercury compile (the program I've been working on for the last couple
of years); Linux - even though Linux's development was started by Linus
Torvalds, a citizen of Finland whose native toungue is Swedish, if I
remember the details right), and even though Linux is used in a variety
of countries whose primary language is not English; and a variety of
other programs, both commercial and free.

The reason for this is simple: the cost of producing multi-lingual programs
usually exceeds the benefits.

>(This really doesn't have much
>to do with Fergus' point, but it is a pet peave of mine.)

I've noticed ;-)

>|> What is relevant is that in many C programs,
>|> most calls to printf() have a string literal as the first argument; if
>|> optimizing those calls to printf() is likely to speed up the program or
>|> reduce code size, then any good optimizing compiler should do so, just
>|> as any good optimizing compiler should optimize division by a
>|> constant.
>
>Optimization isn't free.  I would argue against this optimization on
>two grounds: 1) It only affects a limited number of programs,
>generally, test programs or other quick hacks (let's face it, I'll put
>a constant string in a printf, too, if the program is only going to be
>run once, or if I'm the only person who will see the output), and

I don't agree with this.  As noted above, in my experience the vast
majority of programs that use printf() use string literals for the
format string.  While I'm aware that my experience is unlikely to be
reflective of the situation world-wide, it does nevertheless mean
that this is true for at very least a significant proportion of all
programs.

>2) I am almost willing to bet that the time spent in parsing the printf
>string is totally negligible next to the time spent in conversion and
>output (if this wasn't the case, iostream, which doesn't parse, would
>be significantly faster than printf). Also: I would hope that the
>number of C++ using printf is very small anyway.  (This is
>comp.lang.c++, not comp.lang.c.)


This is most likely true.  That's why I carefully said "_if_ optimizing
those calls to printf() is likely to speed up the program or
reduce code size ...".  So I agree with your conclusion - I just
disagree with some of your arguments.

>If the compiler is going to spend time optimizing (and the compiler
>writer is going to spend time developing the optimization), then I'd
>rather see it go to things that will really improve performance.

Agreed.

>|> The fact that there may be many programs that don't use
>|> division by a constant or printf() with a string literal for the format
>|> string does not imply that compilers should not optimize those
>|> constructs.
>
>Actually, I would argue that it does, in so far that optimization
>costs, and programs that don't use these features shouldn't have to
>pay the cost.

The cost of an optimization such as the above that is not applied is
pretty negligable; if it provides significant benefits for some programs,
then it should be included.  These days, good optimizers need to include
a wide variety of optimizations that are only applicable to particular
circumstances.  For any given piece of code, only a small portion of
them may be applicable.  Nevertheless, such optimizations are necessary
for good performance.  If optimizations were not implemented simply
because they might not apply to most pieces of code, you would end up with
a poor optimizer.

-- 
Fergus Henderson             |  #define x t=a[i],a[i]=a[m],a[m]=t/* use -O */
                             |  char a[]=" 12345678";main(m,i,j,t){for(i=m;i<
fjh@cs.mu.oz.au              |  9;x,i++)for(x,j=m;--j?(t=a[m-j]-a[m])-j&&t+j:
http://www.cs.mu.oz.au/~fjh  |  main(m+1)*0;);m-9||puts(a+1);} /* 8 queens */