I have been working on optimizing some code, and I've noticed that 64 bit code is SLOWER than the corresponding 32 bit programs. Has anyone else noticed this, or am I just missing something?

Sure, it is slower in the general case. You have to need the 64bit registers before you will see any benefit from it. Adding qword(2) + qword(2) using 64bit code is a good way to to make your code larger and slower for absolutely no beneficial purpose.

You can still use EAX etc. One thing I've noticed in a lot of 64-bit code is the use of e.g. "xor rax,rax" when "xor eax,eax" does the same thing.
The only times you need to use a 64-bit gpr is for memory access, handles or some 64-bit maths. Even rip addressing is only 32-bit isn't it?

Can you post some code that shows the difference?

I noticed it when using the upper xmmx registers. It might be that it put presure on the reaning engine, or could have just been the extra prefix.
Do you know if there are any speed differences between 64bit mode and 32 bit mode? I would like to use the 16 gpr but I only need to work with 32bit words, and my initial testing indicated that there is no speed difference between moving an aligned qword and an aligned dword to and from memory. Is this correct in your experience?

RIP is 64-bit register so it addresses whole 64 bits. You can also use 32-bit EIP addressing (generally not recommended):

@tthsqe
For op-code / instruction latencies and throughput refer to the Intel (or AMD) 64bit optimization manual.
www.intel.com/products/processor/manuals/

If you care to share the algorithm / code you are using, I'm sure someone here could offer more specific speed / tuning help.

The only think I can think of is that when 32-bit code takes less space than 64-bit code. That is when using REX prefix makes your code differ from the 32-bit one. For example 15 bytes versus 17 bytes and all the alignments and caches get messed up.

Madis, are you sure the 15 bytes limit can be exceeded in 64-bit mode? Do you have an example?

I'm sure it can't.

LocoDelAssembly: Two consecutive instructions each with a REX prefix could push a 15byte piece of code to 17bytes.

@revolution: That's exactly what I meant. When "just" switching to 64-bit mode (i.e. without taking care of additional prefixes) you might be hit with a surprise of a few more bytes here and there.
Additionally there are problems of absolute 32-bit addresses, where one would need to add an extra instruction (lea reg,[addr] or mov reg,addr).

So do you think 32bit code should run just as fast in 64bit mode as it does in 32bit mode? There seem to be some problems with push's and pop's and inc's and dec's...

32bit instructions/registers will likely run faster when in 64bit mode when compared to 64bit instructions (as long as your data requirement is all 32bit or less or course). However when compared to 32bit mode then 32bit mode will run the 32bit code fastest, unless your system has many many tasks and >4GB memory then perhaps an underlying 64bit OS would be best to run 32bit code in compatibility mode.

Of course if you are processing 64bit data then you should use 64bit instructions/registers, that is what 64bit is for.

sry about that last post. I forgot to change ebp to rbp so everything in the floating point section was being referenced by ebp. oops. With this change, the performance is the same.