Complete.Org: Mailing Lists: Archives: freeciv-dev: March 2002:
[Freeciv-Dev] Re: [Patch] Bool cleanup of options.c
Home

[Freeciv-Dev] Re: [Patch] Bool cleanup of options.c

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>
Cc: freeciv development list <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: [Patch] Bool cleanup of options.c
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 18 Mar 2002 08:48:53 +0100
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

On Sun, Mar 17, 2002 at 10:13:54PM -0500, Ross W. Wetmore wrote:
> 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.

Why have the C++ choose 1 byte at the size of their bool?

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

Look for the movs in the diff. It looks like it is required by the ABI
that the return value is extended to 32bit even if it is only
8bit. This isn't the case for C++:

Compiling
char f(void) {return 'k';}
char g(void) {return g()+1;}
under C and C++ yields these diff:

--- t_c.s       Mon Mar 18 08:43:37 2002
+++ t_cpp.s     Mon Mar 18 08:43:21 2002
@@ -1,15 +1,14 @@
-f:
+f__Fv:
        pushl   %ebp
-       movl    $107, %eax
+       movb    $107, %al
        movl    %esp, %ebp
        popl    %ebp
        ret

-g:
+g__Fv:
        pushl   %ebp
        movl    %esp, %ebp
-       call    g
+       call    g__Fv
        incl    %eax
-       movsbl  %al,%eax
        popl    %ebp
        ret

So it looks like C++ is "8bit clean" (doesn't have to extend it to
32bit).

> > - 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?

I only have to sizeof of some structs:

int:
sizeof(struct unit)=140
sizeof(struct city)=2148
sizeof(struct player)=12672

char:
sizeof(struct unit)=132
sizeof(struct city)=2140
sizeof(struct player)=12572

IMHO they can be a bit smaller in the char case if the members are
rearranged but in general the difference is small.

> Is it even noticeable, or do the extra code instructions to handle
> bytes swamp the data memory savings for anything but a bool[]?

What extra code instructions?

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

Quite possible.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
    1) Customers cause problems.
    2) Marketing is trying to create more customers.
  Therefore:
    3) Marketing is evil.


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