From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id E15B1BB81 for ; Sun, 27 Nov 2005 19:03:25 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id jARI3P2Q030980 for ; Sun, 27 Nov 2005 19:03:25 +0100 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id TAA27404 for ; Sun, 27 Nov 2005 19:03:24 +0100 (MET) Received: from cenn.mc.mpls.visi.com (cenn.mc.mpls.visi.com [208.42.156.9]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id jARI3OSF030976 for ; Sun, 27 Nov 2005 19:03:24 +0100 Received: from [192.168.42.2] (bhurt.dsl.visi.com [208.42.141.66]) by cenn.mc.mpls.visi.com (Postfix) with ESMTP id 4A2F18178; Sun, 27 Nov 2005 12:03:23 -0600 (CST) Date: Sun, 27 Nov 2005 12:08:56 -0600 (CST) From: Brian Hurt X-X-Sender: bhurt@localhost.localdomain To: "Michael D. Adams" Cc: caml-list@inria.fr Subject: Re: [Caml-list] Efficency of varient types In-Reply-To: Message-ID: References: <4387ACC9.2040107@motion-twin.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Miltered: at concorde with ID 4389F4ED.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 4389F4EC.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 bool:01 char:01 pointers:01 pointer:01 segfault:01 ocaml:01 minor:01 wrote:01 slower:01 int:01 primitives:01 data:02 data:02 variant:02 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 On Sun, 27 Nov 2005, Michael D. Adams wrote: > I should clarify what I am proposing because it also only requires one > word. The bottom one or two bits of that word would say which variant > it is. The remaining bits representing any data with that variant. > (Obviously this would only work if the associated data is small > enough, but fortunately most of the primitives are small enough (e.g. > int (31 bits), bool (1 bit), char (8 bits).)) Except that this runs into the problem of knowing the subtle details of the GC- not only how it works now, but what (if any) gaurentees are being given for future development. For example, is it gaurenteed that the GC will recognize words with the low two bits being 10 as not pointers? Or does the low bit being 0 means the GC may (or may not) assume it's a pointer, and weird word values would cause the GC to segfault? Even if it works now, will it continue to work with Ocaml 3.10, 3.20, 4.0, etc. I don't know- I don't work at INRIA. This is exactly what I was warning about earlier. The other thing I'll throw in here is a warning against premature optimization. OK, so method A is 15x slower than method B. But how big of an effect will this have on the overall program? If method B is one clock cycle, and method A is 15 clock cycles, probably not much. 15 clock cycles is about the cost of one mispredicted branch, and much, much cheaper than a cache miss. If you're doing anything at all interesting, the most likely case is that the 14 clock difference will be minor compared to the costs of the rest of the program. Brian