Re: OSKI, an automatically tuned sparse kernel library.

[David Bateman]

Richard Vuduc wrote:

> Octave developers,
>
> My colleagues and I have released an initial implementation of OSKI, a 
> library that provides automatically tuned sparse matrix kernels like 
> sparse matrix-vector multiply and triangular solve. It's designed to 
> have BLAS-style functionality, and is similar in spirit to ATLAS and 
> FFTW, which I'm sure are familiar to this group.
>
>    http://bebop.cs.berkeley.edu/oski

> I just wanted to mention OSKI, in case it might be of future interest 
> to you. I imagine it would be a lot of work to provide an option to 
> use OSKI within Octave, but at the very least, I invite your comments 
> on whether the OSKI interface (described in its User's Guide) would 
> provide adequate useful functionality.


It looks interesting. Octave at the moment has a pretty good sparse 
matrix mul code, that is significantly faster than matlab for most 
densities. Matlab beats octave for very low densities. This was written 
by Andy Adler and so perhaps he can comment on whether OSKI makes sense 
as a replacement for his code or not. As for the triangular solve code I 
just copied the algorithm from
the blas {d,z}trsm function and adpated it for sparse matrices.... So 
you might be faster there as
well. Motivation to try your code might be lacking however due to a 
severe lack of time :-)

One question I have is the issue of tuning. The workload limits you set 
seems to imply that the code in OSKI is supposed to be used in a kernel 
of an iterative technique. This is one area where at the moment octave 
hasn't got much code... I have an implementation of eigs (that is buggy) 
where a mul tuned function for use with ARPACK would help. However, if 
the workload limits on the tuning in OSKI implies that the tuning is a 
significant cost in the calculation then perhaps for the basic mul and 
triangular solve functions, its better to avoid tuning. What are the 
gains you might expect from OSKI in the case where there is very little 
tuning, and the calculation is performed once? Is it in general better 
than what we already have?

Regards
David

> Best regards,
> --rich


--
David Bateman                                address@hidden
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax) 
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary