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

["imbaczek@xxxxxxxxxxxxxx" <imbaczek@xxxxxxxxxxxxxx>]

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

On 04-01-05 you wrote:

> Since inline functions are always less effective than macros, what is the
> performance *loss* by going from the previous macro form to the inline one.
> What is the justification for making the change from macro to inline given
> all the inherent problems with inline not shared by macros?

Have you read what Jason wrote?

>> The attached patch inlines map_pos_to_index.  This speeds up the server
>> by 5-10% as well as making the code smaller and more readible.
>> 
>> This is a special case of a piece of code that NEEDS to be
>> inlined/macrod, but for which macros are much inferior to inlining.
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                                                  !

> There have been many discussions over the years on the macro vs inline
> issue, and the result has always been that one should use macros in "C"
> programming over inline for performance reasons.

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

I keep forgetting about changing To:, so you've propably got my email with
this: http://gcc.gnu.org/c99status.html

C99 inline functions do not generate an external definition if
declared without extern, but do if declared with extern, the opposite
of GCC's handling of inline and extern inline.

IMHO this implies that the compiler always is obliged to at least
try very hard to inline functions declared as such. I may be wrong,
though, I don't have the standard.

> 2)  inline functions do not optimize as fully as macros in all cases,
>      since some of the compiler specific inline structuring can block
>      some sorts of optimizations.

I think those cases need to be somewhat obscure for the compiler to
not inline and optimize correctly.

> As this patch introduces a concept (inline functions) that has so far
> been pubically declared as undesirable for Freeciv, and it reduces
> performance over the macro form, it should be rejected. When Freeciv moves
> to C++ or another object oriented language where there is no preprocessor
> advantage of "C" programming model, this could be revisited.

But this patch increases performance! _And_ looks cleaner than the
macro form.

BTW, IMO the "C programming model" is just a convention that should
not be held to when it gets in the way.

-- 
{ Marek Baczyński :: UIN 57114871 :: GG 161671 :: JID imbaczek@xxxxxxxxxxxxx  }
{ http://www.vlo.ids.gda.pl/ | imbaczek at poczta fm | http://www.promode.org }
.. .. .. .. ... ... ...... evolve or face extinction ...... ... ... .. .. .. ..