Folding Forum

I don't think it's a 32-bit issue.
It's just how windows is made.

Neil-B wrote:

MeeLee wrote:The only Windows solution to this, is to buy Windows Enterprise, which can handle up to 128 threads, but costs you a monthly fee (unlike most other Windows versions which only cost you the purchase price at the beginning).

This is incorrect ... It is not, I repeat not a licensing issue ... it is the FAHClient/FAHControl code that cause this issue - Not Licensing, nor the FAHCore.

I think this is incorrect.

Enterprise as far as I know, has a subscription (unlike Windows home, or windows pro); and the core limitation is also a windows issue, not a FAH issue.
You can't run games on software renderer past 64 cores either, on windows Home.
I believe either 32 or 64 cores is the maximum a single program can be assigned to.
But if ran via VM, one could unlock the other cores.
Windows Home should be able to handle up to 64 cores, and the pro version should also be able to handle 128 cores, enterprise 256 cores.

MeeLee wrote:I think this is incorrect.

Then we shall have to agree to differ ... but we may actually be agreeing more than differing to be honest - I am answering the thread question of 32 max threads on WIndows - which is a wholly FAHClient/FAHControl artefact and not a limit set by the OS or the FAHCore ... If it were OS then the extra cores would simply not be visible in the OS ... If it were FAHCore then it wouldn't run with more than 32 (and it does).

"Windows Home should be able to handle up to 64 cores, and the pro version should also be able to handle 128 cores, enterprise 256 cores." is absolutely correct - and hence is why any limitation to 32 threads in a cpu slot is not a licensing issue !! ... Yes there are licensing limits for number of cores but these are not relevant to the FAHClient/FAHControl 32 thread limit on a windows cpu slot - if software is limited to fewer than the number of cores available to the OS then it is the software itself that is limiting that use.

https://en.wikipedia.org/wiki/Windows_1 ... ison_chart

Home does 64 others 128 or more ... and having run FAHCore with more than 32 threads from command line on Enterprise and Pro I know for a fact that the it works and that the issue is not a FAHCore or OS issue that is limiting the usage of CPU Slot threads under windows to 32 ... As to windows Home I have seen no evidence to make me think that the wiki page is incorrect - especially as I recall this changing many years back and there being press releases from MS about past limitations being removed.

The issue appears most likely down to the FAHClient being 32bit and using a call that only recognises up to 32 threads (as shown by calxalot earlier in this thread https://foldingforum.org/viewtopic.php? ... 36#p355011) when auto generating cpu slots and the coding in the FAHClient/FAHControl having a hard limit at 32 that cannot be overridden in settings ... Home can do 64 threads but FAHClient/FAHControl won't let those settings be made ... So I repeat my assertion that this is not a licensing issue nor is it an operating system issue.

However - as I said at the start - and hey we beg to differ

Oh yes just to go back to original solution posted of subscribing to Windows Enterprise - THIS DOES NOT WORK - I run various systems including Win Enterprise Systems and FAHClient/FAHControl still limits cpu slots to a maximum on 32 threads on these ... hence my previous "This is Incorrect" post ... Windows Enterprise IS NOT a solution for this issue and tbh your original posted core limit of windows enterprise was a tad out too

>>> If anyone reads this thread and who might be looking to run cpu slots greater than 32 threads on windows please not a this time take out a windows enterprise subscription as contrary to statements that may indicate that this will then allow you to run slots greater than 32 threads this will not work at this time as it is not a licensing issue <<<

...again... No one is speaking of licensing cores.
The license I'm talking about is the license of Windows enterprise, it doesn't get bought in a store like windows Home or Pro.
Nothing to do with licensing cores.
And yes, there is an operating system limitation, and that's what I'm talking about.
Because if you run 2x 32 thread WUs in VMs on home edition, you're going to hit the OS maximum!

For what it's worth here is the 2017 blurb on the number of CPUs/cores each version of Windows is licenced for.
https://www.microsoft.com/en-us/microso ... processors.

I'm also thinking that the issue with the FAHClient is that it is a 32-bit application, meaning the largest number it can handle is 32-bits in size.
I wrote my own powershell script to assign CPU cores/threads to specific processes, in it each core/thread is addressed by a single bit. For my Ryzen that is a 24-bit number, for my i5 that is a 4-bit number.
I imagine if the FAHClient is working the same way it will be limited to a 32-bit number thus will only be able to address the first 32 CPU cores/threads. Whether that will be per processor, or total for the system, I have no idea.

That was the type of news release I seemed to recall that opened up the limitations that had previously existed. With FAHClient not actually doing any of the real work (FAHCore does that) it could readily manage to hand off the correct number of threads to be used by the core if only the 32 limit wasn't hard coded and manual config was accepted - it doesn't even need to run the code to identify the number of cores once the config has been set let alone override the input from the user ... Just a bit of legacy headed code that is getting in the way ... but maybe with a lot of luck this might get resolved by v8 ... I won't hold my breath though - either for v8 or for it resolving the issue.

The other question would be:
What will be the best way to fold on CPU with more than 32 cores?

Initially I'm tempted to say, just to use Linux, and try a workaround to use multiple instances of a program, however, Fah might actually have issues with this (trying to fold the same WUs twice, or crash/error).

There's another option, you could run a Windows client, while at the same time install WSL (linux terminal from Windows), and install Fah there again.
that way you can do 32+32 cores max.
Since there aren't any 32+ thread WUs available anyway, you'll be forced to run multiple instances of it anyway.

And the easiest way is to run FAH directly from the OS, and run one or multiple VMs that will process the WUs a bit slower than the native client on the native os.

The question here is, which OS is best for running multi VMs?
Since Windows 10, many programs have been optimized, and hardware layers slimmed down.

Linux has always been the OS of preference for CPU tasks, even with VMs, but I think we need to see 2 identical machines fold on CPU, each with a different OS (one Windows, one MacOS, and one Linux).
And then see which OS runs the highest performance numbers, and see if this is still true in the VMs under that OS.

I have demonstrated on a current/recent project that a single 32+ slot on one of my servers rather than two slot produced both a higher total WU per day throughput and each;/every wu was completed much faster with a single rather than with two so the answer on my kit is that a single high thread count slot IS the best way to cold on cpu - hence why I care about trying to get this sorted

Neil-B wrote:I have demonstrated on a current/recent project that a single 32+ slot on one of my servers rather than two slot produced both a higher total WU per day throughput and each;/every wu was completed much faster with a single rather than with two so the answer on my kit is that a single high thread count slot IS the best way to cold on cpu - hence why I care about trying to get this sorted

Yes, but apparently you're going to hit the 32 thread WU limitation, hence you have no other option than to split up the WUs.

No I am not going to hit a limitation with os or fahcore .. the limitation is an artificial one imposed by fahclient/fahcontrol which needs fixing .. there is no 32thread wu limitation - current projects do not have an upper thread limit bar a few and they are limited to 8 or 4 threads or less .. again this is not a project wu limitation simply the legacy programming issue with fahclient/fahcontrol

At this point I will bow out of this discussion ... I have made my point clearly ... the current fahclient/fahcontrol limitation is what limits a cpu slot under any current version of windows to a maximum 32 threads - not licensing, fahcore or project wu limitations ... this cannot be solved by buying a subscription to win ent and will only be made possible when the client/control is updated and the legacy code limitations resolved ... further debate is simply covering ground already dealt with in this and previous threads ... there is clear evidential data to show that single cpu slots of greater than 32 threads can outperform multiple slots of 32 or less of many projects ... until such time as the client/control is updated to remove the legacy limit which is no longer relevant in any way the benefits of running these large thread count slots cannot be accrued to fah

Joseph believes he has fixed it.
This will need extensive testing when v8 reaches beta.
I hope those with high thread count systems will help test.

https://github.com/CauldronDevelopmentL ... /issues/81

calxalot wrote: ↑Thu Feb 10, 2022 11:01 pm Joseph believes he has fixed it.
This will need extensive testing when v8 reaches beta.
I hope those with high thread count systems will help test.

https://github.com/CauldronDevelopmentL ... /issues/81

Can I test this? I have a 2650L v4x2 system (56threads) and a 2698v4 (80threads) and a 2990wx (64 threads).

There is no v8 client available to beta test yet.

Hey topicstarter nice machine! Whish I could have one. -)
You may use 4 slots 32t each

The open beta for v8 has been released, testing to see if that 32 thread limit is still a problem can be done now.