m4ri icon indicating copy to clipboard operation
m4ri copied to clipboard

L3 cache detection issue

Open kiwifb opened this issue 7 years ago • 5 comments

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).

kiwifb avatar Jun 24 '17 20:06 kiwifb

Hi there, from the discussion it seems the culprit isn't quite L3 detection, or am I misreading this?

malb avatar Jun 26 '17 08:06 malb

You are right. I thought it was when I opened the issue but further discussion seem to indicate something more subtle.

kiwifb avatar Jun 26 '17 09:06 kiwifb

It looks like compiling with no optimisation (-O0) leads to the breakage. That's something to remember. I guess the issue can closed.

kiwifb avatar Jul 05 '17 03:07 kiwifb

I think I'll leave the issue open, as this is too odd to ignore :)

malb avatar Jul 05 '17 07:07 malb

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.

kiwifb avatar Jul 06 '17 02:07 kiwifb