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

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

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


Marcelo Burda wrote:
[...]
> if i make it as macros, and other topological function too we no more
> can use gprof to evaluate the impact of topological work, probably there
> is best to pospose to switch to macros until new topo work as evoluted a
> litle. there are easy to switch to inline or frmm inline function to
> best evaluate the impact of a oftend used code!! then we can suitch to
> macro. 

There are two main uses of macros. The first is to standardize code use
by supplying #defined constants and trivial APIs that are used everywhere
but defined in one spot. The second is for performance optimizations. The
latter should only be done after code is written, and the performance is
measured and deemed worth improving. If you follow through with this you
should have no problems deciding how to develop and complete new code.


As a trivial template to help you with measurement issues, you can use
this sort of wrapper technique along with some heuristics that measure
the basic cost of the function call and/or global performance losses from
deoptimization introduced by the presence of the function. It also works
for type checking.

*.h:

#define _macfn()  ( <internal/non-public implementation of optimized code> )

//  Set the public API to function or macro form
#ifdef MACFN_PROF
#define macfn()  _macfn()
#else
extern int macfn();
#endif

*.c:

#ifndef MACFN_PROF

int macfn()
{
   // full code for the functional implementation
   //   or
   // simply wrap the internal macro to avoid code duplication
   return _macfn();
}

#endif

You can of course twiddle the above to make both macro and function forms
available with the API defined to the preferred case. One advantage of
macros over inline is you get absolute control over what you are doing
rather than ending up with random behaviour depending on the compiler's
whims of the moment. Thus you really can test for performance and rely
on it carrying through to arbitrary compiler environments.


> Today topologies is hard developing stade. 

Hard happens when things are poorly understood. As the underying concepts
become clearer, things will become easier. THis is sort of a corollary to
the KISS principle.

> Marcelo

Cheers,
RossW
=====