[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 971021: netcdf 3.3 and C++

> >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