Hello,

Visual Studio 2008/CPP:

64 bit integers twice as slow as 64 bit doubles (on x64) ?

Here is a little benchmark:

When set to debug it works ok, when set to release configuration it 
malfunctions ??? Huh ?

Something strange happens and it only take 7 ticks or so... while normally 
it takes 5 million ticks ?

Weird.

Why are 64 bit integers so slow ?

// Test64BitPerformance.cpp : Defines the entry point for the console 
application.
//
#include "stdafx.h"
#include "windows.h"

long long TestSimulatedInt64Performance()
{
int vIndex;
long long a;
long long b;
long long c;
a = 0;
b = 1;
c = 2;
for (vIndex = 0; vIndex < 10 * 1024 * 1024; vIndex++)
{
// additions faster with simulated int than doubles
a = a + 1;
b = b + 1;
c = c + 1;
// multiplications slower with simulated int than doubles
a = a * 5;
b = b * 5;
c = c * 5;
// divisions slower with simulated int than doubles
a = a / 5;
b = b / 5;
c = c / 5;
a = a + b;
b = b + c;
c = c + a;
// subtractions probably faster just like additions (not really tested :))
a = a - a;
b = b - b;
c = c - c;
}
return a + b + c;
}
double TestDoublePerformance()
{
int vIndex;
double a;
double b;
double c;
a = 0;
b = 1;
c = 2;
for (vIndex = 0; vIndex < 10 * 1024 * 1024; vIndex++)
{
a = a + 1;
b = b + 1;
c = c + 1;
a = a * 5;
b = b * 5;
c = c * 5;
a = a / 5;
b = b / 5;
c = c / 5;
a = a + b;
b = b + c;
c = c + a;
a = a - a;
b = b - b;
c = c - c;
}
return a + b + c;
}


int _tmain(int argc, _TCHAR* argv[])
{
LARGE_INTEGER Tick1;
LARGE_INTEGER Tick2;
int vLoop;
for (vLoop=1; vLoop <= 10; vLoop++)
{
Sleep( 1000 );
QueryPerformanceCounter( &Tick1 );
TestSimulatedInt64Performance();
QueryPerformanceCounter( &Tick2 );
printf( "Simulated Int64 Ticks: %lld \n", Tick2.QuadPart-Tick1.QuadPart );
Sleep( 1000 );
QueryPerformanceCounter( &Tick1 );
TestDoublePerformance();
QueryPerformanceCounter( &Tick2 );
printf( "Double Ticks: %lld \n", Tick2.QuadPart-Tick1.QuadPart );
}
getchar();

return 0;
}

Bye,
  Skybuck.

Integer 64-bit pipeline back-to-back issue delay:
Add/Sub: 1 cycle scalarity 3/cycle
Mul: 5 cycles scalarity 1/cycle
Div: 67 cycles scalarity 1/cycle

Float 64-bit pipeline back-to-back issue delay
Add/Sub: 1 cycle scalarity 1/cycle
Mul: 1 cycle scalarity 1/cycle
Div: 17 cycles scalarity 1/cycle shared with FMul.

Divide is eating your lunch, and multiply is not doing you any favors.
In Barcelona, int div comes down into the 20-odd cycle range thanks to
dedicated int div circuitry.

Mitch

Ok interesting.

What about other instructions like:

xor, and, or, compare, not, shr, shl, and ofcourse mov :) ?

Bye,
  Skybuck.

MitchAlsup wrote:
> Integer 64-bit pipeline back-to-back issue delay:
> Add/Sub: 1 cycle scalarity 3/cycle
> Mul: 5 cycles scalarity 1/cycle
> Div: 67 cycles scalarity 1/cycle

The divide time is long enough that it could be feasible to make some 
interesting workarounds:

I'm willing to bet that nearly all divisors will actually fit inside 53 
bits, not needing those last 11 mantissa bits, in which case...
> 
> Float 64-bit pipeline back-to-back issue delay
> Add/Sub: 1 cycle scalarity 1/cycle
> Mul: 1 cycle scalarity 1/cycle
> Div: 17 cycles scalarity 1/cycle shared with FMul.

... a 17-cycle fp divide might do a pretty good job!

In fact, since using the fp divider will require a fixup step anyway, 
why not go all the way and start by calculating an approximate 
reciprocal, then use that in a two-stage process to generate the exact 
answer?

If you can setup your code to do two or four of these divisions at the 
same time, with independent divisors, then you can use the SSE 12-bit 
1/x lookup opcode, one NR iteration to get ~float precision, then 
convert to double and do another iteration for near double precision.

Multiply the dividend by this ~50-bit reciprocal, convert to integer, 
back-multiply and subtract.

One more iteration like this and you have four exact results, probably 
in close to the same time as a single 64-bit DIV opcode. :-)

> Divide is eating your lunch, and multiply is not doing you any favors.
> In Barcelona, int div comes down into the 20-odd cycle range thanks to
> dedicated int div circuitry.

At which point tricky code becomes less useful.

Terje
> 
> Mitch


-- 
- 
"almost all programming can be viewed as an exercise in caching"

On Mar 10, 3:06 pm, "Skybuck Flying"  wrote:
> Here is a little benchmark:
>
> When set to debug it works ok, when set to release configuration it
> malfunctions ??? Huh ?
>
> Something strange happens and it only take 7 ticks or so... while normally> it takes 5 million ticks ?
>
> Weird.


Undoubtedly when you turn optimization on, the compiler removes all
the code in the loops once it figures out it doesn't actually do
anything.  Verify that by asking for the assembler output in either
case.

> Undoubtedly when you turn optimization on, the compiler removes all
> the code in the loops once it figures out it doesn't actually do
> anything.

Oh it should do quite a lot:

1. Do calculations like I told it too.

2. Consume cpu cycles like I told it too ;)

3. Consume electricity like I told it too.

4. Generate heat like I told it too :)

I am cold I neat the heat ;)

> Verify that by asking for the assembler output in either
> case.

Not possible for release configuration ?

Only debug configurations are able to show disassemblies ???

Bye,
  Skybuck.

On Mar 10, 9:36 pm, "Skybuck Flying"  wrote:
> > Verify that by asking for the assembler output in either
> > case.
>
> Not possible for release configuration ?
>
> Only debug configurations are able to show disassemblies ???


You have to set the properties separately for the two build types
(select the build type, then set the compiler options).  Or just
compile from the command line with the appropriate switches.

Possibility 1, works:

Project Properties->Configuration Properties->C/C++->Output Files->Assembler 
Output:

Assembly With Source Code (/FAs)

*.asm files will be generated.

Open them with an editor.

Possibility 2, does not work:

Debug->Start Debugging

Debug->Windows->Disassembly.

(Disassembly cannot be displayed in run mode.)

Strange.

Bye,
  Skybuck.

On Tue, 11 Mar 2008 14:42:25 -0000, Skybuck Flying   
wrote:

> Possibility 2, does not work:
>
> Debug->Start Debugging
> Debug->Windows->Disassembly.
> (Disassembly cannot be displayed in run mode.)
>
> Strange.

Not really. The disassembly window normally tracks EIP, which would
be rather difficult when running. If you stop at a breakpoint then
you'll find the disassembly window is available.

Ok,

Now I understand what the problem was.

Because both functions are optimized away, breakpoints don't work on that 
code.

So I have to place a breakpoint somewhere else and then it works.

Bye,
  Skybuck.

Notice how identation is lost when copy&pasting from Visual Studio 2008...

Bye,
  Skybuck