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 pB8BC4il022360 for ; Thu, 8 Dec 2011 12:12:04 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgBAB+a4E7RVaG2imdsb2JhbAApGoUGnUoBiAwIIgEBAQoJDQcSBiGBcgEBAQEDEgIPHQEbHQEDDAYFBAcHMAICIgERAQUBDg4GEwgMDodtI5oACoscSIJrhEw9iHECBQyKGYEWBIJbkhCNcD2Deg X-IronPort-AV: E=Sophos;i="4.71,319,1320620400"; d="scan'208";a="134529055" Received: from mail-gx0-f182.google.com ([209.85.161.182]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 08 Dec 2011 12:11:59 +0100 Received: by ggnp1 with SMTP id p1so3046790ggn.27 for ; Thu, 08 Dec 2011 03:11:58 -0800 (PST) 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=04D+6smdx7YOgukCrEv9oXKrfiCmNZPEteHUPvatQbM=; b=UffHge2AY/QNX0+f3MoUcI5SzkEcu/wdNWWIGLtLtmtk3HzU0Yeu7AaEKpkgorRuua h/WOJbOXMj5I3CIXRmoeSUYLLLPqFKfsHWdsNTzaegMRtNtoSwzm93JoepmfN4UwGPKj 0b3MgRBdfwHViOH3iUg1WIMKxMIsY/E3YBzrk= Received: by 10.101.113.9 with SMTP id q9mr491687anm.132.1323342717244; Thu, 08 Dec 2011 03:11:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.105.228 with HTTP; Thu, 8 Dec 2011 03:11:36 -0800 (PST) In-Reply-To: References: <55531934-37A5-4CC5-AB67-20CE4CCE8269@googlemail.com> <4EE08955.30207@frisch.fr> From: Pierre-Alexandre Voye Date: Thu, 8 Dec 2011 12:11:36 +0100 Message-ID: To: Benedikt Meurer Cc: Alain Frisch , caml users , caml@inria.fr Content-Type: multipart/alternative; boundary=001636ed731693d6ce04b392bcd7 Subject: Re: [Caml-list] OCaml maintenance status / community fork (again) --001636ed731693d6ce04b392bcd7 Content-Type: text/plain; charset=UTF-8 2011/12/8 Benedikt Meurer > > > > The problem is IMHO that there is no one at INRIA caring about ARM. In an > open model we would have maintainers for the ARM port(s). > Note that if Ocaml compiler would have a C backend, all these problems or architecture port would disappear... Ocaml would have more than 30 target[1] In my Opinion, trying to generate assembler is a bad idea because modern CPU require a lot of work to generate good assembler. Only the GCC and LLVM team are big enough to be able to make a good job. In the Lisaac project, we were able to compete with C[2]. Lisaac is a compiler for a Smalltalk like language : the if/then/else is unknown to the compiler, it is defined in the true/false object. So it is a proof that a very high level language can reach C performance. Ocaml can do this, because the compiler is able to know a lot of type informations. The Lisaac compiler use strong flow analysis and, more importantly generate C code. To reach performance, Lisaac tailor C code to help GCC to generate very optimized code. For instance, GCC is able to produce MMX/SSE/AVX code when you write code like this : http://gcc.gnu.org/projects/tree-ssa/vectorization.html#vectorizab AutoVectorization is just an example of what you can do with GCC (or LLVM soon certainly) and which would require a lot of work with an own asm generator. [1] http://en.wikipedia.org/wiki/GNU_Compiler_Collection#Architectures [2] http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lisaac&lang2=gcc -- --------------------- https://twitter.com/#!/ontologiae/ http://linuxfr.org/users/montaigne --001636ed731693d6ce04b392bcd7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

2011/12/8 Benedikt Meurer <benedikt.meurer@g= ooglemail.com>



The problem is IMHO that there is no one at INRIA caring about ARM. I= n an open model we would have maintainers for the ARM port(s).
Note that if Ocaml compiler would have a C backend, all these prob= lems or architecture port would disappear...
Ocaml would have more than 30 target[1]
In my Opinion, trying to generat= e assembler is a bad idea because modern CPU require a lot of work to gener= ate good assembler.
Only the GCC and LLVM team are big enough to be able= to make a good job.

In the Lisaac project, we were able to compete with C[2]. Lisaac is a c= ompiler for a Smalltalk like language : the if/then/else is unknown to the = compiler, it is defined in the true/false object. So it is a proof that a v= ery high level language can reach C performance. Ocaml can do this, because= the compiler is able to know a lot of type informations.
The Lisaac compiler use strong flow analysis and, more importantly generate= C code. To reach performance, Lisaac tailor C code to help GCC to generate= very optimized code.
For instance,=C2=A0 GCC is able to produce MMX/SSE= /AVX code when you write code like this : http://gcc.gnu.org/projects/t= ree-ssa/vectorization.html#vectorizab

AutoVectorization is just an example of what you can do with GCC (or LL= VM soon certainly) and which would require a lot of work with an own asm ge= nerator.

[1] http://en.wikipedia.org/wiki/GNU_Compiler_Collectio= n#Architectures
[2] http://shootout.alioth.debian.org/gp4= /benchmark.php?test=3Dall&lang=3Dlisaac&lang2=3Dgcc


--
---------------------
https://twitter.com/#!/ontologiae/http://li= nuxfr.org/users/montaigne

--001636ed731693d6ce04b392bcd7--