[GRASS-dev] BLAS/LAPACK (Part II)
soerengebbert at gmx.de
Tue Aug 21 22:33:26 CEST 2007
-------- 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
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.
> > 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
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
More information about the grass-dev