[Freeciv-Dev] Re: (PR#7279) Macro optimizations

["Arnstein Lindgard" <a-l@xxxxxxx>]

<URL: http://rt.freeciv.org/Ticket/Display.html?id=7279 >

On Mon, 26 Jan 2004 18:44:01 -0800 rwetmore@xxxxxxxxxxxx wrote:

I wrote:
> > 1. It's pretty. Nice colors. Less brackets. No backslashes.
> > 2. No need to maintain two forms of a function for type checking.
> > 3. We can add local variables wantonly, without breaking POSIX or
> >    bloating the interface.

You wrote:
> It is fascinating that none of the above refer to performance concerns
> or any technical improvement to the "C" code. They all seem suspiciously
> like religious considerations

Yes, it is fascinating. It demonstrates that you can trump pure
technical arguments with political ones, if you are inclined to do
so. Once you've learned to do it, you have a new *tool* for technical
as well as political debates.

However, when conservatism starts to defend itself by inventing new
arguments in addition to the original ones, the thinking starts to
take on the characteristics of religion.

On the performance issue, I read that even successfully inlined
functions will push stuff on the stack and therefore only the
call/ret instructions are optimized, which is mostly pointless.

If that's what you were getting at with the obfuscated alloca()
example, I suppose I get extra 10 points. Then I suppose one should
leave functions with local variables out of line, and you'd have to
use macros and non thread safe globals if you want to optimize that
particular function. Still I seem to remember Jason measured a speed
improvement for inlining map_pos_to_index(). I certainly would
excpect a decent compiler to only bother the stack when necessary.

It's hard to believe other compilers will push pop the actual
arguments to a successfully inlined function.

On the other hand, gcc states that

  "An Inline is As Fast As a Macro".

So why not use inline for map_get_tile() and such?

I wrote:
> > The fact that gcc takes a progressive stance on inlining, is a hint
> > to the programmers that we may or may not choose to take.

You wrote:
> Inlining is a hint to the *compiler* that it may or may not choose to take.
> Please get this straight.

Of course I understand that too. It would be most interesting to
learn whether this may cause side effects other than not gaining
speed we otherwise would have. It may be that gcc inlines better than
the standard because there's no reason not to.

> You really should review the history and reasons for inlining and why it
> was backported from C++ to C plus the vigorous discussion this entailed
> in the late 80s.

It would have been so much easier if an enlightened person provided
some clear (and valid) examples on situations where inlining in C was
dangerous, so that I didn't need to read up on the history of two
programming languages. From what I have read, there are *still* no
arguments *against* inlining other than not gaining the *full* speed
improvement on conformist compilers.

I see a tool that is now part of C. You have said yourself that when
language is chosen, one should use the full set of available tools.
Goes for lint too. There could be advantages to both the preprocessor
and the compiler, for different situations.

> If you see an inline statement, it means you think your compiler is not up
> to snuff and needs a bit of help.

I may be wrong, but believe most binaries are compiled with -O1 or
-O2, not -O3. If the goal is to give performance to the masses,
inlining would make sense, just as macros would.

With assembly as a tool for fact-checking, I can confirm that inlined
functions of some size, such as normalize_map_pos(), sometimes end up
smaller, and thus faster, than the equivalent macro version, when
using gcc with optimization.

If you insist on (ab)using the preprocessor to impose rigid code, it
means you prevent the compiler from slashing unnecessary bits of
code.

Since the extra speed gain is very small, it's completely unfair of
me to deploy the latter argument, wouldn't you say? Furthermore,
since large functions probably should not be inlined/macroed, it
becomes entirely absurd. I do apologize if I spoiled the exercise in
debunking my nonsense with unnecessary clarity.

I wrote:
> > There should be clear reasons for banning inlining

You wrote:
> There are.

What are those?

> You have been told what the masters of the ISO standards thought
> about inlining and what is the common understanding of those that lived
> through or have done their homework by reading up on the relevant material.
> 
> Making foolish assumptions that because something is possible means that is
> is the best way to go is a very, very immature thing to do - especially in
> the standards world. If you ever sit on a standards committee you will get
> a healthy surprise.

When they allowed inlining in C, they should've anticipated I will
use it. That's their business, not mine.

If some committee has introduced a user-hostile mess (because they
are more concerned with C/C++ compatability in any given compiler
than providing the users of one particular language with the best
tools) and gcc subsequently comes to the rescue, that's just
progressivism.

Freeciv doesn't particularly need identical instances of all
functions in all translation units. I assume by default that nutty
committee professors would impose it upon us, because it makes their
precious Standard look prettier as a whole, when you consider both C
and C++.

I wrote:
> > The superior power of macros can certainly be useful in some
> > situations. If you want to run a campaign for a particular coding
> > style as a crusade against inlining, you may find yourself implicitly
> > defending the position that all functions should be rewritten as
> > macros because it presents more power we don't need.

You wrote:
> Nice try.
> 
> But since my position has always been that macros are most useful when
> used sparingly for performance optimizations, or as ways to codify APIs
> that are really nothing more than one-liners or wrappers around a few
> operations, essentially the standard for "C" coding since day one, it
> is a bit of a difficult sell. At worst, you have to accuse me of defending
> the Freeciv status quo as opposed to some radical new coding style :-).

Yes.. My above comment was a reference to your illustration of how to
have several maps in the same game by bloating the interface. This
could be done with functions as well, so it's hard to see the
relevance.

> Now those that want to use inling to do C++ type checking, make code
> pretty and as we have seen in the last few weeks, appear to be on an
> active crusade to remove all other forms that don't fit this style and
> replace them with inlines, are probably the ones you should be eying a
> little more suspiciously. You wouldn't be one of these types, would you?

No. My particular epiphany is to rethink conservatism whenever the
original arguments may have expired.

I wrote:
> > I prefere not type checking my arguments in either political or
> > technical debates. While I would not use the word "incorrect" I would
> > say it is "politically incorrect" not to clash political arguments up
> > against technical ones.

You wrote:
> So you agree that everytime the technical argument produces a given
> solution is is rather politically incorrect to then chose the alternative
> for political reasons such as Raimar thinks it is pretty and the other ugly
> or it better supports the C++ methodology which while not officially
> required for Freeciv programming is clearly better at type checking
> and so the way to go.

No, it means we've got opposite definitions of political correctness
even if we agree on income taxes. I'm saying you should attempt to
measure both technical and political arguments in absolute although
composite values, and compare the results.

It is a way to broaden the issue at hand in direction of usefulness.
If your base camp is standardization, you might then possibly realize
alternative methods could be useful in specific C projects. The
wordmesh is of course another failed attempt to persuade you to
examplify the dangers of the method you are against, as opposed to
describe historical issues in general terms.

Convincing me to the other side is still possible, but you would have
to provide concrete examples rather than reciting the wisdom of Jedi
masters who truly understand the mysteries of a different programming
language that has nothing to do with Freeciv.

Of course, this post should only be seen as a tool to inspire better
argumentation that may convince others to your position.

Oh, yes and let's quote Stroustrup:

    http://www.cuj.com/documents/s=8011/cuj0207stroustr/

  " The phrases 'the spirit of C' and 'the spirit of C++' are often
    used as weapons to condemn notions supposedly not in the right
    spirit and therefore somehow illegitimate. More reasonably, these
    phrases can be used to distinguish languages aimed at supporting
    low-level systems programming, such as C and C++, from languages
    without such support. I find these 'spirit' arguments poisonous
    when they are thoughtlessly applied within the C/C++ community.
    More often than not, these phrases dress up personal likes and
    dislikes as philosophies supposedly backed by 'the fathers of C'
    or 'the fathers of C++.' These attacks can be amusing and
    occasionally embarrassing to Dennis Ritchie and me. We are still
    alive and do hold opinions, though Dennis, being older and wiser,
    is better able to keep quiet. "


Arnstein