OJ Board

Recently I purchased a new machine with an AMD64 processor and installed Ubuntu AMD64 on it, together with the latest version of gcc (which can compile to 64 bit code).

1. Does anyone know if gcc compiles into 64 bit code by default ($ gcc prog.c) or do I have to add a switch to the command line?

2. Since the type 'int' is supposed to be the default machine word, is it now 64 bits long? If I print sizeof(int) it returns 4, which would suggest 32 bits. sizeof(long long) returns 8, so it is 64 bits, not 128 or higher.

3. If an 'int' is 32 bits and a 'long long' 64 bits, is the int type now actually slower to use than a long long type, since the processor only accesses 64 bit chunks in memory, and has to mask and shift to access a 32 bit entity? (Just like 8 and 16 bit entities on a 32 bit machine).

4. What is the size of the 'truth type' (bool in C++), in other words, is there coercion if I assign (a==b) to an int type? (int t=(a==b);).

Just curious, but there might be a big impact if the judge switches to a 64 bit machine and the size of an int would change. Lots of peoples' answers to problems depend on the fact that an int is 32 bits, including some of mine (even though I know it is bad programming practice :) ).

1. It compiles to whatever architecture your system has.
2. No, it's still 32-bit. Note that longs are now 64-bit, though.
3. No. But why don't you write a simple benchmark and tell us?
4. Whatever sizeof(bool) prints out. Most likely it will be 1 byte.

Thanks.
Good to know longs are 64 bits now, so sizeof(long) is a decider between 32 and 64 bit code for gcc.
I did the benchmarks, and assignment, addition and multiplication are (almost) equally fast for ints, longs and long longs.
About the bool type: there isn't one in C, only an implicit one, that's why I asked. sizeof(1==0) returns 4, so I guess an int is used.

Talking about benchmarks:
division using 64 bit doubles is about 2.5 times faster than using 32 bit ints;
division using 128 bit long doubles is also about 2.5 faster than using 64 bit longs and about 1.5 times slower than using 64 bit doubles. At least on my processor (AMD 64 X2 3800+).

Can I safely assume that the guys at AMD put more effort in optimizing their math co-processor than their main core? Or is that nonsense.

little joey wrote:Thanks.
Talking about benchmarks:
division using 64 bit doubles is about 2.5 times faster than using 32 bit ints;
division using 128 bit long doubles is also about 2.5 faster than using 64 bit longs and about 1.5 times slower than using 64 bit doubles. At least on my processor (AMD 64 X2 3800+).

Can I safely assume that the guys at AMD put more effort in optimizing their math co-processor than their main core? Or is that nonsense.

That conclusion would be incorrect. IIRC slow fixed-point arithmetics was an issue with older AMD CPUs as well.

I am using gcc 4.2.1 compiler(CodeBlocks IDE ) on windows platform . Why I am getting a compile error inspite of the fact that size of long long data type is 8 bytes .


Will I have the same problem when I submit something like this in Online Judge ??

Thanx in advance !!

Why are you asking this, didn't your IDE already tell you the reason of these compile errors?

I guess, you should try to add LL suffix to the constant 221474836590, move its declaration to the beginning of main(), and add 'return 0;' at the end of main().

I get the output -
4
4
8
-2080218972

while when I use the statement printf("%lu\n",n); I get the right answer ... Why is this happening ??

Regarding the return 0 thing , that was a silly mistake on my side while putting the code on the post ...

My guess is that you use mingw gcc, which links your program with an old (but widely available) version of Microsoft's msvcrt.dll. The dll recognizes %I64d, but not the standard %lld for printing long long. Blame Microsoft for not following standards.

You can either replace %lld with %I64d to do local testing with your current gcc (but beware that it won't work on online judge), or install a much better port of gcc to Windows - Cygwin, with which %lld does work.

Thank u very much MF for clearing my doubt ...