This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
> >To: address@hidden > >From: Charles Martin <address@hidden> > >Subject: netcdf 3.3 and C++ > >Organization: National Center for Atmospheric Research > >Keywords: 199710211609.KAA28055 > > I'm very keen to take advantage of the 2x > improvement in processing that netcdf 3.3 > has compared to 2.4. However, I am > using the c++ interface. I assume that the > efficiency improvements should apply to > this as well, in spite of the fact that > the c++ interface has not been changed since > v 2.4. Is this assumption correct? Charlie: This is correct. The significant changes are in the underlying C layer. > The reason I mention this is that I have not > noticed an outright improvement since changing > to 3.3.1. However, my code is fairly involved, and so > it may be difficult for me to measure a change. > > By the way, I am running on Solaris x86. Both > 2.4 and 3.3.1 have worked just fine for me. > > Thanks, > Charlie Martin > ATD I've been working with Gordon McClean from ATD on some performance problems in netcdf-3 that he noted with his pattern of usage. It turns out that wall clock time could get very bad (compared to netcdf-2) if access is over a busy NFS server, especially when doing netcdf "redefinition". I believe this is fixed now, but we haven't made an new general release yet. (Gordon is at sea, and hasn't had a chance to check it out.) If you want to give it a go, grab ftp://ftp.unidata.ucar.edu/pub/netcdf/netcdf-3.4atd.tar.Z. Gordon is also using the C++ interface. The main performance improvement change between netcdf 2.x and 3.x is that the "primitive" netcdf data conversion operations operate on arrays rather than looping over the elements and calling the appropriate single element conversion function via a function pointer. The changes should show more significant improvement on machines where conversion of data is neccessary (like CRAY or x86 byte swapping) and where the access pattern deals in chunks of data. In the worst case (no coversions and singleton data access), netcdf-3 might theoretically be a fuzz slower, but I think other improvements in netcdf-3 would wash that out. -glenn