This is the mail archive of the gsl-discuss@sources.redhat.com mailing list for the GSL project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

GSL, VSIPL, and the ultimate numerical library


I just read a good chunk of the year 2000
list archives.  I've been following the VSIPL
forum work on and off for the past couple of 
years, and I was pretty excited when I saw the announcement
of GSL 0.7 on freshmeat.net, because it sounded 
like it might have already beaten VSIPL to the punch
so to speak.  It appears that a lot of good work
has gone into GSL so far.

I've been thinking about what I would want in a grand
numerical library.  The things I myself would probably use a 
good numerical library for are some real-time speech processing
under Linux, and maybe as a basis for a neural networks
library.  Performance is important for both of those, otherwise
for offline use I would just use Octave or Matlab.  
If the Intel Signal Processing library ran under Linux that 
would be great, but it doesn't, and it is also a closed-source
library, which I'm generally against. 

The TASP VSIPL code is a pretty good choice, but it looks
hard to maintain since there is so much code replication to
support the different data types.  I recall an early version
the Hughes VSIPL code which used a preprocessor template
scheme that seemed pretty slick.  It looks like GSL has a
similar problem, many functions are written 3 and 4 times
just to support the different float and int types the user might want
to instantiate.  And after all that, it still can't support
neat things like arbitrary precision numbers, while a templating
scheme might be able to.

To boil it down, the library I would like to use would be
(most important first):
   high performance
   generic to allow optimizing under the hood 
      and advanced algorithms
   templated for data type choices and easier maintenance
   open source
   easily tested for correctness with an automated suite

I think the VSIPL API has a lot of good ideas for the 
functions that it supports, but the reference implementation 
would be easier to deal with if it were templatized.
Maybe it's my personality, but making the same change 
in more than one place just wears me out.

The GSL team has implemented a large breadth
of functions, many of which have no equivalent in the VSIPL
spec, but which could probably benefit from some of its principles.
Since both the TASP reference implementation and
GSL are open source, it might be possible to gradually
combine them, as Randall Judd seems interested
in doing.  Many GSL functions not present in VSIPL might
be wrapped to present an interface similar to the VSIPL API.
Then gradually the underlying GSL code could be moved into
the wrapper to increase performance, better conform to
VSIPL, etc.

It might also be nice to go back to the
technique in the Hughes code of implementing most of the
functions in terms of other VSIPL/GSL functions or lower-level
helper functions whenever possible.
This could have the advantage of allowing a mostly optimized version
for a specific hardware platform by just optimizing the lowest-level
vector routines and helpers for that platform, and allowing the 
more complicated routines to ride on top and still benefit.
The hope would be that, say, 80% of the Altivec
(or Intel's SIMD) performance gain could come from 
writing Altivec assembly in only, say, 20% of the functions.  
I mention this because the neat thing to me about having 
a nice numerical library is being able to do some impressive
real-time signal processing tricks on a desktop PC.
Intel's MMX and Streaming SIMD Extensions, AMD's 3D Now instructions,
and PowerPC's Altivec technology all allow for amazingly fast
computation, but since standard compilers can't take advantage
of them, writing assembly code with a high-level API is the
way to go.  But the idea of writing Rob's Gee Whiz Altivec Library
is not very appealing to me, first because VSIPL and GSL have
put a lot of thought into how to do it right, and second because
I'd rather not start from scratch if I switch to a non-Altivec machine.

I guess in the end I can understand why Tisdale
is so interested in the vision and goals of GSL, so
it is easier to decide if it is the same direction 
that he would like to go.  I am in a similar quandary,
there are several interesting-looking projects with
various tradeoffs, and looking into the future a little would
help me bind to one or decide to start my own.

Comments and replies welcome!

-Rob
-- 
Robert W. Brewer  PGP RSA 2048-bit Key ID: 03E0E635
Jesus rules!      Fingerprint: 6327 8034 7BDA D144 B40C C5E2 F760 13BB

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]