<div dir="ltr"><div><div><div>just a brief comment again on OpenMP:<br><br></div>openmp IS compatible with c++, and a clang version exists already, although it is not merged to the repository<br><br><a href="http://clang-omp.github.io/">http://clang-omp.github.io/</a><br> <br><br></div>regards<br></div>Riccardo<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Dec 9, 2013 at 4:14 PM, Nasos Iliopoulos <span dir="ltr"><<a href="mailto:nasos_i@hotmail.com" target="_blank">nasos_i@hotmail.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Karli,<br> I am not so sure the requirements for smal /large containers are so diverse. After all you can have compile-time dispatching for small (static) or large (dynamic) containers if you want to use different algorithms for each or for mixed cases. Can you please elaborate if I am not getting it right?<br> <br> -Nasos<div><div class="h5"><br> <br> <br> <br> On 12/09/2013 09:49 AM, Karl Rupp wrote:<br> </div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"> Hi guys,<br> <br> <br> > the whole problem of most numerical packages, IMHO, is that everything<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> is tied together. I would encourage a very loosely coupled system. I.e.,<br> a system that maybe even would be able to switch storage layout,<br> algorithms, etc., at run-time, maybe following some simple numerical<br> tests. Of course, only if this would be enabled at compile-time.<br> </blockquote> <br> >From my experience with rebuilding the uBLAS interface within ViennaCL I fully support this suggestion.<br> <br> <br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> * the storage of data. This is about memory-efficiency, and hence, speed<br> of computation. Storage engines might be linear, sparse, etc..<br> * functional shape of the data. Dense, triangular, etc.<br> * numerical properties of the data. Positive definite, etc.<br> * loading and saving the data. Why not support a whole bunch of<br> data-formats<br> * unified matrix/vector view on the data<br> * procedural manipulation of the data, shallow views on the data, views<br> on views, etc.<br> </blockquote> <br> One important question should be answered upfront: Should ublas focus on linear algebra for 'small' vectors/matrices, or 'big' vectors/matrices? I don't consider 'both' a legitimate answer here, because the two extremes have highly diverse requirements:<br> - For 'small' data (say, 10x10) one goes with expression templates, just because any additional runtime overhead is not acceptable.<br> - For 'large' data one can do a lot of tricks with respect to avoiding memory transfers with some delayed execution techniques. Also, this is the regime where one can slowly start to think about threads, accelerators, etc. Most machine-specific metrics then become only available at runtime, so one needs some runtime logic in addition to expression templates anyway. One may even get rid of expression templates here and instead enjoy faster compilation times and increased flexibility at runtime.<br> <br> Just my 2 cents of course... :-)<br> <br> Best regards,<br> Karli<br> <br> ______________________________<u></u>_________________<br> ublas mailing list<br> <a href="mailto:ublas@lists.boost.org" target="_blank">ublas@lists.boost.org</a><br> <a href="http://lists.boost.org/mailman/listinfo.cgi/ublas" target="_blank">http://lists.boost.org/<u></u>mailman/listinfo.cgi/ublas</a><br></div></div> Sent to: <a href="mailto:athanasios.iliopoulos.ctr.gr@nrl.navy.mil" target="_blank">athanasios.iliopoulos.ctr.gr@<u></u>nrl.navy.mil</a><br> </blockquote><div class="HOEnZb"><div class="h5"> <br> ______________________________<u></u>_________________<br> ublas mailing list<br> <a href="mailto:ublas@lists.boost.org" target="_blank">ublas@lists.boost.org</a><br> <a href="http://lists.boost.org/mailman/listinfo.cgi/ublas" target="_blank">http://lists.boost.org/<u></u>mailman/listinfo.cgi/ublas</a><br> Sent to: <a href="mailto:rrossi@cimne.upc.edu" target="_blank">rrossi@cimne.upc.edu</a><br> </div></div></blockquote></div><br><br clear="all"><br>-- <br><p><span style="font-size:10.0pt;font-family:"Arial","sans-serif"">Dr. Riccardo Rossi, Civil Engineer<br></span></p> <p><span style="font-size:10.0pt;font-family:"Arial","sans-serif"">Member of Kratos Team<span style="color:#1f497d"> </span></span></p> <p><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#1f497d">International Center for Numerical Methods in Engineering - CIMNE<br> Campus Norte, Edificio C1</span><span style="color:#1f497d"> </span></p> <p style="text-align:justify"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#1f497d" lang="ES">c/ Gran Capitán s/n</span></p> <p style="text-align:justify"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#1f497d" lang="ES">08034 Barcelona, España</span></p> <p style="text-align:justify"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#1f497d" lang="ES">Tel: <a value="+34934015696">(+34) 93 401 56 96</a></span></p> <p style="text-align:justify"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#1f497d" lang="ES">Fax: <a value="+34934016517">(+34) 93.401.6517</a></span></p> <span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#1f497d" lang="ES">web:</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif"" lang="ES"> </span><span lang="ES"><a href="http://www.cimne.com/" target="_blank"><span style="font-size:10.0pt;font-family:"Arial","sans-serif"">www.cimne.com</span></a></span> </div>