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 p0FCegDE015297 for ; Sat, 15 Jan 2011 13:40:42 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcNAKokMU1V2gB5ZGdsb2JhbAClCAsKBhIku3kNhUMEjl0 X-IronPort-AV: E=Sophos;i="4.60,326,1291590000"; d="scan'208";a="86985378" Received: from emailfrontal2.citycable.ch ([85.218.0.121]) by mail2-smtp-roc.national.inria.fr with SMTP; 15 Jan 2011 13:40:37 +0100 X-Alinto-smtpauth-localdomain: Yes Received: from seldon (unknown [85.218.92.99]) (Authenticated sender: guillaume.yziquel@citycable.ch) by emailfrontal2.citycable.ch (Postfix) with ESMTPA id 8067F83490E; Sat, 15 Jan 2011 13:40:36 +0100 (CET) Received: from yziquel by seldon with local (Exim 4.72) (envelope-from ) id 1Pe5Ow-0004oy-Fb; Sat, 15 Jan 2011 13:38:38 +0100 Date: Sat, 15 Jan 2011 13:38:38 +0100 From: Guillaume Yziquel To: Eray Ozkural Cc: Caml List Message-ID: <20110115123838.GS4195@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id p0FCegDE015297 Subject: Re: [Caml-list] Unboxing: how to do it best? Le Saturday 15 Jan 2011 à 14:02:11 (+0200), Eray Ozkural a écrit : > 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 If you do not care about having the annotation available at runtime instead of being something static (after all, MPI datatypes are available at runtime), you could go for encapsulating type information in first class modules representing datatypes. Then, for instance, given a datatype, you may wish to construct the datatype of an array of such types. Such a function needs to know details about the way OCaml boxes or unboxes different kinds of arrays, and it can be done (though rather awkwardly in my case). So first-class modules encapsulating datatype information seems to me a worthwile option and the only solution I could come with to mimic what would be done in C++ with traits. As for 'annotating type definitions', where would you put the line as to what 'annotating' means? Using type-conv-like Camlp4 processing? But as to avoiding pointer chasing, I think there's no workaround to the way OCaml handles memory. The only solution I can come of is the obvious: use arrays or bigarrays and smart datatypes. -- Guillaume Yziquel