[GRASS-dev] BLAS/LAPACK (Part II)

["Sören Gebbert"]

-------- Original-Nachricht --------
> Datum: Tue, 21 Aug 2007 19:15:48 +0000
> Von: Brad Douglas <rez at touchofmadness.com>
> An: Daniel Bundala <bundala at gmail.com>
> CC: Wolf Bergenheim <wolf+grass at bergenheim.net>, "Sören Gebbert" <soerengebbert at gmx.de>, GRASS developers list <grass-dev at grass.itc.it>
> Betreff: Re: [GRASS-dev] BLAS/LAPACK (Part II)

> On Mon, 2007-08-20 at 22:08 +0200, Daniel Bundala wrote:
> > Guys,
> > 
> > It is quite interesting, but I have had plans to replace v.generalize
> > matrix code by "yours" library code. I have not studied G_matrix_*
> > code carefully, but it seems to me that it is superior.
> 
> BLAS/LAPACK are vastly superior.
> 
> I have a couple modules I'm working on that I've either used or in
> process of converting to use G_matrix_*()/G_vector_*() functions that
> call BLAS/LAPACK.  I would also like to expand the usage of BLAS/LAPACK
> by making additional functions available (I suspect this may be
> beneficial to you, also).
> 
> > Firstly, Soeren wrote that the current code is multithreaded.
> 
> Soeren's code does not use BLAS/LAPACK.  It probably should.

Well ... :),
a mathematic Professor (http://www.math.tu-berlin.de/~schwandt/index_en.html)
told me, that some compiler with OpenMP support replace the matrix
and vector stuff with high optimized BLASS/LAPACK functions.

I guess thats what the intel compiler partly did with my code to get this 
nice speedup:
http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/GRASS_PDE_lib_SGI_bench.png
http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/sgi_altix_cg_bench.png

I was thinking about this too, but im not sure how to implement this.
I dont know if the BLAS/LAPACK wrapper is thread safe and i dont know if 
multi threaded code works correctly together with scalapack libraries.

There are only a few LAPACK methods available in the gmath library, we need to 
extend it. Also many algorithms within the gmath directory do not make use of the
BLAS/LAPACK stuff, eg: the lu solver.

Well i think i can use the G_matrix and G_vector constructs within the gpde library.   
I will have a deeper look in the gmath stuff.

Best regards
Soeren

> 
> > Secondly, someone mentioned, that it supports the sparse matrices.
> > Support of sparse matrices would increase the efficiency of
> > v.generalize since it uses only the sparse matrices.
> > Thirdly, Soeren mentioned that the current code supports many methods
> > my code doesnt support. To tell the truth, I have never heard about
> > many of them (Well, I am still (young) student...)
> > 
> > The only thing I am missing in the current code is the direct access
> > to the elements of a matrix. But, this is quite dangerous and I really
> > doubt whether this is a good API-desing.
> > 
> > On the other hand, it is true that the current code is quite obscure,
> > say. Also, it is tempting to replace fortran code by C code.
> > Therefore, my suggestons are: clean library code and replace the
> > current code by v.generalize code only if it is really faster. Some
> > benchmarks are probably required, but I doubt that my code beats
> > (optimized) library code.
> 
> One way or the other, it doesn't really matter to me.  I just don't want
> to have modules with dependency requirements that others do not.  
> 
> BLAS/LAPACK are superior, but there's no since having it around if
> nobody is going to use it.  It just becomes clutter at that point.  IMO,
> few will compile it into their build if only a few obscure modules use
> it; leaving those with more specific needs at a disadvantage.
> 
> 
> -- 
> 73, de Brad KB8UYR/6 <rez touchofmadness com>
> 
> _______________________________________________
> grass-dev mailing list
> grass-dev at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev

-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser