Re: [ublas] [PATCH 3/3] boost::ublas increasing the range of BLAS level 3 benchmarks

Subject: Re: [ublas] [PATCH 3/3] boost::ublas increasing the range of BLAS level 3 benchmarks
From: Nasos Iliopoulos (nasos_i_at_[hidden])
Date: 2016-03-09 08:42:31

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" <imre_palik_at_[hidden] 
> <mailto:imre_palik_at_[hidden]>> 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
>     <rrossi_at_[hidden] <mailto:rrossi_at_[hidden]>> 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" <nasos_i_at_[hidden]
>     <mailto:nasos_i_at_[hidden]>> 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
>>         <imre_palik_at_[hidden] <mailto:imre_palik_at_[hidden]>> 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
>>             <imre_palik_at_[hidden] <mailto:imre_palik_at_[hidden]>>
>>             wrote:
>>
>>
>>             Fork is here:
>>             https://github.com/imre-palik/ublas/tree/feature/ublas00004_simd_gemm
>>
>>             pull request is sent.
>>
>>
>>
>>
>>
>>             _______________________________________________
>>             ublas mailing list
>>             ublas_at_[hidden] <mailto:ublas_at_[hidden]>
>>             http://lists.boost.org/mailman/listinfo.cgi/ublas
>>             Sent to: rrossi_at_[hidden] <mailto:rrossi_at_[hidden]>
>>
>>
>>
>>
>>         -- 
>>         *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.([phone] 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
>>         cimne_at_[hidden] <mailto:cimne_at_[hidden]>. 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
>>         ublas_at_[hidden] <mailto:ublas_at_[hidden]>
>>         http://lists.boost.org/mailman/listinfo.cgi/ublas
>>         Sent to:athanasios.iliopoulos.ctr.gr_at_[hidden]
>>         <mailto:athanasios.iliopoulos.ctr.gr_at_[hidden]>
>
>
>         _______________________________________________
>         ublas mailing list
>         ublas_at_[hidden] <mailto:ublas_at_[hidden]>
>         http://lists.boost.org/mailman/listinfo.cgi/ublas
>         Sent to: rrossi_at_[hidden] <mailto:rrossi_at_[hidden]>
>
>
>     _______________________________________________
>     ublas mailing list
>     ublas_at_[hidden] <mailto:ublas_at_[hidden]>
>     http://lists.boost.org/mailman/listinfo.cgi/ublas
>     Sent to: imre_palik_at_[hidden] <mailto:imre_palik_at_[hidden]>
>
>
>
>     _______________________________________________
>     ublas mailing list
>     ublas_at_[hidden] <mailto:ublas_at_[hidden]>
>     http://lists.boost.org/mailman/listinfo.cgi/ublas
>     Sent to: rrossi_at_[hidden] <mailto:rrossi_at_[hidden]>
>
>
>
> _______________________________________________
> ublas mailing list
> ublas_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to: athanasios.iliopoulos.ctr.gr_at_[hidden]