|
From: Dan U. <up...@vi...> - 2008-03-04 16:53:43
|
Hi all, Has anybody had any experience, or more to the point, difficulty running 434.zeusmp or 447.dealII from the SPEC2006FP benchmark suite? On zeusmp I get: valgrind: mmap(0x54a000, 1172238336) failed in UME with error 22 (Invalid argument). valgrind: this can be caused by executables with very large text, data, or bss segments. dealII doesn't generate any errors, but it seems not to be halting--I know Valgrind introduces overhead, but I don't think it introduces so much that a benchmark that runs natively in under an hour should take more than 2 days to run on Valgrind ;) All of the benchmarks, along with Valgrind, were compiled on CentOS4.5 64-bit, using gcc 3.4.6 and gfortran 4.1.2. Any thoughts? |
|
From: Julian S. <js...@ac...> - 2008-03-04 17:07:28
|
On Tuesday 04 March 2008 17:53, Dan Upton wrote: > Hi all, > > Has anybody had any experience, or more to the point, difficulty > running 434.zeusmp or 447.dealII from the SPEC2006FP benchmark suite? There have been some discussions on this list before about SPEC2006FP, I believe. Try searching the archives. > dealII doesn't generate any errors, but it seems not to be halting Yes - this is to do with FP accuracy differences IIRC. The previous discussions also addressed this problem. J |
|
From: Nicholas N. <nj...@cs...> - 2008-03-04 21:13:38
|
On Tue, 4 Mar 2008, Dan Upton wrote:
> Has anybody had any experience, or more to the point, difficulty
> running 434.zeusmp or 447.dealII from the SPEC2006FP benchmark suite?
> On zeusmp I get:
>
> valgrind: mmap(0x54a000, 1172238336) failed in UME with error 22
> (Invalid argument).
> valgrind: this can be caused by executables with very large text,
> data, or bss segments.
>
> dealII doesn't generate any errors, but it seems not to be halting--I
> know Valgrind introduces overhead, but I don't think it introduces so
> much that a benchmark that runs natively in under an hour should take
> more than 2 days to run on Valgrind ;)
>
> All of the benchmarks, along with Valgrind, were compiled on CentOS4.5
> 64-bit, using gcc 3.4.6 and gfortran 4.1.2. Any thoughts?
This is from Vince Weaver (and is now in docs/internals/SPEC-notes.txt):
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<long double>
(std::numeric_limits<double>::epsilon() / 100),
static_cast<long double>(std::numeric_limits<long
double>::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.
|