Folding Forum

foxpy wrote: ↑Sun Dec 14, 2025 2:58 pm It is not hard to check again

I should probably take my words back then

I ran a few quick tests (5-10 frames) using 6, 8, and 10 cores on the same WU. 10 cores was consistently about 20% faster per frame than 6 cores, with 8 cores about half way in between (possibly a bit closer in speed to 1the 10 -core run). I certainly wouldn't want to draw any firm conclusions from...

Good idea. I tested it BRIEFLY, and based on a very small sample of 10 frames in one WU, 6 CPUs took about 20% longer to fold than using all 10 CPUs in the same WU. I'm going to let it run until the end on 6 and see if the time moderates with a larger sample. I wonder: has anyone has done a more ca...

Yeah, the worst thing for FAH is folding on more threads than physically available, your issue was 10 threads crammed into 4 CPUs, leading to almost zero PPD. Glad to hear it works well on your side now! You might also want to benchmark and compare how well 6 threads perform V/s 10 threads. E-cores ...

Windows really likes to schedule background jobs on smaller CPUs. FAH has a fix for MacOS, where is asks MacOS to run stuff on big CPUs, but there is unfortunately nothing like that for Windows. Simply setting thread count to 6 (like in MacOS) won't suffice, you will have to install Process Lasso an...

Not a complaint, just an observation from a WU I had to dump: 16781 had a TPF of nearly 40 minutes and resource utilization was low, indicating that it's not particularly efficient on this GPU compared to other projects of similar atom count and number of steps. I'm sure it will fold with ease when...

Well, it is not quite like NUMA. Yes, synchronization across CCDs can be expensive, but memory access speed should be uniform, if I understand it correctly?

When I pin all threads but one to a single core, the remaining thread drops to around 70%. I believe that is because it exceeds the limit of the load balancer. I'll check the source code to make sure, but I don't think it is using spinlocks. Maybe it doesn't use spinlocks indeed, but still somethin...

Sadly I don't have a Linux machine to test it right now, but try running a WU with 4 threads, and pin them in the following configuration: thread 0 - cpu 0 thread 1 - cpu 1 thread 2 - cpu 2 thread 3 - cpu 2 You will quickly notice that threads 0 and 1 still keep using 100% of CPU time, although comm...

Well, it definitely uses a mutex under the hood for something, but the main question I have: if the quicker threads slow down (which they definitely do, I agree), why do they still run 100% of the time instead of sleeping on a mutex?

The biggest issue in my eyes is that GROMACS threads for some reason just sit in infinite busy poll and wait until all threads finish their slice of work, instead of yielding and waiting on e.g. a mutex. This design choice denies slower threads a chance to access a free/quicker CPU and finish job fa...

I think the client doesn't change the parameters it requests on the fly, while being in the request loop. That's why pausing, then changing the amount of CPUs and unpausing it again might actually fix the problem.

This concept is really stupid and I don't understand why they made it so complicated

wait, don't you have GTT to extend the video memory? you can use radeontop tool to read the amount of available GTT. If there is none, you could specify more via amdgpu.gttsize module parameter: https://www.kernel.org/doc/html/v6.14/g ... eters.html

I've found that the best way to make use of that architecture is to run one WU on the P-cores and one on the E-cores, assuming the system has sufficient cooling capacity to maintain boost rates on all cores, otherwise the heat from the E-cores causes the P-cores to throttle. But if cooling is suffi...