Re: sizeof bool > sizeof int ?!?

Re: sizeof bool > sizeof int ?!?

[Mike Stump]

> Date: Thu, 20 Aug 1998 12:04:47 -0400
> From: Richard Hadsell <hadsell@blueskystudios.com>
> To: EGCS mailing list <egcs@cygnus.com>

> Richard Hadsell wrote:
> > 
> > > I realize that some (all?) alpha processors do not handle 1-byte data
> > > efficiently.  I hope that the situation will change with future
> > > versions.  But it's hard to believe that alphas don't have an efficient
> > > instruction set for (4-byte) int data.  What about short data?  Are they
> > > handled as badly as 1-byte data?
> > >
> > > I would prefer that bool be implemented with the best performance in
> > > mind, including the effects of using memory efficiently, too.
> > 
> > I haven't seen any comments from the compiler group on their decision to
> > implement bool as an 8-byte datum on alphas.  If the performance is so
> > much better that it is worth the cost in memory usage, why is an int
> > only 4 bytes.  Since the standard allows it to be as big as a long, why
> > not?  I thought that we could expect an int to be whatever size gives
> > the best integer performance.
> > 
> > So I don't understand why a bool is any longer than an int.  What other
> > considerations were there in making the decision?

> Comments anyone ?

No.  Well, ok, I wasn't going to comment, but let me make one meta
comment about this.  The most persuasive comment is one from a
benchmark type person that measures the performance in a couple of
different and realistic ways and makes a statement about the
performance characteristics, the rest of us can sit back and debate if
we want to blow the 5%, and save the space, and maybe be better to the
cache.

Random comments from random people that say `wow, man, 8 bytes instead
of one bit, sounds like a bug' is less interesting to me.

Re: sizeof bool > sizeof int ?!?

[Richard Hadsell]

Mike Stump wrote:
> 
> No.  Well, ok, I wasn't going to comment, but let me make one meta
> comment about this.  The most persuasive comment is one from a
> benchmark type person that measures the performance in a couple of
> different and realistic ways and makes a statement about the
> performance characteristics, the rest of us can sit back and debate if
> we want to blow the 5%, and save the space, and maybe be better to the
> cache.
> 
> Random comments from random people that say `wow, man, 8 bytes instead
> of one bit, sounds like a bug' is less interesting to me.

Agreed.  I expected that a compiler person working on the alpha version
would have measured or obtained some instruction timings in order to
calculate the performance of various ops needed to access bool data.

My only personal information relevant to the discussion comes from a DEC
person who seems to know a lot about their C++ compiler.  I expressed my
concern about how bool was implemented in C++ 6.0 (I'm still stuck with
5.7, which does not support bool), and I mentioned that EGCS g++ used
8-byte bool data.  He said that bool was just 1 byte in the DEC compiler
and that its performance was not a problem.  I don't know whether their
compiler uses some tricks that g++ folks have not thought of.  Perhaps
he means that on the EV56 or even EV6 the instruction timings are better
than on older processors.  Perhaps this person was mistaken.

If someone is sure that byte access is really slow on a particular
machine, then let's at least use a reasonably fast int instead of a
pointer size to select the bool size:

#define BOOL_TYPE_SIZE ((SLOW_BYTE_ACCESS) ? (SHORT_SIZE) :
(CHAR_TYPE_SIZE))

Or are shorts and ints also slow?  I don't hear anyone suggesting that
ints be implemented as 8 bytes for performance reasons.

That's all.  I'll live with whatever the EGCS folks do or don't do at
this point.

-- 
Dick Hadsell			914-381-8400 x5446 Fax: 914-381-9790
Reply-to:			hadsell@blueskystudios.com
Blue Sky | VIFX                 http://www.bluesky-vifx.com
1 South Road, Harrison, NY 10528

Re: sizeof bool > sizeof int ?!?

[Jeroen Dobbelaere]

Hi,

I once made a benchmark comparison of several compilers using bench++
for an embedded environment (MPC860).

One of the tests uses an array of bools. gcc (gnupro-97r1) suffered
a lot of the fact that it uses 4 bytes for a bool, compared to
the diab compiler which uses only one byte... (I don't have the values
any more since i moved to another company :( )
(another problem was, that this array was put on the stack so that the stack 
became very large)

Mike Stump wrote:
> 
> > Date: Thu, 20 Aug 1998 12:04:47 -0400
> > From: Richard Hadsell <hadsell@blueskystudios.com>
> > To: EGCS mailing list <egcs@cygnus.com>
> 
> > Richard Hadsell wrote:
> > >
> > > > I realize that some (all?) alpha processors do not handle 1-byte data
> > > > efficiently.  I hope that the situation will change with future
> > > > versions.  But it's hard to believe that alphas don't have an efficient
> > > > instruction set for (4-byte) int data.  What about short data?  Are they
> > > > handled as badly as 1-byte data?
> > > >
> > > > I would prefer that bool be implemented with the best performance in
> > > > mind, including the effects of using memory efficiently, too.
> > >
> > > I haven't seen any comments from the compiler group on their decision to
> > > implement bool as an 8-byte datum on alphas.  If the performance is so
> > > much better that it is worth the cost in memory usage, why is an int
> > > only 4 bytes.  Since the standard allows it to be as big as a long, why
> > > not?  I thought that we could expect an int to be whatever size gives
> > > the best integer performance.
> > >
> > > So I don't understand why a bool is any longer than an int.  What other
> > > considerations were there in making the decision?
> 
> > Comments anyone ?
> 
> No.  Well, ok, I wasn't going to comment, but let me make one meta
> comment about this.  The most persuasive comment is one from a
> benchmark type person that measures the performance in a couple of
> different and realistic ways and makes a statement about the
> performance characteristics, the rest of us can sit back and debate if
> we want to blow the 5%, and save the space, and maybe be better to the
> cache.
> 
> Random comments from random people that say `wow, man, 8 bytes instead
> of one bit, sounds like a bug' is less interesting to me.

sizeof bool > sizeof int ?!?

[Gerald Pfeifer]

I just compiled 
  
  #include <stdio.h>

  int main() {
      printf( "bool = %u\nshort = %u\nint = %u\nlong = %u\n",
              sizeof(bool), sizeof(short), sizeof(int), sizeof(long));
      return 0;
      }

with egcs-2.90.29 980515 (egcs-1.0.3 release) on alphaev56-dec-osf4.0d
and -- surprise, surprise! -- sizeof bool > sizeof int !?!

  bool  = 8
  short = 2
  int   = 4 
  long  = 8


I find it _very_ hard calling this a feature!

Even if it may be standards compliant, this is most surprising for
95%[1] of all developers.


If I remember correctly, Jason has suggested to make sizeof bool == 1
with a new API. Does anybody now the timeframe for this?

Gerald


[1] While we are at making up statistics on the egcs*-lists... :-)
-- 
Gerald Pfeifer (Jerry)      Vienna University of Technology
pfeifer@dbai.tuwien.ac.at   http://www.dbai.tuwien.ac.at/~pfeifer/

Re: sizeof bool > sizeof int ?!?

[Rask Ingemann Lambertsen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1135 bytes --]

Den 03-Jul-98 15:15:06 skrev Gerald Pfeifer følgende om "sizeof bool > sizeof int ?!?":

> with egcs-2.90.29 980515 (egcs-1.0.3 release) on alphaev56-dec-osf4.0d
> and -- surprise, surprise! -- sizeof bool > sizeof int !?!

>   bool  = 8
>   short = 2
>   int   = 4 
>   long  = 8

> I find it _very_ hard calling this a feature!

> Even if it may be standards compliant, this is most surprising for
> 95%[1] of all developers.

Possibly, but does it have any impact on the code? Apart form wasting huge
amounts of memory, that is?

Regards,

/¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯T¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯\
| Rask Ingemann Lambertsen       | E-mail: mailto:rask@kampsax.k-net.dk  |
| Registered Phase5 developer    | WWW: http://www.gbar.dtu.dk/~c948374/ |
| A4000, 775 kkeys/s (RC5-64)    | "ThrustMe" on XPilot, ARCnet and IRC  |
|                 Shakespeare, C Version: (0x2B | ~0x2B)                 |

Re: sizeof bool > sizeof int ?!?

[Gary V. Vaughan]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]

On Sun, Jul 05, 1998 at 11:55:31AM +0200, Rask Ingemann Lambertsen wrote:
> Den 03-Jul-98 15:15:06 skrev Gerald Pfeifer følgende om "sizeof bool > sizeof int ?!?":
> 
> > with egcs-2.90.29 980515 (egcs-1.0.3 release) on alphaev56-dec-osf4.0d
> > and -- surprise, surprise! -- sizeof bool > sizeof int !?!
> 
> >   bool  = 8
> >   short = 2
> >   int   = 4 
> >   long  = 8
> 
> > I find it _very_ hard calling this a feature!
> 
> > Even if it may be standards compliant, this is most surprising for
> > 95%[1] of all developers.
> 
> Possibly, but does it have any impact on the code? Apart form wasting huge
> amounts of memory, that is?

IIRC, the AXP series handle 64bit words faster than 32bit words due to
register width and/or instruction set.

Certainly code will run faster on most 32bit architectures using int's
(32 bits) rather than char's (8 bits), so it makes sense to use, e.g.

typedef int bool;

my £0.005 =)O|

Cheers,
-- 
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia

iQCVAwUBNaCKZaEk4wryQAQBAQGqDQP+O3Pz3DmcLR7N5xeNxf7jHrORzfnOqwD/
L1wSu25ViBCG+4+aqyzu8e9tAmdFZmvUec0jPPCtN+l1IbTPQ75X4FQW11SQM1U0
YwonoRKWYMN570os6Bis+cxqL76rwTTb7beR6ImfREioXof7I2X+log3IAi5wwTy
5bF90Ooy5Fo=
=njyg
-----END PGP SIGNATURE-----

Re: sizeof bool > sizeof int ?!?

[Per Bothner]

> Certainly code will run faster on most 32bit architectures using int's
> (32 bits) rather than char's (8 bits), so it makes sense to use, e.g.
> typedef int bool;

Why stop there?  We should by the same argument:

    typedef int short;

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: sizeof bool > sizeof int ?!?

[Gary V. Vaughan]

Per Bothner wrote:
> 
> > Certainly code will run faster on most 32bit architectures using int's
> > (32 bits) rather than char's (8 bits), so it makes sense to use, e.g.
> > typedef int bool;
> 
> Why stop there?  We should by the same argument:
> 
>     typedef int short;

Surely you mean

#define short int

??? =)O|

...but yes, bizarre though it may sound, using shorts is a trading speed
for space (modulo the architecture instruction set), except perhaps in
the pedagogical case quoted earlier in the thread where the
proliferation of register width words in place of narrower types causes
additional page faults...

short array[10000];

anyone?

OTOH, please correct me if I am grossly misinformed.

Cheers,
	Gary V. Vaughan
begin:          vcard
fn:             Gary Vaughan
n:              Vaughan;Gary
org:            Aethos Communication Systems ltd.
email;internet: gvaughan@oranda.demon.co.uk
tel;work:       01454 - 204411
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard

Re: sizeof bool > sizeof int ?!?

[Richard Hadsell]

Rask Ingemann Lambertsen wrote:
> 
> Possibly, but does it have any impact on the code? Apart form wasting huge
> amounts of memory, that is?

Yes.  When our application has 100,000+ objects, the increase in memory
also raises the working set significantly.  That is, cache and paging
activity increases, so the application performance decreases.

I realize that some (all?) alpha processors do not handle 1-byte data
efficiently.  I hope that the situation will change with future
versions.  But it's hard to believe that alphas don't have an efficient
instruction set for (4-byte) int data.  What about short data?  Are they
handled as badly as 1-byte data?

I would prefer that bool be implemented with the best performance in
mind, including the effects of using memory efficiently, too.

-- 
Dick Hadsell			914-381-8400  Fax: 914-381-9790
Reply-to:			hadsell@blueskystudios.com
Blue Sky | VIFX			http://www.blueskystudios.com
1 South Road, Harrison, NY 10528

Re: sizeof bool > sizeof int ?!?

[Richard Hadsell]

Richard Hadsell wrote:
> 
> I realize that some (all?) alpha processors do not handle 1-byte data
> efficiently.  I hope that the situation will change with future
> versions.  But it's hard to believe that alphas don't have an efficient
> instruction set for (4-byte) int data.  What about short data?  Are they
> handled as badly as 1-byte data?
> 
> I would prefer that bool be implemented with the best performance in
> mind, including the effects of using memory efficiently, too.

I haven't seen any comments from the compiler group on their decision to
implement bool as an 8-byte datum on alphas.  If the performance is so
much better that it is worth the cost in memory usage, why is an int
only 4 bytes.  Since the standard allows it to be as big as a long, why
not?  I thought that we could expect an int to be whatever size gives
the best integer performance.

So I don't understand why a bool is any longer than an int.  What other
considerations were there in making the decision?

-- 
Dick Hadsell			914-381-8400 x5446 Fax: 914-381-9790
Reply-to:			hadsell@blueskystudios.com
Blue Sky | VIFX                 http://www.bluesky-vifx.com
1 South Road, Harrison, NY 10528

Re: sizeof bool > sizeof int ?!?

[Richard Hadsell]

Richard Hadsell wrote:
> 
> > I realize that some (all?) alpha processors do not handle 1-byte data
> > efficiently.  I hope that the situation will change with future
> > versions.  But it's hard to believe that alphas don't have an efficient
> > instruction set for (4-byte) int data.  What about short data?  Are they
> > handled as badly as 1-byte data?
> >
> > I would prefer that bool be implemented with the best performance in
> > mind, including the effects of using memory efficiently, too.
> 
> I haven't seen any comments from the compiler group on their decision to
> implement bool as an 8-byte datum on alphas.  If the performance is so
> much better that it is worth the cost in memory usage, why is an int
> only 4 bytes.  Since the standard allows it to be as big as a long, why
> not?  I thought that we could expect an int to be whatever size gives
> the best integer performance.
> 
> So I don't understand why a bool is any longer than an int.  What other
> considerations were there in making the decision?

Comments anyone ?

-- 
Dick Hadsell			914-381-8400 x5446 Fax: 914-381-9790
Reply-to:			hadsell@blueskystudios.com
Blue Sky | VIFX                 http://www.bluesky-vifx.com
1 South Road, Harrison, NY 10528

Re: sizeof bool > sizeof int ?!?

[Per Bothner]

The last time this came up, I lobbied for making sizeof(bool)
be 1 byte.  I see little reason for making sizeof(bool) > sizeof(short),
yet no-one argues for making sizeof(short) be 4 or 8 on any system,
even though it would be consistent with standards, and probably
more efficient.  The thing is that people *expect* sizeof(short)
to be 2, and changing that would break some code, and make other
code be unacceptably bloated.

Well, guess what?  I think most programmers *expect* sizeof(bool)
to be 1 - but we are violating their very reasonable expectation.

What we really want is for bool in arrays and structs to be 1 byte,
but bool as a standalone variable to be whatever is fastest,
or at least the compiler to act as if it were.  Last time around
I was told that Gcc actualy does have the mechanism for something
like that - basically use full-words registers for bool local
variables.  It was also suggested this would remove most of
the speed penalty of making bool be 1 byte.

Note we also have a framework for making incomaptible changes:
-fnew-abi.  So I see no reason for not changing sizeof(bool) to 1
in the new ABI.  (This assumes the back-end people can help
with whatever magic flags are needed to making this faster.)

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: sizeof bool > sizeof int ?!?

[Gerald Pfeifer]

On Thu, 20 Aug 1998, Per Bothner wrote:
> The last time this came up, I lobbied for making sizeof(bool)
> be 1 byte.  I see little reason for making sizeof(bool) > sizeof(short)
> [...]
> Well, guess what?  I think most programmers *expect* sizeof(bool)
> to be 1 - but we are violating their very reasonable expectation.

I just checked and GCC 2.95.2 and Alpha still has sizeof bool == 8,
even with -fnew-api!

> Note we also have a framework for making incomaptible changes:
> -fnew-abi.  So I see no reason for not changing sizeof(bool) to 1
> in the new ABI.

Is there any chance this get's change, at least when we change the ABI?
I mean, at the very least this should be reduced to sizeof int!

And Mike Mike Stump <mrs@wrs.com> wrote:
> No.  Well, ok, I wasn't going to comment, but let me make one meta
> comment about this.  The most persuasive comment is one from a
> benchmark type person that measures the performance in a couple of
> different and realistic ways and makes a statement about the
> performance characteristics, the rest of us can sit back and debate if
> we want to blow the 5%, and save the space, and maybe be better to the
> cache.

Well, I *did* benchmarks back then with an AI system where I am one of the
developers, and there the difference was incredible:

We used lots of medium sized arrays of bool (with a couple of thousand
elements each) and an average alpha started swaping like crazy, until we
ran out of memory. Once we switched to arrays of char, our code became
significantly faster and consumed less than 100MB.


Again, there may be reasons not to bring down sizeof bool to 1 on that
platform, but sizeof bool > sizeof int is really, really weird! :-/

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: sizeof bool > sizeof int ?!?

[Mark Mitchell]

>>>>> "Gerald" == Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

    Gerald> On Thu, 20 Aug 1998, Per Bothner wrote:
    >> The last time this came up, I lobbied for making sizeof(bool)
    >> be 1 byte.  I see little reason for making sizeof(bool) >
    >> sizeof(short) [...]  Well, guess what?  I think most
    >> programmers *expect* sizeof(bool) to be 1 - but we are
    >> violating their very reasonable expectation.

    Gerald> I just checked and GCC 2.95.2 and Alpha still has sizeof
    Gerald> bool == 8, even with -fnew-api!

The IA64 C++ ABI specifies that the size and alignment of `bool' are
one.  Efficiency aside, that's what everyone expects `bool' to be, and
that's what it will be with -fnew-abi in the very near future.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: sizeof bool > sizeof int ?!?

[Mark Mitchell]

>>>>> "Gerald" == Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

    Gerald> On Thu, 20 Aug 1998, Per Bothner wrote:
    >> The last time this came up, I lobbied for making sizeof(bool)
    >> be 1 byte.  I see little reason for making sizeof(bool) >
    >> sizeof(short) [...]  Well, guess what?  I think most
    >> programmers *expect* sizeof(bool) to be 1 - but we are
    >> violating their very reasonable expectation.

    Gerald> I just checked and GCC 2.95.2 and Alpha still has sizeof
    Gerald> bool == 8, even with -fnew-api!

The IA64 C++ ABI specifies that the size and alignment of `bool' are
one.  Efficiency aside, that's what everyone expects `bool' to be, and
that's what it will be with -fnew-abi in the very near future.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: sizeof bool > sizeof int ?!?

[Gerald Pfeifer]

On Thu, 20 Aug 1998, Per Bothner wrote:
> The last time this came up, I lobbied for making sizeof(bool)
> be 1 byte.  I see little reason for making sizeof(bool) > sizeof(short)
> [...]
> Well, guess what?  I think most programmers *expect* sizeof(bool)
> to be 1 - but we are violating their very reasonable expectation.

I just checked and GCC 2.95.2 and Alpha still has sizeof bool == 8,
even with -fnew-api!

> Note we also have a framework for making incomaptible changes:
> -fnew-abi.  So I see no reason for not changing sizeof(bool) to 1
> in the new ABI.

Is there any chance this get's change, at least when we change the ABI?
I mean, at the very least this should be reduced to sizeof int!

And Mike Mike Stump <mrs@wrs.com> wrote:
> No.  Well, ok, I wasn't going to comment, but let me make one meta
> comment about this.  The most persuasive comment is one from a
> benchmark type person that measures the performance in a couple of
> different and realistic ways and makes a statement about the
> performance characteristics, the rest of us can sit back and debate if
> we want to blow the 5%, and save the space, and maybe be better to the
> cache.

Well, I *did* benchmarks back then with an AI system where I am one of the
developers, and there the difference was incredible:

We used lots of medium sized arrays of bool (with a couple of thousand
elements each) and an average alpha started swaping like crazy, until we
ran out of memory. Once we switched to arrays of char, our code became
significantly faster and consumed less than 100MB.


Again, there may be reasons not to bring down sizeof bool to 1 on that
platform, but sizeof bool > sizeof int is really, really weird! :-/

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: sizeof bool > sizeof int ?!?

[Richard Henderson]

On Thu, Aug 20, 1998 at 12:04:47PM -0400, Richard Hadsell wrote:
> > So I don't understand why a bool is any longer than an int.  What other
> > considerations were there in making the decision?
> 
> Comments anyone ?

You are reading too much into this.  No decision was made at all. 
The default chosen by the C++ front end is

#define BOOL_TYPE_SIZE ((SLOW_BYTE_ACCESS) ? (POINTER_SIZE) : (CHAR_TYPE_SIZE))

To change it now though would break ABI compatibility.  If people
care so much, it could perhaps be keyed to -fnew-abi.


r~