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 23D22BC57 for ; Wed, 1 Dec 2010 23:03:44 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0AAPFU9kxKfVK0kGdsb2JhbACWNIxkCBUBAQEBCQkMBxEEHqldi3wBBY14AQSCE4M0 X-IronPort-AV: E=Sophos;i="4.59,285,1288566000"; d="scan'208";a="81086250" Received: from mail-wy0-f180.google.com ([74.125.82.180]) by mail4-smtp-sop.national.inria.fr with ESMTP; 01 Dec 2010 23:03:43 +0100 Received: by wyb29 with SMTP id 29so2718557wyb.39 for ; Wed, 01 Dec 2010 14:03:43 -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=zqbBFAZypLCf4oeENssRf98OlLzVSD4fh2UicfKPkqY=; b=jghKK26EUsyBlXLeo/UWX/HKV/D+AVDu8lR+8O7EHNyNgMPCsBIUUr8KFIrSxXO8r5 xhXtT3UY9fAvCSUTKV8eVsH++Kj7Cbg7UOqG6ZLBxSRveMe6EQCNMqqLxqOLh1MwIKrJ +Dr3uXmoDDbSbryG8RywLWTFmdCEDa14tlNPA= 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=CNs23P+hzCTtAt1ulWEbDPc9ggr92h+Bl/vVfnfqkynhvn93Wo7ZESXI+FCJDUc0FN pSojKe/R3jrgCS7gcgoPi8Do6iRIPsxOx+dIygCPMRGWJ5m1UN3RKFWIErtjzldvNY1J DuNrkgscFzLZyOzRMH3l5rS5LmJl2FxPPOKc8= Received: by 10.227.28.100 with SMTP id l36mr2112480wbc.102.1291241023055; Wed, 01 Dec 2010 14:03:43 -0800 (PST) Received: from WinEight ([87.113.160.118]) by mx.google.com with ESMTPS id x6sm249291weq.37.2010.12.01.14.03.40 (version=SSLv3 cipher=RC4-MD5); Wed, 01 Dec 2010 14:03:41 -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> <0b3b01cb9161$a81c8e10$f855aa30$@com> In-Reply-To: Subject: RE: [Caml-list] OCamlJIT2 vs. OCamlJIT Date: Wed, 1 Dec 2010 22:03:16 -0000 Organization: Flying Frog Consultancy Message-ID: <0b9301cb91a3$8f42fd60$adc8f820$@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: AcuRaKMmZub/mec6RM+8MpiAxyAGLgAFrx3g Content-Language: en-gb X-Spam: no; 0.00; compilation:01 ocaml:01 bindings:01 gcc:01 ocaml:01 ocamlopt:01 compiler:01 ocamlopt:01 polymorphism:01 integers:01 compiler:01 low-level:01 bytecode:01 bytecode:01 cheers:01 Benedikt wrote: > On Dec 1, 2010, at 15:11 , Jon Harrop wrote: > > 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. > > LLVM sure does better as an intermediate language than C does, no > question. But that wasn't my point in this example. I think we are talking at cross purposes. My post was to explain some of the many benefits of LLVM in response to Yoann's statement: "I don't understand why there is so much hype around LLVM. Why would you think something written in C++ would be far better than the ocaml code we have in the ocamlopt compiler?" I was not just talking about porting ocamlopt to LLVM but more generally about the advantages of using LLVM from OCaml in any way. > >> 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. > > As does assembler, so even more reasons to emit assembler? LLVM makes it a *lot* easier to generate efficient code, of course. > >> 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. > > So this is an area to work on within ocamlopt. If you can add value types and reified generics to ocamlopt and get them accepted that would be great. > > 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. > > We are talking about using LLVM within the OCaml compiler, so we have > to talk about OCaml, not HLVM or anything else. I was talking more generally about the benefits of LLVM in response to Yoann's statement about the hype surrounding LLVM. HLVM demonstrates some of the things a next-generation ocamlopt might be capable of. > Don't get me wrong, I'm curious to see an LLVM backend for ocamlopt, > especially since that way we would get a native top-level for free (at > least for the JIT capable LLVM targets). But I doubt that LLVM will > make a noticeable difference (except for probably reduced number of > target specific code), since it will be faced with the same data > representation used right now and LLVM will not be able to optimize > much (assuming the ocamlopt higher level optimizations were already > applied). Absolutely. > What you are talking about is replacing several design decisions within > OCaml (which have nothing to do with the low-level code generator); Except that those design decisions have a huge effect on the optimizations LLVM will do (if it is your code gen). > this might be a good idea, and may indeed improve generated code. HLVM's benchmark results would certainly seem to indicate that, yes. > I don't know the opinion of the OCaml core developers, but from my POV, > this sounds like an interesting challenge; however getting beyond a > simplified proof-of-concept requires a lot of hard work. Yes. At the end of the day, the performance gains that can be obtained by bringing the GC up to date already dwarf all of these other effects so a new GC is surely the highest priority. This begs a couple of questions: * How dependent is OCaml bytecode on the data representation and GC? * Could you write an OCaml bytecode interpreter in OCaml? Perhaps we could write a multicore friendly OCamlJIT3. :-) Cheers, Jon.