Re: [glob2-devel] speedup possible on resource gradients

[Nuage]

Andrew Sayers wrote:
> I've been trying to analyse speeds, and have run into a few bugs:
> 
> * The island map generator creates a huge patch of stone for every team.
>   It would be better if only a single piece was created.  I can upload a
>   hackish patch for that, unless you want to spend the time doing it
>   neatly.

The created games are not really meant to be playable yet. Any improve is
welcome when it is about the resources. The code is bad looking enough that a
"hack" would not be noticed...


> * I can't find any way to end a game running with "--nox" cleanly.  This
>   means that log files don't get written.  Ideally, I'd like it to catch
>   a "KILL" or "HUP" signal, or to respond to "quit" typed on the
>   command-line, and end the game cleanly.  Is this something that would
>   be easy to do?

The "glob2 --nox" stops at the end of the game. Take a saved game that is almost
at the end. The game without X is much faster.

Or start a saved game like I did, and look at your o'clock... If you start and
stop the game with good human precision this is fairly enough. Still waiting 60s
is better. If you are unsure, add some log into Engine.log to display the total
number of steps.


> * Adding an SGSL script in the editor causes the game to crash when the
>   script is saved, or the editor exits.

I don't know about anything about SGSL management, sorry.


> I've been learning to use the profiling tool "gprof" - early tests
> suggest that over 90% of execution time is spent in
> updateRessourcesGradient() and updateGradientLine(), so optimising these
> functions is pretty much the only thing that matters in terms of game
> speed.

I used gprofile, and noticed big differences of cpu spending ratios depending on
the optimizations flags.

Can you tell us:
-Which is your cpu, and how big are cache level-1 and level-2 ?
-Which optimization flags you use.

I can see a 4x overall speedup when I use "--march=athlon-xp".