Dynamic, multi-dimensional arrays
csc14us
I am a programmer with a strong interest in high-performance numerical
computation. I know both Fortran 95 and C++ well and think they're
both good tools for numerics. However, I think F95 has one very big
edge on C++, which is built-in support for high-performance,
dynamically allocatable arrays of 2 or more dimensions. Yes, you can
find libraries that do it in C++ in various places. But they're
scattered, not standard, and you never know if you can trust them.
For example, how well has boost::multi_array been tested? It provides
a natural interface, yes, but how does it stack up in performance? If
it's slow, it's no use.
I'm not asking you guys where to find fast C++ array libraries. We
know the answer to this. My concern is there's no standard library
support for numerical programmers, in which the ISO committee has
carefully filtered the various proposals and picked the one that meets
our needs best. I think this is very disappointing and makes it hard
for me to want to start a heavy-duty project that uses multi-
dimensional arrays (think atmosphere modeling, for example, in which
the problem is 3D by nature) in C++. Is this something other users of
C++ see as a deficiency in the language?
-CSC
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
James Kuyper
> Greetings,
>
> I am a programmer with a strong interest in high-performance numerical
> computation. I know both Fortran 95 and C++ well and think they're
> both good tools for numerics. However, I think F95 has one very big
> edge on C++, which is built-in support for high-performance,
> dynamically allocatable arrays of 2 or more dimensions. Yes, you can
> find libraries that do it in C++ in various places. But they're
> scattered, not standard, and you never know if you can trust them.
> For example, how well has boost::multi_array been tested? It provides
> a natural interface, yes, but how does it stack up in performance? If
> it's slow, it's no use.
>
> I'm not asking you guys where to find fast C++ array libraries. We
> know the answer to this. My concern is there's no standard library
> support for numerical programmers, in which the ISO committee has
> carefully filtered the various proposals and picked the one that meets
> our needs best.
A key problem with that is that "meets our needs best" implies a single
monolithic set of needs, as opposed to a large, diverse community with
widely varying needs. Secondly, even if there were a single well-defined
criterion for determining which library is "best", the library that does
so might be a different library on different platforms.
The committee is really supposed to work primarily by standardizing
existing practice, so the emergence of a single widely popular numerics
library would be a key step toward standardizing such a library.
However, the single most important factor influencing the lack of
support for numerics in C++ is the shortage of numerical experts on the
committee. If you want to change that, I'd strongly recommend joining
the committee. They'd be glad to have you. See
<http://www.open-std.org/jtc1/sc22/wg21/>, and in particular the links
at the bottom of the page "if you want to contribute".
Thomas Richter
> I am a programmer with a strong interest in high-performance numerical
> computation. I know both Fortran 95 and C++ well and think they're
> both good tools for numerics. However, I think F95 has one very big
> edge on C++, which is built-in support for high-performance,
> dynamically allocatable arrays of 2 or more dimensions. Yes, you can
> find libraries that do it in C++ in various places. But they're
> scattered, not standard, and you never know if you can trust them.
> For example, how well has boost::multi_array been tested? It provides
> a natural interface, yes, but how does it stack up in performance? If
> it's slow, it's no use.
>
> I'm not asking you guys where to find fast C++ array libraries. We
> know the answer to this. My concern is there's no standard library
> support for numerical programmers, in which the ISO committee has
> carefully filtered the various proposals and picked the one that meets
> our needs best. I think this is very disappointing and makes it hard
> for me to want to start a heavy-duty project that uses multi-
> dimensional arrays (think atmosphere modeling, for example, in which
> the problem is 3D by nature) in C++. Is this something other users of
> C++ see as a deficiency in the language?
The point is that C++ is a multi-purpose language, number-crunching
being only one of the possible applications. I agree that for people
working in numerics C++ is probably not the prime choice due to lack of
proper multi-dimensional arithmetics in the STL (no, valarray is hardly
a proper candidate, typical implementations do not provide acceptable
performance, i.e. not comparable to FORTAN).
Again, other people might consider the lack of proper GUI support as a
missing feature in C++, support that is available in other languages
like Java.
However, if you have such needs, my answer would be that you should
probably look for a language that fits your needs better than C++ does,
which is much more general purpose. I don't see a problem here.
Similarly, nobody would use Java for heavy number crunching either -
it's the wrong tool for the job.
So long,
Thomas
Francis Glassborow
>
> The point is that C++ is a multi-purpose language, number-crunching
> being only one of the possible applications. I agree that for people
> working in numerics C++ is probably not the prime choice due to lack of
> proper multi-dimensional arithmetics in the STL (no, valarray is hardly
> a proper candidate, typical implementations do not provide acceptable
> performance, i.e. not comparable to FORTAN).
I wonder :) In general standards have nothing to say about efficiency. I
would hazard a guess that the reason Fortran has highly efficient
support for multi-dimensional dynamic arrays is that its user community
wants them and no implementation that did not provide high efficiency in
this area would be marketable.
The real question is whether a language enables the writing of efficient
support for a feature desired by a sub=community of its users.
>
> Again, other people might consider the lack of proper GUI support as a
> missing feature in C++, support that is available in other languages
> like Java.
And that makes my point for me. Java's support for a (portable) GUI
comes at the cost of efficiency. Where portability is valued Java has a
good deal going for it. However where efficiency is vital C++ scores
(but it needs a good implementer to achieve it)
>
> However, if you have such needs, my answer would be that you should
> probably look for a language that fits your needs better than C++ does,
> which is much more general purpose. I don't see a problem here.
> Similarly, nobody would use Java for heavy number crunching either -
> it's the wrong tool for the job.
But I am not convinced that C++ is the wrong tool. As a language it has
attracted a considerable number of expert library implementers
Thomas Richter
>> The point is that C++ is a multi-purpose language, number-crunching
>> being only one of the possible applications. I agree that for people
>> working in numerics C++ is probably not the prime choice due to lack of
>> proper multi-dimensional arithmetics in the STL (no, valarray is hardly
>> a proper candidate, typical implementations do not provide acceptable
>> performance, i.e. not comparable to FORTAN).
>
> I wonder :) In general standards have nothing to say about efficiency. I
> would hazard a guess that the reason Fortran has highly efficient
> support for multi-dimensional dynamic arrays is that its user community
> wants them and no implementation that did not provide high efficiency in
> this area would be marketable.
Well, only partially. FORTRAN has a very strong (but archaic) support
for all types of array and matrix types, most of them are very deeply
anchored in the language itself. This makes it pretty easy to write
efficient algorithms on such types, and to provide good support for such
types in the compilers as well. A pure library solution (as in C++) can
only do what the language can, a FORTRAN compiler can do what the
machine can do, e.g. direct support of vector instructions etc. are
easier to emit by the compiler itself.
A FORTRAN compiler is not been taken serious unless it provides good
number crunching, but a C++ compiler can "get away" with it because it's
not in the primary focus of the language - yes, it is probably a
community issue, but that doesn't make C++ more appropriate for such
tasks either.
> The real question is whether a language enables the writing of efficient
> support for a feature desired by a sub=community of its users.
>
>>
>> Again, other people might consider the lack of proper GUI support as a
>> missing feature in C++, support that is available in other languages
>> like Java.
>
> And that makes my point for me. Java's support for a (portable) GUI
> comes at the cost of efficiency. Where portability is valued Java has a
> good deal going for it. However where efficiency is vital C++ scores
> (but it needs a good implementer to achieve it)
>>
>> However, if you have such needs, my answer would be that you should
>> probably look for a language that fits your needs better than C++ does,
>> which is much more general purpose. I don't see a problem here.
>> Similarly, nobody would use Java for heavy number crunching either -
>> it's the wrong tool for the job.
>
> But I am not convinced that C++ is the wrong tool. As a language it has
> attracted a considerable number of expert library implementers.
Maybe, but apparently the committee does not provide enough "drive" in
the numerics/number crunching direction to standardize such libraries as
a part of C++. I'm not saying that the committee does a bad job, just
that the focus is likely a bit different. And I'm neither saying that
C++ could reach the performance of C++ here, it certainly can. But the
focus of the user community and the standards committee is just a
different one.
So long,
Thomas
Jonathan Thornburg
> for people
> working in numerics C++ is probably not the prime choice due to lack of
> proper multi-dimensional arithmetics in the STL (no, valarray is hardly
> a proper candidate, typical implementations do not provide acceptable
> performance, i.e. not comparable to FORTAN).
>
> Again, other people might consider the lack of proper GUI support as a
> missing feature in C++, support that is available in other languages
> like Java.
>
> However, if you have such needs, my answer would be that you should
> probably look for a language that fits your needs better than C++ does,
> which is much more general purpose. I don't see a problem here.
There's a common illusion that number-crunching consists solely of
the sort of nested-loops-operating-on-contiguous-arrays which Fortran 77
already handled quite nicely (albeit without dynamic storage allocation).
Those remain very important, but today's number-crunching codes often
need much more:
* string handling to process parameters and configuration files
* recursion, pointers, and dynamic data structures for fancy adaptive
algorithms
* C compatability to interoperate with other software
* templates so libraries can be re-used in new contexts
* templates for policy-class polymorphism
* inheritance (sometimes multiple), virtual functions, operator
overloading, and lots of other C++ features to try to keep code
readable
* namespaces to help tame programming-in-the-large
* fancy libraries (whose implementations rely on lots of C++ features)
for things like software quad precision arithmetic
So, when you combine *all* the needs for a programming language for
a number-crunching project, C++ often comes out on top, even if its
support for classic nested-loops-operating-on-contiguous-arrays is
still in beta test (a.k.a. boost::multi_array).
--
-- "Jonathan Thornburg [remove -animal to reply]"
<jth...@astro.indiana-zebra.edu>
Dept of Astronomy, Indiana University, Bloomington, Indiana, USA
"Washing one's hands of the conflict between the powerful and the
powerless means to side with the powerful, not to be neutral."
-- quote by Freire / poster by Oxfam