[petsc-dev] ugliness due to missing lapack routines

[Barry Smith]

> How would you like to manipulate that code? What would that achieve?
>  

    Having running applications that mix real and complex and different precisions. Having super efficient 2 by 2 SNES solves. Having super efficient 20 by 20 TS integrations and all combinations of such things. 

   Yes, this could conceivably be done using the macro games of sfbasic.c and vscat.h but that's a bit like taking some hand tools into the forests of Alaska and building a house. Challenging and fun, but still you've got to share one room with the kids and go outside to take a dump.

   As I said I don't even know if this is doable, but I think now is a good time to dream big.

   Barry



On Feb 7, 2013, at 7:36 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> On Thu, Feb 7, 2013 at 6:32 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> 
> On Feb 7, 2013, at 5:56 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> 
> >
> > On Thu, Feb 7, 2013 at 5:51 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> >    These are in the category of  those that CANNOT be trivially converted to C functions. They are the tough nuts to crack. We need to categorize them and see what makes sense to do with them.
> >
> > Do you agree that the "new" version of those constructs will not be plain C? Either you will be moving non-trivial logic from C to the preprocessor itself (thus distributing logic between preprocessor implementation and "normal" source files) or you will be adding some extra semantics to the dialect of "C" that will be understood by the preprocessor?
> 
> 1)   All of the "sticking in extra error processing stuff" like PetscFunctionBegin/CHKERRQ()/PetscStackCall()  does not require any new syntax in the C language.
> 
> It's just syntax, easily produced automatically from our editors, and easy to "look past". Either we put it in automatically everywhere, with some annotation or list of rules about where to _not_ put it in, or we put it in everywhere we need it. There are a lot of ways that we could handle this so let's focus on the more interesting parts.
>  
> 
> 2)   Macros like PetscTryMethod() won't be needed. Instead the user interface functions like KSPGMRESSetRestart() would be completely auto-generated from the underlying implementation routines KSPGMRESSetRestart_GMRES().
> 
> Recall that there are multiple different implementations of the same interface (_GMRES and _FGMRES in this case).
>  
> 
>     Now the question of how the system knows that the routine KSPGMRESSetRestart_GMRES() should auto-generate KSPGMRESSetRestart() is a good question. I don't think we need to resolve that now; it could be a formatted comment in the code, it could be based on the function naming convention; it is really associated with our class structure (whether we want to teach our "source tools" about the class structure comes later). But it doesn't need to require adding syntax to C.
> 
> No, you're just changing the behavior of the code by annotating using comments. I.e., extending the language. It's not plain C because the "comments" are semantically significant and not even optional.
>  
> 3)   Code generation for different types and block sizes
> 
>    No matter what we do it couldn't be worse then the absolutely horrible stuff you added recently in the top of sfbasic.c Didn't you feel all itching when you were typing that stuff in?
> 
> Sure, but it's more contained and more generic than vpscat.h/vpscat.c. I would have used C++ templates there (very isolated) if we could use such a thing. I actually think C++ templates solve that problem about as well as any system could. (It's everything else templates are used for that is the disaster.)
>  
> 
>    I actually would like the original routine(s) to be pure C and then to separately indicate what other functions to build from that original one. So for example if you have myfunction(int a,double *b, int *c) and you want a version of the function build from my function() with arguments int,int*,double*. You would tell the system this and it would generate the new version. Note that because the AST "understands" the routine as C  (not ascii) there is no reason to do all the <type> crap that C++ templates or your horrific sfbasic.c code requires.
> 
> HOW does it "understand" the semantics you are writing down? Is it through more annotation that you're going to put in the comments? Or magic names and a piece of code in the preprocessor that recognizes that name and pattern?
>  
> 
>   So my answer is yes there will be no new language syntax added and yes the "non-trivial" logic will be in a different place from the code.  But I submit that the "non-trivial" logic will generally be trivial certainly it will be trivial to reproduce all the horrible stuff we manage now with CPP. And the logic isn't associated with any one particular chunk of C code so doesn't need to be with that particular source code.
> 
> The PetscOptions macros are far from trivial logic.
>  
> 
>    Is what I propose possible? I don't know, nor do I particularly care, but I do know that the stuff at the top of sfbasic.c is not a good approach and the more stuff we add like that the more difficult it will ever get to do things "a better way" since that kind of CPP can never be represented in a way that allows manipulating the source code via source code tools (because CPP plus C is not a language).
> 
> How would you like to manipulate that code? What would that achieve?
>  
> 
>    Barry
> 
> Jed,
> 
>     I am not meaning to attack you in particular for utilizing CPP in this way. I am very guilty of it as well, because at those times I felt it was the only "reliable" way to do things.  I am now hoping I was wrong.
> 
> I felt it was the least-bad of the available choices in this case. I'd like to have a better mechanism, but that code only took a couple hours to write and it's working reliably now, even if it's for from aesthetic.
> 
> I believe MPI should provide a way for us to avoid writing code like that, but I needed something that worked now, not in 15 years.