h5diff has been gotten 2 orders of magnitude slower

Dave_Wade-Stein · December 7, 2008, 5:28pm

h5diff seems to have slowed down by 2 orders of magnitude from 1.6.5 to 1.8.1. To wit:

[dws@ice empic]$ time h5diff-1.6.5 unideltaf3p_electrons_1.h5 /ice/httpd/html/wwwice/vpresults-ice-opt/empic/unideltaf3p/unideltaf3p_electrons_1.h5 /electrons -r
0 differences found

real 0m0.512s
user 0m0.101s
sys 0m0.411s

[dws@ice empic]$ time h5diff-1.8.1 -r unideltaf3p_electrons_1.h5 /ice/httpd/html/wwwice/vpresults-ice-opt/empic/unideltaf3p/unideltaf3p_electrons_1.h5 /electrons

real 0m47.461s
user 0m47.270s
sys 0m0.183s

I just tried 1.8.2 and it's comparable to 1.8.1.

It's pretty much unusable for us now, as a test suite which used to take about an hour now takes 2.5 hours due to the time increase for h5diff'ing.

Thanks,
Dave

···

----------------------------------------------------------------------
This mailing list is for HDF software users discussion.
To subscribe to this list, send a message to hdf-forum-subscribe@hdfgroup.org.
To unsubscribe, send a message to hdf-forum-unsubscribe@hdfgroup.org.

epourmal · December 8, 2008, 3:48pm

Dave,

Could you please provide us with some files so we can investigate the performance?

Thank you!

Elena

···

On Dec 7, 2008, at 11:28 AM, Dave Wade-Stein wrote:

h5diff seems to have slowed down by 2 orders of magnitude from 1.6.5 to 1.8.1. To wit:

[dws@ice empic]$ time h5diff-1.6.5 unideltaf3p_electrons_1.h5 /ice/httpd/html/wwwice/vpresults-ice-opt/empic/unideltaf3p/unideltaf3p_electrons_1.h5 /electrons -r
0 differences found

real 0m0.512s
user 0m0.101s
sys 0m0.411s

[dws@ice empic]$ time h5diff-1.8.1 -r unideltaf3p_electrons_1.h5 /ice/httpd/html/wwwice/vpresults-ice-opt/empic/unideltaf3p/unideltaf3p_electrons_1.h5 /electrons

real 0m47.461s
user 0m47.270s
sys 0m0.183s

I just tried 1.8.2 and it's comparable to 1.8.1.

It's pretty much unusable for us now, as a test suite which used to take about an hour now takes 2.5 hours due to the time increase for h5diff'ing.

Thanks,
Dave

----------------------------------------------------------------------
This mailing list is for HDF software users discussion.
To subscribe to this list, send a message to hdf-forum-subscribe@hdfgroup.org.
To unsubscribe, send a message to hdf-forum-unsubscribe@hdfgroup.org.

----------------------------------------------------------------------
This mailing list is for HDF software users discussion.
To subscribe to this list, send a message to hdf-forum-subscribe@hdfgroup.org.
To unsubscribe, send a message to hdf-forum-unsubscribe@hdfgroup.org.

Pedro_Vicente2 · April 12, 2009, 3:45am

Hello

h5diff seems to have slowed down by 2 orders of magnitude from 1.6.5
to 1.8.1. To wit:

[dws@ice empic]$ time h5diff-1.6.5 unideltaf3p_electrons_1.h5 /ice/ httpd/html/wwwice/vpresults-ice-opt/empic/unideltaf3p/ unideltaf3p_electrons_1.h5 /electrons -r
0 differences found

real 0m0.512s
user 0m0.101s
sys 0m0.411s

[dws@ice empic]$ time h5diff-1.8.1 -r unideltaf3p_electrons_1.h5 /ice/ httpd/html/wwwice/vpresults-ice-opt/empic/unideltaf3p/ unideltaf3p_electrons_1.h5 /electrons

real 0m47.461s
user 0m47.270s
sys 0m0.183s

I just tried 1.8.2 and it's comparable to 1.8.1.

It's pretty much unusable for us now, as a test suite which used to
take about an hour now takes 2.5 hours due to the time increase for
h5diff'ing.

Thanks,
Dave

What made h5diff slower between those 2 versions (1.6.5 and 1.8.1) was the introduction of Not a Number (NaN) detection (or more specifically the way we deal with this detection).

We are requesting for comments regarding a new h5diff option that would enable (or disable) that NaN detection. First (1) I explain how h5diff now handles NaN and (2) the new option

1) Detection of NaN

Consider a floating point number X.

Currently, NaN is detected (in some cases), converting X to a string (using the C library function sprintf , computationally a very slow operation) and then doing a string comparison between this string and one of the possible string representations of NaN. This NaN string representation varies between operating systems and can be for example "NAN ", "nan", "1.#SNAN", etc.

The expression " X != X ", is always false for every infinite or finite number X but reverse, true, if X is NaN. So we could theoretically use this expression to detect NaN.

However, in some platforms, this expression does not evaluate to true for NaN, so in these cases, we have to use the string approach.

Here's how the code works

First , we do the test to detect if X is NaN or not

retval = (X!=X);
if (retval==FALSE)
{
Call sprintf
}

For a "regular" number, retval evaluates to FALSE, so the sprintf is always called . So, worst case scenario, a file with no NaNs at all, like your file, sprintf is always called.

If X is a NaN on a platform where that expression correctly detects NaN (linux for example), retval evaluates to TRUE, and the sprintf is *not* called. So, if your file had only NaNs, you wouldn't see that 2 orders of magnitude slow down.

In some platforms (windows for example) that expression does not correctly detect NaN and retval evaluates to FALSE when X is a nan. In that case , the sprintf is always called too.

Here's the way h5diff prints these quantities
Consider the 2 datasets with 6 elements

Array element 0 1 2 3 4 5
Dataset 1 nan 1 nan 1 1 1
Dataset 2 nan nan 1 1 1 1

h5diff now reports this

dataset: </g1/fp17> and </g1/fp18>
size: [6] [6]
position fp17 fp18 difference

RFC_NaNsHDF5.pdf (349 KB)

···

At 12:28 PM 12/7/2008, Dave Wade-Stein wrote:
------------------------------------------------------------
[ 1 ] 1 -1.#IND 1.#QNAN
[ 2 ] -1.#IND 1 1.#QNAN
2 differences found

That there are 2 differences between the datasets. This result is consistent with all platforms we support . We consider the array position 0 (where both elements are NaN) to be a "no" difference.

2) Option in h5diff to avoid the NaN detection

To avoid these performance issues, we are introducing an option to enable (or disable) NaN detection. We are requesting comments regarding if h5diff should detect NaNs by default or not.

2.1) h5diff compares NaN by default

The new proposed option would be something like

-N, --nan Avoid NaNs detection

Example
./h5diff file1 file2

would compare file1 and file2, doing NaN detection (the default, slow).
To disable NaN detection, one would use

./h5diff -N file1 file2

2.2) h5diff does NOT compare NaN by default

The new proposed option would be something like

-N, --nan Detect NaNs

Example
./h5diff file1 file2

would compare file1 and file2, NOT doing NaN detection (the default, fast).
To enable NaN detection, one would use

./h5diff -N file1 file2

Here are some examples of h5diff output regarding the previous example, this time NOT detecting NaN.

For example, running on linux, we get

dataset: </g1/fp17> and </g1/fp18>
size: [6] [6]
position fp17 fp18 difference
------------------------------------------------------------
[ 0 ] nan nan nan
[ 1 ] 1 nan nan
[ 2 ] nan 1 nan
3 differences found

And running on windows we get

dataset: </g1/fp17> and </g1/fp18>
0 differences found

Note that these results vary between themselves and with the result using NaN detection.

Attached is a document with more details about the way h5diff currently detects NaN.

----------------------------------------------------------------------
This mailing list is for HDF software users discussion.
To subscribe to this list, send a message to hdf-forum-subscribe@hdfgroup.org.
To unsubscribe, send a message to hdf-forum-unsubscribe@hdfgroup.org.

--------------------------------------------------------------
Pedro Vicente (T) 217.265-0311
pvn@hdfgroup.org
The HDF Group. 1901 S. First. Champaign, IL 61820

werner · April 12, 2009, 6:30am

Why can't you use the isnan() function from math.h ?

http://www.opengroup.org/onlinepubs/000095399/functions/isnan.html

Werner

···

On Sat, 11 Apr 2009 20:45:49 -0700, Pedro Vicente <pvn@hdfgroup.org> wrote:

Hello

At 12:28 PM 12/7/2008, Dave Wade-Stein wrote:

h5diff seems to have slowed down by 2 orders of magnitude from 1.6.5
to 1.8.1. To wit:

[dws@ice empic]$ time h5diff-1.6.5 unideltaf3p_electrons_1.h5 /ice/ httpd/html/wwwice/vpresults-ice-opt/empic/unideltaf3p/ unideltaf3p_electrons_1.h5 /electrons -r
0 differences found

real 0m0.512s
user 0m0.101s
sys 0m0.411s

[dws@ice empic]$ time h5diff-1.8.1 -r unideltaf3p_electrons_1.h5 /ice/ httpd/html/wwwice/vpresults-ice-opt/empic/unideltaf3p/ unideltaf3p_electrons_1.h5 /electrons

real 0m47.461s
user 0m47.270s
sys 0m0.183s

I just tried 1.8.2 and it's comparable to 1.8.1.

It's pretty much unusable for us now, as a test suite which used to
take about an hour now takes 2.5 hours due to the time increase for
h5diff'ing.

Thanks,
Dave

What made h5diff slower between those 2 versions (1.6.5 and 1.8.1) was the introduction of Not a Number (NaN) detection (or more specifically the way we deal with this detection).

We are requesting for comments regarding a new h5diff option that would enable (or disable) that NaN detection. First (1) I explain how h5diff now handles NaN and (2) the new option

1) Detection of NaN

Consider a floating point number X.

Currently, NaN is detected (in some cases), converting X to a string (using the C library function sprintf , computationally a very slow operation) and then doing a string comparison between this string and one of the possible string representations of NaN. This NaN string representation varies between operating systems and can be for example "NAN ", "nan", "1.#SNAN", etc.

The expression " X != X ", is always false for every infinite or finite number X but reverse, true, if X is NaN. So we could theoretically use this expression to detect NaN.

However, in some platforms, this expression does not evaluate to true for NaN, so in these cases, we have to use the string approach.

Here's how the code works

First , we do the test to detect if X is NaN or not
retval = (X!=X);
if (retval==FALSE)
{
Call sprintf
}
For a "regular" number, retval evaluates to FALSE, so the sprintf is always called . So, worst case scenario, a file with no NaNs at all, like your file, sprintf is always called.
If X is a NaN on a platform where that expression correctly detects NaN (linux for example), retval evaluates to TRUE, and the sprintf is *not* called. So, if your file had only NaNs, you wouldn't see that 2 orders of magnitude slow down.
In some platforms (windows for example) that expression does not correctly detect NaN and retval evaluates to FALSE when X is a nan. In that case , the sprintf is always called too.

Here's the way h5diff prints these quantities
Consider the 2 datasets with 6 elements

Array element 0 1 2 3 4 5
Dataset 1 nan 1 nan 1 1 1
Dataset 2 nan nan 1 1 1 1
h5diff now reports this
dataset: </g1/fp17> and </g1/fp18>
size: [6] [6]
position fp17 fp18 difference
------------------------------------------------------------
[ 1 ] 1 -1.#IND 1.#QNAN
[ 2 ] -1.#IND 1 1.#QNAN
2 differences found
That there are 2 differences between the datasets. This result is consistent with all platforms we support . We consider the array position 0 (where both elements are NaN) to be a "no" difference.

2) Option in h5diff to avoid the NaN detection

To avoid these performance issues, we are introducing an option to enable (or disable) NaN detection. We are requesting comments regarding if h5diff should detect NaNs by default or not.

2.1) h5diff compares NaN by default

The new proposed option would be something like

-N, --nan Avoid NaNs detection

Example
./h5diff file1 file2

would compare file1 and file2, doing NaN detection (the default, slow).
To disable NaN detection, one would use

./h5diff -N file1 file2

2.2) h5diff does NOT compare NaN by default

The new proposed option would be something like

-N, --nan Detect NaNs

Example
./h5diff file1 file2

would compare file1 and file2, NOT doing NaN detection (the default, fast).
To enable NaN detection, one would use

./h5diff -N file1 file2

Here are some examples of h5diff output regarding the previous example, this time NOT detecting NaN.

For example, running on linux, we get
dataset: </g1/fp17> and </g1/fp18>
size: [6] [6]
position fp17 fp18 difference
------------------------------------------------------------
[ 0 ] nan nan nan
[ 1 ] 1 nan nan
[ 2 ] nan 1 nan
3 differences found
And running on windows we get
dataset: </g1/fp17> and </g1/fp18>
0 differences found
Note that these results vary between themselves and with the result using NaN detection.

Attached is a document with more details about the way h5diff currently detects NaN.

----------------------------------------------------------------------
This mailing list is for HDF software users discussion.
To subscribe to this list, send a message to hdf-forum-subscribe@hdfgroup.org.
To unsubscribe, send a message to hdf-forum-unsubscribe@hdfgroup.org.

--------------------------------------------------------------
Pedro Vicente (T) 217.265-0311
pvn@hdfgroup.org
The HDF Group. 1901 S. First. Champaign, IL 61820

--
___________________________________________________________________________
Dr. Werner Benger <werner@cct.lsu.edu> Visualization Research
Laboratory for Creative Arts and Technology (LCAT)
Center for Computation & Technology at Louisiana State University (CCT/LSU)
239 Johnston Hall, Baton Rouge, Louisiana 70803
Tel.: +1 225 578 4809 Fax.: +1 225 578-5362

----------------------------------------------------------------------
This mailing list is for HDF software users discussion.
To subscribe to this list, send a message to hdf-forum-subscribe@hdfgroup.org.
To unsubscribe, send a message to hdf-forum-unsubscribe@hdfgroup.org.

Dave_Wade-Stein · April 13, 2009, 7:14pm

Two questions:

1. NaN's should produce (X == X) -> false, but are you sure that they are guaranteed to produce (X != X) -> true?

2. Why can't the builtin NaN-detecting functions be used when they are available, via configure? If you resolved this during configure time for the platforms that have an easy solution, you wouldn't have to use sprintf in most cases, would you?

Dave

···

On Apr 11, 2009, at 9:45 PM, Pedro Vicente wrote:

Hello

...

What made h5diff slower between those 2 versions (1.6.5 and 1.8.1) was the introduction of Not a Number (NaN) detection (or more specifically the way we deal with this detection).

We are requesting for comments regarding a new h5diff option that would enable (or disable) that NaN detection. First (1) I explain how h5diff now handles NaN and (2) the new option

1) Detection of NaN

Consider a floating point number X.

Currently, NaN is detected (in some cases), converting X to a string (using the C library function sprintf , computationally a very slow operation) and then doing a string comparison between this string and one of the possible string representations of NaN. This NaN string representation varies between operating systems and can be for example "NAN ", "nan", "1.#SNAN", etc.

The expression " X != X ", is always false for every infinite or finite number X but reverse, true, if X is NaN. So we could theoretically use this expression to detect NaN.

However, in some platforms, this expression does not evaluate to true for NaN, so in these cases, we have to use the string approach.

Here's how the code works

First , we do the test to detect if X is NaN or not

retval = (X!=X);
if (retval==FALSE)
{
Call sprintf
}

For a "regular" number, retval evaluates to FALSE, so the sprintf is always called . So, worst case scenario, a file with no NaNs at all, like your file, sprintf is always called.

If X is a NaN on a platform where that expression correctly detects NaN (linux for example), retval evaluates to TRUE, and the sprintf is *not* called. So, if your file had only NaNs, you wouldn't see that 2 orders of magnitude slow down.

In some platforms (windows for example) that expression does not correctly detect NaN and retval evaluates to FALSE when X is a nan. In that case , the sprintf is always called too.

Here's the way h5diff prints these quantities
Consider the 2 datasets with 6 elements

Array element 0 1 2 3 4 5
Dataset 1 nan 1 nan 1 1 1
Dataset 2 nan nan 1 1 1 1

h5diff now reports this

dataset: </g1/fp17> and </g1/fp18>
size: [6] [6]
position fp17 fp18 difference
------------------------------------------------------------
[ 1 ] 1 -1.#IND 1.#QNAN
[ 2 ] -1.#IND 1 1.#QNAN
2 differences found

That there are 2 differences between the datasets. This result is consistent with all platforms we support . We consider the array position 0 (where both elements are NaN) to be a "no" difference.

2) Option in h5diff to avoid the NaN detection

To avoid these performance issues, we are introducing an option to enable (or disable) NaN detection. We are requesting comments regarding if h5diff should detect NaNs by default or not.

2.1) h5diff compares NaN by default

The new proposed option would be something like

-N, --nan Avoid NaNs detection

Example
./h5diff file1 file2

would compare file1 and file2, doing NaN detection (the default, slow).
To disable NaN detection, one would use

./h5diff -N file1 file2

2.2) h5diff does NOT compare NaN by default

The new proposed option would be something like

-N, --nan Detect NaNs

Example
./h5diff file1 file2

would compare file1 and file2, NOT doing NaN detection (the default, fast).
To enable NaN detection, one would use

./h5diff -N file1 file2

Here are some examples of h5diff output regarding the previous example, this time NOT detecting NaN.

For example, running on linux, we get

dataset: </g1/fp17> and </g1/fp18>
size: [6] [6]
position fp17 fp18 difference
------------------------------------------------------------
[ 0 ] nan nan nan
[ 1 ] 1 nan nan
[ 2 ] nan 1 nan
3 differences found

And running on windows we get

dataset: </g1/fp17> and </g1/fp18>
0 differences found

Note that these results vary between themselves and with the result using NaN detection.

----------------------------------------------------------------------
This mailing list is for HDF software users discussion.
To subscribe to this list, send a message to hdf-forum-subscribe@hdfgroup.org.
To unsubscribe, send a message to hdf-forum-unsubscribe@hdfgroup.org.

Daniel_Kahn1 · April 13, 2009, 7:14pm

Pedro,

My understanding then, is that you have discovered bugs in some
platforms. You note that one place you’ve seen a problem is on
Windows, however, judging from your description of the problem I’d
guess that in most cases the bugs reside either in the compiler or the
libraries, but not in OS itself. Is this a correct assessment?

I think the simplest approach is for h5diff to warn users when they are
running on a buggy platform and that h5diff will work around the
problem at the cost of performance. It would also be nice to issue
warnings during builds or installations.

It would be of service to users if you would post on the HDF Group web
site what you know of platforms that do and don’t have these bugs.
This will make it easier for users to switch to platforms which do not
have the problem and also to complain to vendors to get the problem
fixed.

I suggest not adding any switches to work around these platform bugs
since this problem will ultimately go away. If this seems unavoidable,
then I recommend the switches only be necessary when running on a
platforms which has these bugs.

Cheers,

–dan

Pedro Vicente wrote:

···

hdf-forum-subscribe@hdfgroup.orghdf-forum-unsubscribe@hdfgroup.orgpvn@hdfgroup.orghdf-forum-subscribe@hdfgroup.orghdf-forum-unsubscribe@hdfgroup.org

-- Daniel Kahn
Science Systems and Applications Inc.
301-867-2162

Pedro_Vicente2 · April 15, 2009, 2:21pm

Hello

h5diff seems to have slowed down by 2 orders of magnitude from 1.6.5
to 1.8.1. To wit:

[dws@ice empic]$ time h5diff-1.6.5 unideltaf3p_electrons_1.h5 /ice/ httpd/html/wwwice/vpresults-ice-opt/empic/unideltaf3p/ unideltaf3p_electrons_1.h5 /electrons -r
0 differences found

real 0m0.512s
user 0m0.101s
sys 0m0.411s

[dws@ice empic]$ time h5diff-1.8.1 -r unideltaf3p_electrons_1.h5 /ice/ httpd/html/wwwice/vpresults-ice-opt/empic/unideltaf3p/ unideltaf3p_electrons_1.h5 /electrons

real 0m47.461s
user 0m47.270s
sys 0m0.183s

I just tried 1.8.2 and it's comparable to 1.8.1.

It's pretty much unusable for us now, as a test suite which used to
take about an hour now takes 2.5 hours due to the time increase for
h5diff'ing.

Thanks,
Dave

a correction:

The NaN detection is not the only factor that causes h5diff 1.6.5 versus h5diff 1.8.1 to be slower.

The NaN comparison only accounts for 29 times slower when doing NaN versus not doing NaN detection (this number was obtained trying the file Dave sent on the current 1.8 development branch, enabling and disabling the NaN detection).

About the extra slowness, we don�t know where it comes from. It might be using the 1.8 branch versus the 1.6 library branch, only those particular releases 1.8.1 or 1.8.2, or other.

About using the C library function isNan(), I don�t recall more details about its use (which platforms, trying files cross platforms, etc).

Thanks for all the comments.

Pedro

···

At 10:45 PM 4/11/2009, Pedro Vicente wrote:

At 12:28 PM 12/7/2008, Dave Wade-Stein wrote:

What made h5diff slower between those 2 versions (1.6.5 and 1.8.1) was the introduction of Not a Number (NaN) detection (or more specifically the way we deal with this detection).

We are requesting for comments regarding a new h5diff option that would enable (or disable) that NaN detection. First (1) I explain how h5diff now handles NaN and (2) the new option

1) Detection of NaN

Consider a floating point number X.

Currently, NaN is detected (in some cases), converting X to a string (using the C library function sprintf , computationally a very slow operation) and then doing a string comparison between this string and one of the possible string representations of NaN. This NaN string representation varies between operating systems and can be for example "NAN ", "nan", "1.#SNAN", etc.

The expression " X != X ", is always false for every infinite or finite number X but reverse, true, if X is NaN. So we could theoretically use this expression to detect NaN.

However, in some platforms, this expression does not evaluate to true for NaN, so in these cases, we have to use the string approach.

Here's how the code works

First , we do the test to detect if X is NaN or not

retval = (X!=X);
if (retval==FALSE)
{
Call sprintf
}

For a "regular" number, retval evaluates to FALSE, so the sprintf is always called . So, worst case scenario, a file with no NaNs at all, like your file, sprintf is always called.

If X is a NaN on a platform where that expression correctly detects NaN (linux for example), retval evaluates to TRUE, and the sprintf is *not* called. So, if your file had only NaNs, you wouldn't see that 2 orders of magnitude slow down.

In some platforms (windows for example) that expression does not correctly detect NaN and retval evaluates to FALSE when X is a nan. In that case , the sprintf is always called too.

Here's the way h5diff prints these quantities
Consider the 2 datasets with 6 elements

Array element 0 1 2 3 4 5
Dataset 1 nan 1 nan 1 1 1
Dataset 2 nan nan 1 1 1 1

h5diff now reports this

dataset: </g1/fp17> and </g1/fp18>
size: [6] [6]
position fp17 fp18 difference
------------------------------------------------------------
[ 1 ] 1 -1.#IND 1.#QNAN
[ 2 ] -1.#IND 1 1.#QNAN
2 differences found

That there are 2 differences between the datasets. This result is consistent with all platforms we support . We consider the array position 0 (where both elements are NaN) to be a "no" difference.

2) Option in h5diff to avoid the NaN detection

To avoid these performance issues, we are introducing an option to enable (or disable) NaN detection. We are requesting comments regarding if h5diff should detect NaNs by default or not.

2.1) h5diff compares NaN by default

The new proposed option would be something like

-N, --nan Avoid NaNs detection

Example
./h5diff file1 file2

would compare file1 and file2, doing NaN detection (the default, slow).
To disable NaN detection, one would use

./h5diff -N file1 file2

2.2) h5diff does NOT compare NaN by default

The new proposed option would be something like

-N, --nan Detect NaNs

Example
./h5diff file1 file2

would compare file1 and file2, NOT doing NaN detection (the default, fast).
To enable NaN detection, one would use

./h5diff -N file1 file2

Here are some examples of h5diff output regarding the previous example, this time NOT detecting NaN.

For example, running on linux, we get

dataset: </g1/fp17> and </g1/fp18>
size: [6] [6]
position fp17 fp18 difference
------------------------------------------------------------
[ 0 ] nan nan nan
[ 1 ] 1 nan nan
[ 2 ] nan 1 nan
3 differences found

And running on windows we get

dataset: </g1/fp17> and </g1/fp18>
0 differences found

Note that these results vary between themselves and with the result using NaN detection.

Attached is a document with more details about the way h5diff currently detects NaN.

----------------------------------------------------------------------
This mailing list is for HDF software users discussion.
To subscribe to this list, send a message to hdf-forum-subscribe@hdfgroup.org.
To unsubscribe, send a message to hdf-forum-unsubscribe@hdfgroup.org.

--------------------------------------------------------------
Pedro Vicente (T) 217.265-0311
pvn@hdfgroup.org
The HDF Group. 1901 S. First. Champaign, IL 61820

----------------------------------------------------------------------
This mailing list is for HDF software users discussion.
To subscribe to this list, send a message to hdf-forum-subscribe@hdfgroup.org.
To unsubscribe, send a message to hdf-forum-unsubscribe@hdfgroup.org.

--------------------------------------------------------------
Pedro Vicente (T) 217.265-0311
pvn@hdfgroup.org
The HDF Group. 1901 S. First. Champaign, IL 61820

----------------------------------------------------------------------
This mailing list is for HDF software users discussion.
To subscribe to this list, send a message to hdf-forum-subscribe@hdfgroup.org.
To unsubscribe, send a message to hdf-forum-unsubscribe@hdfgroup.org.

Pedro_Vicente2 · April 12, 2009, 5:11pm

Why can't you use the isnan() function from math.h ?

http://www.opengroup.org/onlinepubs/000095399/functions/isnan.html

Werner

I did try that function, but it turned out to be non-portable. That is, if I generated the NaN on one platform, that function obviously worked, but then when I tried that file on other platform, it did not detect the NaN.

There may be other (possibly faster) ways to detect the NaN, like doing a bit by bit inspection of the number, for example (I did not try that).

The HDF5 distribution has the file mentioned earlier in the example.
It is in

/tools/h5diff/testfiles/h5diff_basic1.h5

To try the example do,

./h5diff -v h5diff_basic1.h5 h5diff_basic1.h5 g1/fp15 g1/fp16
or
/h5diff -v h5diff_basic1.h5 h5diff_basic1.h5 g1/fp17 g1/fp18

The first is for float type, the second for double.

Anything other than the output mentioned earlier, please let us know.

Pedro

···

At 01:30 AM 4/12/2009, Werner Benger wrote:

On Sat, 11 Apr 2009 20:45:49 -0700, Pedro Vicente <pvn@hdfgroup.org> wrote:

Hello

At 12:28 PM 12/7/2008, Dave Wade-Stein wrote:

h5diff seems to have slowed down by 2 orders of magnitude from 1.6.5
to 1.8.1. To wit:

[dws@ice empic]$ time h5diff-1.6.5 unideltaf3p_electrons_1.h5 /ice/
httpd/html/wwwice/vpresults-ice-opt/empic/unideltaf3p/
unideltaf3p_electrons_1.h5 /electrons -r
0 differences found

real 0m0.512s
user 0m0.101s
sys 0m0.411s

[dws@ice empic]$ time h5diff-1.8.1 -r unideltaf3p_electrons_1.h5 /ice/
httpd/html/wwwice/vpresults-ice-opt/empic/unideltaf3p/
unideltaf3p_electrons_1.h5 /electrons

real 0m47.461s
user 0m47.270s
sys 0m0.183s

I just tried 1.8.2 and it's comparable to 1.8.1.

It's pretty much unusable for us now, as a test suite which used to
take about an hour now takes 2.5 hours due to the time increase for
h5diff'ing.

Thanks,
Dave

What made h5diff slower between those 2 versions (1.6.5 and 1.8.1) was
the introduction of Not a Number (NaN) detection (or more specifically
the way we deal with this detection).

We are requesting for comments regarding a new h5diff option that would
enable (or disable) that NaN detection. First (1) I explain how h5diff
now handles NaN and (2) the new option

1) Detection of NaN

Consider a floating point number X.

Currently, NaN is detected (in some cases), converting X to a string
(using the C library function sprintf , computationally a very slow
operation) and then doing a string comparison between this string and
one of the possible string representations of NaN. This NaN string
representation varies between operating systems and can be for example
"NAN ", "nan", "1.#SNAN", etc.

The expression " X != X ", is always false for every infinite or finite
number X but reverse, true, if X is NaN. So we could theoretically use
this expression to detect NaN.

However, in some platforms, this expression does not evaluate to true
for NaN, so in these cases, we have to use the string approach.

Here's how the code works

First , we do the test to detect if X is NaN or not
retval = (X!=X);
if (retval==FALSE)
{
Call sprintf
}
For a "regular" number, retval evaluates to FALSE, so the sprintf is
always called . So, worst case scenario, a file with no NaNs at all,
like your file, sprintf is always called.
If X is a NaN on a platform where that expression correctly detects NaN
(linux for example), retval evaluates to TRUE, and the sprintf is *not*
called. So, if your file had only NaNs, you wouldn't see that 2 orders
of magnitude slow down.
In some platforms (windows for example) that expression does not
correctly detect NaN and retval evaluates to FALSE when X is a nan. In
that case , the sprintf is always called too.

Here's the way h5diff prints these quantities
Consider the 2 datasets with 6 elements

Array element 0 1 2 3 4 5
Dataset 1 nan 1 nan 1 1 1
Dataset 2 nan nan 1 1 1 1
h5diff now reports this
dataset: </g1/fp17> and </g1/fp18>
size: [6] [6]
position fp17 fp18 difference
------------------------------------------------------------
[ 1 ] 1 -1.#IND 1.#QNAN
[ 2 ] -1.#IND 1 1.#QNAN
2 differences found
That there are 2 differences between the datasets. This result is
consistent with all platforms we support . We consider the array
position 0 (where both elements are NaN) to be a "no" difference.

2) Option in h5diff to avoid the NaN detection

To avoid these performance issues, we are introducing an option to
enable (or disable) NaN detection. We are requesting comments regarding
if h5diff should detect NaNs by default or not.

2.1) h5diff compares NaN by default

The new proposed option would be something like

-N, --nan Avoid NaNs detection

Example
./h5diff file1 file2

would compare file1 and file2, doing NaN detection (the default, slow).
To disable NaN detection, one would use

./h5diff -N file1 file2

2.2) h5diff does NOT compare NaN by default

The new proposed option would be something like

-N, --nan Detect NaNs

Example
./h5diff file1 file2

would compare file1 and file2, NOT doing NaN detection (the default,
fast).
To enable NaN detection, one would use

./h5diff -N file1 file2

Here are some examples of h5diff output regarding the previous example,
this time NOT detecting NaN.

For example, running on linux, we get
dataset: </g1/fp17> and </g1/fp18>
size: [6] [6]
position fp17 fp18 difference
------------------------------------------------------------
[ 0 ] nan nan nan
[ 1 ] 1 nan nan
[ 2 ] nan 1 nan
3 differences found
And running on windows we get
dataset: </g1/fp17> and </g1/fp18>
0 differences found
Note that these results vary between themselves and with the result
using NaN detection.

Attached is a document with more details about the way h5diff currently
detects NaN.

----------------------------------------------------------------------
This mailing list is for HDF software users discussion.
To subscribe to this list, send a message to
hdf-forum-subscribe@hdfgroup.org.
To unsubscribe, send a message to hdf-forum-unsubscribe@hdfgroup.org.

--------------------------------------------------------------
Pedro Vicente (T) 217.265-0311
pvn@hdfgroup.org
The HDF Group. 1901 S. First. Champaign, IL 61820

--
___________________________________________________________________________
Dr. Werner Benger <werner@cct.lsu.edu> Visualization Research
Laboratory for Creative Arts and Technology (LCAT)
Center for Computation & Technology at Louisiana State University (CCT/LSU)
239 Johnston Hall, Baton Rouge, Louisiana 70803
Tel.: +1 225 578 4809 Fax.: +1 225 578-5362

--------------------------------------------------------------
Pedro Vicente (T) 217.265-0311
pvn@hdfgroup.org
The HDF Group. 1901 S. First. Champaign, IL 61820

----------------------------------------------------------------------
This mailing list is for HDF software users discussion.
To subscribe to this list, send a message to hdf-forum-subscribe@hdfgroup.org.
To unsubscribe, send a message to hdf-forum-unsubscribe@hdfgroup.org.

Quincey_Koziol · April 14, 2009, 3:13pm

Hi Dave,

Two questions:

1. NaN's should produce (X == X) -> false, but are you sure that they are guaranteed to produce (X != X) -> true?

2. Why can't the builtin NaN-detecting functions be used when they are available, via configure? If you resolved this during configure time for the platforms that have an easy solution, you wouldn't have to use sprintf in most cases, would you?

This goes back to the portability problem that Pedro mentioned in his earlier message: one platform's isnan() routine is not reliable at detecting NaNs that are produced on other platforms, and we don't have a good way to characterize that in order to possibly try to work around it.

It would be possible, if applications were willing to pay the price, to inspect each floating-point value written to a file and (assuming they are in a "native" format for that machine) use the isnan() routine to change NaNs on that machine into a neutral "HDF5 NaN" representation. Then, when reading, we could inspect each floating-point value read in for the HDF5 NaN value and replace it with a native representation for the reading machine. Somehow, I think the overhead for this operation wouldn't be worth it...

Quincey

···

On Apr 13, 2009, at 2:14 PM, Dave Wade-Stein wrote:

Dave

On Apr 11, 2009, at 9:45 PM, Pedro Vicente wrote:

Hello

...

What made h5diff slower between those 2 versions (1.6.5 and 1.8.1) was the introduction of Not a Number (NaN) detection (or more specifically the way we deal with this detection).

We are requesting for comments regarding a new h5diff option that would enable (or disable) that NaN detection. First (1) I explain how h5diff now handles NaN and (2) the new option

1) Detection of NaN

Consider a floating point number X.

Currently, NaN is detected (in some cases), converting X to a string (using the C library function sprintf , computationally a very slow operation) and then doing a string comparison between this string and one of the possible string representations of NaN. This NaN string representation varies between operating systems and can be for example "NAN ", "nan", "1.#SNAN", etc.

The expression " X != X ", is always false for every infinite or finite number X but reverse, true, if X is NaN. So we could theoretically use this expression to detect NaN.

However, in some platforms, this expression does not evaluate to true for NaN, so in these cases, we have to use the string approach.

Here's how the code works

First , we do the test to detect if X is NaN or not

retval = (X!=X);
if (retval==FALSE)
{
Call sprintf
}

For a "regular" number, retval evaluates to FALSE, so the sprintf is always called . So, worst case scenario, a file with no NaNs at all, like your file, sprintf is always called.

If X is a NaN on a platform where that expression correctly detects NaN (linux for example), retval evaluates to TRUE, and the sprintf is *not* called. So, if your file had only NaNs, you wouldn't see that 2 orders of magnitude slow down.

In some platforms (windows for example) that expression does not correctly detect NaN and retval evaluates to FALSE when X is a nan. In that case , the sprintf is always called too.

Here's the way h5diff prints these quantities
Consider the 2 datasets with 6 elements

Array element 0 1 2 3 4 5
Dataset 1 nan 1 nan 1 1 1
Dataset 2 nan nan 1 1 1 1

h5diff now reports this

dataset: </g1/fp17> and </g1/fp18>
size: [6] [6]
position fp17 fp18 difference
------------------------------------------------------------
[ 1 ] 1 -1.#IND 1.#QNAN
[ 2 ] -1.#IND 1 1.#QNAN
2 differences found

That there are 2 differences between the datasets. This result is consistent with all platforms we support . We consider the array position 0 (where both elements are NaN) to be a "no" difference.

2) Option in h5diff to avoid the NaN detection

To avoid these performance issues, we are introducing an option to enable (or disable) NaN detection. We are requesting comments regarding if h5diff should detect NaNs by default or not.

2.1) h5diff compares NaN by default

The new proposed option would be something like

-N, --nan Avoid NaNs detection

Example
./h5diff file1 file2

would compare file1 and file2, doing NaN detection (the default, slow).
To disable NaN detection, one would use

./h5diff -N file1 file2

2.2) h5diff does NOT compare NaN by default

The new proposed option would be something like

-N, --nan Detect NaNs

Example
./h5diff file1 file2

would compare file1 and file2, NOT doing NaN detection (the default, fast).
To enable NaN detection, one would use

./h5diff -N file1 file2

Here are some examples of h5diff output regarding the previous example, this time NOT detecting NaN.

For example, running on linux, we get

dataset: </g1/fp17> and </g1/fp18>
size: [6] [6]
position fp17 fp18 difference
------------------------------------------------------------
[ 0 ] nan nan nan
[ 1 ] 1 nan nan
[ 2 ] nan 1 nan
3 differences found

And running on windows we get

dataset: </g1/fp17> and </g1/fp18>
0 differences found

Note that these results vary between themselves and with the result using NaN detection.

----------------------------------------------------------------------
This mailing list is for HDF software users discussion.
To subscribe to this list, send a message to hdf-forum-subscribe@hdfgroup.org.
To unsubscribe, send a message to hdf-forum-unsubscribe@hdfgroup.org.

gnwiii · April 13, 2009, 8:24pm

Why can't you use the isnan() function from math.h ?

http://www.opengroup.org/onlinepubs/000095399/functions/isnan.html
   Werner
I did try that function, but it turned out to be non-portable. That is, if I generated the NaN on one platform, that function obviously worked, but then when I tried that file on other platform, it did not detect the NaN.

The problem is isnan() is surprising and smells like a bug. I think
isnan() was created
because compilers tend to optimize away ( X !=X). Why does sprintf's NaN
detection work in isnan() fails? For most vendors, the isnan() macro
does type checking
and then calls some type-specific function like __isnand() or
__isnanf(). At least
for i386 these tend to be inlined assembler -- presumably some work
has gone into
finding fast and reliable algorithms.

There may be other (possibly faster) ways to detect the NaN, like doing a bit by bit inspection of the number, for example (I did not try that).

<https://mail.mozilla.org/pipermail/tamarin-devel/2008-February/000325.html>
has some
discussion of the efficiency of various tests for NaN.

···

On Sun, Apr 12, 2009 at 2:11 PM, Pedro Vicente <pvn@hdfgroup.org> wrote:

At 01:30 AM 4/12/2009, Werner Benger wrote:

The HDF5 distribution has the file mentioned earlier in the example.
It is in

/tools/h5diff/testfiles/h5diff_basic1.h5

To try the example do,

./h5diff -v h5diff_basic1.h5 h5diff_basic1.h5 g1/fp15 g1/fp16
or
/h5diff -v h5diff_basic1.h5 h5diff_basic1.h5 g1/fp17 g1/fp18

The first is for float type, the second for double.

Anything other than the output mentioned earlier, please let us know.

Pedro

On Sat, 11 Apr 2009 20:45:49 -0700, Pedro Vicente <pvn@hdfgroup.org> wrote:

Hello

At 12:28 PM 12/7/2008, Dave Wade-Stein wrote:

h5diff seems to have slowed down by 2 orders of magnitude from 1.6.5
to 1.8.1. To wit:

[dws@ice empic]$ time h5diff-1.6.5 unideltaf3p_electrons_1.h5 /ice/
httpd/html/wwwice/vpresults-ice-opt/empic/unideltaf3p/
unideltaf3p_electrons_1.h5 /electrons -r
0 differences found

real 0m0.512s
user 0m0.101s
sys 0m0.411s

[dws@ice empic]$ time h5diff-1.8.1 -r unideltaf3p_electrons_1.h5 /ice/
httpd/html/wwwice/vpresults-ice-opt/empic/unideltaf3p/
unideltaf3p_electrons_1.h5 /electrons

real 0m47.461s
user 0m47.270s
sys 0m0.183s

I just tried 1.8.2 and it's comparable to 1.8.1.

It's pretty much unusable for us now, as a test suite which used to
take about an hour now takes 2.5 hours due to the time increase for
h5diff'ing.

Thanks,
Dave

What made h5diff slower between those 2 versions (1.6.5 and 1.8.1) was
the introduction of Not a Number (NaN) detection (or more specifically
the way we deal with this detection).

We are requesting for comments regarding a new h5diff option that would
enable (or disable) that NaN detection. First (1) I explain how h5diff
now handles NaN and (2) the new option

1) Detection of NaN

Consider a floating point number X.

Currently, NaN is detected (in some cases), converting X to a string
(using the C library function sprintf , computationally a very slow
operation) and then doing a string comparison between this string and
one of the possible string representations of NaN. This NaN string
representation varies between operating systems and can be for example
"NAN ", "nan", "1.#SNAN", etc.

The expression " X != X ", is always false for every infinite or finite
number X but reverse, true, if X is NaN. So we could theoretically use
this expression to detect NaN.

However, in some platforms, this expression does not evaluate to true
for NaN, so in these cases, we have to use the string approach.

Here's how the code works

First , we do the test to detect if X is NaN or not
retval = (X!=X);
if (retval==FALSE)
{
Call sprintf
}
For a "regular" number, retval evaluates to FALSE, so the sprintf is
always called . So, worst case scenario, a file with no NaNs at all,
like your file, sprintf is always called.
If X is a NaN on a platform where that expression correctly detects NaN
(linux for example), retval evaluates to TRUE, and the sprintf is *not*
called. So, if your file had only NaNs, you wouldn't see that 2 orders
of magnitude slow down.
In some platforms (windows for example) that expression does not
correctly detect NaN and retval evaluates to FALSE when X is a nan. In
that case , the sprintf is always called too.

Here's the way h5diff prints these quantities
Consider the 2 datasets with 6 elements

Array element 0 1 2 3 4 5
Dataset 1 nan 1 nan 1 1 1
Dataset 2 nan nan 1 1 1 1
h5diff now reports this
dataset: </g1/fp17> and </g1/fp18>
size: [6] [6]
position fp17 fp18 difference
------------------------------------------------------------
[ 1 ] 1 -1.#IND 1.#QNAN
[ 2 ] -1.#IND 1 1.#QNAN
2 differences found
That there are 2 differences between the datasets. This result is
consistent with all platforms we support . We consider the array
position 0 (where both elements are NaN) to be a "no" difference.

2) Option in h5diff to avoid the NaN detection

To avoid these performance issues, we are introducing an option to
enable (or disable) NaN detection. We are requesting comments regarding
if h5diff should detect NaNs by default or not.

2.1) h5diff compares NaN by default

The new proposed option would be something like

-N, --nan Avoid NaNs detection

Example
./h5diff file1 file2

would compare file1 and file2, doing NaN detection (the default, slow).
To disable NaN detection, one would use

./h5diff -N file1 file2

2.2) h5diff does NOT compare NaN by default

The new proposed option would be something like

-N, --nan Detect NaNs

Example
./h5diff file1 file2

would compare file1 and file2, NOT doing NaN detection (the default,
fast).
To enable NaN detection, one would use

./h5diff -N file1 file2

Here are some examples of h5diff output regarding the previous example,
this time NOT detecting NaN.

For example, running on linux, we get
dataset: </g1/fp17> and </g1/fp18>
size: [6] [6]
position fp17 fp18 difference
------------------------------------------------------------
[ 0 ] nan nan nan
[ 1 ] 1 nan nan
[ 2 ] nan 1 nan
3 differences found
And running on windows we get
dataset: </g1/fp17> and </g1/fp18>
0 differences found
Note that these results vary between themselves and with the result
using NaN detection.

Attached is a document with more details about the way h5diff currently
detects NaN.

----------------------------------------------------------------------
This mailing list is for HDF software users discussion.
To subscribe to this list, send a message to
hdf-forum-subscribe@hdfgroup.org.
To unsubscribe, send a message to hdf-forum-unsubscribe@hdfgroup.org.

--------------------------------------------------------------
Pedro Vicente (T) 217.265-0311
pvn@hdfgroup.org
The HDF Group. 1901 S. First. Champaign, IL 61820

--
___________________________________________________________________________
Dr. Werner Benger <werner@cct.lsu.edu> Visualization Research
Laboratory for Creative Arts and Technology (LCAT)
Center for Computation & Technology at Louisiana State University (CCT/LSU)
239 Johnston Hall, Baton Rouge, Louisiana 70803
Tel.: +1 225 578 4809 Fax.: +1 225 578-5362

--------------------------------------------------------------
Pedro Vicente (T) 217.265-0311
pvn@hdfgroup.org
The HDF Group. 1901 S. First. Champaign, IL 61820

----------------------------------------------------------------------
This mailing list is for HDF software users discussion.
To subscribe to this list, send a message to hdf-forum-subscribe@hdfgroup.org.
To unsubscribe, send a message to hdf-forum-unsubscribe@hdfgroup.org.

--
George N. White III <aa056@chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia

----------------------------------------------------------------------
This mailing list is for HDF software users discussion.
To subscribe to this list, send a message to hdf-forum-subscribe@hdfgroup.org.
To unsubscribe, send a message to hdf-forum-unsubscribe@hdfgroup.org.

Dave_Wade-Stein · April 14, 2009, 3:17pm

But how hard is it to determine on the bad platform or not at configure time? We do that all the time with our software and have specific Windows code which is compiled in.

Dave

···

On Apr 14, 2009, at 9:13 AM, Quincey Koziol wrote:

Hi Dave,

On Apr 13, 2009, at 2:14 PM, Dave Wade-Stein wrote:

Two questions:

1. NaN's should produce (X == X) -> false, but are you sure that they are guaranteed to produce (X != X) -> true?

2. Why can't the builtin NaN-detecting functions be used when they are available, via configure? If you resolved this during configure time for the platforms that have an easy solution, you wouldn't have to use sprintf in most cases, would you?

  This goes back to the portability problem that Pedro mentioned in his earlier message: one platform's isnan() routine is not reliable at detecting NaNs that are produced on other platforms, and we don't have a good way to characterize that in order to possibly try to work around it.

  It would be possible, if applications were willing to pay the price, to inspect each floating-point value written to a file and (assuming they are in a "native" format for that machine) use the isnan() routine to change NaNs on that machine into a neutral "HDF5 NaN" representation. Then, when reading, we could inspect each floating-point value read in for the HDF5 NaN value and replace it with a native representation for the reading machine. Somehow, I think the overhead for this operation wouldn't be worth it...

  Quincey

Dave

On Apr 11, 2009, at 9:45 PM, Pedro Vicente wrote:

Hello

...

What made h5diff slower between those 2 versions (1.6.5 and 1.8.1) was the introduction of Not a Number (NaN) detection (or more specifically the way we deal with this detection).

We are requesting for comments regarding a new h5diff option that would enable (or disable) that NaN detection. First (1) I explain how h5diff now handles NaN and (2) the new option

1) Detection of NaN

Consider a floating point number X.

Currently, NaN is detected (in some cases), converting X to a string (using the C library function sprintf , computationally a very slow operation) and then doing a string comparison between this string and one of the possible string representations of NaN. This NaN string representation varies between operating systems and can be for example "NAN ", "nan", "1.#SNAN", etc.

The expression " X != X ", is always false for every infinite or finite number X but reverse, true, if X is NaN. So we could theoretically use this expression to detect NaN.

However, in some platforms, this expression does not evaluate to true for NaN, so in these cases, we have to use the string approach.

Here's how the code works

First , we do the test to detect if X is NaN or not

retval = (X!=X);
if (retval==FALSE)
{
  Call sprintf
}

For a "regular" number, retval evaluates to FALSE, so the sprintf is always called . So, worst case scenario, a file with no NaNs at all, like your file, sprintf is always called.

If X is a NaN on a platform where that expression correctly detects NaN (linux for example), retval evaluates to TRUE, and the sprintf is *not* called. So, if your file had only NaNs, you wouldn't see that 2 orders of magnitude slow down.

In some platforms (windows for example) that expression does not correctly detect NaN and retval evaluates to FALSE when X is a nan. In that case , the sprintf is always called too.

Here's the way h5diff prints these quantities
Consider the 2 datasets with 6 elements

Array element 0 1 2 3 4 5
Dataset 1 nan 1 nan 1 1 1
Dataset 2 nan nan 1 1 1 1

h5diff now reports this

dataset: </g1/fp17> and </g1/fp18>
size: [6] [6]
position fp17 fp18 difference
------------------------------------------------------------
[ 1 ] 1 -1.#IND 1.#QNAN
[ 2 ] -1.#IND 1 1.#QNAN
2 differences found

That there are 2 differences between the datasets. This result is consistent with all platforms we support . We consider the array position 0 (where both elements are NaN) to be a "no" difference.

2) Option in h5diff to avoid the NaN detection

To avoid these performance issues, we are introducing an option to enable (or disable) NaN detection. We are requesting comments regarding if h5diff should detect NaNs by default or not.

2.1) h5diff compares NaN by default

The new proposed option would be something like

-N, --nan Avoid NaNs detection

Example
./h5diff file1 file2

would compare file1 and file2, doing NaN detection (the default, slow).
To disable NaN detection, one would use

./h5diff -N file1 file2

2.2) h5diff does NOT compare NaN by default

The new proposed option would be something like

-N, --nan Detect NaNs

Example
./h5diff file1 file2

would compare file1 and file2, NOT doing NaN detection (the default, fast).
To enable NaN detection, one would use

./h5diff -N file1 file2

Here are some examples of h5diff output regarding the previous example, this time NOT detecting NaN.

For example, running on linux, we get

dataset: </g1/fp17> and </g1/fp18>
size: [6] [6]
position fp17 fp18 difference
------------------------------------------------------------
[ 0 ] nan nan nan
[ 1 ] 1 nan nan
[ 2 ] nan 1 nan
3 differences found

And running on windows we get

dataset: </g1/fp17> and </g1/fp18>
0 differences found

Note that these results vary between themselves and with the result using NaN detection.

werner · April 14, 2009, 5:15pm

It seems the (X==X)->false test (that most isnan()'s seem to implement) doesn't
recognize non-native NaN bit patterns on all platforms. Which sounds mostly like
a bug in the CPU hardware then, as it doesn't implement the IEEE standard correctly.

However, an HDF5-provided H5isnan() function which does a bit-pattern test instead
of the (X==X)-> false test should do the job, since if the bit-pattern test would
not work, then it won't be an IEEE NaN anyway.

A related question might be if one wants to distinguish among different kinds
of NaN's, like signaling and non-signaling.

Werner

···

On Tue, 14 Apr 2009 08:17:29 -0700, Dave Wade-Stein <dws@txcorp.com> wrote:

But how hard is it to determine on the bad platform or not at configure time? We do that all the time with our software and have specific Windows code which is compiled in.

Dave

On Apr 14, 2009, at 9:13 AM, Quincey Koziol wrote:

Hi Dave,

On Apr 13, 2009, at 2:14 PM, Dave Wade-Stein wrote:

Two questions:

1. NaN's should produce (X == X) -> false, but are you sure that they are guaranteed to produce (X != X) -> true?

2. Why can't the builtin NaN-detecting functions be used when they are available, via configure? If you resolved this during configure time for the platforms that have an easy solution, you wouldn't have to use sprintf in most cases, would you?

  This goes back to the portability problem that Pedro mentioned in his earlier message: one platform's isnan() routine is not reliable at detecting NaNs that are produced on other platforms, and we don't have a good way to characterize that in order to possibly try to work around it.

  It would be possible, if applications were willing to pay the price, to inspect each floating-point value written to a file and (assuming they are in a "native" format for that machine) use the isnan() routine to change NaNs on that machine into a neutral "HDF5 NaN" representation. Then, when reading, we could inspect each floating-point value read in for the HDF5 NaN value and replace it with a native representation for the reading machine. Somehow, I think the overhead for this operation wouldn't be worth it...

  Quincey

Dave

On Apr 11, 2009, at 9:45 PM, Pedro Vicente wrote:

Hello

...

What made h5diff slower between those 2 versions (1.6.5 and 1.8.1) was the introduction of Not a Number (NaN) detection (or more specifically the way we deal with this detection).

We are requesting for comments regarding a new h5diff option that would enable (or disable) that NaN detection. First (1) I explain how h5diff now handles NaN and (2) the new option

1) Detection of NaN

Consider a floating point number X.

Currently, NaN is detected (in some cases), converting X to a string (using the C library function sprintf , computationally a very slow operation) and then doing a string comparison between this string and one of the possible string representations of NaN. This NaN string representation varies between operating systems and can be for example "NAN ", "nan", "1.#SNAN", etc.

The expression " X != X ", is always false for every infinite or finite number X but reverse, true, if X is NaN. So we could theoretically use this expression to detect NaN.

However, in some platforms, this expression does not evaluate to true for NaN, so in these cases, we have to use the string approach.

Here's how the code works

First , we do the test to detect if X is NaN or not

retval = (X!=X);
if (retval==FALSE)
{
  Call sprintf
}

For a "regular" number, retval evaluates to FALSE, so the sprintf is always called . So, worst case scenario, a file with no NaNs at all, like your file, sprintf is always called.

If X is a NaN on a platform where that expression correctly detects NaN (linux for example), retval evaluates to TRUE, and the sprintf is *not* called. So, if your file had only NaNs, you wouldn't see that 2 orders of magnitude slow down.

In some platforms (windows for example) that expression does not correctly detect NaN and retval evaluates to FALSE when X is a nan. In that case , the sprintf is always called too.

Here's the way h5diff prints these quantities
Consider the 2 datasets with 6 elements

Array element 0 1 2 3 4 5
Dataset 1 nan 1 nan 1 1 1
Dataset 2 nan nan 1 1 1 1

h5diff now reports this

dataset: </g1/fp17> and </g1/fp18>
size: [6] [6]
position fp17 fp18 difference
------------------------------------------------------------
[ 1 ] 1 -1.#IND 1.#QNAN
[ 2 ] -1.#IND 1 1.#QNAN
2 differences found

That there are 2 differences between the datasets. This result is consistent with all platforms we support . We consider the array position 0 (where both elements are NaN) to be a "no" difference.

2) Option in h5diff to avoid the NaN detection

To avoid these performance issues, we are introducing an option to enable (or disable) NaN detection. We are requesting comments regarding if h5diff should detect NaNs by default or not.

2.1) h5diff compares NaN by default

The new proposed option would be something like

-N, --nan Avoid NaNs detection

Example
./h5diff file1 file2

would compare file1 and file2, doing NaN detection (the default, slow).
To disable NaN detection, one would use

./h5diff -N file1 file2

2.2) h5diff does NOT compare NaN by default

The new proposed option would be something like

-N, --nan Detect NaNs

Example
./h5diff file1 file2

would compare file1 and file2, NOT doing NaN detection (the default, fast).
To enable NaN detection, one would use

./h5diff -N file1 file2

Here are some examples of h5diff output regarding the previous example, this time NOT detecting NaN.

For example, running on linux, we get

dataset: </g1/fp17> and </g1/fp18>
size: [6] [6]
position fp17 fp18 difference
------------------------------------------------------------
[ 0 ] nan nan nan
[ 1 ] 1 nan nan
[ 2 ] nan 1 nan
3 differences found

And running on windows we get

dataset: </g1/fp17> and </g1/fp18>
0 differences found

Note that these results vary between themselves and with the result using NaN detection.

----------------------------------------------------------------------
This mailing list is for HDF software users discussion.
To subscribe to this list, send a message to hdf-forum-subscribe@hdfgroup.org.
To unsubscribe, send a message to hdf-forum-unsubscribe@hdfgroup.org.

--
___________________________________________________________________________
Dr. Werner Benger <werner@cct.lsu.edu> Visualization Research
Laboratory for Creative Arts and Technology (LCAT)
Center for Computation & Technology at Louisiana State University (CCT/LSU)
239 Johnston Hall, Baton Rouge, Louisiana 70803
Tel.: +1 225 578 4809 Fax.: +1 225 578-5362

werner · April 13, 2009, 8:54pm

Why can't you use the isnan() function from math.h ?

http://www.opengroup.org/onlinepubs/000095399/functions/isnan.html
   Werner
I did try that function, but it turned out to be non-portable. That is, if I generated the NaN on one platform, that function obviously worked, but then when I tried that file on other platform, it did not detect the NaN.
The problem is isnan() is surprising and smells like a bug. I think
isnan() was created
because compilers tend to optimize away ( X !=X). Why does sprintf's NaN
detection work in isnan() fails? For most vendors, the isnan() macro
does type checking
and then calls some type-specific function like __isnand() or
__isnanf(). At least
for i386 these tend to be inlined assembler -- presumably some work
has gone into
finding fast and reliable algorithms.

So the problem doesn't seem to be to detect NaN's when they stem from a
file that was generated on the same platform where the test is executed?

Certainly in this case isnan() should be used. If reading numbers from
a file with a different bitlayout than the local platform, and they are
not recognized as nan's, then it seems this is a problem of the bit conversion
when reading those non-native NaN's. They should be converted into
machine-NaN's like little-endian is converted into big-endian, and vice versa,
such that also application code - independent of h5diff - can use the
system-provided isnan() function. That would be the behavior that I would
expect from HDF5 and its data transformations.

There may be other (possibly faster) ways to detect the NaN, like doing a bit by bit inspection of the number, for example (I did not try that).

<https://mail.mozilla.org/pipermail/tamarin-devel/2008-February/000325.html>
has some
discussion of the efficiency of various tests for NaN.

It seems they came to the final conclusion to do a bit-testing, like checking
for the Nan definition pattern in the IEEE standard:

http://en.wikipedia.org/wiki/NaN

In the case of reading non-platform native NaN's, there would need to be
an additional endianness-check, but otherwise, as long as NaN's are part
of the IEEE standard, would there be any reason not to use this bit checking
but rely on a c libraries's sprintf() function instead? Is there a need to
support non-IEEE NaN's (do such exist?) ?

Werner

···

On Mon, 13 Apr 2009 13:24:14 -0700, George N. White III <gnwiii@gmail.com> wrote:

On Sun, Apr 12, 2009 at 2:11 PM, Pedro Vicente <pvn@hdfgroup.org> wrote:

At 01:30 AM 4/12/2009, Werner Benger wrote:

The HDF5 distribution has the file mentioned earlier in the example.
It is in

/tools/h5diff/testfiles/h5diff_basic1.h5

To try the example do,

./h5diff -v h5diff_basic1.h5 h5diff_basic1.h5 g1/fp15 g1/fp16
or
/h5diff -v h5diff_basic1.h5 h5diff_basic1.h5 g1/fp17 g1/fp18

The first is for float type, the second for double.

Anything other than the output mentioned earlier, please let us know.

Pedro

On Sat, 11 Apr 2009 20:45:49 -0700, Pedro Vicente <pvn@hdfgroup.org> >>> wrote:

Hello

At 12:28 PM 12/7/2008, Dave Wade-Stein wrote:

h5diff seems to have slowed down by 2 orders of magnitude from 1.6.5
to 1.8.1. To wit:

[dws@ice empic]$ time h5diff-1.6.5 unideltaf3p_electrons_1.h5 /ice/
httpd/html/wwwice/vpresults-ice-opt/empic/unideltaf3p/
unideltaf3p_electrons_1.h5 /electrons -r
0 differences found

real 0m0.512s
user 0m0.101s
sys 0m0.411s

[dws@ice empic]$ time h5diff-1.8.1 -r unideltaf3p_electrons_1.h5 /ice/
httpd/html/wwwice/vpresults-ice-opt/empic/unideltaf3p/
unideltaf3p_electrons_1.h5 /electrons

real 0m47.461s
user 0m47.270s
sys 0m0.183s

I just tried 1.8.2 and it's comparable to 1.8.1.

It's pretty much unusable for us now, as a test suite which used to
take about an hour now takes 2.5 hours due to the time increase for
h5diff'ing.

Thanks,
Dave

What made h5diff slower between those 2 versions (1.6.5 and 1.8.1) was
the introduction of Not a Number (NaN) detection (or more specifically
the way we deal with this detection).

We are requesting for comments regarding a new h5diff option that would
enable (or disable) that NaN detection. First (1) I explain how h5diff
now handles NaN and (2) the new option

1) Detection of NaN

Consider a floating point number X.

Currently, NaN is detected (in some cases), converting X to a string
(using the C library function sprintf , computationally a very slow
operation) and then doing a string comparison between this string and
one of the possible string representations of NaN. This NaN string
representation varies between operating systems and can be for example
"NAN ", "nan", "1.#SNAN", etc.

The expression " X != X ", is always false for every infinite or finite
number X but reverse, true, if X is NaN. So we could theoretically use
this expression to detect NaN.

However, in some platforms, this expression does not evaluate to true
for NaN, so in these cases, we have to use the string approach.

Here's how the code works

First , we do the test to detect if X is NaN or not
retval = (X!=X);
if (retval==FALSE)
{
Call sprintf
}
For a "regular" number, retval evaluates to FALSE, so the sprintf is
always called . So, worst case scenario, a file with no NaNs at all,
like your file, sprintf is always called.
If X is a NaN on a platform where that expression correctly detects NaN
(linux for example), retval evaluates to TRUE, and the sprintf is *not*
called. So, if your file had only NaNs, you wouldn't see that 2 orders
of magnitude slow down.
In some platforms (windows for example) that expression does not
correctly detect NaN and retval evaluates to FALSE when X is a nan. In
that case , the sprintf is always called too.

Here's the way h5diff prints these quantities
Consider the 2 datasets with 6 elements

Array element 0 1 2 3 4 5
Dataset 1 nan 1 nan 1 1 1
Dataset 2 nan nan 1 1 1 1
h5diff now reports this
dataset: </g1/fp17> and </g1/fp18>
size: [6] [6]
position fp17 fp18 difference
------------------------------------------------------------
[ 1 ] 1 -1.#IND 1.#QNAN
[ 2 ] -1.#IND 1 1.#QNAN
2 differences found
That there are 2 differences between the datasets. This result is
consistent with all platforms we support . We consider the array
position 0 (where both elements are NaN) to be a "no" difference.

2) Option in h5diff to avoid the NaN detection

To avoid these performance issues, we are introducing an option to
enable (or disable) NaN detection. We are requesting comments regarding
if h5diff should detect NaNs by default or not.

2.1) h5diff compares NaN by default

The new proposed option would be something like

-N, --nan Avoid NaNs detection

Example
./h5diff file1 file2

would compare file1 and file2, doing NaN detection (the default, slow).
To disable NaN detection, one would use

./h5diff -N file1 file2

2.2) h5diff does NOT compare NaN by default

The new proposed option would be something like

-N, --nan Detect NaNs

Example
./h5diff file1 file2

would compare file1 and file2, NOT doing NaN detection (the default,
fast).
To enable NaN detection, one would use

./h5diff -N file1 file2

Here are some examples of h5diff output regarding the previous example,
this time NOT detecting NaN.

For example, running on linux, we get
dataset: </g1/fp17> and </g1/fp18>
size: [6] [6]
position fp17 fp18 difference
------------------------------------------------------------
[ 0 ] nan nan nan
[ 1 ] 1 nan nan
[ 2 ] nan 1 nan
3 differences found
And running on windows we get
dataset: </g1/fp17> and </g1/fp18>
0 differences found
Note that these results vary between themselves and with the result
using NaN detection.

Attached is a document with more details about the way h5diff currently
detects NaN.

----------------------------------------------------------------------
This mailing list is for HDF software users discussion.
To subscribe to this list, send a message to
hdf-forum-subscribe@hdfgroup.org.
To unsubscribe, send a message to hdf-forum-unsubscribe@hdfgroup.org.

--------------------------------------------------------------
Pedro Vicente (T) 217.265-0311
pvn@hdfgroup.org
The HDF Group. 1901 S. First. Champaign, IL 61820

--
___________________________________________________________________________
Dr. Werner Benger <werner@cct.lsu.edu> Visualization Research
Laboratory for Creative Arts and Technology (LCAT)
Center for Computation & Technology at Louisiana State University (CCT/LSU)
239 Johnston Hall, Baton Rouge, Louisiana 70803
Tel.: +1 225 578 4809 Fax.: +1 225 578-5362

--------------------------------------------------------------
Pedro Vicente (T) 217.265-0311
pvn@hdfgroup.org
The HDF Group. 1901 S. First. Champaign, IL 61820

----------------------------------------------------------------------
This mailing list is for HDF software users discussion.
To subscribe to this list, send a message to hdf-forum-subscribe@hdfgroup.org.
To unsubscribe, send a message to hdf-forum-unsubscribe@hdfgroup.org.

--
___________________________________________________________________________
Dr. Werner Benger <werner@cct.lsu.edu> Visualization Research
Laboratory for Creative Arts and Technology (LCAT)
Center for Computation & Technology at Louisiana State University (CCT/LSU)
239 Johnston Hall, Baton Rouge, Louisiana 70803
Tel.: +1 225 578 4809 Fax.: +1 225 578-5362

----------------------------------------------------------------------
This mailing list is for HDF software users discussion.
To subscribe to this list, send a message to hdf-forum-subscribe@hdfgroup.org.
To unsubscribe, send a message to hdf-forum-unsubscribe@hdfgroup.org.

Daniel_Kahn1 · April 13, 2009, 9:19pm

Werner Benger wrote:

Why can't you use the isnan() function from math.h ?

http://www.opengroup.org/onlinepubs/000095399/functions/isnan.html

Werner

I did try that function, but it turned out to be non-portable. That is, if I generated the NaN on one platform, that function obviously worked, but then when I tried that file on other platform, it did not detect the NaN.

The problem is isnan() is surprising and smells like a bug. I think
isnan() was created
because compilers tend to optimize away ( X !=X). Why does sprintf's NaN
detection work in isnan() fails? For most vendors, the isnan() macro
does type checking
and then calls some type-specific function like __isnand() or
__isnanf(). At least
for i386 these tend to be inlined assembler -- presumably some work
has gone into
finding fast and reliable algorithms.

So the problem doesn't seem to be to detect NaN's when they stem from a
file that was generated on the same platform where the test is executed?

Certainly in this case isnan() should be used. If reading numbers from
a file with a different bitlayout than the local platform, and they are
not recognized as nan's, then it seems this is a problem of the bit conversion
when reading those non-native NaN's. They should be converted into
machine-NaN's like little-endian is converted into big-endian, and vice versa,
such that also application code - independent of h5diff - can use the
system-provided isnan() function. That would be the behavior that I would
expect from HDF5 and its data transformations.

Werner,

I don't think this is an endian issue. The HDF5 library should have taken care of that. On the Wikipedia page you reference you'll see the NaN bitmap laid out with a string of X's indicating "don't care." The string of bits for NaN is not unique, different FPU's can produce different strings. Thus, a correctly written isNaN() will check all possibilities, which probably means applying a mask. An incorrectly written NaN might just use integer == with the FPU's native representation of NaN as the other argument (integer == because a float == will follow the IEEE rules for floats).

I think Pedro's compliant is when isNaN() doesn't perform the correct check--not that the NaN word itself is corrupted. Ultimately the best route might be handing the checks by treating the REAL value as a bit string and doing the masks and compares using the standard as a guide. Pity though, since the isNaN() is supposed to work.

Cheers,
--dan

···

On Mon, 13 Apr 2009 13:24:14 -0700, George N. White III > <gnwiii@gmail.com> wrote:

On Sun, Apr 12, 2009 at 2:11 PM, Pedro Vicente <pvn@hdfgroup.org> wrote:

At 01:30 AM 4/12/2009, Werner Benger wrote:

--
Daniel Kahn
Science Systems and Applications Inc.
301-867-2162

----------------------------------------------------------------------
This mailing list is for HDF software users discussion.
To subscribe to this list, send a message to hdf-forum-subscribe@hdfgroup.org.
To unsubscribe, send a message to hdf-forum-unsubscribe@hdfgroup.org.