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://listarchives.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.(+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
>> 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://listarchives.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://listarchives.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://listarchives.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://listarchives.boost.org/mailman/listinfo.cgi/ublas
> Sent to: rrossi_at_[hidden] <mailto:rrossi_at_[hidden]>
>
>
>
> _______________________________________________
> ublas mailing list
> ublas_at_[hidden]
> http://listarchives.boost.org/mailman/listinfo.cgi/ublas
> Sent to: athanasios.iliopoulos.ctr.gr_at_[hidden]