Folding Forum

Not sure where to put this and since this is for a 64 bit CPUs I thought it should be here. So I'm talking to you programmers are you planing to make a 64 bit version of FAH.

i have often wondered about this myself. i guess we will see what the new client brings.

There's no real benefit to having a 64-bit client but I'd sure like to see a 64-bit core.

Linux has a 64 bit FahCore_a3. The client is 32-bit. To do this, they have REQUIRED that everybody who wants to fold SMP on Linux have a 64-bit OS with 32-bit support. So how long do you expect it to take before it would be reasonable to require 64-bit Windows?

There's probably a way to support both a 32-bit and a 64-bit OS at the same time, since they didn't do that with Linux, it's probably a bigger challenge that they choose to do any time soon.

Since 64 bits doesn't change performances, there's no need to hurry to get a 64 bits version ... the only field where it might helps is when we'll have to assign more than 2 GB of RAM to the core, which might only occur in bigadv WUs in the first place ...

P.S : Linux cores and clients (and OSX too I think) are already 64 bits ... only Windows cores and clients are still 32 bits.

P.S: there are probably some other threads about 64 vs 32 bits around the forums.

64-bit does not change the performance of the CLIENT. 64-bit will change the performance of the CORE.

It doesn't make a lot of differences in the core too ... as I said, the most important improvement of the 64 bits programs is to be able to address more than 2 GB of memory per process ...

Thanks for the feedback and I wonder how much FAH uses the most amount of RAM.

Sandman192 wrote:Thanks for the feedback and I wonder how much FAH uses the most amount of RAM.

In my experience very little is needed except in Big Advanced SMP units, I have run SMPs on a quad core with 1g of RAM, GPUs seem to see very little if any benefit from more RAM. Maybe this will change in the future. VMs when they were popular for SMPs needed plenty of RAM but that was for the VM not for F@H .

If you have a server with 24 or 32 or 48 cores, then -smp 24 / 32 / 48 needs more RAM than if you only run -smp 4 on a quad. Other than that, there's no read demand for more RAM.

I found out 64 bit is for only if each slot needs more then 3.5 Gigs of RAM.

Please note that the only component that may require 64-bit support is the FahCore itself which does the actual processing (folding). Other F@H components like FAHControl, FAHViewer, FAHClient can all still be 32-bit since they don't do any kind of processing* so they won't really gain any benefit from being a 64-bit application.

The current V7 Client can automatically detect the OS type (32-bit or 64-bit) and can download the appropriate FahCore version for the Slot, assuming that it is available in the first place.

EDIT -> * By processing, I meant folding. Do note that there are other tasks which those components perform like; uploading WUs, downloading WUs, downloading Project data, rendering demo/live protein, calculating TPF/PPD/ETA, etc. In these cases, the tasks may not see a significant boost when going from 32-bit to 64-bit so it wouldn't be wise to allocate the limited resources to building a 64-bit application. Also, there would be two branches to manage, Windows 32-bit and Windows 64-bit which wouldn't be feasible at all.

Sandman192 wrote:I found out 64 bit is for only if each slot needs more then 3.5 Gigs of RAM.

That's not the only limitation, but the one most people understand, and while their are many, only a few apply to fah. And those have already be covered in this thread.