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=1.4 required=5.0 tests=AWL,HTML_MESSAGE,SPF_SOFTFAIL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id BC849BBAF for ; Mon, 24 Aug 2009 14:32:44 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFAKckkkqEqOABXWdsb2JhbACCKC6YJxcLCQcUuEiEGgU X-IronPort-AV: E=Sophos;i="4.44,265,1249250400"; d="scan'208,217";a="45067277" Received: from oxalide-out.extra.cea.fr ([132.168.224.1]) by mail4-smtp-sop.national.inria.fr with ESMTP; 24 Aug 2009 14:32:44 +0200 Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n7OCWhJU019638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 24 Aug 2009 14:32:43 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n7OCWhU4003577 for ; Mon, 24 Aug 2009 14:32:43 +0200 (envelope-from Pascal.Cuoq@cea.fr) Received: from is005030.intra.cea.fr (is005030.intra.cea.fr [132.166.132.11]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n7OCWhuW004483 for ; Mon, 24 Aug 2009 14:32:43 +0200 Message-Id: <67BF878D-BA80-4CE8-87BA-760AE8082517@cea.fr> From: Pascal Cuoq To: caml-list@yquem.inria.fr In-Reply-To: <20090824100004.6DBBDBBAF@yquem.inria.fr> Content-Type: multipart/alternative; boundary=Apple-Mail-6-79416974 Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [Caml-list] Physical counterpart to Pervasives.compare? Date: Mon, 24 Aug 2009 14:30:40 +0200 References: <20090824100004.6DBBDBBAF@yquem.inria.fr> X-Mailer: Apple Mail (2.936) X-Spam: no; 0.00; cuoq:01 cuoq:01 pervasives:01 pervasives:01 ocaml's:01 compaction:01 byterun:01 val:01 sizeof:01 ocaml's:01 compaction:01 byterun:01 val:01 sizeof:01 garbage:01 --Apple-Mail-6-79416974 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Pascal Cuoq a =E9crit : >> Elnatan Reisner wrote: >>> Is there something that can complete this analogy: >>> (=3D) is to (=3D=3D) as Pervasives.compare is to ___? >>> > The simple solution is to number at creation the objects that you =20 > want to > physically compare, using an additional field. Since people are still participating in this topic, I have a remark. It is more a "what not to do" kind of remark, but after replying last time, I remembered that the current algorithm used by OCaml's GC for compaction does not change the order of blocks in memory (byterun/compact.c). Therefore, with the current version, if you make sure in some way that the values that you want to compare are allocated directly in the major heap (there are a couple of ways to do that), you can theoretically compare their addresses as unsigned longs: their order will not change during execution. But you should still do the comparison with a unique C function written for this purpose. If you tried to use a "convert address to int" function, you would have a race condition between the conversion of each address and garbage collection. This is all in very poor taste, even more so than the usual discussions about =3D=3D on this list. Do I get some kind of prize for breaking the record? Pascal __ PS: I wrote a "convert address to int" function for another purpose once. In order to increase my chances for the prize, I will provide it here. Someone might be interested in it. Perhaps someone who maintains a small library for computing the size of an ML value... external address_of_value: 'a -> int =3D "address_of_value" value address_of_value(value v) { return (Val_long(((unsigned long)v)/sizeof(long))); } --Apple-Mail-6-79416974 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pascal Cuoq a =E9crit = :
Elnatan Reisner = wrote:
Is there something that can = complete this = analogy:
(=3D) = is to (=3D=3D) as Pervasives.compare is to = ___?

The simple solution is to number at creation the objects = that you want to
physically = compare, using an additional = field.

Since people are still = participating in this topic,
I have a remark. It is more a = "what not to do" kind of
remark, but after replying last time, = I remembered
that the current algorithm used by OCaml's = GC
for compaction does not change the order = of blocks
in memory (byterun/compact.c). Therefore, with = the
current version, if you make sure in some = way
that the values that you want to = compare
are allocated directly in the major = heap
(there are a couple of ways to do = that), 
you can theoretically compare = their addresses
as unsigned longs: their order will = not change
during execution.
But you should still do = the comparison
with a unique C function written for this = purpose.
If you tried to use a "convert address to int" = function,
you would have a race condition between the = conversion
of each address and garbage = collection.

This is all in very poor taste, = even more so than
the usual discussions about =3D=3D on this = list.
Do I get some kind of prize for breaking the = record?

Pascal
__
PS: I = wrote a "convert address to int" function for
another purpose = once. In order to increase my chances
for the prize, I will = provide it here. Someone might be
interested in it. Perhaps = someone who maintains a small
library for computing the = size of an ML value...

external = address_of_value: 'a -> int =3D = "address_of_value"

value address_of_value(value = v)
{
  return = (Val_long(((unsigned = long)v)/sizeof(long)));
}

= --Apple-Mail-6-79416974--