[petsc-dev] ugliness due to missing lapack routines

[Barry Smith]

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

> On Thu, Feb 7, 2013 at 7:35 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: 
> 
>   Yup, absolutely and not a problem since we write the implementations and only the interface is generated. Surely we would not write some generator that is so stupid that it would generate the same thing twice and then barf because it got confused? We have slightly higher standards than Babel.
> 
> Okay, but now the generator needs a global view and/or an understanding of module dependencies. How will you express those dependencies? Here's a compiler guy talking about how to design a module system for C.
> 
> http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf
>  
> > 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.
> 
>    I knew you would say that. Using comments would only be a temporary thing until the tools knew a bit about the class structure and could do everything automatically.
> 
> But not "automatically" in C because these semantics are not directly expressible in C. Presumably you're going to add keywords/syntax to communicate that structure. And now you're making a new programming language.
> 
> 
> > 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?
> 
>    No, based on dependencies it can figure out the types of the internal variables from the the type change to the argument thus doesn't need you to "mark" the variables with some "type" crap name.
> 
> 1. Is your language going to have type inference too?
   
   No! The tools are going to DO type inference! Why not?
> 
> 2. Somewhere we have to decide between static and dynamic typing. Will your language have a JIT?

   Pretty much all static I think is fine.

>   
>    Yes and that is part of the problem. We are dependent on these non-machine-manipulatable constructs in our code (yes, my fault). Hacks, if you will.
> 
> Sure, but what do you replace them with? Comments instructing the preprocessor to perform the equivalent of macro expansion? How is that machine-manipulatable? The manipulator needs to understand your comments to do anything.
>  
> 
>    Regardless, we are using code generation today. Why don't we at least do it honestly and have the generators separate from the data they use to do the generation and the location where the generated code goes? Now it is all in the same damn file!
> 
> I don't think that distributing the logic between more languages/files is better in any way.

   So today you use two languages, one absolutely horrible.  The only way to represent something together in them is as ASCII text! There is no AST for CPP + C nor were there ever be. That means there is no way to manipulate them except as ASCII text (which is why the only manipulation we do on PETSc source code is using an editor or using regular expressions) (and in this circumstance using regular expressions is pretty limited). This means the only improvement and expansion of our code base we can do is by manual programmers typing away. This is not good enough.

  Here is an explicit example, the 2 by 2 SNES problem. If PETSc were coded without any dynamic polymorphism we could essentially inline everything so the Newton loop and the direct solve inside it were all in one block of code and the compiler could do the best it could on it. Because of the polymorphism through function pointers in PETSc this could not happen today. So what could I do? I could open an editor, cut and paste the source code for the MatLUFactor_Dense() (just pretend for this example it is source code and doesn't call LAPACK) and drop it directly into MatLUFactor(), I could do the same thing for MatSolve_Dense(), for PCApply_LU() into PCApply(), VecAXPY_Seq() into VecAXPY(), SNESSolve_LS() into SNESSolve() etc. Now I want to go in and hardwire the loop size to two in the various places, maybe even strip out the loop part of the code completely in cases where the compiler optimizer sucks. Now there would be no function pointer polymorphism or complicated code and (in theory) the compiler could clump everything together and output good object code. 

  Now please tell me a better way today, that is more productive in programmers time to do this? I could try regular expressions but not likely to work and sure would be fragile.