From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p0GH4uig006496 for ; Sun, 16 Jan 2011 18:04:56 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQAAEa0Mk1KfVI0kGdsb2JhbACXeYxpCBUBAQEBCQkMBxEEIKVhjBIBBYpWAQSFUA X-IronPort-AV: E=Sophos;i="4.60,330,1291590000"; d="scan'208";a="85230510" Received: from mail-ww0-f52.google.com ([74.125.82.52]) by mail4-smtp-sop.national.inria.fr with ESMTP; 16 Jan 2011 18:04:49 +0100 Received: by wwd20 with SMTP id 20so4325903wwd.9 for ; Sun, 16 Jan 2011 09:04:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature: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=ZOMDp0aLNkIqo3IVZolHXZQZAJvqTlquXuImhUlJA90=; b=fNh15x1RKUrAACP6Y+xUwdAV1ErnavhhV2mh06GLozQMWFtmAsbhVXCqQ6PfWtqxZU xbUBLXdHzp+NSlaa1zRC7lDGzM4IFZf6TRj90arVEtYR5MzSdR9Oe9iFps2hCPIKP45N P4rWXFKOz7wC8igJqnh7oQyA1MprCSAUiK77U= 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=hf7dfCE+I+cb38Px7QTOT9/I22d62YZap7aPdy8rHnVk5903ItQkyPjxfaVfcLn9Ah Q6kOF/NrMFJuAXwfnbAkxmT3NcrSSNgiiUMkV2WxhFH206l4zMUtPX0zkCyHkl5lZrEf LW5PdPJ9onSuAh/26A6BLTZYsHc/+YpLhWrGM= Received: by 10.227.142.85 with SMTP id p21mr3024475wbu.12.1295197457583; Sun, 16 Jan 2011 09:04:17 -0800 (PST) Received: from WinEight ([87.114.187.20]) by mx.google.com with ESMTPS id m13sm2635354wbz.15.2011.01.16.09.04.15 (version=SSLv3 cipher=RC4-MD5); Sun, 16 Jan 2011 09:04:16 -0800 (PST) From: Jon Harrop To: "'Eray Ozkural'" , "'Caml List'" References: In-Reply-To: Date: Sun, 16 Jan 2011 17:03:57 -0000 Organization: Flying Frog Consultancy Message-ID: <005d01cbb59f$63623880$2a26a980$@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: Acu0rCd7zAAhZupPSAq80cnuyc5/UQA7xP/Q Content-Language: en-gb Subject: RE: [Caml-list] Unboxing: how to do it best? Eray wrote: > It's obvious that avoiding pointer chasing, improving locality and reducing storage > will in some cases improve performance considerably. Yes. Generic hash tables are my favourite example where this hurts. Java and OCaml can be over an order of magnitude slower than .NET due to boxing in that case. > 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. Yes, .NET already does what you are describing: unboxed types are called "value types". For example, you can allocate an array of structs and refer to them by array index rather than reference in order to avoid all allocations and garbage collections. Some people have used this approach to write low-latency software that never incurs a garbage collection during steady state operation. I have recently been writing prototype garbage collectors in F# using the same technique to great effect. HPC programmers using OCaml will have to settle for generating code from OCaml when you need to escape its data representation. HLVM is an example of how this might be done and was specifically designed with HPC in mind. Cheers, Jon.