Re: CI setup
Stefan Seefeld via ublas <[email protected]> Mon, 30 Apr 2018 09:58:17 -0400
| Newsgroups | gmane.comp.lib.boost.ublas |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============0108731918001105907== Content-Type: multipart/alternative; boundary="------------C3436484169783047FB7279D" Content-Language: en-US This is a multi-part message in MIME format. --------------C3436484169783047FB7279D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 2018-04-30 09:20 AM, Cem Bassoy via ublas wrote: > > > On Mon, Apr 30, 2018 at 10:05 AM, David Bellot via ublas > <[email protected] <mailto:[email protected]>> wrote: > >> You mentioned some possible refactoring that would make >> integration easier. Can you please outline what refactoring you > > > Super open to refactoring of ublas. > Curious to know what you have in mind. > > > Yes, thx. In general I would have like to compare the current boost > implementation with blaze and eigen. > I think there are several features or also neglect which we might add > to uBLAS. > > - Should we integrate smart expression templates? I think there was a > gsoc project but I am not sure. What was the output? > - Are (smart) expression templates really required? > - 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? Not sure about the specific questions, but I definitely think Boost.uBLAS should provide the means to handle arbitrary expressions, and allow for optimised backends to be matched (example: recognize `D = A * B + C` as a statement that can be vectorized and evaluated using fused multiply-add instructions, wherever available). > > And regarding the code infrastructure: > > - Do we need iterators within matrix and vector template classes? Or > can we generalize the concepts? > - Can we maybe simplify/replace the projection function with > overloaded brackets? I don't have an opinion on that question yet. > > General questions: > > - Shall we build uBLAS a high-performance library? Not quite sure what you mean by that question. > - Could it also be a convenient wrapper library with good interfaces > to high-performance libraries such as OpenBLAS? Yes, definitely. One of the GSoC projects is right now looking into using OpenCL backends to provide GPU support. The infrastructure for that should be easily extensible, so we could have additional high-performance backends. The trick then is to find ways to map specific (smart ?) expression types to available backend "kernels", and figure out (part compile-time part runtime) which backend to use. I have worked on such an infrastructure in OpenVSIP (see the "Dispatch Engine" part in http://openvsip.org/doc/architecture.html) and think that something like that would be useful in Boost.uBLAS as well. Stefan -- ...ich hab' noch einen Koffer in Berlin... --------------C3436484169783047FB7279D Content-Type: multipart/related; boundary="------------DB65B7F2BD309AF4882A4365" --------------DB65B7F2BD309AF4882A4365 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"> <p><br> </p> <br> <div class="moz-cite-prefix">On 2018-04-30 09:20 AM, Cem Bassoy via ublas wrote:<br> </div> <blockquote type="cite" cite="mid:CADrR+Ftg52MOFi6KBf=-rMmZQaQ0tvL0Sx=cg+nfqG7T_pBQ+w@mail.gmail.com"> <div dir="ltr"><br> <div class="gmail_extra"><br> <div class="gmail_quote">On Mon, Apr 30, 2018 at 10:05 AM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote"><span> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div text="#000000" bgcolor="#FFFFFF"><span> <blockquote type="cite"> <div dir="ltr"> <div dir="auto"> <div>You mentioned some possible refactoring that would make integration easier. Can you please outline what refactoring you </div> </div> </div> </blockquote> </span></div> </blockquote> <div><br> </div> </span> <div style="font-family:arial,helvetica,sans-serif;font-size:small">Super open to refactoring of ublas.</div> <div style="font-family:arial,helvetica,sans-serif;font-size:small">Curious to know what you have in mind.</div> <div style="font-family:arial,helvetica,sans-serif;font-size:small"><br> </div> </div> </div> </div> </blockquote> <div><br> </div> <div>Yes, thx. In general I would have like to compare the current boost implementation with blaze and eigen.<br> </div> <div>I think there are several features or also neglect which we might add to uBLAS.<br> </div> <div><br> </div> <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>- Are (smart) expression templates really required?<br> </div> <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> <br> Not sure about the specific questions, but I definitely think Boost.uBLAS should provide the means to handle arbitrary expressions, and allow for optimised backends to be matched (example: recognize `D = A * B + C` as a statement that can be vectorized and evaluated using fused multiply-add instructions, wherever available).<br> <br> <br> <blockquote type="cite" cite="mid:CADrR+Ftg52MOFi6KBf=-rMmZQaQ0tvL0Sx=cg+nfqG7T_pBQ+w@mail.gmail.com"> <div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote"> <div><br> </div> <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>- Can we maybe simplify/replace the projection function with overloaded brackets?<br> </div> </div> </div> </div> </blockquote> I don't have an opinion on that question yet.<br> <br> <blockquote type="cite" cite="mid:CADrR+Ftg52MOFi6KBf=-rMmZQaQ0tvL0Sx=cg+nfqG7T_pBQ+w@mail.gmail.com"> <div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote"> <div><br> </div> <div>General questions:<br> </div> <div><br> </div> <div>- Shall we build uBLAS a high-performance library?<br> </div> </div> </div> </div> </blockquote> <br> Not quite sure what you mean by that question.<br> <br> <blockquote type="cite" cite="mid:CADrR+Ftg52MOFi6KBf=-rMmZQaQ0tvL0Sx=cg+nfqG7T_pBQ+w@mail.gmail.com"> <div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote"> <div>- Could it also be a convenient wrapper library with good interfaces to high-performance libraries such as OpenBLAS?<br> </div> </div> </div> </div> </blockquote> <br> Yes, definitely. One of the GSoC projects is right now looking into using OpenCL backends to provide GPU support. The infrastructure for that should be easily extensible, so we could have additional high-performance backends.<br> The trick then is to find ways to map specific (smart ?) expression types to available backend "kernels", and figure out (part compile-time part runtime) which backend to use.<br> I have worked on such an infrastructure in OpenVSIP (see the "Dispatch Engine" part in <a class="moz-txt-link-freetext" href="http://openvsip.org/doc/architecture.html">http://openvsip.org/doc/architecture.html</a>) and think that something like that would be useful in Boost.uBLAS as well.<br> <br> <br> <div class="moz-signature"><br> <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> --------------DB65B7F2BD309AF4882A4365 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= --------------DB65B7F2BD309AF4882A4365-- --------------C3436484169783047FB7279D-- --===============0108731918001105907== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline