Complete.Org: Mailing Lists: Archives: freeciv-dev: October 2001:
[Freeciv-Dev] [patch] amortize
Home

[Freeciv-Dev] [patch] amortize

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: "freeciv-dev@xxxxxxxxxxx" <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] [patch] amortize
From: Chris Guest <chris.guest@xxxxxxxxxxxx>
Date: Thu, 25 Oct 2001 14:27:36 +1000

I have two patches here for that rewrite the amortize function, to
avoid the (23/24)^12 = 3/5 kludge. Patches are against
freeciv-cvs-Oct-21 .

(1) amortize_math_patch simply reimpliments the amortize function
using pow from <math.h> .

(2) amortize_array_patch:
generate_amort() pregenerates an array of floats (amortize_frac) of
the form ((MORT-1)/MORT)^n . 
The amortize function returns (amortize_frac[delay] * benefit).
The highest precalculated value of n, MAX_DELAY, and a highest value
for which we can assume amortize(x, MAX_DELAY) = 0 (MAX_BENEFIT) have
been implemented as #defines. 

I have tested both extensively and they perform more accurately than
the current amortize (chiefly because of the kludge).

I compared their performance by averaging the log values for
'End/start-turn server/ai activities:' over a segment of game play
involving 30 ai characters. I tested on a PII 300 with Linux kernel
2.4.2.

Original amortize:                                     0.629 seconds
amortize using math.h pow():                           0.687 seconds
amortize with array:                                   0.692 seconds

As this is motivated by kludge removal, I think a 9-10% ai slowdown is
not such a big sacrifice to make, but I'd appreciate anyone trying
these patches to give some performance indicators on other hardware.

Regards,
Chris






__________________________________________________________________
Get your free Australian email account at http://www.start.com.au

Attachment: amortize_patches.gz
Description: GNU Zip compressed data


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