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 autolearn=disabled version=3.1.3 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 1FD6ABC6C for ; Sun, 15 Jul 2007 15:16:24 +0200 (CEST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l6FDGNEW012415 for ; Sun, 15 Jul 2007 15:16:23 +0200 Received: from [84.59.121.5] (helo=gate.lan.gerd-stolpmann.de) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1IA3xW1YXw-0003LU; Sun, 15 Jul 2007 15:16:22 +0200 Received: from flakew.lan.gerd-stolpmann.de (fw.lan.gerd-stolpmann.de [192.168.1.1]) by gate.lan.gerd-stolpmann.de (Postfix) with ESMTP id 1857CC08C; Sun, 15 Jul 2007 15:16:22 +0200 (CEST) Subject: Re: unboxed scalars - was [Caml-list] caml: camlp4 revised syntax From: Gerd Stolpmann To: Basile STARYNKEVITCH Cc: caml-list@yquem.inria.fr In-Reply-To: <469A082A.70303@starynkevitch.net> References: <4699FB8A.2020504@menta.net> <469A082A.70303@starynkevitch.net> Content-Type: text/plain Date: Sun, 15 Jul 2007 15:16:20 +0200 Message-Id: <1184505381.22819.43.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX18QA20B5tHa+pcdzRLAWOWG1q9/cd0ap9+5F9h cufT+MhSn6CLd/gH8f5MLS/ktjBVNN5s1THNiLQGC35Y4qhfDT jdNdfD1OX+XZ1mOTUFMV4ZcM/0udia/ X-Miltered: at concorde with ID 469A1E27.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; unboxed:01 camlp:01 syntax:01 gerd:01 stolpmann:01 basile:01 unboxing:01 non-trivial:01 unboxing:01 gerd:01 stolpmann:01 viktoriastr:01 64293:01 darmstadt:01 6151:01 Am Sonntag, den 15.07.2007, 13:42 +0200 schrieb Basile STARYNKEVITCH: > Besides, I am pretty sure than on current processors, unboxing scalars is probably more a win because of memory & cache > issues than because of the additional shift & add required to transform a 2n+1 into n or vice versa. Such ALU operations > are very cheap today. Absolutely. Given that any non-trivial program spends 20-40% of its time in garbage collection, the net effect is probably positive, i.e. the GC becomes more faster because of the tagged int representation than the additional ALU cycles cost. (Any unboxing without tagging will make the GC algorithm more complex and thus slower.) You don't see this net effect in too simplistic benchmarks since you need test programs of certain complexity. Gerd -- ------------------------------------------------------------ Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de Phone: +49-6151-153855 Fax: +49-6151-997714 ------------------------------------------------------------