m4ri
m4ri copied to clipboard
L3 cache detection issue
On sage-on-gentoo on a Debian prefix my friend Steve Trogdon noticed some random failures that seemed related to the use of openmp in m4ri. Disabling openmp solved made the issue go away.
After he investigated further it seems that the L3 cache of the machine is misdetected. Entering some safe values again made it go away. See https://github.com/cschwan/sage-on-gentoo/issues/475 for the full discussion. I am wondering if the L3 cache detection routine needs updating for newer cpus. The macro hasn't received an update in years (not only in m4ri but upstream as well).
Hi there, from the discussion it seems the culprit isn't quite L3 detection, or am I misreading this?
You are right. I thought it was when I opened the issue but further discussion seem to indicate something more subtle.
It looks like compiling with no optimisation (-O0
) leads to the breakage. That's something to remember. I guess the issue can closed.
I think I'll leave the issue open, as this is too odd to ignore :)
OK then serious summary:
When compiled with openmp and -O0
some of m4ri tests fail
PASS: test_random
PASS: test_transpose
PASS: test_colswap
PASS: test_kernel
PASS: test_misc
PASS: test_smallops
PASS: test_ple
PASS: test_solve
FAIL: test_trsm
PASS: test_elimination
FAIL: test_invert
FAIL: test_multiplication
This can resolved by setting the size of the L3 cache to 0 or the same size than the L2 cache. The tests then pass.