linux-c-programming.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Steve Graegert" <graegerts@gmail.com>
To: linux-c-programming@vger.kernel.org
Subject: Re: Disadvantage of using long long int
Date: Wed, 22 Feb 2006 20:09:27 +0100	[thread overview]
Message-ID: <6a00c8d50602221109i40f9947do5754467e2b918c26@mail.gmail.com> (raw)
In-Reply-To: <17404.45980.455312.5228@cerise.gclements.plus.com>

On 2/22/06, Glynn Clements <glynn@gclements.plus.com> wrote:
>
> Steve Graegert wrote:
>
> > > In terms of performance and raw speed, is there any disadvantage of using
> > > "long long int" instead of "long int", "long double" instead of "double" on
> > > 32-bit machine ? Are there any other disadvantage that I should consider?
> >
> > On 32-bit Intel machines a long long int (64 bits) is usually not the
> > same as a long int (32 bits), the same is true for double (64 bits,
> > IEEE754) and long double (96 bits, IEEE845).
>
> In C99 (ISO-IEC 9899:1999), long double is supposed to be one of the
> two ISO-IEC 60559 extended formats, which are 80 or 128 bits. On x86,
> it's usually 80 bits.

x86 ABI defines long double 12 Bytes of size (96 bits) on x86.  80
bits for precision, 12 bits is padding, totalling for 96 bits of size.
 It _can_ be put in a 128 bit container to preserve alignment.  The
compilers default to 96-bit but gcc has an option to pad out to 128bit
(-m128bit-long-double) resulting in a gain of performance with IA64
but slower speed on x86 due to software emulation.

> > BTW long long int is a GNU extension and subject to portability.
>
> long long int is part of the C99 standard.

Ok, thanks.

	\Steve

      reply	other threads:[~2006-02-22 19:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-22 17:35 Disadvantage of using long long int Reuben D. Budiardja
2006-02-22 17:46 ` Glynn Clements
2006-02-22 17:54 ` Steve Graegert
2006-02-22 18:55   ` Glynn Clements
2006-02-22 19:09     ` Steve Graegert [this message]

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=6a00c8d50602221109i40f9947do5754467e2b918c26@mail.gmail.com \
    --to=graegerts@gmail.com \
    --cc=linux-c-programming@vger.kernel.org \
    /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 NNTP newsgroup(s).