[Freeciv-Dev] Re: (PR#7195) inlining map_pos_to_index

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

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


Raimar Falke wrote:
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=7195 >
> 
> On Mon, Jan 05, 2004 at 01:50:57PM -0800, Brandon J. Van Every wrote:
> 
>><URL: http://rt.freeciv.org/Ticket/Display.html?id=7195 >
>>
>>Marek wrote:
>>
>>>RossW wrote:
>>>
>>>>The key elements are:
>>>>1)  inline functions are merely a *hint* to the compiler 
>>>>     with no hard requirement to actually inline the code.
>>>
>>>But a darn strong one. In gcc, defining a function as extern inline
>>>makes the compiler to not emit the body of the function (ie. doing
>>>&inlined_function would result in link error.)
>>
>>Ok, I've been trying really hard to shut up, and succeeding.  But
>>I'm now going to obnoxiously interject in an increasingly obnoxious
>>discussion.  Having spent my entire career on low-level ASM
>>optimization bullshit, and having seen *plenty* of inline compilers,
>>I'm inclined to weigh in on this language religious wars
>>gobbledygook nonsense.
>>
>>There are 2 issues:
>>1) *WHY* are you trying to optimize?  Really, what's in it for you?
>>2) If you are trying to optimize, *WHAT COMPILER* are you using?
> 
>>(1) is the bit that's ticking me off.  Here you are, yadda yadding
>>about C style this or that.  It's micromanagerial, and misses the
>>forest for the sake of the trees.  Strategically you should *either*
>>be doing something OO in a higher level language, 'cuz optimization
>>usually doesn't impact the bottom line and your programmer time is
>>better spent, *or* implement a very obvious / needed performance
>>improvement.  And it seems like the case under current discussion is
>>the latter, so what's all the pissing and moaning about macros
>>vs. inlines about?  IF IT WORKS, USE IT.

I think your statements are in basic agreement with the long established
position, at least prior to the closed door discussion that seems to have
taken place and completely reversed this policy a few weeks back.

Since macros will never be less efficient than inline functions, have no
compiler dependencies (since the preprocessor generates "C" code that is
handled by the compiler just like all other code), if one is interested
in performance optimization macros should always be used over inline
functions.

There has never been any justification of the use of inline over macros.

The rewriting of code like terrain.c to strip macros without performance
testing so Raimar can show limited recovery of performance by inlining over
function calls (but of course not doing the comparable macro optimizations)
is really just a make over project to convert Freeciv to a different
programming style. That is one of the previous reasons for the complete
block on inlining, i.e. the slippery slope to wasted style conversions.

[...]
>>(2) adds insult to injury.  GCC might be *wonderful* at inlining.
>>I'm using Visual Studio .NET 2003, and I can assure you its inlining
>>is bollocks.
> 
> Another valid point BUT inlining is part of C99. If your compiler
> doesn't understand it get a better one. Also gcc is available also for
> your platform.
> 
>>People tell me the Intel compiler ain't so hot either.
[...]
>>Ergo, in cross-platform development, you cannot make assumptions
>>about what will or won't be inlined.  Maybe it works *great*.  Maybe
>>it works *terrible*.  There's no a priori reason to decide one way
>>or the other.  The worthwhile general recommendations are:
>>
>>1) feel free to #ifdef based on target compiler
>>2) don't assume lotsa inlines will play well with each other
>>3) don't assume long inlines will get inlined

Since there are all kinds of issues with which compilers inline and how
well they optimize inlined code over normal code, it will always be the
case that inlining will fall short of optimal performance gains.

Since there is a perfectly reasonable alternative, there is absolutely
no need to use an inferior technique, nor waste time doing a code purge
to rewrite everything in the favorite style some maintainers prefer over
the rest of the community.


> I have no problem adding to the INSTALL file:
> 
>   Freeciv requires a compiler which understands inlining according to
>   the C99 standard. Compiler foo and bar are reported to not support
>   these or do the wrong thing. It is recommended to use gcc or the
>   intel compiler in this case.
> 
>       Raimar

Why add unnecessary restrictions to Freeciv. One of the advantages open
source development has is its lack of platform restrictions that many
commercial versions implement for cost or marketting reasons.

I for one really do take issue with such restrictions. I am sure there
are many others that find similar value in truly open source development.

Cheers,
RossW
=====