Re: OONSTD: to early for standards?

Todd Veldhuizen (tveldhui@seurat.uwaterloo.ca)
Wed, 1 Jul 1998 15:40:28 -0400 (EDT)

> The VSIP Forum is supposed to specify a standard API
> (Application Programmer's Interface) and language bindings
> for ANSI C, C++, etc. but I doubt that there will ever be
> a C++ binding or any other binding besides the ANSI C binding.
> The problem with C++ is that you don't need an expensive,
> proprietary compiler or any other tools to generate high performance code.
> An ordinary C++ compiler along with inline expression class definitions
> (possibly inline expression class templates) can effect most
> of the optimizations provided by the proprietary compilers.

I would guess that they are trying to provide a common wrapper for
the major DSP boards and processors. There are a lot of DSP hardware
vendors (e.g. TI) in their membership list.

I suspect most of these companies have their own APIs and compilers
to harness the special DSP hardware features. Ordinary compilers are
unlikely to generate good code for DSP processors (e.g. know
any C++ compilers which automatically emit MMX instructions?)

> I want to propose a standard for scalar, vector, matrix and tensor arithmetic
> which programmers can use to write portable applications. In particular,
> I want to propose a C++ binding which most C++ programmers will find appealing.
> It should permit programmers to write reliable, high performance applications
> clearly and concisely so that they are easy to read, understand and maintain.
> This standard should serve as a basis for digital signal and image processing
> and other standard libraries.

My thinking about standards has shifted a bit lately. One of the
things I've learned from following the C++ standards effort is
that standardizing libraries can sometimes be the wrong thing to do.
(Note: I think that standardizing some parts of the C++
library is essential e.g. iostreams, strings, locales, etc.)

Why?

1. Standardization kills a library's ability to evolve rapidly.
Feature turnaround becomes very slow: if you want to add something
to the library, you have to champion your ideas through years of
committee meetings, and then hound vendors to implement them.

2. People may become frustrated with the slow feature turnaround rate
and implement their own extensions. The result is many versions of
the standard, all with different sets of extensions. This has
happened a bit with STL.

3. Experimental features must be prematurely standardized, before
experience can produce a consensus on the "right way" to implement them.
Example: tensors in C++. We don't have a clue how to do these right
in C++ yet. Our first pass at them is likely to be unsatisfactory;
we'll probably need several iterations to get them right. A standard
would make it very difficult to iterate towards the right solution.
Another example: valarray<T> in the ISO/ANSI C++ standard. Lots of
people agree that isn't the right solution, even some of its designers.
But now that it's standardized, it's going to be tough (maybe
impossible) to chuck it out and start over again.

Maybe most importantly, who would implement a standard scientific
computing C++ library? Compiler vendors? Standard library providers
(e.g. Rogue Wave)? What would be the economic incentive for them to
do so? Scientific computing is a very small market segment for most
compiler vendors. And the standard library you propose would be
very expensive to implement.

Maybe defacto standards are a better way to go. Look at
how successful BLAS, LAPACK, IMSL etc. have been. They are portable,
widely available, and offer high performance.