From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p7PAQHOL016551 for ; Thu, 25 Aug 2011 12:26:17 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEBAPEhVk7RVdg2kGdsb2JhbABCFoQ2mycBhylcCBQBAQEBCQkNBxQEIYFAAQEBAQEBARICDx0BGx0BAwELBgUEBwMEBioCAiIBEQEFAQ4OBhMih1AEnXsKi3lAglWFETuIbQIDBoU1gREEglGQSIxcPINl X-IronPort-AV: E=Sophos;i="4.68,280,1312149600"; d="scan'208";a="106578812" Received: from mail-qw0-f54.google.com ([209.85.216.54]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 25 Aug 2011 12:26:11 +0200 Received: by qwc9 with SMTP id 9so2057986qwc.27 for ; Thu, 25 Aug 2011 03:26:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Jeer0S0Qmsnk/tTpKZTvXVINZ1IcJBvjOT2OogT649o=; b=Qgc8twy0Tyw2uU5dCVcQPpwQTr5ia597KLg/TJXLFm88qIAHsntFmcJDS8fo5ZS8x4 xtSVwHfPOm0Ev4PhKJCKrrraJurLrqD+Y0vhPaPSWyUEWDqJSQZjMkRV+34WIXZNUB+k YZvR8RgNYTEl8Qb/JZlbJORdOvMCCIQXD6Aqk= Received: by 10.229.3.81 with SMTP id 17mr299515qcm.101.1314267969119; Thu, 25 Aug 2011 03:26:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.191.71 with HTTP; Thu, 25 Aug 2011 03:25:49 -0700 (PDT) In-Reply-To: <1314267668.3496.62.camel@thinkpad> References: <93199F3B-E9CF-4D93-9B2B-BAAB03F4FC08@googlemail.com> <4EF51F29-D437-4F6F-9C91-DBEA3D4C3EB8@googlemail.com> <1314218451.3496.42.camel@thinkpad> <11577B43-4270-4BA4-AA77-7FDEFB4B563B@googlemail.com> <1314267668.3496.62.camel@thinkpad> From: Pierre-Alexandre Voye Date: Thu, 25 Aug 2011 12:25:49 +0200 Message-ID: To: Gerd Stolpmann Cc: Benedikt Meurer , caml-list@inria.fr, Fischbach Marcell Content-Type: multipart/alternative; boundary=0016364eeb1a70673804ab51db01 Subject: Re: [Caml-list] Linear Scan Register Allocator for ocamlopt/ocamlnat --0016364eeb1a70673804ab51db01 Content-Type: text/plain; charset=UTF-8 I have a stupid question : I wonder if it would not be a bad idea that Ocaml output C code and let gcc do its work, so compile code with good performances in a lot of architecture ? Gcc is able to do autovectorization (SSE, MMX, Larabee in the futur, etc...), very specific processor optimization, etc... But maybe it's a stupid idea ? 2011/8/25 Gerd Stolpmann > Am Donnerstag, den 25.08.2011, 11:34 +0200 schrieb Benedikt Meurer: > > On Aug 25, 2011, at 10:02 , Benedikt Meurer wrote: > > > > >>> - > http://ps.informatik.uni-siegen.de/~meurer/tmp/compiletime_timings.pdfcontains a comparison of the ocamlopt invocations. > > >>> - http://ps.informatik.uni-siegen.de/~meurer/tmp/runtime_timings.pdfcontains comparison of the generated code. > > >>> > > >>> As can be seen from the results, amd64 is more sensitive to register > allocator changes than i386. > > >> > > >> Well, this particular i386 CPU model is a strange guy - Northwoods > have > > >> this extremely long pipeline, which is very sensitive to unforeseen > > >> jumps. It would be more interesting to see this test on a modern CPU > in > > >> i386 mode. My guess is that it behaves then more like amd64. > > > > > > Modern CPUs most probably don't run ocaml in 32bit mode, but more > likely in long mode. That's why we choose to run the i386 on "real 32bit > hardware", where the ocaml i386 port is actually used. > > Right. However, if you look at new 32-bit-only CPUs like older Atoms > these base on modern cores where only some of the circuits were omitted > that are needed for 64-bit execution.-- > [cut] > --------------------- https://twitter.com/#!/ontologiae/ http://linuxfr.org/users/montaigne --0016364eeb1a70673804ab51db01 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have a stupid question : I wonder if it would not be a bad idea that Ocam= l output C code and let gcc do its work, so compile code with good performa= nces in a lot of architecture ? Gcc is able to do autovectorization (SSE, M= MX, Larabee in the futur, etc...), very specific processor optimization, et= c...
But maybe it's a stupid idea ?

2011/8= /25 Gerd Stolpmann <info@gerd-stolpmann.de>
Am Donnerstag, den 25.08.2011, 11:34 +0200 schrieb Benedikt Meurer:
> On Aug 25, 2011, at 10:02 , Benedikt Meurer wrote: >
> >>> - http://ps.informatik.uni-si= egen.de/~meurer/tmp/compiletime_timings.pdf contains a comparison of th= e ocamlopt invocations.
> >>> - http://ps.informatik.uni-siegen= .de/~meurer/tmp/runtime_timings.pdf contains comparison of the generate= d code.
> >>>
> >>> As can be seen from the results, amd64 is more sensitive = to register allocator changes than i386.
> >>
> >> Well, this particular i386 CPU model is a strange guy - North= woods have
> >> this extremely long pipeline, which is very sensitive to unfo= reseen
> >> jumps. It would be more interesting to see this test on a mod= ern CPU in
> >> i386 mode. My guess is that it behaves then more like amd64.<= br> > >
> > Modern CPUs most probably don't run ocaml in 32bit mode, but = more likely in long mode. That's why we choose to run the i386 on "= ;real 32bit hardware", where the ocaml i386 port is actually used.

Right. However, if you look at new 32-bit-only CPUs like older Atoms<= br> these base on modern cores where only some of the circuits were omitted
that are needed for 64-bit execution.--
=C2=A0
[cut]
=
---------------------
https://twitter.com/#!/ontologiae/
http://linuxfr.org/users/m= ontaigne

--0016364eeb1a70673804ab51db01--