Poll: -bigadv on a 32bit system?

[Napoleon]

According to the Project 2682 malloc error thread, big advanced WUs may already be hitting the 32bit memory barrier. Makes me wonder if there actually are any -bigadv capable rigs out there running a 32bit OS?

If not, wouldn't the easiest solution be to create separate 64bit cores for -bigadv only and make a 64bit system a requirement for -bigadv, along with the existing 8 core/thread detection and requirement? Perhaps we'll see the 64bit capability detection in the v7 client?

EDIT: added poll option "not folding -bigadv at all"

[orion]

I voted the "not folding -bigadv at all"

For I await the return of the LINUX -bigadv client.

[PantherX]

From my guide, I have noticed that there are 2 donors with 32 bit Windows. I am running 64 and have 4 GB RAM.

[toTOW]

I can only vote once, but I have two 32 bits bigadv folders (i7 920 @ 3.8 GHz, 3 GB of RAM and i7 860 @ 3.5 GHz, 2 GB of RAM, both running XP SP3 32 bits).

P.S : the WUs have been fixed.

[uncle fuzzy]

W7 64 for me.

[codysluder]

Nobody likes it when the rules change, but I think they should require 64-bit for bigadv. We already know bigadv is for machines that are significantly above today's typical home computer (8 or more cores) so what's the harm in saying it also has to have a 64-bit OS? Sure there are a few that have limited ram, but having 8 cores with only 2 or 3 GiBs is a poorly configured computer and for 4 GiB or more not haveing 64-bit is also a poorly configured computer.

The bigadv bonus is there for a reason. You do get a bigger bonus than regular smp, but if you're not providing access to enough ram, the regular smp bonus near enough until you get around to upgrading to something that's really significantly above today's typical home computer, you can still earn some pretty nice bonuses.

[7im]

I disagree. The Rules have not changed, they are just now getting enforced because the WUs have continued to grow in size, and it's starting to bite those who've tried to get by with less than the minimum recommended specs.

They've always recommend .5 GB per thread for SMP, and 1 GB per thread for -bigadv. Does anyone really try to run a 32 bit OS with 8 GB memory with 8 CPU cores?

[Napoleon]

They've always recommend .5 GB per thread for SMP, and 1 GB per thread for -bigadv. Does anyone really try to run a 32 bit OS with 8 GB memory with 8 CPU cores?

Um, nothing wrong with it as such, see Physical Address Extension at MSDN for example. The catchphrase in the article is: PAE does not change the amount of virtual address space available to a process. Each process running in 32-bit Windows is still limited to a 4 GB virtual address space.

Before A3 core, the client launched several processes - each process having their own virtual playground. MPICH and the like were needed for inter-process communication and keeping things in sync. PAE took care of breaking the 32bit barrier.

On the other hand, FahCore_a3.exe is a single process with multiple threads which all share the one and only virtual playground. Good old pre-A3 2682 had some data duplicated in all the processes, probably because interprocess communication (jumping from one playground to another) is relatively slow, as opposed to communication between threads. When all those separate processes got crammed together into a single process with multiple threads, the amount of duplicated data per thread hit the 32bit barrier once the amount of threads got big enough. Remove duplicate data and call it project 2692, problem solved.

OK, I may be oversimplifying things here, even making outright false assumptions, so feel free to correct me. Just my take on the root cause of the problem with 2682 WUs. A native 64bit FahCore_A3.exe process would have had a much larger virtual playground ==> no problem, apart from the less than optimal memory usage.

Be that as it may, bigadv with 32bit OS and/or core sounds just plain wrong to me.
Then again, the artificial 8-core requirement seems even weirder design choice in retrospect, given the fact that certain modern CPUs can crunch bigadv WUs easily enough with only 4 real cores...

[bruce]

Then again, the artificial 8-core requirement seems even weirder design choice in retrospect, given the fact that certain modern CPUs can crunch bigadv WUs easily enough with only 4 real cores...

It's not really artificial, but FAH's method of enforcing it is. The client contains code which reports the number of cores to the Assignment Server. The AS uses that to help decide which project to assign to you.

The only problem here is that the "number of cores" has two possible meanings and Intel has decided that the code should report virtual cores, not physical cores.

[sgb101]

in running win7pro 64bit with 6gb ram, on watching task manager for a few weeks my ram usage has never exceeded 2.4gb while folding bigadvs. so as it stands i cant see why a 32bit system couldn't run the biggies

[Napoleon]

Bruce, point taken. Let's not deviate too much from my original purpose for this poll:
Would it cause a huge outcry among donors if some BigAdv projects were restricted to 64bit capable setups in the near future? Call them, say, HugeAdv.

To my understanding, the (Windows) client part could still be a much more generic 32bit application with the ability to detect and report back to the server if it's running on a 64bit capable platform, then download a 64bit fahcore for those huge WUs.

As long as the fahcores are 32bit single processes using multiple threads (good), they will be limited to 4GB virtual address space (bad). The proposed "0.5GB / thread" rule of thumb gets quite interesting, here's some rocket science:

Code: Select all

4GB (max) / 0.5GB / thread = 8 threads (max) = -smp 8 (max).

Some future proofing and/or clarification required, wouldn't you agree?

[bruce]

Bruce, point taken. Let's not deviate too much from my original purpose for this poll
. . .
Some future proofing and/or clarification required, wouldn't you agree?

Sure, I agree, does anybody have a 12-core machine with a 32-bit OS? Clearly it can't meet the 0.5 GB per core requirement. You can't future-proof that system.

In the discussion of the Project 2682 malloc error there were some suggestions about how the Assignment Server might handle issues like that and kasson mentioned some server limitations. If projects the size of 2682 are anticipated in the future, some server-side changes (and maybe some client-side changes, too) will be required which might exclude 32-bit OSs or machines with small RAM from getting certain bigadv WUs. That's certainly the right thing to do if a bigadv project happens to exceed the capability of your system.

Sure, he found a way to restructure 2682, but 32-bit limitations can't be future-proofed.

[Grandpa_01]

3 I7's running Windows 7 and Vista 64bit with 6GB of ram on each.

[Amaruk]

in running win7pro 64bit with 6gb ram, on watching task manager for a few weeks my ram usage has never exceeded 2.4gb while folding bigadvs. so as it stands i cant see why a 32bit system couldn't run the biggies

Is that total usage? How much is FahCore_a3 using?

This is my current WU running on my i7 w/6GB, 7 pro 64bit.




This WU chocked on startup (Client-core communications error: ERROR 0xc0000005) trying to run on 32 bit windows.




Two others (bollix47 and myself) completed that same WU. I'm running 7 Pro 64 bit, and with dual xeons it's probable that bollix47 is also.


I do believe that this is the issue Napoleon is referring to. There have reports of issues with 64 bit systems as well.

I have no way of knowing if it will continue to use this much memory, but I'm starting to like the idea of a 64 bit core.

Does anyone really try to run a 32 bit OS with 8 GB memory with 8 CPU cores?

How about with 24 GB?

In their defense, it is a dual boot machine.

[7im]

in running win7pro 64bit with 6gb ram, on watching task manager for a few weeks my ram usage has never exceeded 2.4gb while folding bigadvs. so as it stands i cant see why a 32bit system couldn't run the biggies

http://msdn.microsoft.com/en-us/library ... ory_limits

Because 32 bit versions of Windows are limited to 2 GB of virtual address space per each process. Fahcore_a3 is one process.

Up to 3 GB can be used with IMAGE_FILE_LARGE_ADDRESS_AWARE enabled, and 4-gigabyte tuning and Physical Address Extension (PAE).

Even with a 64 bit Windows, 4 GB appears to be the limit. Me thinks we're bumping up against some hard limits here.