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

["rwetmore@xxxxxxxxxxxx" <rwetmore@xxxxxxxxxxxx>]

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


Arnstein Lindgard wrote:
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=7279 >
> 
> On Fri, 23 Jan 2004 09:05:09 -0800 rwetmore@xxxxxxxxxxxx wrote:
[...]
> Unless the inline is inherently dangerous, the advantages seem clear:

I suggest you read up on the dangers and side effects.

> 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.

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 that one would use to justify a code purge to
install a timeconsuming and heavy handed C++ methodology (complete with type
checking of every line of code or fourth instruction whichever came first)
over just getting on with coding of the Freeciv game in the language of its
design choice - "C".

When you hear people muttering about "my pretty code" or "my precious code"
they have probably fallen to some dark spell that originates in the land of
more do's and don'ts rather than a realm of enlightenment and understanding :-).

Naive and immature programmers are often seduced by such things and don't
really spend the time or thought to fully understand where the benefits are
and what one really needs to do to gain them. When fuzzy subjective criteria
are given more weight than hard practical ones, then the code suffers. That
is fine for anyone experimenting with their private code projects, but a
higher standard needs to be maintained for custodians of public open source.

This is one of the reasons why previous Freeciv maintainers made the *no*
inline coding standard for Freeciv. It was a complete rejection of inline.
One really needs to come up with some pretty hard counters to justify
overturning this and the first one is at least spending a little time
coming up to the level of understanding that those maintainers had.


> This is sufficient grounds for rethinking conformity to tradition.

Not even close ...

> 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.

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

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.


Inlining originated as a wart to fix the devastating performance problems
caused by the C++ methodology of breaking actions down into their smallest
components and wrapping those few lines or operations in a function call.
Even a key architect of C++ like Stroustrup regarded inlining as a C++ wart
and of no value in pure "C" code.

Inlining is only a hint to the compiler, rather than being a feature of the
language, for the same reason that *register* is only a hint to the compiler
about which variables should be cached in faster hardware. When compilers
had improved enough to render code into efficient forms without programmer
assistance, all these hints are supposed to go away and clean code remain.
If you see an inline statement, it means you think your compiler is not up
to snuff and needs a bit of help.


Backporting to "C" was done more to maintain the status of C++ as a better C
with a single compiler for both. It was always recognized that if inlining
was a necessary evil for C++ to run even moderately inefficiently, it was an
unnecessary evil for "C" which did not have any of the language overburden
compelling one to write every other line of code as a function.


> There should be clear reasons for banning inlining. So far, the
> misleading warning about undefined order of evaluation of function
> arguments is clearly irrelevant. We foolhardly assume that the ISO
> standards commitee has not yet been taken over by kamikaze coders. If
> the undefined order was a problem, they simply would have defined it.

There are. 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.

Standards organizations are about finding the best accomodation between
competing views that produces a well defined or at least workable subset
of behaviour that permits interoperability and development to proceed.

Accomodating both C++ and C styles is part of the standards. In the case of
Freeciv, the maintainers and original developers chose the "C" style and
set the standards and rules for the project accordingly.

There needs to be *very* clear reasons for changing this.


> If there are true arguments against inlining, they should be
> presented clearly for scrutiny. If arguing in circles around the
> opposition camp's position was a silver bullet around here, we'd all
> be writing Python already.

The arguments are well-known and available for all to go and read. Those
that supposedly are in charge of maintaining the Freeciv versions should
by all means do their homework and go read up on them.


> 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.

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 :-).

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?


[...]
> 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.

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.


> Coding is a technical process involving coders. Maintainability, ease
> of use, and just plain likeability are perfectly valid arguments that
> may trump pure technical ones. It could just as well lead to more
> productivity and less bugs, depending on the majority's orientation.

Not true half as often as is deemed the case here. You really should
look over the mail archives for the last 3 or so years. You will find
that almost every case where a code patch was said to provide greater
robustness or performance, it was rejected or required to scale an
arbitrarily high barrier of documented improvement. The alternative
cases simply need to say they are performance degrading, but with a
never documented whiney "not by much", and hey they are prettier :-).

The death of a thousand cuts is part of the reason why there is so much
discussion of performance problems in the lists. Is is also why even
after the cleanup of a lot of robustness issues in the core, there have
been so many core faults and programmed aborts in the same period.
Rewriting code to make it pretty has dropped a lot of the original
logic, most often with catastrophic results.


> My opinion is that if Freeciv decides to inline, after making a
> tradeoff between risk, speed and the fact that oranges taste better,
> it will be a sound decision in it's own right. Same goes for the
> opposite decision. I agree it's best to do it on open forums.

If the maintainers have done their homework, understood ths issues,
presented all the arguments and with the concensus of the community
reached a decision to change core Freeciv standards or start a new
version written in C++, then that is fine.

But a couple maintainers getting a partial overthrow of the established
standards in a backroom meeting where even one of them is hedging about
just how much leeway they got, while the otther is off and purging, is
certainly neither a sound decision nor one that is going to sit
particularly well with a large number of past and present contributors.


> Of course, I prefere to allow both forms. Total anarchy, wohoo!

In most cases, I prefer informed choice. In cases where the choise is
going to be abused by one party, or do irreparable damage because it
really is a wrong choice, then one needs to make a firm stand, document
it and abide by it. Nothing else will suffice. I hope the current
maintainers share similar goals.

> Arnstein

Cheers,
RossW
=====