|
|
Ublas : |
Subject: Re: [ublas] [bindings] Initial submission plan?
From: Karl Meerbergen (Karl.Meerbergen_at_[hidden])
Date: 2009-02-11 03:22:59
Dear All,
Several people have asked to have the bindings in Boost. (Some on this
list, some in private communication with me.)
A few months ago I suggested to only have the traits classes in an
official repository since the bindings algorithms (blas, lapack, etc)
were far from complete. (In the meantime, hard work on lapack has been
done.)
So I would opt for an incremental process where the traits should be
part of it from the beginning and bindings to packages can be added once
they are complete. The lapack bindings now are complete and could be
added in this first stage. The blas bindings need a tremendous amount of
work. MUMPS and UMFPACK are OK I think and could also be added. New
bindings could then be created in the sandbox and added after approval
(I am thinking of an FFT package, ARPACK, BLZPACK).
Best,
Karl
Rutger ter Borg wrote:
> Thomas Klimpel wrote:
>
>
>> However, I had hoped to have some sort of "real" release (with
>> statements about what is supported and what isn't) before submitting the
>> library for review. And I had more hoped for some sort of evolution
>> instead of a revolution.
>>
>
> I have been following the development of the numeric bindings since 2002...
> Evolution has had its chance :-). But seriously, it's a good library and I
> think it deserves more attention than just a sandbox. Writing the bindings
> generator has been possible due to the hard work of the authors of the
> current bindings. I don't think it's that revolutionary.
>
>
>> Interesting point. I came from the other side, i.e. I took the existence
>> of the numeric_bindings library for granted, but asked how it should
>> evolve. I'll explain what I mean:
>>
>> [snip]
>>
>
> Good plan, we need clearly stated overview of supported environments. Let's
> start by stating this in the documentation. Perhaps also start with
> ticketing in trac.
>
>
>> I had hoped to have the "initial" release not as part of boost, but to
>> get included into boost later. The inclusion into boost would have been
>> some sort of "long time vision". Even the "lapack generator" script was
>> more meant like some sort of vision to keep the motivation alive than
>> anything I really expected to finish in the near future. But since you
>> obviously finished it already, chances are that you will also bring the
>> entire library into a state that it can be submitted for review.
>>
>
> The generator script doesn't support BLAS generation just yet, ATLAS needs
> to be merged, etc., etc.. There's still a lot to do, but as I see it,
> coding the library itself doesn't seem to be the most time-consuming part
> anymore. We need help with setting up a full testing suite (based on
> current), testing on different environments/compilers, and with writing
> documentation.
>
>
>> The support for ATLAS is somehow quite closely related to the bindings
>> for BLAS and LAPACK, since it is a subset of the functionality, but with
>> support for row-major. What do you mean by support for nVidia CUDA?
>>
>
> I heard about CUDA recently. Apparently nVidia ships a BLAS that runs on
> GPUs, tenfolds faster compared to CPUs. Not that expensive as well.
> http://www.nvidia.com/object/cuda_learn.html
>
>
>> I don't see FFT bindings in the scope of the numeric_bindings library. I
>> guess this is because I see mostly the "linear algebra"/"matrix" aspect
>> of the numeric_bindings, and the FFT is not really related to the
>> "matrix" aspect.
>>
>
> I think the scope of the Numeric_Bindings is just that: having C++ access to
> non-C++ numeric libraries with a high-level interface without paying for it
> in run-time costs. FFT served as an example; it certainly is one that has
> very efficient non-C++ implementations (e.g., FFTW). To further motivate,
> fourier transforms are also included by Intel's MKL, AMD's CML, and
> nVidia's CUDA.
>
>
>> But the initial question was for clear goals.
>>
>
> Yes.
>
>
>> Since I have the impression that you will do the main work,
>>
>
> Please don't :-)
>
>
>> From a functionality point of view, I think that the first version
>> should try to support at least the subset of BLAS/LAPACK functionality
>> supported by ATLAS + the functionality of the simple and expert lapack
>> driver routines.
>>
>
> I think it should support the whole of BLAS, and of LAPACK, and back-ends
> such as ATLAS supported where possible. Seperated high-level and low-level
> interface(s) don't seem to be too far off anymore, but needs some more
> research.
>
>
>> From the computational lapack routines, the routines required for
>> multiplicative decompositions like LU and QR decomposition and the
>> corresponding back substitutions also seem important. Also routines for
>> bidiagonal, tridiagonal and Hessenberg matrices might be important as
>> these might be required as building blocks in certain algorithms (for
>> example Lanczos algorithm for eigenvalue approximations).
>>
>
> I agree, I see a lot of use for being able to write
>
> lapack::qr( ... );
>
> If time permits, I'll try to create the structure in the sandbox tomorrow,
> let's start expanding the documentation with stuff we just discussed. All
> help is greatly appreciated.
>
> Thanks,
>
> Rutger
>
>
>
> _______________________________________________
> ublas mailing list
> ublas_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/ublas
>