[Freeciv-Dev] Re: (PR#2370) Path finding

[Jason Dorje Short <vze49r5w@xxxxxxxxxxx>]

I'm taking this off of RT.  Such flamewars should be confined to 
freeciv-dev where they really belong :-).
rwetmore@xxxxxxxxxxxx via RT wrote:
> At 01:13 AM 02/11/24 -0800, Raimar Falke via RT wrote:
>
> > On Sat, Nov 23, 2002 at 03:43:45PM -0800, rwetmore@xxxxxxxxxxxx via RT wrote:
[snip: arguments about inline]

> > Show me a compiler which doesn't support it. To cope with different
> > syntax we have autoconf (which already has a test for it).
> So you admit, it is non-portable and thus needs to be tested for.
Err, no.  His argument was classic FUD (or anti-FUD, take your pick).

1.  It is portable (i.e., you should demonstrate it is not portable).
2.  Even if it's not portable, that doesn't matter.

> Non-portable is something like being pregnant, you are or aren't.
All logic would seem to suggest otherwise.

> > > Big inline functions are an abuse of the technique, when big is big is
> > > also ambiguous with inline in addition to the compiler issues above.
> > Not a real point.
> Actually it is, but I'll accept you can't see why.
It is not a real point because this is also true of the alternatives.

Large functions may of course be inlined - and I suspect if you compile 
with -O3 many are - but the relative savings will be small.
> > > There is nothing good to say about inlining.
> > > <End discussion>
> > One valid point raised.
> So you do admit inline has no value - that should be enough :-).
Inlining and macros both have problems.  And yet we are willing to trade 
these problems for the extra speed they seem to provide.
I have never seen a demonstration that this extra speed actually 
provides anything better for the end user.  And I am certain that in 
most cases, the time spent optimizing tiny functions could better be 
spent optimizing the frontend.  But that's certainly not as fun...
Case in point: corecleanups takes advantage of a lot of 
micro-optimizations, adding macros all over the place.  But the 
interface is unplayably slow.
Another case: with the CMA+SMA, Raimar found that agents took 16 seconds 
per turn as the game progressed.  But when he broke this down, he found 
that only an insignificant fraction came from actual calculations (very 
similar to the PF ones, I suspect).  What was causing the slowdown was 
network latency and (mostly) unnecessary graphical updates.
> At 01:27 AM 02/11/24 -0800, Jason Short via RT wrote:
>
> > Raimar Falke via RT wrote:
> [...]
>
> > > > Big inline functions are an abuse of the technique, when big is big is
> > > > also ambiguous with inline in addition to the compiler issues above.
> > > Not a real point.
> > In fact a negative point :-).  This argument applies much more quickly 
> > to function-style macros.
> Not really, but the fact that it is more obvious to you in the macro
> case I think proves my point. Big macros are also very bad, in case 
> you didn't catch on the first time.
But what is less easy to see is that small macros are also bad (as are 
small inline functions).  But if we are willing to make the sacrafice 
for the extra speed they (seem to) provide, then we're stuck with one or 
the other.
Lest the bashing go too far: IMO the use of macros in a non-imperative 
way is very good.
jason