From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id OAA13509 for caml-red; Thu, 4 Jan 2001 14:20:45 +0100 (MET) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id SAA04538 for ; Wed, 3 Jan 2001 18:50:10 +0100 (MET) Received: from dalilab.com ([63.203.128.164]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f03Ho8128462 for ; Wed, 3 Jan 2001 18:50:09 +0100 (MET) Received: from [63.198.73.142] (HELO kind.kindsoftware.com) by dalilab.com (CommuniGate Pro SMTP 3.4b7) with ESMTP id 385246; Wed, 03 Jan 2001 09:49:58 -0800 Date: Wed, 03 Jan 2001 09:49:57 -0800 From: "Joseph R. Kiniry" Reply-To: "Joseph R. Kiniry" To: OCAML cc: Markus Mottl , Mattias Waldau Subject: Re: JIT-compilation for OCaml? Message-ID: <49780000.978544197@kind.kindsoftware.com> In-Reply-To: <20010102203051.A18481@miss.wu-wien.ac.at> X-Mailer: Mulberry/2.0.6b2 (Linux/x86) Organization: Department of Computer Science, Caltech X-Image-Url: http://www.cs.caltech.edu/~kiniry/graphics/jrk-8.99.jpg X-Url: http://www.cs.caltech.edu/~kiniry/ X-Face: 9X:!41!x9hOT+cJU.gb=hXxEm6v)ZczE-':_8mlM-7^G!j%2$QC00w?G "x_1ZnY3[!+gGQD.6%=0EMBt[m|kdKsr*m=3J&r(#is5]J>&eVWNy-h^DrtO_5jES gK6NFKoj%c=+E?*%+\S$Rn7Y|mT(a~1Y{[$MZR[8~(bK[P4]RM2E<"5:n|2Gm!V

7aWw 9+K|b{`Ou,uYaNn(`QDDR 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.