Re: [PATCH 3/3] boost::ublas increasing the range of BLAS level 3 benchmarks
Nasos Iliopoulos <[email protected]>
| Newsgroups | gmane.comp.lib.boost.ublas |
|---|---|
| Message-ID | <[email protected]> |
I think the matrix abstraction the way it is now is ok. It would be confusing to have a large matrix class. My current thinking is that we should have a two tier switch. One that detects that openmp is enabled and one that enables parallelization based on user preference: #ifdef _OPENMP && BOOST_UBLAS_PARALLEL // parallel code (with runtime switch if needed) goes here #else #ifdef BOOST_UBLAS_PARALLEL #warning "OPENMP not present. boost::ublas parallel mode not enabled." #end // serial code goes here #endif to enable parallel mode: gcc myfile.cpp -o myexe -fopenmp -DBOOST_UBLAS_PARALLEL the following does not enabe ublas parallel mode but let the user's openmp code run: gcc myfile.cpp -o myexe -fopenmp this will not enable parallelization at all: gcc myfile.cpp -o myexe essentially _OPENMP is defined when you pass the -fopenmp argument to gcc and I suppose in all other compilers that support the standard. * One downside of this approach is that temporarily disabling ublas parallel mode would need some hoci poci. * I think that this approach is better than nothing and If you can think of a more clear and/or efficient way please voice it. * I would favor the std::thread approach but thinking about it again I believe we will need to introduce state so the we have a facility to define the number of threads.We could use (http://en.cppreference.com/w/cpp/utility/program/getenv) but this wouldn't allow for after-execution changes. On the other hand openmp has state and the user can use it deliberately. -Nasos On 03/08/2016 04:45 PM, Riccardo Rossi wrote: > > Nope, I use bounded_matrices when I know the size at compile time. > > But most often I only know it at runtime > > Simple implementations are the best... Important thing is not to have > ifs at runtime > > Can t u create a LargeMatrix class where you do the complicated things > and leave the Matrix class nice and simple? > > Cheers > Riccardo > > On 8 Mar 2016 22:04, "palik imre" <[email protected] > <mailto:[email protected]>> wrote: > > I don't plan to enable openmp by default, just provide some > infrastructure for the user to explicitly enable it. > > As for your case, for 10x10 matrices it doesn't even worth to use > gemm. Would bounded matrices work for you? If the bounds are > below the breakeven point for gemm (set to 27 for double > currently), I could arrange for a compile-time switch. > > > On Tuesday, 8 March 2016, 19:13, Riccardo Rossi > <[email protected] <mailto:[email protected]>> wrote: > > > Well the problem is that fixed matrices and vectors can not be > used if you don t know the size at compile time > In my application (finite elements) I have Millons of matrices of > size around 10by 10 on which I operate within outer openmp loops. > Having openmp in the matrix would be a killer for me > Riccardo > On 7 Mar 2016 18:13, "Nasos Iliopoulos" <[email protected] > <mailto:[email protected]>> wrote: > > That is correct, > there are various options here but none is optimal. Do you > have any suggestions? > > Note: we now have fixed_vector and fixed_matrix classes than > can be used to make compile time decisions with respect to size. > > > -Nasos > > On 03/07/2016 11:56 AM, Riccardo Rossi wrote: >> Hi, >> >> just to give my two cents, some care shall be taken so that >> there is no overhead for very small matrices (say 3*3) >> >> cheers >> Riccardo >> >> On Sun, Mar 6, 2016 at 9:58 PM, palik imre >> <[email protected] <mailto:[email protected]>> wrote: >> >> It just ocured to me, that based on the descriptor struct >> it would be possible to choose between parallel and >> serial implementation of the kernels. >> >> Anybody would be interested in having something like that >> in ublas? >> >> Would an OpenMP parallel implementation be accepted to >> the library? >> >> Thanks, >> >> Imre >> >> >> On Sunday, 6 March 2016, 10:43, palik imre >> <[email protected] <mailto:[email protected]>> >> wrote: >> >> >> Fork is here: >> https://github.com/imre-palik/ublas/tree/feature/ublas00004_simd_gemm >> >> pull request is sent. >> >> >> >> >> >> _______________________________________________ >> ublas mailing list >> [email protected] <mailto:[email protected]> >> http://lists.boost.org/mailman/listinfo.cgi/ublas >> Sent to: [email protected] <mailto:[email protected]> >> >> >> >> >> -- >> *Riccardo Rossi >> * >> PhD, Civil Engineer >> >> member of the Kratos Team: www.cimne.com/kratos >> <http://www.cimne.com/kratos> >> lecturer at Universitat Politècnica de Catalunya, >> BarcelonaTech (UPC) >> Research fellow at International Center for Numerical Methods >> in Engineering (CIMNE) >> >> C/ Gran Capità, s/n, Campus Nord UPC, Ed. C1, Despatx C9 >> 08034 – Barcelona – Spain – www.cimne.com >> <http://www.cimne.com/> - >> T.(+34) 93 401 56 96 skype: *rougered4* >> <http://www.cimne.com/> >> <https://www.facebook.com/cimne><http://blog.cimne.com/><http://vimeo.com/cimne><http://www.youtube.com/user/CIMNEvideos><http://www.linkedin.com/company/cimne><https://twitter.com/cimne> >> Les dades personals contingudes en aquest missatge són >> tractades amb la finalitat de mantenir el contacte >> professional entre CIMNE i voste. Podra exercir els drets >> d'accés, rectificació, cancel·lació i oposició, dirigint-se a >> [email protected] <mailto:[email protected]>. La >> utilització de la seva adreça de correu electronic per part >> de CIMNE queda subjecte a les disposicions de la Llei >> 34/2002, de Serveis de la Societat de la Informació i el >> Comerç Electronic. >> Imprimiu aquest missatge, només si és estrictament necessari. >> <http://www.cimne.com/> >> >> >> _______________________________________________ >> ublas mailing list >> [email protected] <mailto:[email protected]> >> http://lists.boost.org/mailman/listinfo.cgi/ublas >> Sent to:[email protected] >> <mailto:[email protected]> > > > _______________________________________________ > ublas mailing list > [email protected] <mailto:[email protected]> > http://lists.boost.org/mailman/listinfo.cgi/ublas > Sent to: [email protected] <mailto:[email protected]> > > > _______________________________________________ > ublas mailing list > [email protected] <mailto:[email protected]> > http://lists.boost.org/mailman/listinfo.cgi/ublas > Sent to: [email protected] <mailto:[email protected]> > > > > _______________________________________________ > ublas mailing list > [email protected] <mailto:[email protected]> > http://lists.boost.org/mailman/listinfo.cgi/ublas > Sent to: [email protected] <mailto:[email protected]> > > > > _______________________________________________ > ublas mailing list > [email protected] > http://lists.boost.org/mailman/listinfo.cgi/ublas > Sent to: [email protected]