From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82])
	by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p71GvO7R003195
	for <caml-list@sympa-roc.inria.fr>; Mon, 1 Aug 2011 18:57:24 +0200
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnsBAJHaNk7RVaE2kGdsb2JhbABBp1kIFAEBAQEJCQ0HFAQhgUABAQEBAgESAiwBATcBBAsLNBI0AQUBHAY1h0oComgKjwMBjhAFhWNfn0s8g14
X-IronPort-AV: E=Sophos;i="4.67,301,1309730400"; 
   d="scan'208";a="114691717"
Received: from mail-fx0-f54.google.com ([209.85.161.54])
  by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 01 Aug 2011 18:57:19 +0200
Received: by fxe4 with SMTP id 4so9373326fxe.27
        for <caml-list@inria.fr>; Mon, 01 Aug 2011 09:57:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=gamma;
        h=subject:mime-version:content-type:from:in-reply-to:date:cc
         :content-transfer-encoding:message-id:references:to:x-mailer;
        bh=HA5RvdDN/QSffOcv2dQ+qvbuL2dF4FA4yxnm49KKe54=;
        b=NAHBDf5BFYrWZ5C7dwM5IxvW/9SA9+2SAAFp7kxFX91ru7k7JEa/bbYE/ETxCdQnxw
         DjtLoO1dhnQ9JnKYzNQfPBExEur5VYCF9aVhIh1TWl9rS77GntbcvHVBin6zp4AZM5fz
         kM8sqS5UAARh5NqBhhYQ/YtVKelGJOh5BvyFQ=
Received: by 10.223.73.207 with SMTP id r15mr170267faj.90.1312217838795;
        Mon, 01 Aug 2011 09:57:18 -0700 (PDT)
Received: from coruscant.kosmos.all (ip-95-223-170-32.unitymediagroup.de [95.223.170.32])
        by mx.google.com with ESMTPS id d6sm2987584fak.10.2011.08.01.09.57.13
        (version=SSLv3 cipher=OTHER);
        Mon, 01 Aug 2011 09:57:14 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=iso-8859-1
From: Benedikt Meurer <benedikt.meurer@googlemail.com>
In-Reply-To: <CAPFanBGk8gCmVKFVh4bPZyy8LjoTf9dzVWZsNgrEut=POtM=Pw@mail.gmail.com>
Date: Mon, 1 Aug 2011 18:57:09 +0200
Cc: caml-list@inria.fr, Marcell Fischbach <marcellfischbach@googlemail.com>
Message-Id: <5C80E9B0-FFF1-4D8A-99EC-C6B595C44EFF@googlemail.com>
References: <93199F3B-E9CF-4D93-9B2B-BAAB03F4FC08@googlemail.com> <CAPFanBGk8gCmVKFVh4bPZyy8LjoTf9dzVWZsNgrEut=POtM=Pw@mail.gmail.com>
To: Gabriel Scherer <gabriel.scherer@gmail.com>
X-Mailer: Apple Mail (2.1244.3)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id p71GvO7R003195
Subject: Re: [Caml-list] Linear Scan Register Allocator for ocamlopt/ocamlnat


On Aug 1, 2011, at 17:04 , Gabriel Scherer wrote:

> This work is meant to make a compromise between generated code quality
> and compilation speed to have good performances in rapid
> prototyping/development scenario.
> 
> Do you have more precise measurements on
> - the relative costs of the successive transformations during native
> compilation (including external linking etc.)? Which proportion of
> time is currently used for register allocation?

Right now most of the time in ocamlnat is spent in waiting for the assembler and linker to finish and the runtime linker to load the generated library file. However there are no precise timing results yet.

Marcell did a rough test with ocamlopt last week, building the test suite with both graph coloring and linear scan on a 2009 iMac (Core 2 Duo). The overall time spent in the register allocator dropped from 28s to 8s.

> - the performance cost of this new allocator in the generated code? I
> suppose the results may vary between different architectures (eg. x86
> is probably more sensitive to good allocation decisions than x86_64).

Same here... not yet. From what I've seen, the generated amd64 code is really close to the graph coloring code (isomorphic up to register renaming in most cases). Dunno for i386 yet.

Benedikt