From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id SAA16860; Sat, 28 Aug 2004 18:40:43 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id SAA14638 for ; Sat, 28 Aug 2004 18:40:43 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id i7SGeg3f009713 for ; Sat, 28 Aug 2004 18:40:42 +0200 Received: from bourg.inria.fr (bourg.inria.fr [128.93.11.100]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id SAA15557 for ; Sat, 28 Aug 2004 18:40:42 +0200 (MET DST) Received: from basile by bourg.inria.fr with local (Exim 4.34) id 1C16FQ-0001kf-Ab for caml-list@inria.fr; Sat, 28 Aug 2004 18:40:12 +0200 Date: Sat, 28 Aug 2004 18:40:12 +0200 To: caml-list@inria.fr Subject: Re: [Caml-list] Alternative Bytecodes for OCaml Message-ID: <20040828164012.GA6420@bourg.inria.fr> References: <004f01c48c19$9950d8e0$0100a8c0@warp> <412F9059.2080808@orcaware.com> <20040827221801.GB1545@annexia.org> <20040828.083835.21913928.yoriyuki@mbg.ocn.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20040828.083835.21913928.yoriyuki@mbg.ocn.ne.jp> User-Agent: Mutt/1.5.6+20040803i From: "Basile Starynkevitch [local]" X-Miltered: at concorde with ID 4130B58A.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 bytecodes:01 basile:01 basile:01 2004:99 0900,:01 yamagata:01 yoriyuki:01 caml-list:01 bytecodes:01 2004:99 pdd:99 pdd:99 runtime:01 pointers:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sat, Aug 28, 2004 at 08:38:35AM +0900, Yamagata Yoriyuki wrote: > From: Richard Jones > Subject: Re: [Caml-list] Alternative Bytecodes for OCaml > Date: Fri, 27 Aug 2004 23:18:01 +0100 > > The doc is somewhat vague, but Parrot seems to use conservative > mark&sweep GC. http://www.parrotcode.org/docs/pdd/pdd09_gc.html > > There are a lot of people in academia in this list. Maybe > OCaml->Parrot compiler is a good project for undergraduates? Unfortunately, I am not sure it would be a good thing - and I think that it is quite sad that Parrot designers did not consider more cooperation (or feedback?) with the functional language communities. I think that Ocaml programs use a lot of "tuples", as seen by the runtime system (ie a tagged block of value pointers) ; tuples are essential in Ocaml for tuples and recorda in the Ocaml source language. need to allocate tuples quickly (because functional programming style means lots of allocations of small immutable tuples), and to test quickly the tuples' tag, and to fetch quieckly the n-th component of a tuple (for implementation of pattern matching) need to have efficient closures - quickly allocated, and quickly applied (both thru ordinary and tail-recursive terminal calls). Unfortunately, Parrot http://www.parrotcode.org/docs/intro.html implement all structured objects as PMCs, which are opaque data chunks on which all operations goes thru a table of functions (similar to C++ vtables). So, using PMCs for tuple implementations would require an indirect call (even with Parrot JIT technology) for every basic tuple operations (ie allocation, tag fetching, field fetching). Also, I am not sure that Parrot has terminal (tail recursive) calls which are essential to Ocaml (and other functional languages). So, I would guess that a Parrot-based Ocaml implementation (even using Parrot JIT technology) would probably be at least two times slower than the current ocaml byterun implementation (hence about 4 times slower than my OcamlJitRun implementation, at least on x86). An alternative not yet considered in this interesting "bytecode" related thread would be to *extend* a competitive VM (eg Parrot, or maybe CLR or JVM) to add the few features needed to Ocaml, notably: quick tuple allocation & access (both to fields and to tag), quick closure allocation and application, tail-recursive calls. Alos, note that Ocaml (and other functional languages) need a performant garbage collector (because immutable tuples and closures are allocated and accessed a lot), and that conservative GCs (à la Boehm) have lots of interesting features (in particular, conservativeness which makes then C-friendly, and multithreading), but are slower than naive generational copying precise GC (see http://starynkevitch.net/Basile/qishintro.html for some benches). So, instead of porting Ocaml to Parrot, I would favor an extension of Parrot (or any other competitive VM) - by adding the few needed features suggested above) and then a port of the Ocaml compiler to this extended VM. I do recognize that it is a big work, and that the result might be disappointing (in terms of performance at least) w.r.t. the current Ocaml bytecode VM. Regards. NB: in this post, all tuples are (unless explicitly said) in the runtime sense of a tagged block of GC-ed pointers - not in the Ocaml source sense. tuples (in the runtime sense) implements both Ocaml tuples & records. -- Basile STARYNKEVITCH -- basile dot starynkevitch at inria dot fr other email : basile at starynkevitch dot net Project cristal.inria.fr - temporarily http://cristal.inria.fr/~starynke --- all opinions are only mine ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners