Re: [Caml-list] Performance questions, -inline, ...

[Kuba Ober <ober.14@osu.edu>]

On Monday 07 January 2008, Jacques Carette wrote:
> Jon Harrop wrote:
> > You mean it might be possible to recover the performance of C from
> > numerical code with high-level abstractions? Yes. Indeed, I would like to
> > see this done. However, I've never heard of an implementation of any
> > language that can do this.
>
> <shameless plug>
> With MetaOCaml you can -- see either the long version
> http://www.cas.mcmaster.ca/~carette/scp_metamonads.pdf
> or the more condensed version
> http://www.cas.mcmaster.ca/~carette/metamonads/index.html
> </shameless plug>

Yup, that's what my homegrown "compiler" does, although it is all LISP, and 
not really nicely structured - it has grown out of an assembler with LISP 
macros. Eventually the macros became powerful enough to do register 
allocation and optimizations, it was a short road to getting the "assembler" 
to dig generic expression input in LISP syntax too. Function inlining 
and "hoisting" are mostly trivial syntax tree operations -- once you have the 
predicates written to tell you whether it's safe to optimize in a given way.

From day 1 it was a LISP-syntax assembler, of course.  Which may look funny, 
but I never had to write a lexer for it, and "parsing" LISP isn't much :) In 
about 12klocs, for my application it generates assembly mostly on par with 
what I could ever write - 95% is DSP operations in fixed point (matrix by 
vector multiplies, vector adds, MACs (FIR/IIR)). It also handles saturations 
where necessary - I've added a "saturated integer" type which gracefully 
saturates on overflow. Kinda necessary in control loops.

To perform well, some of my applications can't even be coded in C unless you'd 
use some (AFAIK nonexistent) C-extensions, or resort to relatively unclean 
techniques like inlineable assembly functions. That's what gcc digs very 
well, but it becomes mostly unmaintainable crap for someone who only knows a 
higher-level language and assembly, but has no gcc experience. Most languages 
are also perfect at hiding the processor's state/flags register from you, and 
it's nigh impossible to expect the optimizer to deduce that all you want to 
do is long addition or multiplication. I can see (if it gets there) my OCaml 
front-end by default having the result type of + being an (int, bool) tuple 
that coerces to int by default, with the bool being the carry status. Thank 
$deity almost all CPUs know what carry means, so this could be pretty 
portable if I were after that -- which I'm not.

I gave up on working with gcc codebase mostly because C is a very unexpressive 
language for anything scientific-related (I wholeheartedly agree with Jon 
Harrop here). And I don't like the C++ "bolted-on" functional template 
metaprogramming either - it reads like a Turing-machine program to me. It is 
pretty nice in theory, but in practice I found it distracting. And the error 
messages are a yet another story.

But enough rambling, I have some thinking to do :)

Cheers, Kuba