> The first thing that you should notice is that the libraries are very
> similar.
> Many of the functions have the same name and approximately the same
> meaning.
> This really shouldn't surprise anyone. A number of conventions have
> evolved
> during the last decade which have been incorporated into both libraries.
Yes, I tried to use Fortran 90 names whenever possible, to
make it easier for people to migrate (flee?). :-)
> The differences seem to be almost trivial.
There are similarities if you only look at the features provided
by svmt. If you look at the union of the features provided by
both libraries, the differences are more substantial. I've
attached a comparison of my own.
> The blitz++ package is
> obviously
> a research vehicle which includes many more innovations than SVMT.
> Some of these innovations push C++ compiler technology so near the
> bleeding
> edge that you need one of the newest compilers just to compile blitz++.
Yes, this is a problem. Compilers are getting better though; Blitz
compilers with egcs now (the free GNU successor/sibling of gcc),
KCC, Cray, and DECcxx. The HP, Intel, PGI, and Metrowerks compilers
are nearing a usable state.
> I have simply tried to extract proven methods from existing class
> libraries
> and specify a library standard that programmers can use to write high
> performance scientific and engineering applications.
I'm curious about the "high performance" part. If you are
excluding template techniques (particularly expression
templates), how to you hope to achieve decent performance?
If you expect compilers to be written especially for compiling
SVMT, then worrying about blitz's use of ISO/ANSI language
features (particularly templates) is, well, counterproductive.
> The problem is that the blitz++ doesn't distinguish between arrays and
> subarrays like SVMT does.
What you call a bug, I call a feature :-)
In Blitz++, subarrays are "first-class array objects,"
meaning that anything you can do with an array, you can do
with a subarray. For instance, if foo is a function which
operates on an 2-D array:
void foo(Array<float,2>& A);
I can apply foo to (say) a two-dimensional slice
of a 3-D array:
Array<float,3> B(N,N,N); // ...
foo(B(Range::all(), 5, Range::all())); // apply foo to B(:,5,:)
This is difficult if subarrays are a different type,
as in your SVMT proposal. Do you provide an automatic
conversion from arrays to subarrays?
> Two or more blitz++ Array objects may
> reference
> the same one dimensional data array. A reference counter is required
> to determine when the one dimensional data array should be deallocated.
> The obvious advantage of this method is that the one dimensional data
> array
> is never destroyed before the last Array object which references it.
The main advantage to reference counting is efficiency. Without
reference counting you have to resort to making copies of
whole arrays in some situations, which is very inefficient.
For example, returning an array by value:
Array<float,1> foo()
{
}
> The disadvantages, besides a small overhead for reference counting,
> are less obvious. First, it is difficult for the programmer and
> impossible
> for the compiler to distinguish arrays from subarrays.
The way I would phrase this difference is that programmers don't
have to care if they are operating on a subarray or a full
array; they can write one piece of code which works for both
cases. If for some reason they need to know whether an array
is a subarray, there are member functions for this.
I'm not sure what you are getting at when you say that it
is "impossible for the compiler to distinguish arrays
from subarrays." Are you implying that there are
optimizations which SVMT-aware compilers could
perform which blitz can't?
> Second, there is
> no way to determine whether the original array is destroyed before all
> of
> the subarrays are destroyed which is almost certainly a programming
> error.
I'm not sure I understand what you mean here, but there are
no problems related to the order of destruction of arrays
which I know of. Can you give an example?
Here is my version of a blitz/svmt comparison.
Cheers,
Todd
Blitz++ SVMT proposal
Arrays of intrinsic numeric types yes yes
Arrays of complex numbers yes yes
Arrays of user- or library-defined types yes no
Multicomponent/multispectral arrays yes no
Nested arrays (i.e. arrays of arrays) yes no
1-, 2-, and 3- dimensional arrays yes yes
N-dimensional arrays yes no
Arbitrary base index values yes no
Create arrays from pre-existing data yes yes
Array concatenation not pretty yes
Arrays can be returned and passed by value yes no
Array initialization with comma-delimited yes no
list of scalars
C-style storage format yes yes
Fortran storage format yes no
Arbitrary (linear, strided) storage formats yes no
Interlaced arrays yes no
Subarrays using any combination of
Range and integer arguments yes no ?
Subarrays are first-class array
objects yes no
Gang-allocation of identically shaped
arrays yes no
Cycle arrays e.g. [B,C,A]<-[A,B,C] yes no
Efficiency
Implemented with expression templates yes no
(non e.t. implementations of arrays
typically run at 1/3 to 1/10th the speed
of fortran)
Range-syntax for stencils yes no ?
Expressions may involve arrays with
differing storage formats yes n/a
Expressions may mix numeric types, with
type promotion yes no
Index placeholders yes no; "ramp"
provides functionality
for 1D arrays
Explicit casting of arrays yes no
ANSI C++ math functions yes yes ?
IEEE/System V math functions yes no ?
Tensor notation yes no
Complete reductions:
e.g. sum, min, max, any, all yes yes
Partial reductions (ditto) yes yes
Stencil objects and operators yes no
Indirection
List of array positions yes no ?
List of subdomains yes no
Cartesian-product indirection yes no
Support for generic programming yes no