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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 5E86DBBAF for ; Sun, 5 Dec 2010 22:44:27 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoYBAG+W+0zRVdY0gWdsb2JhbACVHI4MCBUBAQsJChoEHqNojAIBBY0CAQSCFIM1 X-IronPort-AV: E=Sophos;i="4.59,302,1288566000"; d="scan'208";a="69917567" Received: from mail-bw0-f52.google.com ([209.85.214.52]) by mail3-smtp-sop.national.inria.fr with ESMTP; 05 Dec 2010 22:44:26 +0100 Received: by bwz4 with SMTP id 4so9884412bwz.39 for ; Sun, 05 Dec 2010 13:44:26 -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=DPbbnSpFMX0I+qfry6aHKGjSu9s1ynBPiSF2Yq0vjp4=; b=gBGIYQo3L/Gd0RQ7uqTGZdYzrZ2e9jXixxPMVeYJA/Zd6gA7f/eTBVbAeWlYndizJK tsKxv967dgvE1N+44CueqCPMfRjCYkdgFqKczdjJIwTDf+mhpsFQ0k2eWQoA5pAV3g4U 2S20PiseNCntN3Q4hcSvI+IyxXx7GU1t1qFRc= 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=NNzJRfYUtR6e8U5fCQzSGlIocbkAY+7XPnA+xeqxCsXZaudsoYscnaSEfcRr1b2l6F 30feiUkjV2JgdgUrIAzW1auOLPNfqTxeZlCp9M6m3eh5j2F9qE6ZnoGuVpelQerNDn16 xn5iFOETZAL6Nxy6/ie6gegk8vemJ0smIi6tA= Received: by 10.204.60.76 with SMTP id o12mr4981904bkh.89.1291585466467; Sun, 05 Dec 2010 13:44:26 -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 v1sm2121282bkt.5.2010.12.05.13.44.25 (version=SSLv3 cipher=RC4-MD5); Sun, 05 Dec 2010 13:44:25 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) Subject: Re: ocamlopt LLVM support (Was: [Caml-list] OCamlJIT2 vs. OCamlJIT) From: Benedikt Meurer In-Reply-To: Date: Sun, 5 Dec 2010 22:44:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8E93EF1D-DD94-477C-ADC7-3E9E21209768@googlemail.com> 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> <0b9301cb91a3$8f42fd60$adc8f820$@com> <0cae01cb9325$a8ddc3d0$fa994b70$@com> <004901cb94b8$c03abf80$40b03e80$@com> To: caml-list@yquem.inria.fr X-Mailer: Apple Mail (2.1081) X-Spam: no; 0.00; ocamlopt:01 ocaml:01 vectors:01 matrices:01 hash:01 unboxed:01 bigarrays:01 ffi:01 coq:01 ocaml:01 ocamlopt:01 computations:01 dependencies:01 dependencies:01 wrote:01 On Dec 5, 2010, at 22:21 , Benedikt Meurer wrote: > On Dec 5, 2010, at 21:12 , Jon Harrop wrote: >=20 >>> Using a different data representation within OCaml would indeed be >>> possible, but one has to ask what it's worth? You'd get better = floating >>> point performance (most likely) >>=20 >> And faster tuples, ints, chars, complex numbers, low-dimensional >> vectors/matrices, hash tables and so on. More types (e.g. int16 and >> float32). Even arbitrary-precision arithmetic can benefit by keeping = small >> numbers unboxed when possible. Bigarrays disappear. The FFI gets = simpler, >> easier to use and more powerful (e.g. you can generate AoS layouts = for >> OpenGL). The benefits are enormous in the general case but that is = beside >> the point here. Moreover, this would never be accepted either because = it >> would degrade the performance of applications like Coq. If it is done = at >> all, such work must be kept separate from the OCaml compilers. >=20 > ocamlopt already supports float32 and int16, tho they are not = exploited to the upper layers (don't know why, but I also don't know why = one would need them). To be exact, you could load/store float32 and int16 values. At least for = int16, computations would be less efficient on modern CPUs, since the = partial register reads/writes would create false dependencies and = therefore result in less efficient instruction scheduling (similar for = float32 with SSE2, i.e. "divss" leaves the three higher doublewords of = the target register unchanged, thereby introducing false dependencies on = previous instructions). Benedikt=