Complete.Org: Mailing Lists: Archives: freeciv-dev: August 2001:
[Freeciv-Dev] Re: Profiling Civserver again
Home

[Freeciv-Dev] Re: Profiling Civserver again

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Lino Mastrodomenico <mastro@xxxxxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: Profiling Civserver again
From: Gaute B Strokkenes <gs234@xxxxxxxxx>
Date: Sat, 04 Aug 2001 02:30:43 +0200

On Fri, 3 Aug 2001, mastro@xxxxxxxxxx wrote:
> Paul Zastoupil wrote:
>> On Fri, Aug 03, 2001 at 02:07:11AM +0200, Gaute B Strokkenes wrote:
>> > Paul, could you try this?
>>
>> http://civserver.freeciv.org/~paulz/gprof-gs234.txt
> 
> Ehm...
> I'm sorry, but this code:
> 
> #define map_adjust_x(X)            \
>   ((X) < 0                         \
>    ? ((X) % map.xsize + map.xsize) \
>    : ((X) >= map.xsize             \
>       ? (X) % map.xsize            \
>       : (X)))
> 
> will reopen the bug
> <http://www.freeciv.org/cgi-bin/bugs?findid=749>.

Ooops.  However, according to Paul's profiling efforts this cuts the
time taken from 603.58 to 464.21 seconds, a 24% speedup.  That's
pretty good, so I think my observation that modulo operations are very
expensive is sound.

Could someone try replacing

  ((X) % map.xsize + map.xsize)

above with

  ((X) % map.xsize != 0 ? (X) % map.xsize + map.xsize : 0)

and see what happens, bug-wise as well as profile-wise.  Assuming it
gives good results in both respects, it really ougth to go in for
1.12.0.  It's just such a huge win.

> If we want to try to speed up Freeciv, we should also try to
> evaluate the impact of options like "-march=i686" or "-march=athlon"
> to gcc (all the recent x86 processors have CMOVs instructions that
> can eliminate many branches).

-- 
Big Gaute                               http://www.srcf.ucam.org/~gs234/
LOU GRANT froze my ASSETS!!


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