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

[Daniel Bundala]

Hi,

I think that it is a good idea to have one library matrix/vector
calculations. But it is not a good idea to base it on v.generalize
matrix code since the suggested methods are more efficient and
general. I am not an expert in the field of LA solvers so I really
cannot tell which one is better. But I am pretty sure to say that the
specially designed and optimised solvers are better than my bunch of
LA functions. And also, it would be a great idead and increase in
efficiency to use specialised LA library for matrix stuff in
v.generalize

Daniel

On 8/21/07, "Sören Gebbert" <soerengebbert at gmx.de> wrote:
>
> -------- 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
>