[Freeciv-Dev] Re: [Patch] Bool cleanup of options.c
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
At 11:26 AM 02/03/15 +0100, Raimar Falke wrote:
>On Wed, Mar 06, 2002 at 10:58:38PM +0100, Raimar Falke wrote:
>>
>> This and the next patch about stdinhand.c are the last ones. Then it
>> should for example be safe to change the type of bool from int to
>> char. I'm anxious to know which one is faster.
Almost certainly using the native wordsize is going to be better for
just about everything, but overall this will be noise level.
>Results from _one_ _small_ auto game:
>char:
> user 6m9.240s
>int:
> user 6m8.160s
>
>Effects:
> - the instructions working with bytes may be faster (I'm not an i386
> expert)
The chip wordsize instructions are typically the fastest and most
optimized/heavily used both in hardware and compiler code.
> - the compiler has to insert instructions which extend a value from 1
> byte to 4 bytes
Most operations do this internally so they can use the normal internal
chip logic circuits. Almost never is there less than wordize parallelism
in all bit paths, so they is typically no savings from byte vs int.
> - the char variant should reduce the memory foot print and so cache
> misses (I see this as the major advantage for char) However this may
> be destroyed if gcc padds structs. Only bool[] should really see
> this.
Have you measured the footprint difference? Is it even noticeable, or
do the extra code instructions to handle bytes swamp the data memory
savings for anything but a bool[]?
Also, memory access is actually optimized for word or word multiples. If
random bytes cause other accesses to cross these boundaries, you lose in
a big way.
>Just for the records I have added the diff between map.c compiled with
>char and int.
>
> Raimar
>
>--
> email: rf13@xxxxxxxxxxxxxxxxx
> "Life is too short for reboots."
>
>Attachment Converted: "c:\program files\eudora\attach\map.s.diff"
>
|
|