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=0.1 required=5.0 tests=AWL,MISSING_HEADERS autolearn=disabled version=3.1.3 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 9F8F8BC6C for ; Wed, 14 Nov 2007 14:45:33 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAL+KOkfAXQImh2dsb2JhbACPAAEICik X-IronPort-AV: E=Sophos;i="4.21,416,1188770400"; d="scan'208";a="4445079" Received: from discorde.inria.fr ([192.93.2.38]) by mail1-smtp-roc.national.inria.fr with ESMTP; 14 Nov 2007 14:45:33 +0100 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id lAEDjX2n002120 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Wed, 14 Nov 2007 14:45:33 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAG+KOkdCm3xr/2dsb2JhbAA X-IronPort-AV: E=Sophos;i="4.21,416,1188770400"; d="scan'208";a="4230552" Received: from janestcapital.com (HELO smtp.janestcapital.com) ([66.155.124.107]) by mail2-smtp-roc.national.inria.fr with ESMTP; 14 Nov 2007 14:45:32 +0100 Received: from [172.25.129.161] [38.96.172.125] by janestcapital.com with ESMTP (SMTPD-9.10) id ABFB051C; Wed, 14 Nov 2007 08:45:31 -0500 Message-ID: <473AFBFB.1090802@janestcapital.com> Date: Wed, 14 Nov 2007 08:45:31 -0500 From: Brian Hurt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: caml-list@inria.fr Subject: Re: [Caml-list] OCaml runtime using too much memory in 64-bit Linux References: <4731F5D1.2070405@janestcapital.com> <1194459622.15728.94.camel@localhost.localdomain> <47320E10.1050307@janestcapital.com> <200711140520.46016.romain.beauxis@gmail.com> <8ef825670711140403m464c01detff5537abb2211946@mail.gmail.com> <473AF04C.7030107@inria.fr> In-Reply-To: <473AF04C.7030107@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 473AFBFD.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 runtime:01 hash:01 hash:01 byte:01 byte:01 ocaml's:01 pointers:01 ocaml:01 hashtable:01 -fold:98 equality:01 polymorphic:01 polymorphic:01 wrote:01 Xavier Leroy wrote: > >If the problem is confirmed, there are several ways to go about it. >One is to implement the page table with a sparse data structure, >e.g. a hash table. However, the major GC and some primitives like >polymorphic equality perform *lots* of page table lookups, so a >performance hit is to be expected. > I've been contemplating doing this on my own (not at work, I comment), just to see how much of a hit it is. If no one else steps up to the plate, I will. One important comment I will make, in moving to a hash table the size of pages has to increase. The current implementation uses 1 byte per (4K) page for the map- a hash table would use, I project, about 4 words (16 or 32 bytes) per page. To keep the memory utilization equal, we'd need to go for a larger page size- 64K for 32-bit systems. I'd be inclined to go larger than that- the 4K page size was standardized back when the average system (using memory protection) has 1MB, and 16MB was a huge amount of memory. Memory sizes have increased 1024-fold in the same time, meaning I could make an argument for 4M pages. I'm not sure I would (I think you'd run into a fragmentation problem on 32-bit), but it makes the page sizes I'd probably settle on (256K for 32-bit, 1M for 64-bit) a lot more palatable. :-) An advantage large pages would have is that they'd make the table a lot smaller, and thus a lot more cache friendly. I mean, think about it- 1GB of 4K pages at 1 byte per page is 256K, while 1GB of 256K pages at 16 bytes per page is 64K, 1/4 the size. 1GB of 1M pages at 32 bytes per page is 32K, smaller yet. The smaller table is more likely to fit into cache, and cheaper to load into cache. While I wouldn't want to gaurentee anything, I could easily see the smaller table size that fits into cache actually gives a performance boost. I've certainly seen weirder things happen. >The other is to revise OCaml's >data representations so that the GC and polymorphic primitives no >longer need to know which pointers fall in the major heap. This seems >possible in principle, but will take quite a bit of work and break a >lot of badly written C/OCaml interface code. You've been warned :-) > > > Of the two, I think I like the hashtable idea better. If it isn't clear, this whole email is just speaking for myself. I'm not allowed to speak for Jane Street (heck, if I'm luck, I'm allowed to speak *to* Jane Street :-). Brian