shuffle2

We still need big RAM bandwidth for these threads It seems like a plausible reason (this cpu has 1/2 dram bandwidth compared to comparable epyc cpus - so the bandwidth is known to be less than it "should" be). But, I was surprised that this would cause the spike in "kernel time" reported after >64 threads. I also tried with large pages (attached), and you can see the kernel time is 1/3 the previously reported value (although overall time is about the same). It seems somewhat surprising that pagefaults...

Thanks for clarification on vm space, i should have looked closer at sources. Here's the same test run on 21.07

Here's the requested file. "# CPU hardware threads: 64" seems suspicious? I should mention though, that with -mmt128, task manager does at least show all threads at 100%... edit2: another (maybe) interesting data point for you. I've tried similar benchmark tests on another machine with a 6C/12T amd cpu on win11, and notice some differences in how cores/threads are reported by 7z as compared to the 3990x: For the 6C machine, 7z prints "cpus: 12 128T" (values which are returned from GetSystemInfo)....

Here's the requested file. "# CPU hardware threads: 64" seems suspicious? I should mention though, that with -mmt128, task manager does at least show all threads at 100%...

Here's the requested file. "# CPU hardware threads: 64" seems suspicious?

Hello Igor. I would like to request support for >64 threads on windows. Behavior seems recently to be fixed by default by the OS to behave as you'd expect: https://docs.microsoft.com/en-us/windows/win32/api/processtopologyapi/nf-processtopologyapi-setthreadgroupaffinity#remarks however if you also want to support older OS you'd need to use this API.