[petsc-dev] ugliness due to missing lapack routines

[Barry Smith]

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

> 
> On Thu, Feb 7, 2013 at 11:01 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>  No! The tools are going to DO type inference! Why not?
> 
> "tools", "compiler", "preprocessor". I don't care what name you use; they all mean the same thing. You're not manipulating plain C because the semantics aren't plain C, they involve the output of the preprocessor.
>  
> >
> > 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.
> 
> We do a lot of dynamic stuff now, modifying types at run-time (injecting methods, etc).
>  
>    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.
> 
> 1. "metaprogramming" is still "programming"
> 
> 2. Your tool is producing new semantics. If you're writing code so that it transforms in some way when a tool is applied, you're writing in a new language.
   
   Fine. It is a new language, actually it is python code that marches through ASTs and modifies them but you can call it a new language.  But the C is still C! It is not C plus "key words" or "imbedded comments" it is always just plan C that is being programmed ON (by the new language).
 

>  
> 
>   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.
> 
> 1. What language will you write all these "desired transformations" in?
> 
> 2. I think that fusion belongs in a JIT so that you can still interact with it using the normal run-time interface.
> 
> 3. I think the JIT should be _only_ on optimization. I would implement it by using a macro (yeah, yeah) to note the function name/file/line-number associated with each dynamically registered function pointer (which are now stored in a struct alongside the function pointer). Then I would always use a special dispatch construct when I call or assign such "location-aware function pointers". The JIT would then take a function of this sort and chase down all the function pointers, gathering the call graph into one compilation unit and replacing each dynamic call with a static call. We have to _control_ use of CPP for this to work, but many uses of CPP are harmless for this sort of thing.
> 
> The function-pointer resolution could be done using Clang or even a tool like pycparser.
>  
> 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.
> 
>