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 741F4BC58 for ; Thu, 16 Sep 2010 02:38:57 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtEBAAIEkUzRVda0kGdsb2JhbACTZIV/AYgICBUBAQEBCQkMBxEDH6wkiTeCFIZ0LYhUAQEDBYU8BIRFhWc X-IronPort-AV: E=Sophos;i="4.56,373,1280700000"; d="scan'208";a="57340409" Received: from mail-iw0-f180.google.com ([209.85.214.180]) by mail3-smtp-sop.national.inria.fr with ESMTP; 16 Sep 2010 02:38:56 +0200 Received: by iwn8 with SMTP id 8so813818iwn.39 for ; Wed, 15 Sep 2010 17:38:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=hcl0/x4TG4QkEJ24+HAqku23/9+SJVTxVHc/3vCcWyY=; b=ZqRF2AFbfMTuPTJo9uymojsYbjFLy108H9uxPn9x9aWOYHIbpcXaS7vf96xtu1xGdZ EkRNS8RFzeuqbP5NiSAhSANd3n2J23kHxjeK59KAiT9iFXbUbffrfSys930cweYa6A4F tfNQQh5anTPTWgFE9/tcgxIR2hcB6QL2oO1DY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=mPlCYpNU01hBLml1iYBdWeaGL8RM/CZ9mArqtvOpbAuPE1+/imfk2Vu02sfkfDvhTg C9QEQmwWHi4ApazieW3gdubRevyvAobQlWmG23kun5Js4IY5LuuKxcpBSNhHMTN+ReHz W1/L09PLJgOWuOGAzCwKR8STfiradJgkfJ8ag= MIME-Version: 1.0 Received: by 10.231.193.135 with SMTP id du7mr1976089ibb.176.1284597535687; Wed, 15 Sep 2010 17:38:55 -0700 (PDT) Received: by 10.231.159.131 with HTTP; Wed, 15 Sep 2010 17:38:55 -0700 (PDT) In-Reply-To: <006a01cb5515$c9c42420$5d4c6c60$@com> References: <4C8F660B.4060901@telecom-bretagne.eu> <20100914124341.GA11500@hector.lesours> <004b01cb54fc$9c435020$d4c9f060$@com> <006a01cb5515$c9c42420$5d4c6c60$@com> Date: Thu, 16 Sep 2010 03:38:55 +0300 Message-ID: Subject: Re: [Caml-list] Compiling Ocaml sources to c sources From: Eray Ozkural To: Jon Harrop Cc: Basile Starynkevitch , Vincent Gripon , caml-list@yquem.inria.fr Content-Type: multipart/alternative; boundary=005045017519cb4a83049055ab3a X-Spam: no; 0.00; ocaml:01 eray:01 ozkural:01 bytecode:01 ocaml:01 real-world:01 speedup:01 compiler:01 compilation:01 compiler:01 abstraction:01 eray:01 ozkural:01 bilkent:01 bytecode:01 --005045017519cb4a83049055ab3a Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 15, 2010 at 11:37 PM, Jon Harrop < jonathandeanharrop@googlemail.com> wrote: > > Hmm, this would only optimize the bytecode fetch/decode step of the ocaml > execution cycle. I am not sure that it will result in much real-world > speedup. > > Would be interesting to try. I suspect the C compiler would then optimize > the sequences of operations on the data as well. For example, something > like > vector addition. > > > In fact, that seems to be the main problem with many of these so-called > JIT interpreters, which in my opinion, do not seem to have learnt from the > HAL architectures of IBM OS's etc. Was probably also the problem with > Transmeta; cheap compilation entails cheap performance. > > Can you elaborate? > > Well, what I would do is to apply a fully optimizing compiler from a proper hardware abstraction layer, whether it is JIT is irrelevant, but I do not see why the system would not start doing this as soon as the code is loaded in some place (and not when it starts to run). What is certain is that some simple transformation will not speed things up much. The right way to do it is to determine hot blocks beforehand. Hot blocks can also be determined on the fly but I do not think that JIT is much needed. The time of the determination of hot blocks is most certainly not crucial to optimizations, although the more time compiler has, the better. Simple optimizations will not have much impact. It is not like you can undo the complexity of an optimizing compiler just because you have JIT. In Transmeta's case, you can't translate an obsolete RISC code to efficient VLIW in real-time. This seems to be putting too much strain on the translation. Which ought to be obvious given the complexity of VLIW compilers? Sometimes outsiders have a better view. Best, -- Eray Ozkural, PhD candidate. Comp. Sci. Dept., Bilkent University, Ankara http://groups.yahoo.com/group/ai-philosophy http://myspace.com/arizanesil http://myspace.com/malfunct --005045017519cb4a83049055ab3a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Sep 15, 2010 at 11:37 PM, Jon Harrop <jon= athandeanharrop@googlemail.com> wrote:
> Hmm, this would only optimize the bytecode fetch/dec= ode step of the ocaml
execution cycle. I am not sure that it will result in much real-world
speedup.

Would be interesting to try. I suspect the C compiler would then opti= mize
the sequences of operations on the data as well. For example, something lik= e
vector addition.

> In fact, that seems to be the main problem with many of these so-calle= d
JIT interpreters, which in my opinion, do not seem to have learnt from the<= br> HAL architectures of IBM OS's etc. Was probably also the problem with Transmeta; cheap compilation entails cheap performance.

Can you elaborate?


Well, what= I would do is to apply a fully optimizing compiler from a proper hardware = abstraction layer, whether it is JIT is irrelevant, but I do not see why th= e system would not start doing this as soon as the code is loaded in some p= lace (and not when it starts to run). What is certain is that some simple t= ransformation will not speed things up much.

The right way to do it is to determine hot blocks befor= ehand. Hot blocks can also be determined on the fly but I do not think that= JIT is much needed. The time of the determination of hot blocks is most ce= rtainly not crucial to optimizations, although the more time compiler has, = the better. Simple optimizations will not have much impact. It is not like = you can undo the complexity of an optimizing compiler just because you have= JIT.

In Transmeta's case, you can't translate an obs= olete RISC code to efficient VLIW in real-time. This seems to be putting to= o much strain on the translation. Which ought to be obvious given the compl= exity of VLIW compilers? Sometimes outsiders have a better view.

Best,
=A0
--
Eray Ozkural, PhD= candidate.=A0 Comp. Sci. Dept., Bilkent University, Ankara
http://groups.yahoo.com/group/a= i-philosophy
http://myspace.com/arizanesil= http://myspace.com/malfunct
--005045017519cb4a83049055ab3a--