Re: JIT-compilation for OCaml?

["Joseph R. Kiniry" <kiniry@acm.org>]

And my 2c (or perhaps 10c) as well...

--On Tuesday, January 02, 2001 20:30:51 +0100 Markus Mottl 
<mottl@miss.wu-wien.ac.at> wrote:

> On Tue, 02 Jan 2001, Mattias Waldau wrote:
>> Why do you want JIT?
>
> I don't need it currently, but I can imagine applications that greatly
> benefit from it.

If OCaml does indeed just do unintelligent interpretation of bytecodes and 
there is sufficient reason for running a non-compiled version of a 
codebase, then a JIT-like mechanism is a wise path to follow.  This bears 
no insult to the OCaml compiler, it has simply been justified by example 
many times over.

>> Do you use Java for regular development? It is a pain,
>
> No, I don't use it at all, but I believe you that it must be very
> painful ;)

Not to go offtopic, but I'd rather see list members educated rather than 
FUD'ded.  If ML is a Prius we still have to respect the Taurus that is Java.

Actually, using Java for regular development isn't all that bad.  The 
libraries are extensive, the language is relatively mature (but still 
experiences growing pains), the platform support is very broad, the 
compilation speed problem is fixed by using a compiler like jikes from IBM, 
and the run-time speed is (these days) excellent.

In fact, one of my companies chose Java over five competitor languages 
(Objective-C, C++, Eiffel, CLOS, and oTcl) in a head-to-head test.  Note 
that this company is a group of uber-geeks with a language geek at the helm 
(me), so we were not working in a vacuum.  We picked a set of languages 
that fulfilled a specific criteria for our work, designed a 
prototype/benchmarking application that would test our design space, and 
implemented it in all but one of the languages (with expert review, of 
course).  We then did writeups of all languages and systems and performed a 
numeric evaluation on a couple of dozen criteria to evaluate our choices. 
In the end, Java and Eiffel came out on top and thus we went with Java for 
mostly business (and a couple of technical) reasons.  A draft whitepaper on 
this is available if anyone is interested, just email me.

>> the reason is
>>
>> 1. Slow, slow
>> 2. Big, big
>
> Maybe that's because the Java JIT-compilers were not written by Xavier? ;)

Speaking from my experience (using Java since the day it came out of Sun in 
1995 and either being a member of, or running, three research groups thus 
far that use Java among other languages),

1. That was true in the past but is no longer the case.  I have problems 
with performance when doing GUI work with Java, but in all other cases I 
have seen, including intensive cases numerical work (our physics and alife 
engines) and language design (projects like Vanilla) Java more than matches 
up with the competition.  The recent JITs (esp Sun's on x86 and SPARC, 
IBM's on x86, HP's on PA, and Compaq's on Alpha) are astounding.

2. The 6-8MB overhead that the runtime imposes on a standard architecture 
most folks will gladly eat. If you are really crunched for space you 
shouldn't be using full Java, but instead should use one of the numerous 
embedded alternatives, some of which run in < 1/4 MB.

>> and the reason that Java gets away with it, is the JIT-compiler. That
>> mean that after enormous start-time, the program might achieve resonable
>> performance after a couple of minutes. However, at that time, it still
>> needs 10-20 extra megs, since the compiler is still loaded into memory.

False on both counts.  Some new variants (like Sun's HotSpot) do amortized 
program analysis at run-time to find code segments to re-optimize, but 
those JITs are only used on very long running (i.e. > days) server-side 
processes.  Neither they, nor the "classic" JITs require 10-20 extra MB of 
memory.

> It shouldn't be too difficult to come up with a protocol that informs
> the interpreter whether it should actually use JIT-compilation or not
> and if yes, how it should compile the code for optimum performance, etc.
>
> This meta information could be generated by passing options to the byte
> code compiler or maybe even by some kind of pragmas in the source. Or
> maybe by a magnificent program analysis tool that finds the "hot spots"
> automatically.

The direction most have gone and certainly an opportunity area.

>> The beatty of Ocaml are the fast compilers, the optimizing compiler is
>> faster than javac, which only produces bytecode.
>
> But the JIT-compiled/interpreted byte code seems to be pretty fast: I have
> tried it with a few mini-benchmarks to see whether this JIT-technology
> is of any worth. Really not bad...
>
>> It is sad that so few
>> other programming language developers realizes that the speed of the
>> development environment matters.
>
> Certainly! I definitely don't want to replace the normal byte code
> interpreter with a purely JIT-one. My motivation was rather portability +
> speed rather than speed alone. For the latter "ocamlopt" is more than
> good enough, and for portability we have the byte code compiler. But
> if you want to have portability with reasonable speed for demanding
> applications...

Excellent point.

>> The only thing Ocaml can learn from Java is its libraries. If I would
>> invent a programming language with a library today, I would just copy
>> Java's interface. Libraries are much harder to learn than programming
>> languages, thus standards are needed.
>
> I haven't tried the Java-libraries so far. The OCaml-ones are quite
> usable, but if you can tell us what Java has that OCaml is missing,
> just tell us (in time! ;)

Certainly the breadth and growth of Java's libraries is a marvel, but I 
*certainly* wouldn't say that they are a uniform example of good design. 
It amazes me that a package can go through so much semi-public design 
review and still have serious design flaws.  Until one uses a library on 
large projects with many people for a some reasonable period of time, 
claims of excellence, esp from the library vendor, are premature.

> - Markus Mottl

And now back to your regularly scheduled ML discussion.

Best,
Joe Kiniry
-- 
Joseph R. Kiniry                   http://www.cs.caltech.edu/~kiniry/
California Institute of Technology       ID 78860581      ICQ 4344804

P.S. I've been simming on throwing in my 2c on overloading, but my bias of 
algebraic systems vs. type systems would expose itself.

P.P.S. The company that I mentioned is called DALi and is linked from my 
homepage.  Much more information is available there.