From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: ** X-Spam-Status: No, score=2.2 required=5.0 tests=AWL,DNS_FROM_RFC_POST, SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id C50B3BBC4 for ; Wed, 4 Mar 2009 17:17:56 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuABAM04rknRVYC7mGdsb2JhbACMa4dYPwEBAQEBCAkMBxGzDJAjAQMBA4QFBoUFgUY X-IronPort-AV: E=Sophos;i="4.38,301,1233529200"; d="scan'208";a="25059955" Received: from fk-out-0910.google.com ([209.85.128.187]) by mail1-smtp-roc.national.inria.fr with ESMTP; 04 Mar 2009 17:17:56 +0100 Received: by fk-out-0910.google.com with SMTP id f40so1434312fka.11 for ; Wed, 04 Mar 2009 08:17:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=s91DUL8Um/ZTAYMPbtgWqZjTVlOYYYjtTQisnQQWTQs=; b=X3NYFUfbZ4qd+4knJZ0hfj9N2TqtZ8FpsWAuBckqkECWT3sYl8098k6LRXKN0xEopa sUNSYsWCkZx5T+7NZhQegH+2rmjRKvddokh3icUmjSojstem8MUt+ydiXYjwrvkde+Y9 VQ58+gRwqDd2cHwFBTDHL5EiBly7BTqah+gkc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=hAHev5Dmm42M0Tb2I8lo4R8r5ZNtE9Tl+1ZqVZdwImWFR5VRaitYoJXDw7dX9D/hap JJGnyvherHXJ9S+Wcp5rm90APjotMSdaitrWmjec/SwYnktSis8AU/1QxG82qbzjlEd0 SzHl4aGX0g/Yd/7M6CVuld0JIM9nnMxc/qURE= MIME-Version: 1.0 Sender: mikkelfj@gmail.com Received: by 10.181.36.19 with SMTP id o19mr10045bkj.135.1236183475934; Wed, 04 Mar 2009 08:17:55 -0800 (PST) In-Reply-To: References: <200902280112.24115.jon@ffconsultancy.com> <200902282152.18430.jon@ffconsultancy.com> <49ABED07.30800@imag.fr> Date: Wed, 4 Mar 2009 17:17:55 +0100 X-Google-Sender-Auth: ef638217a3f9a66e Message-ID: Subject: Re: [Caml-list] Odd performance result with HLVM From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= To: Kuba Ober Cc: caml-list@yquem.inria.fr Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam: no; 0.00; mikkel:01 rgensen:01 mikkel:01 haskell:01 ocaml:01 ocaml:01 ocamlopt:01 compilation:01 run-time:01 compilation:01 polymorphism:01 compiler:01 inlined:01 runtime:01 orthogonal:01 When looking at the benchmark game and other benchmarks I have seen, I noticed that Haskell is almost as fast as OCaml and sometimes faster. Some Lisp implementations are also pretty fast. However, when you look at memory consumption OCaml uses considerably less memory, except for languages in the C family. I suspect that many real world performance scenarios, such as heavily loaded web servers and complex simulations, depend very much on memory consumption. This is both because of GC overhead and because of the slower memory pipeline the more cache levels are involved. So in case of a new JIT solution for OCaml, I believe it is important to observe this aspect as well. Mikkel 2009/3/2 Kuba Ober : > >> Jon Harrop a =C3=A9crit : >>> >>> There are really two major advantages over the current ocamlopt design >>> and both stem from the use of JIT compilation: >>> >>> . Run-time types allow per-type functions like generic pretty printers >>> and comparison. >>> >>> . Monomorphisation during JIT compilation completely removes the >>> performance cost of polymorphism, e.g. floats, tuples and records are n= ever >>> boxed. >> >> Do you mean that each polymorphic function is compiled into a different >> native piece of code each time it is called with different parameter >> types? How does the JIT'ed code size compare to ocamlopt'ed code size? > > Having done it, although not in a JIT but in your plain-old whole-project > compiler, > for my use cases the code size actually shrinks. The functions usually en= d > up inlined > and sometimes reduce to a few machine instructions. Most of the runtime > library is written > using polymorphic functions. Case in point: all sorts of string-processin= g > functions which > can take as arguments either strings stored in RAM or stored in ROM, and > those data types > are very much orthogonal on my platform. An invocation of a tail-recursiv= e > "strlen" reduces to about as many bytes of code than it'd take to push th= e > arguments on > the stack and call a non-polymorphic version of itself. > > That's how I initially got a statically typed LISP to compile for "tiny" = 8 > bit microcontrollers > without using all of the whopping 1kb of RAM and 16kb of program flash on= a > Z8F162x > device. > > Right now I'm hacking away to get rid of last traces of LISPiness and to = get > the project fully > working in OCaml, using ML-like syntax for user code. I like it much bett= er > than LISP's. > > I have also found that by doing whole-project compilation with aggressive > constant propagation > and compile-time execution of functions that depend only on known constan= ts, > I could get > rid of about 85% of LISP macros in my code. The other macros ended up bei= ng > rewritten > to just invoke ct_eval: string -> function, which is a compile-time eval > function. > It's just like LISP macros, but since in ML family code isn't data, it wa= s > easier to just > generate strings and feed them into compiler, rather than expose all of t= he > AST machinery > to "userland". > > Cheers, Kuba > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs >