On Thu, May 24, 2012 at 6:26 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> > So do we manage blocks using internal C++ templates, "templates in C", C > generated using some other system (m4 anyone?), or something else entirely? > > > > Yes! Finally, we acknowledge that this a problem. > > > > 1) C++ templates are not a solution to anything. ANYTHING. > > > > 2) I am assuming "templates in C" would work somewhat like a templating > engine. > > I tried this for the last TOMS paper with Andy. Its was just not a > big payoff for > > the work put in, and definitely did not justify incorporating > another package. > > > > 3) I prefer C generated from another system, like the one I use for FEM > (which I am > > not attached to). We will definitely need this for GPU kernels, and > I am guessing > > thread kernels if they are going to be worth something. > > > > For this particular example (and perhaps many others for sparse > matrices) it is a matter of writing "the same algorithm" for a different > data structure (the split storage). Perhaps what is needed is a "sparse > matrix/graph/mesh" language, for which one can write kernels/code fragments > "independent of the data structure" from which C/whatever is generated? > But I don't have a clue what the language would look like. I think a > general purpose tool (for example templates) is unlikely to be useful for > us. Haven't we already identified most of these primitives? Doesn't it generally come down to selecting a (block) row (upper, lower, or the entire thing) and applying a blocked sparse-dense-{minus,plus}-dot? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120524/2fc49e2c/attachment.html>