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]

Re: GSL, VSIPL, and the ultimate numerical library


Robert W. Brewer wrote:

> I've really enjoyed the responses.
> Based on Gerard's comments about a GNU Scientific Environment,
> I can see that the ideal for me would be a way to write
> high-level, Octave or Matlab style code
> but still have it be fast when needed.
> I have seen Matlab compilers
> which supposedly help with this sort of thing.
> 
> It sounds like that is what Gerard was getting at with the GSE:
> an interactive way to simulate, test, and debug
> an algorithm at a very high level,
> together with additional analysis and graphing tools.
> And then a migration path to deployment on a target,
> which would be further and further optimized in various ways
> for the specific application.
> That would  be very nice, but it is also very lofty.
> Currently the way I would do that
> and the way I've mainly seen that done is like this:
>   Read books, papers, and articles (and think)
>      to find candidate algorithms and approaches,
>   Use Matlab, Octave, or one of many simulation tools
>      to simulate and analyze some candidate solutions.
>      This often involves writing a lot of code
>      in their respective languages.

This is usually caller the "reference version"
or, sometimes, "the golden copy."

>   Choose best algorithm.
>   Reimplement algorithm in C or C++ using whatever helper libraries
>      are available for the target platform.

Unfortunately, developers often stop maintaining the reference version
shortly after the performance version is implemented.

>   If still not fast enough,
>      reimplement inner loops with specialized assembly code.
>   Go back to any previous step if it's still not working as expected.
> 
>   If it's working correctly,
>      gradually misplace books, papers, articles, and thinking.
>      Gradually misplace Matlab simulation code.
>      Gradually misplace everything
>      except working C, C++, and assembly code.
> 
>   Decide to switch target platforms or upgrade algorithm.  
>      Often must go back to step one
>      since results of intermediate stages are gone
>      and working C, C++, and assembly code is too hard to figure out.
> 
> Now certainly a library or a GSE is no substitute for discipline
> and keeping the analysis and design documentation and models updated.
> But I think it can help,
> especially when the library has high-level enough functionality
> that the final code is forced to be somewhat self-documenting.
> 
> OK, back to the topic.  I spent some time considering
> how to create a genericized VSIPL implementation,
> and finally concluded that to ignore all the good work
> that has gone into the TASP VSIPL code would be a big mistake.
> Gerard's comments about the sin of reinventing BLAS helped win me over.

People reinvent the BLAS library all the time.
The BLAS library is really just a standard API
that everybody implements the way that they see fit.
You can get the BLAS [portable] reference implementation from

	http://www.netlib.org/blas/index.html

Just click on blas.tgz

Also, take a look at
The ANSI C Numerical Class Library

	http://www.netwood.net/~edwin/svmt/

The .../cncl/bin/genclass script converts prototype files like
.../cncl/src/vector/vector.hP and .../cncl/src/vector/vector.cP
into ANSI C header and source files.

> Now I think I understand the difference
> between the original Hughes reference code and the TASP code, 
> and it sounds like the reference code may still be lurking
> inside Hughes somewhere.
> Is there any chance of publicly releasing it?

I'm not sure.
I believe that HRL Laboratories LLC was supposed to
bring the Portable Reference Library up to date,
transfer the copyright to the VSIPL Forum and
release it to the public.
I don't believe that is going to happen now.
It might be counter productive
to release the Portable Reference Library as is
because it might be confused with VSIPL API specification.

Anyway, send email to David Schwartz daSchwartz@HRL.com
and ask him for a copy of 

	VSIP Library Reference Implementation (9/10/97)

> I don't have my copy anymore,
> but even if I did I had agreed to keep it private when I received it.
> That would be another codebase for me to consider mucking with.
> But for now I think I'm going to concentrate
> on getting some algorithms to work that would use VSIPL
> and then, if they are too slow,
> I may try to optimize parts of the TASP implementation
> for my target du jour.

Will you share?  For free?  For profit?

> I don't want to fill up too much more of the GSL list
> with purely VSIPL stuff,
> so does anyone know of an active VSIPL list?
> I think I subscribed to some on the VSIPL website years ago
> and have only gotten a few messages a year
> about meeting announcements.

Take a look at the VSIPL Forum home page

	http://www.vsipl.org/forum.html

and click on the GETTING INVOLVED radio button
on the left hand side of the page.

	Join the VSIPL Mail List 
	VSIPL Forum Meeting Schedule 
	Post a comment to the VSIPL Forum 
	Read VSIPL Comments 

> Now that I've spent several hours considering
> how to implement one of these numeric library beasts,
> I have a better appreciation
> for what all the GSL and VSIPL folks have done.
> I even learned a lot of interesting stuff
> just from reading parts of the GSL and VSIPL documentation.

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