public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeroen Dobbelaere <Jeroen.Dobbelaere@tvd.be>
To: Mike Stump <mrs@wrs.com>
Cc: egcs@cygnus.com, hadsell@blueskystudios.com
Subject: Re: sizeof bool > sizeof int ?!?
Date: Sat, 22 Aug 1998 07:32:00 -0000	[thread overview]
Message-ID: <35DED864.588EA76A@tvd.be> (raw)
In-Reply-To: <199808220104.SAA21655@kankakee.wrs.com>

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.

  parent reply	other threads:[~1998-08-22  7:32 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-08-21 19:47 Mike Stump
1998-08-21 19:47 ` Richard Hadsell
1998-08-22  7:32 ` Jeroen Dobbelaere [this message]
  -- strict thread matches above, loose matches on Subject: below --
1998-07-03  6:15 Gerald Pfeifer
1998-07-05  2:58 ` Rask Ingemann Lambertsen
1998-07-06  4:08   ` Gary V. Vaughan
1998-07-09 12:13     ` Per Bothner
1998-07-10  6:04       ` Gary V. Vaughan
1998-07-06 14:48   ` Richard Hadsell
1998-08-13 17:47     ` Richard Hadsell
1998-08-20  9:57       ` Richard Hadsell
1998-08-20 20:37         ` Per Bothner
1999-12-18 17:14           ` Gerald Pfeifer
1999-12-18 17:39             ` Mark Mitchell
1999-12-31 23:54               ` Mark Mitchell
1999-12-31 23:54             ` Gerald Pfeifer
1998-08-20 20:37         ` Richard Henderson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=35DED864.588EA76A@tvd.be \
    --to=jeroen.dobbelaere@tvd.be \
    --cc=egcs@cygnus.com \
    --cc=hadsell@blueskystudios.com \
    --cc=mrs@wrs.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).