Bug ID | 1162291 |
---|---|
Summary | Inexplicable multithreading behaviour |
Classification | openSUSE |
Product | openSUSE Tumbleweed |
Version | Current |
Hardware | x86-64 |
OS | SUSE Other |
Status | NEW |
Severity | Normal |
Priority | P5 - None |
Component | Kernel |
Assignee | kernel-maintainers@forge.provo.novell.com |
Reporter | juergen-fuhrmann@web.de |
QA Contact | qa-bugs@suse.de |
Found By | --- |
Blocker | --- |
Created attachment 828734 [details]
MWE for testing multithreading performance.
I am trying out threading performance in C++/OpenMP and Julia.
On a 6 core 32GB RAM Dell Precision 7540 laptop with Tumbleweed (kernel
5.4.10), multithreading speed up unexpectedly significantly decreases with
problem size.
I attach the test program to be compiled with
g++ -Ofast -fopenmp threads.cxx -o threads
Usage is
threads N nrepeat
Problem size aka array length aka loop range size can be given as the command
line parameter N. nrepeat is the number of repeats of the measurment (to allow
watching CPU usage)
The typical output is as follows:
$threads 100000 1
nthreads=4
scalar=0.004519, para=0.001273, speedup=3.550611
I get 400% CPU usage in top (when setting nrepeat to 100000)
$threads 100000 1
nthreads=4
scalar=0.056637, para=0.046533, speedup=1.217147
In this case CPU usage in top is limited to 266%
I observe this behavior with
g++-10
g++-7
julia 1.3.1 (with a similar test program)
I don't observe this behavior on a compute server with Leap 5.10, kernel
4.12.14 and g++-7:
$threads 100000 1
nthreads=4
scalar=0.008033, para=0.002451, speedup=3.278010
$threads 1000000 1
nthreads=4
scalar=0.069559, para=0.021247, speedup=3.273745
When I copy the executable from the server to the laptop I get the same results
as for the executable compiled on the laptop. I suspect this to be a problem
with thread scheduling, memory management or something related.
And yes, mitigations are already off, and hyperthreading is on (though I don't
use it here).
J�rgen