[Embench] Floating point accuracy

Jon Taylor Jon.Taylor at arm.com
Fri Oct 4 12:16:04 CEST 2019


Relatedly, I've also discovered the nbody test fails when using Arm's fast math library.

In the verification function, this performs explicit != tests against the expected values, rather than testing whether the fabs difference is within a certain range.
If I check the fabs error, it's always <1e-19.

It would be nice if we could find a value of acceptable FP error for all the FP tests and have a consistent checking mechanism for the results. The use of the fast-math library is part of the compiler flags, so will be recorded as part of the run.

Regards,

Jon

From: Embench <embench-bounces at lists.librecores.org> On Behalf Of Jon Taylor
Sent: 02 October 2019 11:21
To: embench at lists.librecores.org
Cc: nd <nd at arm.com>
Subject: [Embench] Floating point accuracy

I'm still testing the performance of Embench on various Arm devices.

During testing, I encountered the ST (stats) test failing. This performs various double precision floating point operations.

When using Arm's fast math library on a device with no hardware floating point support, the test fails.
(see https://developer.arm.com/docs/dui0774/i/compiler-command-line-options/-ffast-math-fno-fast-math)

On debugging this further, this is due to a comparison mismatch in the verify_benchmark function.
If I modify the code with some debug printf statements:
                printf ("first check: %8.8e\n", fabs (expSumA - SumA));
                printf ("second check: %8.8e\n", fabs (expSumB - SumB));
                printf ("third check: %8.8e\n", fabs (expCoef - Coef));
                printf ("Coef %8.8e, expCoef %8.8e\n", Coef, expCoef);

                return (fabs (expSumA - SumA) < 1.0e13)
    && (fabs (expSumB - SumB) < 1.0e-13) && (fabs (expCoef - Coef) < 1.0e-17);

I see the following output:

first check: 0.00000000e+00

second check: 0.00000000e+00

third check: 2.22044605e-16

Coef 9.99900055e-01, expCoef 9.99900055e-01

(It also looks like there's a code error here, since the first comparison is <1e13, the second is <1e-13. Shouldn't the first also be 1e-13?)

The third check result about causes the test to fail since the third comparison looks for an error of less than 1e-17. Is there a particular reason for a tighter threshold on the third check? In fact the absolute difference is less than 1e-17, it's just that the comparison is done quickly and introduces some error. Can it be relaxed to 1e-13 to match the other comparisons? I don't know where those numbers have been derived from.

Regards,

Jon




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/embench/attachments/20191004/bc8fec2d/attachment.htm>


More information about the Embench mailing list