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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id CB18DBC57 for ; Fri, 19 Nov 2010 20:16:44 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al8CADdc5kzRVaE0kGdsb2JhbACUX416CBUBAQEBCQkMBxEDH6Mwi3oBBY4oAQSFSw X-IronPort-AV: E=Sophos;i="4.59,224,1288566000"; d="scan'208";a="67528513" Received: from mail-fx0-f52.google.com ([209.85.161.52]) by mail3-smtp-sop.national.inria.fr with ESMTP; 19 Nov 2010 20:16:44 +0100 Received: by fxm15 with SMTP id 15so2989141fxm.39 for ; Fri, 19 Nov 2010 11:16:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:content-type:mime-version :subject:from:in-reply-to:date:content-transfer-encoding:message-id :references:to:x-mailer; bh=EeMswxDstzS6d4HKdcV+KSXrPV2t12vDLRY03T8QMiw=; b=gGjFldtBECQVXuPSTQhGaq0v3uiKum8xy9wsH/ht+uPYcd19VvUXXvDNcQWnaAG+NG jBcjXFAC0dg8sgIWa1GJcN9iCVsga7x+URwcztlDpoJksMkCfXe2v7lhGi17Wb1FQFZn vQLIkYbpwUoSWgNYFqSNAc2KE0lwsv3xQW00s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=gYxjX58VsQ+yyNrNVqa/0Gtll5bk6kzBcoYJAmj0RDeAWccaAyjQlj2/etalwwuOkV EadiwszGNs40XcsH/ywGnu74ENcTP8jOgN93RFpXOg72RfgS54BEGimWKJVal+mr9U+T A3CMYPpjkwoy61cEE2+rETiT7ZdRRI+OGjLZo= Received: by 10.223.113.78 with SMTP id z14mr2240496fap.50.1290194204158; Fri, 19 Nov 2010 11:16:44 -0800 (PST) Received: from bespin.kosmos.all (ip-95-223-170-32.unitymediagroup.de [95.223.170.32]) by mx.google.com with ESMTPS id k21sm641177faa.25.2010.11.19.11.16.42 (version=SSLv3 cipher=RC4-MD5); Fri, 19 Nov 2010 11:16:43 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) Subject: Re: [Caml-list] Re: Native toplevel? From: Benedikt Meurer In-Reply-To: <4CE64B2B.3050009@inria.fr> Date: Fri, 19 Nov 2010 20:16:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CE395D4.4000105@frisch.fr> <2025993285.616104.1290144569061.JavaMail.root@zmbs4.inria.fr> <4CE64B2B.3050009@inria.fr> To: caml-list@yquem.inria.fr X-Mailer: Apple Mail (2.1081) X-Spam: no; 0.00; toplevel:01 ocamlopt:01 compiler:01 byte-code:01 compiler:01 ocamlopt:01 ocamlc:01 allocating:01 hotspot:98 wrote:01 wrote:01 graph:01 graph:01 inline:01 caml-list:01 On Nov 19, 2010, at 11:02 , Fabrice Le Fessant wrote: > Benedikt Meurer wrote, On 11/19/2010 06:29 AM: >> This is indeed very interesting. I haven't thought of the native = top-level. I haven't done any measurements yet, but from my experience = with ocamlopt, I know that the optimizing native compiler is somewhat = slower than the byte-code compiler. I doubt that this is related solely = to the external as/ld invocations, so there's certainly more work to do = than just replacing the calls to as/ld with an in-process = assembler/linker. >=20 > Indeed, there are some more passes in ocamlopt than in ocamlc, but I > think that most of the time is spent in allocating registers and > generating the assembler file and calling the assembler. As Alain = said, > we already have the inline assembler, so the next step would be to > improve register allocation, either by spilling more variables to = avoid > the quadratic behavior of graph coloring, either by using some linear > scan algorithm (for example, the one of HotSpot). Using the linear scan algorithm with ocamlopt might be a good idea, due = to the structure of the generated code, linear scan should give results = close to that of the graph coloring algorithm for the generated native = code. I'll see if I can hire some students to evaluate an implementation = of linear scan for ocamlopt. > --Fabrice Benedikt=