When you dereference a region reference object, presumably the library internally will open the referenced data set. So where does it get its dataset access property list from?
This is a significant issue for my project, where we have data sets of region references to another dataset. I've found that the performance on reading the dereferenced region is not very good. I've tried tweaking caching and chunking settings on the write side of things, but I see no way to change the chunk cache settings on reading the data. Or am I supposed to set the chunk cache settings for the transfer property list used by the H5Dread call?
When you dereference a region reference object, presumably the library internally will open the referenced data set. So where does it get its dataset access property list from?
Ah, good point, there is no way to pass an access property list to the H5Rdereference() call. I've added a request to our issue tracker to add this. Right now, it passes the default property list to the dataset open call.
This is a significant issue for my project, where we have data sets of region references to another dataset. I've found that the performance on reading the dereferenced region is not very good. I've tried tweaking caching and chunking settings on the write side of things, but I see no way to change the chunk cache settings on reading the data. Or am I supposed to set the chunk cache settings for the transfer property list used by the H5Dread call?
Or, we could allow the cache settings to be adjusted "on the fly" while a dataset was open. (But I'd lean toward the option above)
... but it's for HDF4. Any chance of an HDF5-1.8.x update? There doesn't seem to be any performance-related stuff in the user's guide for HDF5, at least not in any obvious fashion. Perhaps I just missed it.
Quincey Koziol wrote:
···
Hi John,
On Sep 17, 2010, at 5:36 PM, John Knutson wrote:
When you dereference a region reference object, presumably the library internally will open the referenced data set. So where does it get its dataset access property list from?
Ah, good point, there is no way to pass an access property list to the H5Rdereference() call. I've added a request to our issue tracker to add this. Right now, it passes the default property list to the dataset open call.
... but it's for HDF4. Any chance of an HDF5-1.8.x update? There doesn't seem to be any performance-related stuff in the user's guide for HDF5, at least not in any obvious fashion. Perhaps I just missed it.
We are actively working on a revision to the HDF5 Users Guide, but I'm not certain what the schedule for rollout is. Perhaps Mark Evans (on our team) can add some details... (I'm out of the office today, otherwise I'd just ask him myself
Quincey
···
On Sep 21, 2010, at 5:48 PM, John Knutson wrote:
Quincey Koziol wrote:
Hi John,
On Sep 17, 2010, at 5:36 PM, John Knutson wrote:
When you dereference a region reference object, presumably the library internally will open the referenced data set. So where does it get its dataset access property list from?
Ah, good point, there is no way to pass an access property list to the H5Rdereference() call. I've added a request to our issue tracker to add this. Right now, it passes the default property list to the dataset open call.
I have added to my list of tasks doing an update for the HDF4 doc on performance. This update probably won't be in the next revision of the User's Guide, but I'll check to see if it's possible.
... but it's for HDF4. Any chance of an HDF5-1.8.x update? There doesn't seem to be any performance-related stuff in the user's guide for HDF5, at least not in any obvious fashion. Perhaps I just missed it.
We are actively working on a revision to the HDF5 Users Guide, but I'm not certain what the schedule for rollout is. Perhaps Mark Evans (on our team) can add some details... (I'm out of the office today, otherwise I'd just ask him myself
Intel(R) Visual Fortran Intel(R) 64 Compiler Professional for applications runni
ng on Intel(R) 64, Version 11.1 Build 20100203 Package ID: w_cprof_p_11.1.060
Copyright (C) 1985-2010 Intel Corporation. All rights reserved.
: catastrophic error: Variable FLOATING_TYPES too large for NTCOFF. Bigger than
2GB. Use heap instead
in file test.obj, line 0, column 0
I have added to my list of tasks doing an update for the HDF4 doc on performance. This update probably won't be in the next revision of the User's Guide, but I'll check to see if it's possible.
... but it's for HDF4. Any chance of an HDF5-1.8.x update? There doesn't seem to be any performance-related stuff in the user's guide for HDF5, at least not in any obvious fashion. Perhaps I just missed it.
We are actively working on a revision to the HDF5 Users Guide, but I'm not certain what the schedule for rollout is. Perhaps Mark Evans (on our team) can add some details... (I'm out of the office today, otherwise I'd just ask him myself
Cyril,
Note that hdf5-1.8.5(-patch1) was built with VS2008 and Intel Fortran 10.1. There may be an issue with IVF10 vs IVF11. I know there is a difference in project files.
Allen
···
Hello,
I'd like to know if there is anybody using
Windows XP64
Intel fortran 11.1
hdf5-1.8.5-patch1-win64
successfully ?
Because I have a compilation issue with HDF5 under these conditions.
When I try to compile a simple test program :
Intel(R) Visual Fortran Intel(R) 64 Compiler Professional for applications runni
ng on Intel(R) 64, Version 11.1 Build 20100203 Package ID: w_cprof_p_11.1.060
Copyright (C) 1985-2010 Intel Corporation. All rights reserved.
: catastrophic error: Variable FLOATING_TYPES too large for NTCOFF. Bigger than
2GB. Use heap instead
in file test.obj, line 0, column 0
I have added to my list of tasks doing an update for the HDF4 doc on performance. This update probably won't be in the next revision of the User's Guide, but I'll check to see if it's possible.
... but it's for HDF4. Any chance of an HDF5-1.8.x update? There doesn't seem to be any performance-related stuff in the user's guide for HDF5, at least not in any obvious fashion. Perhaps I just missed it.
We are actively working on a revision to the HDF5 Users Guide, but I'm not certain what the schedule for rollout is. Perhaps Mark Evans (on our team) can add some details... (I'm out of the office today, otherwise I'd just ask him myself
You are right and that is why I wonder if i am the only person
exprementing this issue.
( I have not VS2008 for windows 64 to build HDF5 and I have not ifort 10.1 )
Regards,
Cyril.
Le 23/09/2010 16:41, Allen D Byrne a �crit :
···
Cyril,
Note that hdf5-1.8.5(-patch1) was built with VS2008 and Intel Fortran 10.1. There may be an issue with IVF10 vs IVF11. I know there is a difference in project files.
Allen
Hello,
I'd like to know if there is anybody using
Windows XP64
Intel fortran 11.1
hdf5-1.8.5-patch1-win64
successfully ?
Because I have a compilation issue with HDF5 under these conditions.
When I try to compile a simple test program :
Intel(R) Visual Fortran Intel(R) 64 Compiler Professional for applications runni
ng on Intel(R) 64, Version 11.1 Build 20100203 Package ID: w_cprof_p_11.1.060
Copyright (C) 1985-2010 Intel Corporation. All rights reserved.
: catastrophic error: Variable FLOATING_TYPES too large for NTCOFF. Bigger than
2GB. Use heap instead
in file test.obj, line 0, column 0
I have added to my list of tasks doing an update for the HDF4 doc on performance. This update probably won't be in the next revision of the User's Guide, but I'll check to see if it's possible.
... but it's for HDF4. Any chance of an HDF5-1.8.x update? There doesn't seem to be any performance-related stuff in the user's guide for HDF5, at least not in any obvious fashion. Perhaps I just missed it.
We are actively working on a revision to the HDF5 Users Guide, but I'm not certain what the schedule for rollout is. Perhaps Mark Evans (on our team) can add some details... (I'm out of the office today, otherwise I'd just ask him myself
