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

["Jason Short" <jshort@xxxxxxxxxxxxxx>]

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

Raimar Falke wrote:
> Freeciv has no hardware requirements
> like commercial games have. This leads to a "lets make it as fast as
> we can since there may be slow hardware out there". But even with a
> fast hardware (1GHz+ CPU) you can watch it crawl when you do an
> autogame (set timeout to -1 and use only AI players).

The autogame is so easy to measure that it has become a benchmark for 
measuring "speed".  But as I've said before I believe this is highly 
flawed.  The vast majority of a normal player's wasted time is spent 
watching units animate (i.e., the "stepped movement").

Try:

- Timing an autogame.
- Timing the same autogame with a client observer attached.
- Timing the same autogame with a client observer attached and animation 
off.

The second game probably won't complete because the client is too slow 
for the server and will be cut.

Increasing the between-turn speed for players is a MAJOR boon.  Half the 
people I know didn't like civ3 because all you do is watch workers move 
around.  The same is true in freeciv.

Some methods have been proposed to improve this.  However most of these 
have drawbacks.  The player needs to get this information, after all, 
and people can only understand incoming data so fast.

- Make auto-settlers take more efficient paths.  This would certainly 
improve the problem.  But it is hard to do.

- Animate multiple units at once.  But then the player wouldn't be able 
to pay attention to all of them.

- Disable animation selectively.  For instance you could not animate 
auto-settlers at all, or not animate allied units, or not animate enemy 
units.  IMO this method has the best possibility for success.


Server speed does have an impact in some cases, though.  One is mapgen. 
  Current mapgen programs may take up to 5s (?) to run on popular 
hardware.  Future mapgens may take 10x as long but run on faster 
hardware.  Most importantly, while mapgen is running the user must wait. 
  So optimization here is helpful, although *algorithmic* optimization 
is probably going to be a lot more helpful than constant-factor 
optimization.

Pubserver also needs civserver to be fast, since it runs many civservers 
and no civclients.  I suspect this is not an issue now, but if it were 
more heavily trafficked it could become one.  Of course we always have 
the option of improving the hardware.

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

Currently we handle C99 feature on a per-feature basis.  Variadic macros 
and variable-sized arrays are required and checked for during 
configure-time.  Inlining is checked for, but it is not a fatal error if 
it's not found (it's just disabled).  But if we start using inlining a 
lot this will make things slower (if it's not supported, that is).

jason