caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Chris Hecker <checker@d6.com>
To: caml-list@inria.fr
Subject: [Caml-list] native code optimization priorities
Date: Tue, 30 Oct 2001 19:08:37 -0800	[thread overview]
Message-ID: <4.3.2.7.2.20011030174718.02888870@arda.pair.com> (raw)


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


             reply	other threads:[~2001-10-31  3:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-31  3:08 Chris Hecker [this message]
2001-10-31  7:50 ` Fabrice Le Fessant
2001-11-06 14:20   ` [Caml-list] compiler patches in the CDK Xavier Leroy
2001-11-06 13:49     ` Fabrice Le Fessant
2001-11-06 14:06 ` [Caml-list] native code optimization priorities Xavier Leroy
     [not found]   ` <20011106154533.D27723@chopin.ai.univie.ac.at>
2001-11-08  9:45     ` Xavier Leroy
     [not found]   ` <Pine.SOL.4.20.0111061141330.10389-100000@godzilla.ics.uci.edu>
2001-11-08  9:59     ` Xavier Leroy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4.3.2.7.2.20011030174718.02888870@arda.pair.com \
    --to=checker@d6.com \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).