From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: ** X-Spam-Status: No, score=2.8 required=5.0 tests=DNS_FROM_RFC_POST,SPF_NEUTRAL autolearn=disabled version=3.1.3 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 3FC8FBBAF for ; Mon, 1 Jun 2009 19:04:30 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnkCAFenI0rRVdmxkGdsb2JhbACXTz8BAQEBCQkMBxEDpSQIgQyOKgEDAgSECAWGPQ X-IronPort-AV: E=Sophos;i="4.41,285,1241388000"; d="scan'208";a="28648648" Received: from mail-gx0-f177.google.com ([209.85.217.177]) by mail3-smtp-sop.national.inria.fr with ESMTP; 01 Jun 2009 19:04:26 +0200 Received: by gxk25 with SMTP id 25so2046571gxk.21 for ; Mon, 01 Jun 2009 10:04:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:reply-to:to:subject:date :user-agent:references:in-reply-to:content-type :content-transfer-encoding:content-disposition:message-id; bh=8G3qFmDWyf00Dx7YqLQE4H1DonS1gG7YlAJ6h5ZbqZ0=; b=QTbAUuPixEjCFHkotYgC2JXt4GwvNsjQQnazTxMycRNY2lRffoV7EoGLC2zhhUCsDj 0HTkUF+Hn7gxsZHKsAcl4tJr+vl8obyum5tnROaJ+/QY1+BBkqKOZixJRPnzEr0qiqj7 4S+5GZyXZAUl2EFP5gnotHVHPdKWhxD4edytU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:reply-to:to:subject:date:user-agent:references:in-reply-to :content-type:content-transfer-encoding:content-disposition :message-id; b=czqYJzb9fDCreaKBAOsHlOxZD2JlrODbgYKPsBHSLtH9/j9jsg0ZAnQvEi7P57U57V Zt9UkZ+6ICZX2qY7Dz3buZmAPRKc/LIkn2NWvYgntDifyjaEYxBXkXk7Y4ewQwGoga+v ZTXK4uYCIXT+K5CbmGwA4v6IrA/tEwqzGIvV0= Received: by 10.90.101.17 with SMTP id y17mr5384276agb.107.1243875862854; Mon, 01 Jun 2009 10:04:22 -0700 (PDT) Received: from ?192.168.0.102? ([98.230.173.131]) by mx.google.com with ESMTPS id 4sm7558607agc.12.2009.06.01.10.04.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 01 Jun 2009 10:04:22 -0700 (PDT) From: Peng Zang Reply-To: peng.zang@gmail.com To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Width subtyping Date: Mon, 1 Jun 2009 13:04:18 -0400 User-Agent: KMail/1.9.9 References: <820784.66094.qm@web111511.mail.gq1.yahoo.com> <008901c9e2c4$46975500$d3c5ff00$@allsopp@metastack.com> In-Reply-To: <008901c9e2c4$46975500$d3c5ff00$@allsopp@metastack.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906011304.20561.peng.zang@gmail.com> X-Spam: no; 0.00; subtyping:01 hash:01 bytecode:01 ocamlopt:01 optimise:01 caching:01 compiler:01 bytecode:01 runtime:01 peng:98 peng:98 2009:98 paging:98 wrote:01 wrote:01 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 01 June 2009 10:21:36 am David Allsopp wrote: > Dario Teixeira wrote: > > Thanks -- that is also an interesting solution. I'm guessing it will > > be faster, though it might consume more memory in cases where only one > > field is actually used. I'll have to try it side-by-side with the > > object based solution to see how they compare in the real world with my > > So as I wouldn't immediately be told "the overhead is irrelevant", I ran a > "quick" benchmark before my last post. I compared summing 7 million > 3-int-field records and 7 million 3-int-field objects using names a, b, c. > On my machine, averaged out and with enough RAM that neither paging nor the > GC get in the way, objects were nearly 3 times slower. I then tried with > 10-int-field records and objects - in this case, objects were just over 4 > times slower (read on). This was in bytecode - I didn't bother with native > code. > > The overhead of an object is 2 words (one contains tracking information > about the actual class of the object and the other is a unique identifier) > + (I think) 1 extra word for every field (because each int is boxed in a > 1-tuple so that its tag can be recorded). Importantly, accessing fields in > a record is an O(1) operation but for objects it's O(log n) for the number > of fields because a binary search is done to locate the field with the > correct tag. ocamlopt may of course optimise this search by caching the > absolute index of the field in a "recognised" object layout; I didn't look > in the compiler. My test between 3 and 10 fields would suggest that this > optimisation does not apply in bytecode. > > > David This also matches what I've seen. It seems many optimizations are not performed in bytecode. As a result, the performance characteristics of objects change dramatically when compiled to native code. In my experience objects incur a 20% hit on runtime in native code. Peng -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFKJAoUfIRcEFL/JewRAjlOAJ98T4OTRDy9+TxhzZ6bVuzu7pFjHACdFreL gFn1gN+whdEntNO2JcZguzQ= =1FQS -----END PGP SIGNATURE-----