Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] native code optimization priorities
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Chris Hecker <checker@d...>
Subject: [Caml-list] native code optimization priorities

Hi, this is just a general question about the caml development team's priorities with respect to the native code compiler's optimized code generation (and bytecode where appropriate), and some specific questions that go along with that.  

I think optimizations are far less important than new features since Moore's law works on the former but not the latter.  So, in some sense, I hope adding new features[*] is prioritized much higher than optimization.

However, I have a bunch of small things I'd like to implement (or see implemented) for making native numerical code faster.  This is primarily for my video game work, but the kinds of things I have in mind will also help any numerically intensive application.  So, here are my questions:

0.  How important is optimization to the team?

1.  Are there any new (big or small) optimizations planned or in the works?

2.  What's the relative priority of new features versus compiler optimizations?

3.  Is there some kind of standard suite of test applications the caml team runs to figure out whether an optimization is worth it to include?  

4.  Are numerical operations an important area for ocaml to succeed?  Put another way, if an optimization helps numerical code but does not help other code (or even slightly hurts it), how would that patch be received?  What about command line options for optimization (of which there very few now) to offset this affect?

5.  How does the team feel about optimizations added to the x86 code generator that don't help other platforms?

Thanks,
Chris

* My personal favorites one more time: overloading, module recursion, generics!

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr