On May 24, 2012, at 6:45 PM, Jed Brown wrote:
> 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?
Sarcasm on --
Yes, of course. It is essentially done, write it up and I want it on my desk
by 8 AM Friday.
-- Sarcasm off
So what if we know the primatives. How does it give us the "language" to
express these kernels and the tools to do the processing?
Barry
