64-bit Computing Will Be With Us for a While

I think 64-bit computing will be with us for a while. I recently came across this interesting tidbit of information:

"A 64-bit PC can track 2^64 addresses, yielding a theoretical memory ceiling of about 16 exabytes — 16 billion gigabytes."

That would be a lot of RAM.

MS has moved to only 64 bit server. Exchange 2007 is 64 bit only and Server 2008 R2 is 64 bit only.  Outperforms the 32 bit versions by 7 times I've been told from tests.

@dale_tem: 64-bit does shift more data, but on its own doesn't make it faster.

The biggest advantage of 64-bit is the number of registers. Software designed for 64-bit can use 8 more registers than 32-bit code.

In a 32-bit system you have the 32-bit registers:

eax, ebx, ecx, edx, esi, edi, ebp, esp

In a 64-bit system you have the 64-bit registers:

rax, rbx, rcx, rdx, rsi, rdi, rbp, rsp, r8 through r15.

This saves you having to push stuff onto the stack (stored in the slower memory) as well as reducing memory accesses so speeds the whole thing up wildly.

The big issue with 32-bit code on 64-bit OS is that it still does stuff the 32-bit way.

Not all 64-bit code can make best use of the fact there are more registers in 64-bit mode, as M$ screwed up with the 64-bit design and can still require data to be pushed onto the stack when making API calls (when more than 4 parameters need to be passed).   When calling your own functions though you can make use of all the registers available making a big difference to performance.

stdcall (typical in 32-bit on MS systems): http://en.wikipedia.org/wiki/Stdcall#stdcall

fastcall (typical in 64-bit on MS systems): http://en.wikipedia.org/wiki/Fastcall#Microsoft_x64_calling_convention

The #1 reason I love assembler:

int _cdecl MyFunction(int i){ int k; return i + k; } ;entry sequence push ebp ; 1 cycle. mov ebp, esp ; 1 cycle. sub esp, 4 ;create function stack frame. 1 cycle. ;function code mov eax, [ebp + 8] ; 1 cycle. ;move parameter i to accumulator add eax, [ebp - 4] ; 2 cycles. ;add k to i ;result is returned in eax ;exit sequence mov esp, ebp ; 1 cycle. pop ebp ; 4 cycles. ret ; 5 cycles

They failed to actually assign any value to k in the example, so it is actually undefined, and is bad coding practise.

The C++ code above, if coded directly in assembler would be:

mov eax,5 ; same as int i above. 1 cycle call Add ; 5 cycles ; eax now contains 12 ret ; End of program Add proc add eax,7 ; same as int k above ; 1 cycle ret ; 5 cycles Add endp

By only using the registers to pass variables, I got code that takes 16 cycles to execute down to 12 cycles. I can reduce it to 1 cycle by inlining the function (93% faster).

Overall their example is pretty poor. Using pure assembler to prove the point is better.

sub esp, 4 ; make room for a DWORD or 32-bits or 4 bytes mov dword ptr [esp-4], "Hi!",0 ; zero-terminated string literal 4 bytes long, written to the new area on the stack push 0 push [esp-4] ; pointer to the start of the string. Square brackets mean treat register as memory address push [esp-4] ; pointer to the start of the string. Square brackets mean treat register as memory address push 0 call MessageBox ; produces a message box that says Hi! add esp,4 ; re-balance the stack (effectively removes "Hi!",0 from the stack but it is still there if we look) ret ; End of the program

You'll note I didn't need to mess with the base pointer, and in fact I could actually use it in my functions if I was careful, but no API calls could be made otherwise Windows would go nuts.

In 64-bit code:

sub rsp, 8 ; make room for a QWORD or 64-bits or 8 bytes to keep aligned otherwise we could have cache miss later which just kills things mov rax, "Hi!",0,0,0,0,0 ; zero-terminated string literal 8 bytes long, written to the RAX register due to the 4 byte limit of mov when writing to a memory location mov [rsp-8], rax push 0 push [rsp-8] ; pointer to the start of the string. Square brackets mean treat register as memory address push [rsp-8] ; pointer to the start of the string. Square brackets mean treat register as memory address push 0 call MessageBox ; produces a message box that says Hi! add rsp,8 ; re-balance the stack (effectively removes "Hi!",0,0,0,0,0 from the stack but it is still there if we look) ret ; End of the program

No advantage, unless MessageBox is 64-bit and is faster than its 32-bit counterpart, but I also have to trash a register in the process to move more than 4 bytes in a signle instruction (if this was real code it would be hand optimized to move only 4 bytes to memory directly and leave the register intact).

In fact, I suspect little of Windows is actually any different, except for the memory manager and kernel. There is no seperate 64-bit API, and all the calls, even from 64-bit apps, are using the Win32 APIs.   The only code that could be fully 64-bit are those written from scratch to use all the processor features available in 64-bit and avoid Windows functions as much as possible, especially in speed critical regions.

Best regards,
Vulcan.

That wouldn't explain the difference sufficiently.

My 32-bit and 64-bit code examples demonstrate very nicely that where Windows is concerned, there is practically no difference between the two, and that the only time 64-bit can be made to show its benefits is in code where it is part of the design, and not used retrospectively.

Best regards,
Vulcan.

Well kinda. Addressing memory is just a small part of what 64-bit offers. It is all to do with the processor. The memory is just an aside, but the thing everyone jumps on for two reasons:

1) It takes very little to understand it

2) it is about the only advantage to most people. 32-bit is still perfectly adequate. XP forever!

Best regards,
Vulcan.

You can sit there and laugh, but these optimizations are why *nix and OSX are typically 6 to 10 times faster than Windows, independent of the word-size of the data.

I suggest you know nothing about high performance computing - quite a world away from mundane and often bloated websites.

You never did offer a reason to why Explorer.exe on Win 7 keeps locking .exe files whilst browsing folders, preventing them being overwritten or deleted for approximately 2 minutes after the last access, or providing a fix to prevent it.

To re-cap: it is like the file is protected, dissimilar in behavior to not having permission to overwrite or delete the file where you get the categoric "You do not have permission to perform this action" message box.

Best regards,
Vulcan.

My word Vulcan, you are anal about computers aren't you?

I'm not trying to impress anyone - I couldn't give a stuff, not to mention the time it takes to write the damn thing. As it was I edited it several times to correct minor coding errors as I hadn't actually built and tested it first.

I was trying to explain exactly what 64-bit really means, but that in reality few people will ever use what is available, and demonstrated with an example.

Anyone who is a half-reasonable software engineer would know what I wrote - it's not rocket science, but is the best way to truly explain the details.

If you don't care - fine, but who knows who else is reading who might? I read stuff in forums all the time that is not directly related to the topic at hand, but maybe just adds a piece to the jigsaw I've been looking for, for something else.

My word Vulcan, you are anal about computers aren't you?   I always reply to the question in the same style as it was posted. A generalised comment about 64 bit was replied with another general comment about 64 bit. Not OTT indepth information about 64 bit that only a few people even in computing care about.

Anal? I think the word you are looking for is "geek". I started coding when I was 4, and been doing it ever since.

I usually "reply to the question in the same style as it was posted" but this subject has come up a few times, and people think it is just about the memory. It's not, and that is what I was trying to explain.

If people gave a rats arse about details once in a while, things may be in a better state than they are.

Soaranden is obviously interested as he raised the point about the amount of RAM available in 64-bit in the first place. I'm just filling in the picture. Do with the information as you please, but don't insult me for providing it.

What does "high performance computing" even mean?

HPC (actually High Performance Technical Computing) is the art of writing extremely high performance code for engineering tasks, such as computational fluid dynamics, simulation, etc..

It is written in such a way to use the system to its optimum, taking advantage of the architecture of the system being used. It is the ultimate software design challenge, and is the basis of clustered computing and distributed computing for solving very complex problems (such a prime number factorization to brute-force RSA crypto, and simulation of nuclear weapons tests for example).

Best regards,
Vulcan.