Hi all,

Does long long and unsigned long long types achive worst performance
when compiled on x86 platform (Visual C++ Express Edition)? All modern
CPUs have 64 bit registers, so I suppose that calculations wouldn't
suffer using 64 bit integer values on x86 platforms. I am right?
Are long long and unsigned long long part of the standard (C/C++)?

Thank you all for help :-P

{ Fact: They are part of the latest C standard -- ISO/IEC 9899:1999,
  casually known as "C99". They are NOT part of the current C++
  standard -- ISO/IEC 14882:2003, a.k.a. "C++03", though they are
  expected to be included in the next version, a.k.a. "C++0x". -mod/sk }

-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

On 11 Jun., 03:23, danilobrambi...@tiscali.it wrote:
>
> Does long long and unsigned long long types achive worst performance
> when compiled on x86 platform (Visual C++ Express Edition)? All modern
> CPUs have 64 bit registers, so I suppose that calculations wouldn't
> suffer using 64 bit integer values on x86 platforms. I am right?

It also depends on your operating system and whether your CPU is in
32bit mode or 64bit mode. In 32bit mode the compiler doesn't use those
64bit registers AFAICT.

> Are long long and unsigned long long part of the standard (C/C++)?

C90: no.
C99: yes.
C++: not yet officially.

You may also consider using the header stdint.h and its typedefs. It's
also not yet officially part of C++ but many compilers support those
C99 extensions.

Cheers!
SG

-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

danilobrambilla@tiscali.it wrote:
> Hi all,
> 
> Does long long and unsigned long long types achive worst performance
> when compiled on x86 platform (Visual C++ Express Edition)? All modern
> CPUs have 64 bit registers, so I suppose that calculations wouldn't
> suffer using 64 bit integer values on x86 platforms. I am right?

The x86 platform is 32 bit, so if you use long long (size depends on
your compiler and platform: here 64 bit) your code will be at best equal
fast to code using 32 bit integers, but more likely it will be slower.

The situation changes on the x64 platform, where long long fits into a
register. Your x64 code which uses long long will be commonly faster
than x86 code which uses long long.
However due to the rather large size of long long even on the x64
platform >may be< slower than long integers, due to the memory latency
when the registers have to be passed by stack or stored in memory (e.g.
vector<long long>).

To be sure about the performance of your code, either profile it or have
a look at the generated assembly code. Things may change depending on
the compiler and the platform you compile for.

> Are long long and unsigned long long part of the standard (C/C++)?

Long long is part of the C standard. AFAIK it is part of the upcoming
C++0x standard. But I'm not 100% sure about that.

VC supports the proprietary __int64 integer, which will be always 64 bit.

By the way I don't know why C/C++ uses multiple keywords for a single
type. Generally I would prefer single keywords:

unsigned long long a = 0;

are far to much characters to type for a lazy C++ developer ;-)



> Thank you all for help :-P
> 

Hope it helped,
Andre

-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

danilobrambilla@tiscali.it wrote:
> Hi all,
>
> Does long long and unsigned long long types achive worst performance
> when compiled on x86 platform (Visual C++ Express Edition)? All
> modern CPUs have 64 bit registers, so I suppose that calculations
> wouldn't suffer using 64 bit integer values on x86 platforms. I am
> right?

The answer is, of course, "it depends" on several levels.

If you are using a 32 bit operating system, or a 32 bit compiler (like
the Express Edition), you don't have access to the "64-bittedness" of
the hardware. It still runs in 32 bit compatibility mode.

On the other hand, even when you have access to 64 bit registers, the
operations on long long require an additional byte in the instructions
and uses more space in the data cache. So it is no faster than using
an int.

However, if you really need the extra range of values provided by the
wider data types, it is likely a win over using two 32-bit operations.

> Are long long and unsigned long long part of the standard (C/C++)?

They are part of the current C standard (C99), but not yet part of the
C++ standard. They will be soon, though.


Bo Persson



-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Thank you all for answers.

> It also depends on your operating system

Target Operating System is now Windows x86, but I am interested in
write a portable code if possible.

> The situation changes on the x64 platform, where long long fits into a
> register. Your x64 code which uses long long will be commonly faster
> than x86 code which uses long long.

Does this means that also calculations may be done in two steps in x86
(first high/low order 32 bits then the remaining?) or the problem may
be related only when transferring data?

Best regards, Danilo

-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

On 11 June, 02:23, danilobrambi...@tiscali.it wrote:
> Hi all,
>
> Does long long and unsigned long long types achive worst performance
> when compiled on x86 platform (Visual C++ Express Edition)? All modern
> CPUs have 64 bit registers, so I suppose that calculations wouldn't
> suffer using 64 bit integer values on x86 platforms. I am right?
> Are long long and unsigned long long part of the standard (C/C++)?
>
> Thank you all for help :-P
>
> { Fact: They are part of the latest C standard -- ISO/IEC 9899:1999,
>   casually known as "C99". They are NOT part of the current C++
>   standard -- ISO/IEC 14882:2003, a.k.a. "C++03", though they are
>   expected to be included in the next version, a.k.a. "C++0x". -mod/sk }

{ quoted clc++m banner removed - please do it yourself. -mod }

Performance of calculations on "big" integers will depend at least in
part on what the calculations actually are - addition and subtraction
are going to be fast however they are done and contrariwise
multiplication and division are likely to be relatively slow whether
done in 32 or 64 bits underlying architecture.

I've been playing with Lua recently and I think that I've probably
seen the future - In Lua ALL arithmetic is in IEEE 64 bit float. The
reasoning is that modern floating point units are the fastest way to
do the hard maths anyway and you're still getting 53 bit exact
integers which covers almost all real world integer values.

I'm not saying that that is how C++ will or should go (I doubt that
the Lua implementation is all float) but it does expose the
pointlessness of some discussions about integer sizes and performance.


-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

LiloLilo wrote:
> Thank you all for answers.
>
>> It also depends on your operating system
>
> Target Operating System is now Windows x86, but I am interested in
> write a portable code if possible.
>
>> The situation changes on the x64 platform, where long long fits
>> into a register. Your x64 code which uses long long will be
>> commonly faster than x86 code which uses long long.
>
> Does this means that also calculations may be done in two steps in
> x86 (first high/low order 32 bits then the remaining?) or the
> problem may be related only when transferring data?
>

Considering that the current hardware is capable of doing several
instructions in parallel (multi-issue, out-of-order execution), even
if a 64 bit operation is performed as several 32 bit operations, these
might actually be performed at the same time.


Bo Persson


-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

LiloLilo wrote:
> Thank you all for answers.
> 
>> It also depends on your operating system
> 
> Target Operating System is now Windows x86, but I am interested in
> write a portable code if possible.

Portability is a different target than performance. IMHO if you increase
performance, you will decrease the portability of the code or the code
is only optimized for a single platform.

Generally I wouldn't care about (code) performance that much. Care more
about your algorithms / libraries. A slow algorithm which uses optimized
code is still slower than a fast algorithm using non optimized code.

E.g. writing large data using C-functions/OS-functions will be (in my
experience) >much faster< than using iostreams. However, if you use
OS-functions the code isn't that portable anymore.

Regarding portability you should only care about pointer operations and
binary data, which may be exchanged with other applications under
different platforms.

>> The situation changes on the x64 platform, where long long fits into a
>> register. Your x64 code which uses long long will be commonly faster
>> than x86 code which uses long long.
> 
> Does this means that also calculations may be done in two steps in x86
> (first high/low order 32 bits then the remaining?) or the problem may
> be related only when transferring data?

Yes. Many 64 bit calculations must be divided into 2 or more steps under
x86. Since you will always have memory transactions involved to load /
store results in registers x64 code will be only faster if more
calculations can be done in registers (more registers are available) and
passed through registers (x64 Windows code uses register calling
convention - __fastcall) - or - the big advantage of the x64 platform -
if more memory is available for an application which uses much memory.

But as I wrote above, you should only optimize relevant parts of your
code and optimize central algorithms (80:20 rule).
Let the compiler do it's task to generate optimized code and use only 64
bit data (stored in memory / storage devices) if you really require the
larger size.

> Best regards, Danilo

Best regards,
Andre


-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Nick Hounsome wrote:

> 
> I've been playing with Lua recently and I think that I've probably
> seen the future - In Lua ALL arithmetic is in IEEE 64 bit float. The
> reasoning is that modern floating point units are the fastest way to
> do the hard maths anyway and you're still getting 53 bit exact
> integers which covers almost all real world integer values.
> 
> I'm not saying that that is how C++ will or should go (I doubt that
> the Lua implementation is all float) but it does expose the
> pointlessness of some discussions about integer sizes and performance.
> 
But there is nothing to prevent a C++ implementation doing the same thing.

-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

On Jun 11, 7:28 am, Andre Kaufmann <akfmn...@t-online.de> wrote:
> unsigned long long a = 0;
>
> are far to much characters to type for a lazy C++ developer ;-)

There's always typedef unsigned long long ull; :-).

There's a long history in C and C++ of avoiding adding keywords to the
language.

David


-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

dbradley wrote:
> On Jun 11, 7:28 am, Andre Kaufmann <akfmn...@t-online.de> wrote:
>> unsigned long long a = 0;
>>
>> are far to much characters to type for a lazy C++ developer ;-)
> 
> There's always typedef unsigned long long ull; :-).

Yes, but therefore I have to include a common header everywhere and
since it's not a standard IMHO the code will be hard to read (for other
developers) if standard types are replaced by typedefs.

> There's a long history in C and C++ of avoiding adding keywords to the
> language.

There's also a long history avoiding context sensitive keywords.
Although in this context I feel somewhat it to be a bad joke, no new
keywords, but a single type split into 3 keywords ;-) to prevent the
introduction of new keywords.

Besides, IIRC C/C++ has had "unsigned int" in it's first standard. So
keywords alone shouldn't have been the main reason to split up types
into two keywords.

> David

Andre


-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

On Fri, 12 Jun 2009 17:21:57 CST, dbradley <dbradley@gmail.com> wrote:
> On Jun 11, 7:28 am, Andre Kaufmann <akfmn...@t-online.de> wrote:
>> unsigned long long a = 0;
>>
>> are far to much characters to type for a lazy C++ developer ;-)
>
> There's always typedef unsigned long long ull; :-).

If what he wants is an unsigned 64-bit type, he should call it
uint64_t, not ull.  If that name isn't already defined in his
environment, it *will* be in a few years.

(I had to mention it -- if I encounter one more non-standard or
project-specific ULONG/U32/u_int32_t/u32/foo_uint32_t/... typedef,
I will scream ...)

/Jorgen

-- 
   // Jorgen Grahn <grahn@        Ph'nglui mglw'nafh Cthulhu
\X/     snipabacken.se>          R'lyeh wgah'nagl fhtagn!

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

On Jun 13, 6:55 pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
> (I had to mention it -- if I encounter one more non-standard or
> project-specific ULONG/U32/u_int32_t/u32/foo_uint32_t/... typedef,
> I will scream ...)

Yeah, I agree. If you're really going to typedef something like that,
make it something informative and useful. Such as typedef unsigned int
AccountNumber;

Another pet peeve of mine is people who encode type into their
typedefs. A simplistic example typedef std::vector<std::string>
StringVector.

I didn't really intend the ull as a real alternative, though I guess
it came off like that.

David


-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]