From f3b38367f039bdf599fee2237b65d73728975a7a Mon Sep 17 00:00:00 2001 From: Nicholas Nethercote Date: Mon, 11 Feb 2008 21:22:15 +0000 Subject: [PATCH] notes about SPEC benchmarks git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7401 --- docs/internals/SPEC-notes.txt | 43 +++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) create mode 100644 docs/internals/SPEC-notes.txt diff --git a/docs/internals/SPEC-notes.txt b/docs/internals/SPEC-notes.txt new file mode 100644 index 000000000..59017f097 --- /dev/null +++ b/docs/internals/SPEC-notes.txt @@ -0,0 +1,43 @@ +From Vince Weaver: + +I've been running the SPEC CPU 2006 benchmarks under valgrind (doing some +work on my BBV generating plugin). + +There are two benchmarks that have issues, and I thought I'd share them +here for future reference. + +1). zeusmp - does not run + + It has a 1GB data segment, which valgrind cannot handle on a 32-bit + CPU. + +2). dealII - runs forever, never ending + + It took a while, but I tracked this down to a 64bit/80bit + floating point issue. + + The code in the QGauss<1>::QGauss() function has some code like this: + + const long double tolerance = std::max (static_cast + (std::numeric_limits::epsilon() / 100), + static_cast(std::numeric_limits::epsilon() *5)); + + do { + .... + various fp operations + .... + } while (abs(p1/pp) > tolerance); + + + The tolerance in this case is being set to ~2.22e-18, but the + abs(p1/pp) value never gets below ~2.586e-17 under valgrind. + + [This is because Valgrind only uses 64-bit FP values on x86, not 80-bit + values.] + + This is similar to an issue that happens with the "art" + benchmark on SPEC CPU 2000, but in the "art" case it only + makes the code take longer to finish; this "dealII" problem + makes the benchmark loop forever. +