From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p0FC20ZF009398 for ; Sat, 15 Jan 2011 13:02:13 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnIAAEsbMU1KfVM2kWdsb2JhbACkXggVAQEBAQkLCgcRBCCkLYl6ghiEJy6GWgEBAwWFSwSLHw X-IronPort-AV: E=Sophos;i="4.60,326,1291590000"; d="scan'208";a="86982542" Received: from mail-gw0-f54.google.com ([74.125.83.54]) by mail2-smtp-roc.national.inria.fr with ESMTP; 15 Jan 2011 13:02:12 +0100 Received: by gwj21 with SMTP id 21so1484060gwj.27 for ; Sat, 15 Jan 2011 04:02:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=81dg+CHtnLUtospJn6j3fpy+AwP5bGjUHB33QuEratk=; b=h1FLvDYa7cuneX7NHk2MxenytrrtowXHKMMKSnOrSkmOFtRZvP6O0vPdzwKcCNdWWk d28pbOHXTlTwUe8ICTSp59vNr/9TKvPyyPg+9m0EsSkgGswCWvD+LxYnKyycb6LS7LdB 28+WfHCkAFUgYZ+WdqLiLM/wBF/7lJUrdgyk8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ddvaey91Gnp0auMu0ajP6jQHi5GLaNy3Vn/6PPpJXGJhxsNPlL05ROC5fTEODSzydS A+ZrixYzp5tc6ZyPSvNnya0hkwMehANS3P7rAQ4H6p27xKrPg/Mk7c9Gg5TtMGsn4Jzj ZG/LKtR6gReg1qqdyNJUPV2Vm5p+EECh5oLdU= MIME-Version: 1.0 Received: by 10.90.78.12 with SMTP id a12mr2438282agb.38.1295092931913; Sat, 15 Jan 2011 04:02:11 -0800 (PST) Received: by 10.90.89.4 with HTTP; Sat, 15 Jan 2011 04:02:11 -0800 (PST) Date: Sat, 15 Jan 2011 14:02:11 +0200 Message-ID: From: Eray Ozkural To: Caml List Content-Type: multipart/alternative; boundary=0016361e8978286ba30499e15295 Subject: [Caml-list] Unboxing: how to do it best? --0016361e8978286ba30499e15295 Content-Type: text/plain; charset=ISO-8859-1 It's obvious that avoiding pointer chasing, improving locality and reducing storage will in some cases improve performance considerably. I've found many discussions about unboxing, but I haven't seen any solutions that would satisfy high-performance-computing programmers, who would probably like to have better (i.e. fine-grained) control over memory layout (unboxing double arrays isn't enough). In C++ this is trivial, because C++ is just an abstraction of assembly code. To cut it short, could not we have basically the same affordances of C++ in ocaml by annotating type definitions to indicate where unboxing would be forced? Such annotations aren't a new idea in programming languages, specifically HPF was based largely on parallel storage annotations. Regards, -- Eray Ozkural, PhD candidate. Comp. Sci. Dept., Bilkent University, Ankara --0016361e8978286ba30499e15295 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It's obvious that avoiding pointer chasing, improving locality and redu= cing storage will in some cases improve performance considerably. I've = found many discussions about unboxing, but I haven't seen any solutions= that would satisfy high-performance-computing programmers, who would proba= bly like to have better (i.e. fine-grained) control over memory layout (unb= oxing double arrays isn't enough). In C++ this is trivial, because C++ = is just an abstraction of assembly code. To cut it short, =A0could not we h= ave basically the same affordances of C++ in ocaml by annotating type defin= itions to indicate where unboxing would be forced? Such annotations aren= 9;t a new idea in programming languages, specifically HPF was based largely= on parallel storage annotations.

Regards,

--
Eray Ozkural, PhD = candidate.=A0 Comp. Sci. Dept., Bilkent University, Ankara

--0016361e8978286ba30499e15295--