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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 343EFBC57 for ; Sun, 12 Dec 2010 22:50:33 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0AABvSBE1KfVK2kGdsb2JhbACXBYx5CBUBAQIJCQwHEQQlpwmMCAEFjHIBBIVK X-IronPort-AV: E=Sophos;i="4.59,333,1288566000"; d="scan'208";a="82480121" Received: from mail-wy0-f182.google.com ([74.125.82.182]) by mail4-smtp-sop.national.inria.fr with ESMTP; 12 Dec 2010 22:50:32 +0100 Received: by wyf19 with SMTP id 19so5484914wyf.27 for ; Sun, 12 Dec 2010 13:50:32 -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=wq53DpzLPYaRQp8mjOuSLxmRMv/At2pkxEruEma2M1o=; b=vqBKSkqcQBbs3ju+9pmByqB136YHeHLsokRJ9jj458KBYZY/Y6Dlu4ln4K9hmryo63 yBLI20aBO8tgcqRYvzH+E389YXzgen9a95jAXEbvnX+x/WbuahTPZpg8Cgf2MY58BEnf 8kYq9h/WIw7+WVoqyYds05GitK3oiiKvu0U6k= 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=pHlaZUIH0wzBSt6sOJ+oIROM6WihGdQ9JqDgTo0UdLdKuA4teXO9OsaayeWtZZuNhA GJJZYK6SNmx+tOGANXokRQOv4uAK0mgDztYF/px0k25BSQoxu/lZU+1cXYqv42nL01U4 LEpbZ804532aGN4cNIan1SBo/0RfwMlyYQQII= Received: by 10.216.175.21 with SMTP id y21mr3808043wel.16.1292190631807; Sun, 12 Dec 2010 13:50:31 -0800 (PST) Received: from WinEight ([84.93.149.66]) by mx.google.com with ESMTPS id t5sm271340wes.33.2010.12.12.13.50.29 (version=SSLv3 cipher=RC4-MD5); Sun, 12 Dec 2010 13:50:30 -0800 (PST) From: Jon Harrop To: "'Benedikt Meurer'" , References: <036001cb9a0c$725acef0$57106cd0$@com> <20101212175524.73a8e285@deb0> <9264BEE6-DBAE-4523-93AC-4560615D2AC5@googlemail.com> In-Reply-To: <9264BEE6-DBAE-4523-93AC-4560615D2AC5@googlemail.com> Subject: RE: Value types (Was: [Caml-list] ocamlopt LLVM support) Date: Sun, 12 Dec 2010 21:50:15 -0000 Organization: Flying Frog Consultancy Message-ID: <03a601cb9a46$934916a0$b9db43e0$@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: AcuaMB3Y85eJ18mfS3unEzF29DhekAAB3RBQ Content-Language: en-gb X-Spam: no; 0.00; ocamlopt:01 compiler:01 'int:01 ocamlopt:01 int's:01 nativeint:01 unboxing:01 unboxing:01 unboxed:01 compiler:01 cmmgen:01 ocaml:01 runtime:01 runtime:01 c--:01 Benedict wrote: > > A C compiler would optimize this to a right shift. Changing that to > > 'Int64.shift_right n 1' speeds up the code. > > This is easy to fix in ocamlopt (see attached patch ocamlopt- > natint.patch), by applying the same optimizations already used for > constant int's to constant natint's (Int64 is Nativeint on 64bit). Note > however, that "mod 2" is not really "and 1", neither is "div 2" > equivalent to "lsr 1"; that would be the case for unsigned arithmetic > (doesn't matter in your example, tho). That's great. Does it optimize div and mod by any constant integer as C compilers do? > >> 1. Unboxing can give huge performance improvements on serial code, > > > > s/Unboxing/arithmetic optimizations/ > > Please find an example where the performance benefit is due to > > unboxing, and not due to arithmetic optimizations performed on the > > unboxed code. > > The boxing involved is relevant, but boxing in general is not the > issue. In this special case, the "let nlen, n = if..." code requires > heap allocation, because of the way the pattern is compiled. This could > be fixed by moving the condition out of the code and using two if's to > select n/nlen separately (doesn't speed up that much). Fixing the > pattern compiler to handle these cases might be interesting for general > benefit. > > I already mentioned this multiple times, but here we go again: Unboxing > optimizations may indeed prove useful if applied wisely (cmmgen.ml is > of special interest here, the unboxing optimizations are more or less > special cases; that could be extended to include interesting cases like > moving boxing out of if-then-else in return position, etc). > > But (here comes the special "Harrop note") this has absolutely nothing > to do with LLVM (and of course really, really, really nothing to do > with HLVM). Using a different data representation for the heap requires > a nearly complete rewrite of the OCaml system (you would probably need > to start at the Typing level); if one wants to do this, enjoy and come > back with code. But even then, data representation issues will have to > be considered long before it comes to actual code generation (if you > are serious, you'll have to think about the runtime first prior to > talking about code generation for a non-existing runtime), so even then > it has nothing to do with LLVM (or C-- or C or whatever IR you can > think of). OCaml programmers can benefit from more appropriate data representations by using LLVM as a library to generate code from OCaml. HLVM is an example of this that anyone can play with. > Combining alloc's across if-then-else constructs further reduces code > size in your example (and probably other programs as well), see > attached file ocamlopt-comballoc-ifthenelse.patch. It's quick&dirty, > but it should illustrate the idea. I think that is an even more valuable improvement to ocamlopt than the int optimization. > This doesn't mean that LLVM wouldn't be useful (in fact, I've just > started an LLVM backend for ocamlopt). But it is important to note that > LLVM is not the solution to everything. As the name implies, it's "low > level", it does a few "higher level" optimizations for C, but these are > special cases (and somewhat ugly if you take the time to read the > code). It won't make a faster OCaml magically, just like it didn't make > a faster Haskell by itself. Absolutely. > I could go on by quoting common "Harrop jokes" like "you need types in > the low-level IR", etc. trying to tell him that this is simply wrong; > but after reading through the Caml/LISP mailing list archives (thanks > for the pointers by several readers), I'm pretty much convinced that > Jon simply decided to end his war against LISP just to start a new one > against ocamlopt. Suggesting that OCaml programmers use LLVM as a library because you can get huge performance gains is hardly a "war against ocamlopt". Cheers, Jon.