<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 7, 2013 at 11:01 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":1jj"> No! The tools are going to DO type inference! Why not?<br></div></blockquote><div><br></div><div style>
"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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":1jj">
<div class="im">><br>
> 2. Somewhere we have to decide between static and dynamic typing. Will your language have a JIT?<br>
<br>
</div>   Pretty much all static I think is fine.<br></div></blockquote><div><br></div><div style>We do a lot of dynamic stuff now, modifying types at run-time (injecting methods, etc).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":1jj"><div class="im">
</div>   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.<br>
</div></blockquote><div><br></div><div style>1. "metaprogramming" is still "programming"</div><div style><br></div><div style>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":1jj">
<br>
  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.</div>
</blockquote><div><br></div><div style>1. What language will you write all these "desired transformations" in?</div><div style><br></div><div style>2. I think that fusion belongs in a JIT so that you can still interact with it using the normal run-time interface.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>The function-pointer resolution could be done using Clang or even a tool like pycparser.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":1jj"> 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.<br>
<br>
  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.</div></blockquote></div><br><br></div></div>