Agreed.

Re VFP: yes, a VFP EXE will typically run in a single thread but (to name some):
- many talk to an RDBMS back-end
- the VFP runtime makes Windows system calls
- AV is probably keeping an eye on what's happening

One could set processor affinity for the VFP EXE, but if the effects on other required components are unknown, will overall performance of the VFP app be improved? One would need to test extensively, and the results will probably not be repeatable on different computers.

There are lots of variables, and new ones pop up from time to time. One recent example is Intel's architecture change in Alder Lake and later CPUs, with so-called P-cores and E-cores no longer being truly symmetric. This has prompted Intel to implement a "Thread Director" in the CPU itself, and Microsoft to make corresponding updates to the scheduler in Windows 11: https://www.anandtech.com/show/16959/intel-innovation-alder-lake-november-4th/3 . One might think that a "hybrid" architecture like this would be a great candidate for processor affinity but I can't immediately find any testing or recommendations for using it on Alder Lake. At first glance it looks like Thread Director and the Windows scheduler do a "good enough" job.

And, I think that's in itself a significant point. If there were big gains to be had (and no other drawbacks) by using processor affinity, there would be lots of "how-to" guides. I, for one, haven't seen anything that looks (to me) well-researched and solid. There are some posts such as https://www.youtube.com/watch?v=pKS1eLiR-Vk from gamers, cryptominers and others who need or want to squeeze the most out of their hardware but results I've seen have not been impressive.

"Process Lasso" is available for Windows for those who want to play around with this sort of thing i.e. second-guess the Windows scheduler: https://en.wikipedia.org/wiki/Process_Lasso . I've never used it, not having worked with systems that are persistently CPU-bound; the bottlenecks have always been elsewhere. I believe it's a good idea to heed the caveats about it in the Wiki article - "use at your own risk".

>Hi Al,
>
>I am all the way with you that trying to outsmart processor affinity compared to automatic OS handling will probably be utile and perhaps might even degrade app performance.
>
>I'd probably be a nastier devils advocate than your hinted
>>- Ask them for expected benefits and expected degradation of other processes
>>- Ask them for detailed technical background to show they understand why the process will benefit.
>>- Make sure YOU understand the reasons they give and can accept the drawbacks
>
>OTOH,
>>That said, I doubt anyone would see much benefit doing this for a VFP app on a modern Windows system.
>
>might create false impression - at least for some clearly defined edge cases.
>Are there potential benefits ? Yes, CPU and context switching incur lags, esp. when caches are flushed or "other" caches are accessed, causing a fill.
>
>Also vfp being single threaded for most aspects of running user code IMO makes it a better fit for such operations than a modern exe utilizing many threads, asynch or parallel processing.
>
>If CPU has ample cores for every background task and CPU of vfp process is maxxed, such action could yield benefit. You would need to restrict all other tasks to a pool without "reserved cores", perhaps assign every accessed process (think AV or FW) separate pool or dedicated core(s), and let vfp run full blast on a dedicated core, you might eek out few single digit % perf benefit. Doing it via GUI is a no-no, do it up front via API for all running processes.
>
>If CPU and OS support elevating single core frequency, even more tests are needed - forcing minimal background activity on "other" cores might cut turbo-frequency.
>
>That said, I am certain a comparable effort (hourwise) in optimizing the app source code or distribute work lode over multiple threads or processes will get a much larger benefit in performance. If no source is available, just buying faster HW probably will also get more bang for the buck.
>
>regards
>thomas
>
>>>Is there a way you can bind an executable to a particular CPU core?
>>https://en.wikipedia.org/wiki/Processor_affinity
>>
>>Assuming you're talking about Windows, NT and successors support this:
>>https://winbuzzer.com/2020/07/03/how-to-set-cpu-affinity-in-windows-10-with-task-manager-or-system-properties-xcxwbt/
>>
>>That said, I doubt anyone would see much benefit doing this for a VFP app on a modern Windows system. Bear in mind doing this reduces the flexibility of the Windows scheduler - it can no longer fully optimize resource usage amongst all competing processes. If setting affinity for one process improves its performance by X%, the performance of all other processes will probably be reduced by (some multiple of) X%.
>>
>>These days CPU is rarely a performance bottleneck. If you need more overall performance you'll probably see greater gains by improving disk, RAM or network.
>>
>>I've read that some enterprise loads such as SQL Server and Exchange can benefit from it, especially on multi-processor/NUMA hardware e.g. https://infohub.delltechnologies.com/l/performance-best-practices-3/sql-server-2019-cpu-affinity . Getting those techniques to actually work as expected is enterprise-grade stuff.
>>
>>If someone is asking you to set CPU affinity for a regular business-type application I'd suggest:
>>
>>- Ask them for expected benefits and expected degradation of other processes
>>- Ask them for detailed technical background to show they understand why the process will benefit. Basically, explain how setting affinity for that process will be better than the default scheduler behaviour
>>- Make sure YOU understand the reasons they give and can accept the drawbacks
>>
>>Be aware that setting affinity won't work well, or at all, in a virtualized environment unless the hypervisor will accept hints from guest OSs (and abide by them). That sort of paravirtualization support is not a given. If not in place the hypervisor will manage its vCPUs however it sees fit, regardless of what guest OSs think they're doing.

pKS1eLiR-Vk