-------- Original-Nachricht -------- > Datum: Tue, 21 Aug 2007 19:15:48 +0000 > Von: Brad Douglas <[EMAIL PROTECTED]> > An: Daniel Bundala <[EMAIL PROTECTED]> > CC: Wolf Bergenheim <[EMAIL PROTECTED]>, "Sören Gebbert" <[EMAIL PROTECTED]>, > GRASS developers list <grass-dev@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@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 _______________________________________________ grass-dev mailing list grass-dev@grass.itc.it http://grass.itc.it/mailman/listinfo/grass-dev
