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 2A78ABC57 for ; Wed, 1 Dec 2010 16:00:41 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQAAPrx9UzRVdc0k2dsb2JhbACjDAgVAQEBAQkJCgkRBB6qGot8AQWOCAEEghODNA X-IronPort-AV: E=Sophos;i="4.59,283,1288566000"; d="scan'208";a="90506789" Received: from mail-ew0-f52.google.com ([209.85.215.52]) by mail1-smtp-roc.national.inria.fr with ESMTP; 01 Dec 2010 16:00:40 +0100 Received: by ewy23 with SMTP id 23so3304485ewy.39 for ; Wed, 01 Dec 2010 07:00:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:content-type:mime-version :subject:from:in-reply-to:date:content-transfer-encoding:message-id :references:to:x-mailer; bh=jEcr2fOa4ezjYfaJkTz3nLemFqIpA01nhanuAxW/JuM=; b=mf7d8BuQNpAIww45SnwoxZQs4FC6njpVew6cu1SKn2NkYc11CNZ4qqJA3ZpQyJhTes qmUBs32ptz15OavIQ/OZQuYIsBh23YMz83Pj74tZpQ1K7cMn5vpFghlLhKErNrjlRn/j qj9nChjdkGhQWqXbwtH/QdqmWWeNHbwwbKbDA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=rDo90uiPy7WqtRDMWKNkM4Zm3YZ5ILAXfwmErgatEyp4XCyD2oT4XUOApratf6nfkx ESHDgeOX0oP6ocK1N9upuHN2Xz6KEJTdsjbJCezlMAea2FwN/jpCBsOF1787/voj6RbT 0tcmP3MJaQPELUGk/3xzb1+gy/nnlYsi63f8s= Received: by 10.213.26.74 with SMTP id d10mr4353710ebc.61.1291215640534; Wed, 01 Dec 2010 07:00:40 -0800 (PST) Received: from bespin.kosmos.all (ip-95-223-170-32.unitymediagroup.de [95.223.170.32]) by mx.google.com with ESMTPS id x54sm51651eeh.23.2010.12.01.07.00.39 (version=SSLv3 cipher=RC4-MD5); Wed, 01 Dec 2010 07:00:39 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) Subject: Re: [Caml-list] OCamlJIT2 vs. OCamlJIT From: Benedikt Meurer In-Reply-To: <0b3b01cb9161$a81c8e10$f855aa30$@com> Date: Wed, 1 Dec 2010 16:00:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: 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> To: caml-list@yquem.inria.fr X-Mailer: Apple Mail (2.1081) X-Spam: no; 0.00; compilation:01 ocaml:01 bindings:01 gcc:01 polymorphism:01 integers:01 ocamlopt:01 ocamlopt:01 ocaml's:01 ocaml:01 compiler:01 low-level:01 cheers:01 unproductive:98 wrote:01 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. >> So this is about data representation not code generation (using LLVM >> with boxed floats would result in same/lower performance); >=20 > 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? >> 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. >=20 > 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. >> 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. >=20 > 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. 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). What you are talking about is replacing several design decisions within = OCaml (which have nothing to do with the low-level code generator); this = might be a good idea, and may indeed improve generated code. 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. > Cheers, > Jon. greets, Benedikt=