Re: CI setup
Stefan Seefeld via ublas <[email protected]> Thu, 3 May 2018 09:40:43 -0400
| Newsgroups | gmane.comp.lib.boost.ublas |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============6837024094394864057== Content-Type: multipart/alternative; boundary="------------51D08C27A7E20EDA3ED78627" Content-Language: en-GB This is a multi-part message in MIME format. --------------51D08C27A7E20EDA3ED78627 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 03.05.2018 09:16, Cem Bassoy via ublas wrote: > > > On Wed, May 2, 2018 at 10:11 PM, David Bellot via ublas > <[email protected] <mailto:[email protected]>> wrote: > > - Should we integrate smart expression templates? I think > there was a gsoc project but I am not sure. What was the output? > > > it was really good > > > okay. I cannot see it in the development branch. Is it intended to be > integrated into uBLAS? > > > > > - Are (smart) expression templates really required? > > > but after second thought, I wonder like you. > > > I think smart expression templates could be beneficial in terms of > selecting and executing high-performance kernels! > Expression templates seem to be outdated. See > https://epubs.siam.org/doi/abs/10.1137/110830125 One of the GSoC projects is adding GPU support to uBLAS. And while it may be useful to have an API layer that lets users explicitly request the GPU backend to be used (for the supported subset of BLAS functions for which there are GPU kernels), we also may want to offer full integration, whereby a user just uses generic uBLAS expressions, and leaves the selection of the appropriate backend (GPU or other) to the library itself. But to be able to implement this selection mechanism, we need some advanced dispatching technique. I'm not sure I understand enough about "smart expression templates", but I did implement such dispatching infrastructure in the past (http://openvsip.org/), which scales well to a high number of backends (GPU, SIMD vectorization, TBB-style parallelization, etc.). I hope we can manage to get to the point where we can discuss what techniques are most appropriate for Boost.uBLAS, and perhaps even start to implement them over this summer. We shall see... > > > > - How often do expressions like A = B*C + D*D - ... occur in > numerical applications? > - Should we provide a fast gemm implementation of the > Goto-Algorithm like in Eigen? > > > why not. > > > Because, tuning algorithms and getting them to nearly peak performance > for standard processors is a nontrivial task to my mind. I am not sure > but we could try to integrate and link to existing highly optimized > kernels. As with the above, the problem really is to pick the right backend(s) for the current platform, as the optimal choice depends on many things (available hardware, data layout, problem size, etc.). Coming up with a good optimization strategy (and an architecture that supports it) is non-trivial. > > > > > And regarding the code infrastructure: > > - Do we need iterators within matrix and vector template > classes? Or can we generalize the concepts? > > > once there's been a discussion about that. Can we factorize all > this code into one place, one generic concept ? > This would make things so simple and efficient in the end. > > > Yes, I will try to built iterators for tensors so we can discuss this > by investigating my code. Sounds good. > > > > > - Can we maybe simplify/replace the projection function with > overloaded brackets? > > > Can we do that ? That would be awesome ! > > > > Will try to show that it is possible. > > > > General questions: > - Shall we build uBLAS a high-performance library? > > > Yes, I suppose. > What do you mean exactly by "high-performance" ? > > > I wanted to say that uBLAS could serve as an optimizer and dispatcher > between different types of existing high-performance libraries instead > of providing high-performance functions. I agree. The project I referred to above (OpenVSIP) started out as a library implementing operations itself, until we realized how foolish an idea that was, at which point it turned more and more into "middleware", i.e. something like an "algorithm abstraction layer", which makes it easy to plug in new backends (to support new hardware, say), without the need for applications to change any code. Boost has long prided itself reimplementing wheels. I hope we can overcome this NIH syndrom and demonstrate how beneficial it is to reuse existing know-how / technology. Focusing on C++ APIs should be the goal of Boost, while good optimizations are certainly helpful to increase the rate of adoption. Stefan -- ...ich hab' noch einen Koffer in Berlin... --------------51D08C27A7E20EDA3ED78627 Content-Type: multipart/related; boundary="------------7393CAD6946A1163EBCCD6D5" --------------7393CAD6946A1163EBCCD6D5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">On 03.05.2018 09:16, Cem Bassoy via ublas wrote:<br> </div> <blockquote type="cite" cite="mid:CADrR+FsYwVn7PA=g3dfoqhhDEP1uV4b_YHmQxqvbeZH0CH6oWg@mail.gmail.com"> <div dir="ltr"><br> <div class="gmail_extra"><br> <div class="gmail_quote">On Wed, May 2, 2018 at 10:11 PM, David Bellot via ublas <span dir="ltr"><<a href="mailto:[email protected]" target="_blank" moz-do-not-send="true">[email protected]</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote"><span class="gmail-"> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote"> <div>- Should we integrate smart expression templates? I think there was a gsoc project but I am not sure. What was the output?<br> </div> </div> </div> </div> </blockquote> <div><br> </div> </span> <div style="font-family:arial,helvetica,sans-serif;font-size:small">it was really good</div> </div> </div> </div> </blockquote> <div><br> </div> <div>okay. I cannot see it in the development branch. Is it intended to be integrated into uBLAS?<br> </div> <div> </div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote"><span class="gmail-"> <div style="font-family:arial,helvetica,sans-serif;font-size:small"></div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote"> <div>- Are (smart) expression templates really required?<br> </div> </div> </div> </div> </blockquote> <div><br> </div> </span> <div style="font-family:arial,helvetica,sans-serif;font-size:small">but after second thought, I wonder like you.</div> </div> </div> </div> </blockquote> <div><br> </div> <div>I think smart expression templates could be beneficial in terms of selecting and executing high-performance kernels!<br> </div> <div>Expression templates seem to be outdated. See <a href="https://epubs.siam.org/doi/abs/10.1137/110830125" moz-do-not-send="true">https://epubs.siam.org/doi/abs/10.1137/110830125</a><br> </div> </div> </div> </div> </blockquote> <br> One of the GSoC projects is adding GPU support to uBLAS. And while it may be useful to have an API layer that lets users explicitly request the GPU backend to be used (for the supported subset of BLAS functions for which there are GPU kernels), we also may want to offer full integration, whereby a user just uses generic uBLAS expressions, and leaves the selection of the appropriate backend (GPU or other) to the library itself.<br> But to be able to implement this selection mechanism, we need some advanced dispatching technique. I'm not sure I understand enough about "smart expression templates", but I did implement such dispatching infrastructure in the past (<a class="moz-txt-link-freetext" href="http://openvsip.org/">http://openvsip.org/</a>), which scales well to a high number of backends (GPU, SIMD vectorization, TBB-style parallelization, etc.).<br> I hope we can manage to get to the point where we can discuss what techniques are most appropriate for Boost.uBLAS, and perhaps even start to implement them over this summer. We shall see...<br> <br> <blockquote type="cite" cite="mid:CADrR+FsYwVn7PA=g3dfoqhhDEP1uV4b_YHmQxqvbeZH0CH6oWg@mail.gmail.com"> <div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote"> <div><br> </div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote"><span class="gmail-"> <div style="font-family:arial,helvetica,sans-serif;font-size:small"></div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote"> <div>- How often do expressions like A = B*C + D*D - ... occur in numerical applications?<br> </div> <div>- Should we provide a fast gemm implementation of the Goto-Algorithm like in Eigen?<br> </div> </div> </div> </div> </blockquote> <div><br> </div> </span> <div style="font-family:arial,helvetica,sans-serif;font-size:small">why not.</div> </div> </div> </div> </blockquote> <div><br> </div> <div>Because, tuning algorithms and getting them to nearly peak performance for standard processors is a nontrivial task to my mind. I am not sure but we could try to integrate and link to existing highly optimized kernels.<br> </div> </div> </div> </div> </blockquote> <br> As with the above, the problem really is to pick the right backend(s) for the current platform, as the optimal choice depends on many things (available hardware, data layout, problem size, etc.). Coming up with a good optimization strategy (and an architecture that supports it) is non-trivial. <br> <br> <blockquote type="cite" cite="mid:CADrR+FsYwVn7PA=g3dfoqhhDEP1uV4b_YHmQxqvbeZH0CH6oWg@mail.gmail.com"> <div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote"> <div> </div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote"><span class="gmail-"> <div style="font-family:arial,helvetica,sans-serif;font-size:small"></div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote"> <div>And regarding the code infrastructure:<br> </div> <div><br> </div> <div>- Do we need iterators within matrix and vector template classes? Or can we generalize the concepts?<br> </div> </div> </div> </div> </blockquote> <div><br> </div> </span> <div style="font-family:arial,helvetica,sans-serif;font-size:small">once there's been a discussion about that. Can we factorize all this code into one place, one generic concept ?</div> <div style="font-family:arial,helvetica,sans-serif;font-size:small">This would make things so simple and efficient in the end.</div> </div> </div> </div> </blockquote> <div><br> </div> <div>Yes, I will try to built iterators for tensors so we can discuss this by investigating my code.<br> </div> </div> </div> </div> </blockquote> <br> Sounds good.<br> <blockquote type="cite" cite="mid:CADrR+FsYwVn7PA=g3dfoqhhDEP1uV4b_YHmQxqvbeZH0CH6oWg@mail.gmail.com"> <div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote"> <div> </div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote"><span class="gmail-"> <div style="font-family:arial,helvetica,sans-serif;font-size:small"></div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote"> <div>- Can we maybe simplify/replace the projection function with overloaded brackets?<br> </div> </div> </div> </div> </blockquote> <div><br> </div> </span> <div style="font-family:arial,helvetica,sans-serif;font-size:small">Can we do that ? That would be awesome !</div> <span class="gmail-"> <div> </div> </span></div> </div> </div> </blockquote> <div><br> </div> <div>Will try to show that it is possible.<br> </div> <div><br> </div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote"><span class="gmail-"> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote"> <div>General questions:</div> <div>- Shall we build uBLAS a high-performance library?<br> </div> </div> </div> </div> </blockquote> <div><br> </div> </span> <div style="font-family:arial,helvetica,sans-serif;font-size:small">Yes, I suppose.</div> <div style="font-family:arial,helvetica,sans-serif;font-size:small">What do you mean exactly by "high-performance" ?</div> </div> </div> </div> </blockquote> <div><br> </div> <div>I wanted to say that uBLAS could serve as an optimizer and dispatcher between different types of existing high-performance libraries instead of providing high-performance functions. <br> </div> </div> </div> </div> </blockquote> <br> I agree. The project I referred to above (OpenVSIP) started out as a library implementing operations itself, until we realized how foolish an idea that was, at which point it turned more and more into "middleware", i.e. something like an "algorithm abstraction layer", which makes it easy to plug in new backends (to support new hardware, say), without the need for applications to change any code.<br> <br> Boost has long prided itself reimplementing wheels. I hope we can overcome this NIH syndrom and demonstrate how beneficial it is to reuse existing know-how / technology. Focusing on C++ APIs should be the goal of Boost, while good optimizations are certainly helpful to increase the rate of adoption.<br> <br> <br> <div class="moz-signature"> <div class="moz-signature"><img moz-do-not-send="false" src="cid:[email protected]" alt="Stefan" width="73" height="45"><br> <pre>-- ...ich hab' noch einen Koffer in Berlin... </pre> </div> </div> </body> </html> --------------7393CAD6946A1163EBCCD6D5 Content-Type: image/png; name="signature.png" Content-Transfer-Encoding: base64 Content-ID: <[email protected]> Content-Disposition: inline; filename="signature.png" iVBORw0KGgoAAAANSUhEUgAAAEkAAAAtCAYAAADiFkaQAAAABHNCSVQICAgIfAhkiAAAAAlw SFlzAAAVhwAAFYcBshnuugAAABl0RVh0U29mdHdhcmUAd3d3Lmlua3NjYXBlLm9yZ5vuPBoA AAVDSURBVGiB5dpprF1TFMDx33u0iqpWW6LmqWpIVUkoNVbM81ShiJifIakgxAc1VEzxwRiC 8EHwgaAilBhCg6BClJIYaqohSM1t6fVh7afXfffcd+55d8I/uXnvnL3PWuvus/daa699+e8x CFfhlnYb0qkMw40o4dA229KRDMLL+AnvYYX2mtOZXIj5+B4HttmWjmQkfsCreLDNtnQsV+Er fIsxbbalI1kDi/AnTm6zLR3LpSKazUJXm23JRauNHIyF+ByjWqy7boagB59gGR4QIbnZHCeW 2Z4t0DUgNsXh4k2Owxti+l/eAt0vt0jPgNgUn2FC2b2NsFjkK81M6E4UDntYE3UMmC6Rl9xU pW2WmE2bNUn3OPzsX7A/OxC/q+4wrxGDtE3GszvgmIJ6h+CtJH/7gjJaxiO4P6PtSvEltqjS tifmYXhBvXeJAPF2wedbxmgswd4Z7bfgR30j3Dr4FFsV1HsmZmMOpheU0TJ6hE9YKaN9Hm6v uNeF53F+QZ2T8IFYYouxZkE5LeNhPJHRNgXfiVlTzikiPeguoG8UFmBXkWE/WkBGS+kWg1Bt uo/AXOxRcX8kvhFfsl668BhmpusPMK2AnJaytXDKk7EyrhNlihfFbnztKs/chocK6jsbLwn/ Nl5E1NULymoZ08RWYDUMxUE4UiSR1dhQVAuL5EwrieDQu0QvEzlYx3M93q+j/724oUG638UJ DZLVVJ4SPiIPY8XWYa0G6N1cpB0jGiCrLsojTVY4r2QTEWnyMBN34Ot6jKqgt/xyFF4Q/i8v Q3EA9jHAMs5kkaCtmqNvt8hRLsjRdwJ+U92R52VHvCPqRq/In0CuhRl4Uszk0gDt8Jr8kWdM Unh0P/0GiS3LPem6W/6Z2st2+CPpW08Ei81z6D1HnLn16pulAc5+cR1CJgmjd8honyAG/Qvh P8aLrcSjWLFOuw5PuhYLZ/1hP/3XFfWliWX3dhKuoTKxrYsVxQnDdmLNlvrpv376+1VG+0TL d+ZLcRZOFVP/jzpt+65MzvH+meEPFynHJtg2fcaLlzM39dkYV4sN9Rd16u7DfWJwds/R99zU d5WM9mmpvYTTsH/6v6eAXd2Wl0RK4mXOw0d4M9k9XfjU4cKhl8SW6XSRgBbdSPdhryR8do6+ M/FLjfapSdYPIhs/IF3fnUN2t76llddFhr1ELPWRNZ7fUpRRFogl2ju4S8TJ7tQcNtTkpSRw t3763SlqOVkcmeTcmq5HikH9DTvXeG6UOL+vjJofJ3lz+rGrl/KUZpQo+l2UZCxUvIYFdhGn HO+Jyl8Wj4m3m8WpyaD9yu71pHuLxCBUJoMjhO86Xd/606/p2Stqm98vTyc5P+FxcXjQgyPE pnuc2t/7b25Pgq6t0efVpCSLGUnG1hX3DxP5Tkk48Hl4VuQ+9wunW8kIy5fMQI+MBos95hUi LXlCROEFYpaXRIrxsUiHTpZxjjcsdVomsttqfCky6CzmiEHIeisbill2lCin1DpQ3CoZv1S+ RLcoXdgA+4qKxvyk92dR1egTpCakxl+EoyxniBjt8zKUjU7t8xtgOLGVKKm9vJtBFw62fLAq K6yIJG6pWL97ld3fMT00JUP4viJMZ7XXy0lJX7Ujq1YwRHYNH+HQlojwe7FwqOeJyDY445nR 4hcejeISMUjHNlBmw9ldnM6WROn1OdUdbLO4WXMPOBvGajgDh2j9L0YeFr6xyMHB/4bX0qft dPJb2kjkU22nUwdpmNjS5K2ANpVOHaSx6e/CtlqR6NRB6q0GfN5WKxKdOkhjRF72TLsNgb8A ty4jMPtjABcAAAAASUVORK5CYII= --------------7393CAD6946A1163EBCCD6D5-- --------------51D08C27A7E20EDA3ED78627-- --===============6837024094394864057== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline