[Freeciv-Dev] Re: [Patch] Bool cleanup of options.c
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
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.
|
|