thatlr

Here is my MemTest unit which I use together with WinMemMgr, in all my productive applications: https://github.com/thatlr/Delphi-SupportUnits/blob/main/source/MemTest.pas

Sub-scheduling by the application (even determining how many threads to run to reach 100% CPU load) would have to deal with all the topics mentioned here https://learn.microsoft.com/en-us/windows/win32/procthread/scheduling as also Hyperthreading, Turbo Boost and Core Parking (https://learn.microsoft.com/en-us/windows-server/administration/performance-tuning/hardware/power/power-performance-tuning, Why is Windows using only even-numbered processors? ). And now also with cores with different performance characteristics, which is a new topic for x86 and therefore Windows. All in all, that why I wrote that no applicaton "parallel-for" and no naive-implemented thread pool should try to deal will all this. Other programs can change their CPU demand at any time, meaning the overall situation is highly dynamic. Taking all this factors into account is very hard, and should be left to the operating system.

" How does Delphi (11.3 in particular) handle this with the parallel for? " Hopefully not at all. It is not its job. The CPU cores are a shared resource; other application and services use them too. So, it is up to the operationg system to somehow measure the load of all cores over some time, and make scheduling decisions based on that. The only factors (aside from the affinity mask) that incluence the decisions of the scheduler are the priority of the process amd its threads. As for affinity masks, this would probably also not the right tool, as soon as CPUs with 32 or 64 cores (or more) become more widespread in the near future, due to the existence of the processor groups: https://docs.microsoft.com/en-us/windows/win32/procthread/processor-groups How do this groups handle different kinds of cores? In my opinion, trying to measure CPU load from inside an application, and trying to second-guess the scheduler is not the right approach.

I just want to point to this solution: https://github.com/thatlr/Delphi-StackTrace As it is relying on PDB files, it is not limited to Delphi sources: With the matching PDBs, it will also display function names and source code locations for foreign DLLs. (It could also display function names of Windows DLLs, if tweaking the SymInitialize searchpath argument, as mentioned in the source).