From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 67CBABC57 for ; Wed, 1 Dec 2010 15:11:56 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQAAEPm9UxKfVK0kGdsb2JhbACWKYxlCBUBAQEBCQkMBxEEHqoHi3wBBY4OAQSCE4M0 X-IronPort-AV: E=Sophos;i="4.59,283,1288566000"; d="scan'208";a="90500086" Received: from mail-wy0-f180.google.com ([74.125.82.180]) by mail1-smtp-roc.national.inria.fr with ESMTP; 01 Dec 2010 15:11:56 +0100 Received: by wyb29 with SMTP id 29so2268938wyb.39 for ; Wed, 01 Dec 2010 06:11:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:organization:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=xk2DsHJLtNCMEEWpWuhj1i46Zh9qEc2bsH5PkMsIPpI=; b=R8U8+CwlrbibB1cJJV2wBk8DpF57qBcm9IpCdt1YM/wUamyE+2Hv7x+QUja4AdTpHV wSyFXhxIwDsD9nmZKS5gppXEkSG9ktGLhEBpcboVYpFfV+orc+UllhE2LJKNx9mByop+ S5V4h4X93Tv0rZwaeskqxMB2HlcKsoyYDaHjk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:organization:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=A0ewSnQMZvXxra5/9y4XETloyuoAUMQGVROSDrHa5g1T5SxiSbDIQ2+l9BsRpum6SP fyPdGWlImj/omxNmnMuQ11z1etMgfCYFXeRhR80BVGaWUnv4zg98pGlzYOUwwcjWHB7M kXek1MGavuZe30y8RVjTjdn+51p14PATjc6ho= Received: by 10.227.10.198 with SMTP id q6mr5165913wbq.21.1291212715746; Wed, 01 Dec 2010 06:11:55 -0800 (PST) Received: from WinEight ([87.113.160.118]) by mx.google.com with ESMTPS id m10sm14859wbc.10.2010.12.01.06.11.54 (version=SSLv3 cipher=RC4-MD5); Wed, 01 Dec 2010 06:11:54 -0800 (PST) From: Jon Harrop To: "'Benedikt Meurer'" , References: <3DCEA910-1382-47E5-876B-059178F8F82E@googlemail.com> <20101130124803.7952fca1@deb0> <0a8b01cb90da$da5e6240$8f1b26c0$@com> <5E2DA3F1-7998-4F62-B617-7B6451D1001D@googlemail.com> In-Reply-To: <5E2DA3F1-7998-4F62-B617-7B6451D1001D@googlemail.com> Subject: RE: [Caml-list] OCamlJIT2 vs. OCamlJIT Date: Wed, 1 Dec 2010 14:11:31 -0000 Organization: Flying Frog Consultancy Message-ID: <0b3b01cb9161$a81c8e10$f855aa30$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuQ4L20F4euDfBGRkSqi7QI7kFe4wAdCBaQ Content-Language: en-gb X-Spam: no; 0.00; fwiw:01 gcc:01 gcc:01 compilation:01 ocaml:01 bindings:01 polymorphism:01 trivial:01 ocaml:01 parallelism:01 polymorphism:01 integers:01 ocamlopt:01 recursive:01 invokes:01 Benedikt wrote: > This has nothing to do with LLVM, but is simply due to the fact that > your code does not box the float parameters/results. Exactly, yes. > The following peace of C code is most probably even faster than your > code, so what? > > double fib(double x) { if (x < 1.5) return x else return fib(x-1) + > fib(x-2); } FWIW, gcc -O2 takes longer to compile and produces slower code than HLVM anyway: $ time gcc -O2 fib.c -o fib real 0m0.161s user 0m0.124s sys 0m0.036s $ time ./fib 102334155.000000 real 0m2.792s user 0m2.792s sys 0m0.000s If you're asking what the advantages of using LLVM over generating C code are, I'd say functionality like more numeric types, tail calls and JIT compilation come top but also the fact that LLVM bundles nice OCaml bindings and makes it easy to generate fast code. Also, I have other examples (e.g. the random number generator from the SciMark2 benchmark) where LLVM can generate code that runs 2x faster than anything I've been able to get out of GCC. > So this is about data representation not code generation (using LLVM > with boxed floats would result in same/lower performance); Yes. LLVM lets you choose your own data representation and applications like numerics can benefit enormously from that. All the more reason to use LLVM. > HLVM ignores > complex stuff like polymorphism, modules, etc. (at least last time I > checked), which makes code generation almost trivial. OCaml ignores complex stuff like parallelism and value types (at least last time I checked ;-). This is precisely why OCaml and HLVM complement each other. Ideally, we would want all of this at the same time but, for now, we'll have to settle for separate solutions. > The literature > includes various solutions to implement stuff like ML polymorphism: > tagged integers/boxed floats/objects is just one solution, not > necessarily the best; but examples that simply ignore the complex > stuff, and therefore deliver better performance don't really help to > make progress. Right. Reified generics can be a much better solution for performance, particularly when combined with value types, and something else that ocamlopt cannot express but HLVM can. > A possible solution to improve ocamlopt's performance in this case > would be to compile the recursive fib calls in a way that the > parameter/result is passed in a floating point register (not boxed), > and provide a wrapper for calls from outside, which unboxes the > parameter, invokes the actual function code, and boxes the result. This > should be doable on the Ulambda/Cmm level, so it is actually quite > portable and completely independent of the low-level code generation > (which is where LLVM comes into play). That way ocamlopt code will be > as fast as the C code for this example. Wow, I'd love to see your OCaml version that is as fast as C. > > I have microbenchmarks where LLVM generates code over 10x faster than > > ocamlopt (specifically, floating point code on x86) and larger > > numerical programs that also wipe the floor with OCaml. > > ocamlopt's x86 floating point backend is easy to beat, as demonstrated > in the original post. Even a simple byte-code JIT engine (which still > boxes floating point results, etc.) is able to beat it. Yes. Another reason to consider alternatives to ocamlopt for such applications. > Your benchmarks do not prove that LLVM generates faster code than > ocamlopt. My benchmarks show LLVM generating faster code than ocamlopt. > Instead you proved that OCaml's floating point representation > comes at a cost for number crunching applications (which is obvious). > Use the same data representation with LLVM (or C) and you'll notice > that the performance is the same (most likely worse) compared to > ocamlopt. You are saying is that LLVM might not be faster if it were also afflicted with ocamlopt's design, which is unproductive speculation. The point is that LLVM and HLVM are not constrained by those design decisions as OCaml is, so you can use them to generate much faster code. > > LLVM is also much better documented than ocamlopt's internals. > > Definitely, but LLVM replaces just the low-level stuff of ocamlopt > (most probably starting at the Cmm level), so a lot of (undocumented) > ocamlopt internals remain. Sure. OCaml has a good pattern match compiler, for example. Cheers, Jon.