[dman]

I think the problem size is too small. Dialling up the max requests and setting thread count to 64 yields the per thread in multi thread to 1104. (I am guessing the the scheduler will take a while to bring all 64 threads up, so on small problems one might not see the full benefit of available parallelism, but this is just an armchair hypothesis).

[dman@epyc ~]$ sysbench --test=cpu run --max-requests=2000000 --num-threads=64 WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options. WARNING: --num-threads is deprecated, use --threads instead WARNING: --max-requests is deprecated, use --events instead sysbench 1.0.14 (using bundled LuaJIT 2.1.0-beta2)

Running the test with following options: Number of threads: 64 Initializing random number generator from current time

Prime numbers limit: 10000

Initializing worker threads...

Threads started!

CPU speed: events per second: 70704.31

General statistics: total time: 10.0014s total number of events: 707263

Latency (ms): min: 0.68 avg: 0.90 max: 25.23 95th percentile: 1.50 sum: 638330.33

Threads fairness: events (avg/stddev): 11050.9844/1635.68 execution time (avg/stddev): 9.9739/0.02

[effie]

That's interesting, same increase in requests makes little difference on my machine, I get 10432 for multithread (16). I noticed above you have used 64 threads on 64-core system - does that give you better result than using 128 threads? It shouldn't, SMT should give you some increase in speed. At least on my 8-core system, using 16 threads gives 10432, while using 8 threads gives only 7311.