For many of the apps including 321 LLR, there are only 32-bit apps. Is that because it uses GMP and GMP doesn't play well with Win64? If so, have you checked out MPIR? It has 64-bit support for Windows and uses all the same methods as GMP. MPIR is slightly slower than GMP for Win32, but the 64 bit version of MPIR is much faster than running the 32-bit GMP on a 64 bit platform.

Being a C++ developer myself (not for PG, though), a 64-bit port is pretty straightforward. So a couple years back I gathered as much of the LLR source code I could find. What I found was that porting LLR to 64-bit wasn't possible.

There were two problems:

1) I couldn't obtain all the source. There were a couple static (archive) libraries in the projects for which I could not find source. By itself, this prevents the port..

2) There is a LOT of assembly code in the project. This may or may not be an issue when porting to 64-bit. But it makes porting to other non-x86 platforms a near impossibility.

If all the LLR source was available - in C/C++ - (and I wish it was!) - porting it to 64-bit would be straightforward. It would also open the door to porting LLR to non-x86 platforms.

It's been stated that the 64 bit LLR doesn't have any performance benefits over the 32 bit verision, so there's no reason to support and maintain a separate build.
____________Please do not PM me with support questions. Ask on the forums instead. Thank you!

It may be true that 64-bit integer math isn't faster than 32-bit... but I'd like to test it for myself.

As long as LLR is largely written in x86 assembly, it will remain restricted to x86 procs. (I thought the PS3 AP26 port was genius - the PS3 is a hard cruncher.)

And as long as there are static (archive) libraries in the LLR project for which we have no source, there's no chance we could try 64-bit or other cpu ports.

While it is probably the case someone spent countless months tuning the x86 assembly code inside the LLR, the result is that it blocks out anyone else from playing with the code - and it blocks any chance of using a non-x86 cpu.

Even if the C/C++ version was 15% slower than the assembly version, it'd be worth opening the C/C++ version into the programming community - so it could be played with, tuned, etc. Compilers do amazing jobs optimizing these days - and CPU's are offering faster, more specialized instructions all the time. Not to mention that it would be reasonable to consider porting a C/C++ based LLR to CUDA... something I bet everyone on PG would like to see.