On May 24, 2012, at 3:39 PM, Matthew Knepley wrote:
> On Thu, May 24, 2012 at 4:16 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> On Thu, May 24, 2012 at 3:10 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> Absolutely. And if it turns out to be too much of a pain to write and
> maintain such a kernel there is something wrong with our programming model
> and code development system. The right system should make all the complexity
> fall away; when the complexity becomes too much of a bear you know you have
> the wrong system.
>
> 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.
Barry
> Matt
>
> --
> What most experimenters take for granted before they begin their experiments
> is infinitely more interesting than any results to which their experiments
> lead.
> -- Norbert Wiener
