glob2-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Andrew Sayers
Subject: Re: [glob2-devel] speedup possible on resource gradients
Date: Sun, 27 Nov 2005 16:43:54 +0000
User-agent: Mutt/1.5.11

On Sun, Nov 27, 2005 at 04:49:24PM +0100, Nuage wrote:
> 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...

That's good.  I'd put the hack into the RC2 release actually, since we
were pressed for time.

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

Fair enough, I'll try that.

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

That's OK, Stephane's fixed it - it turned out to be an OpenGL bug.

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

I've backed the pointer changes out of the code for RC2 - even with my
numbers, the speed gains are too small to be worth the bother for now.
However, as I've said elsewhere, this is an important debate for the
future.

Anyway, my processor is an Athlon XP 2200+.  According to
http://www.amdboard.com/athlonxp2200special.html, the stats are:

Frequency: 1800MHz
Cache L1 Instructions: 64KB
Cache L1 Datas: 64KB
Cache L2: 256KB
Clock Multiplier: 13.5x

I've been using "-O2 --march=athlon-xp -pg", but tried "-O3" and tried
with/without architecture optimisations.  "-O2" is the only thing I've
seen that's made any significant difference.

        - Andrew




reply via email to

[Prev in Thread] Current Thread [Next in Thread]