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.2 required=5.0 tests=AWL,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 364E8BB84 for ; Wed, 24 Dec 2008 14:12:59 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIBAHzDUUnRVdoUjWdsb2JhbACTLT4BAQEBCQkKCQ8FqjRYhFeMVwEDAQOGP4Jl X-IronPort-AV: E=Sophos;i="4.36,278,1228086000"; d="scan'208";a="20778575" Received: from mail-bw0-f20.google.com ([209.85.218.20]) by mail3-smtp-sop.national.inria.fr with ESMTP; 24 Dec 2008 14:12:58 +0100 Received: by bwz13 with SMTP id 13so9328986bwz.3 for ; Wed, 24 Dec 2008 05:12:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=88mO/nZc2jodUXQJVt0pKrHtnwT85upjzGIf68gNif4=; b=dE6189kfEHyoLZQLGWDsF/3wtO5WoNVCTG0XqhqJX1ZvqDa7qtEAHRdPuxNd1f1DS4 vLU94OoGYLOpfuJPR2kVynij9mZ6J+0dZtZ+HWAAMIdvIIVcyKbuPrrOq9+3u/fmf7gx wSBEwBx7nqn84GnpVBboJckz+DiOXsWqth6+8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=QMpbiiJX18JiuWit9bC5q1QSJNA+0ajeuoYwbHd+u2Kviqx86E3ToG5wl5TqTwoR8h UmL7enCvh7SbXfLj17SjUKU+74rEXdCkfViPQdo5YL2ZW9zEO53UyiY74b64Ov5rUgik jL3qvrn4teDSq7a5fmgGoN/BOtCzMdNbUjMGQ= Received: by 10.181.11.13 with SMTP id o13mr2198669bki.100.1230124378351; Wed, 24 Dec 2008 05:12:58 -0800 (PST) Received: by 10.181.152.4 with HTTP; Wed, 24 Dec 2008 05:12:58 -0800 (PST) Message-ID: Date: Wed, 24 Dec 2008 14:12:58 +0100 From: "=?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?=" Sender: mikkelfj@gmail.com To: "Jon Harrop" Subject: Re: [Caml-list] More Caml Cc: caml-list@yquem.inria.fr In-Reply-To: <200812230959.24662.jon@ffconsultancy.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <157727.93194.qm@web111508.mail.gq1.yahoo.com> <20081222214456.GA8148@annexia.org> <200812230607.37399.jon@ffconsultancy.com> <200812230959.24662.jon@ffconsultancy.com> X-Google-Sender-Auth: 68530776a0b6e2e3 X-Spam: no; 0.00; mikkel:01 rgensen:01 mikkel:01 allocations:01 ocaml:01 allocating:01 non-mutable:01 trivial:01 erlang:01 threading:01 model:01 compiler:01 deterring:98 garbage:01 heap:01 2008/12/23 Jon Harrop : > symbolics. I am guessing the performance of allocation will be degraded > 10-100x but many allocations can be removed. This leaves me wondering how > much slowdown is acceptable without deterring a lot of users? I think this would be major problem. A great advantage of OCaml is that you can do things you would not normally do in C/C++ for performance reasons, like mapping a list. I believe it is desirable to split allocation into pools dedicated to each physical thread. Memory barriers are really expensive, such as used for atomic increment, not to mention locking. Small block allocation could be done in relatively small heap segments where each physical thread locks a larger heap only when it needs a new segment, but not while allocating within a segment. This can further be improved by adding NUMA support and scope based allocation (arena). If full segments are marked non-mutable where possible, it is probably possible to reduce thread blocking during collection. Garbage collection could be limited to processing full segments. Probably not trivial though. How do you think of adding an Erlang style threading model? Speaking of JIT compiler, would eval make any sense? Mikkel