************************************************************************* This message and any attachments (the "message") are confidential, intended solely for the addressee(s), and may contain legally privileged information. Any unauthorised use or dissemination is prohibited. E-mails are susceptible to alteration. Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. ************ Ce message et toutes les pieces jointes (ci-apres le "message") sont confidentiels et susceptibles de contenir des informations couvertes par le secret professionnel. Ce message est etabli a l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisee est interdite. Tout message electronique est susceptible d'alteration. La SOCIETE GENERALE et ses filiales declinent toute responsabilite au titre de ce message s'il a ete altere, deforme ou falsifie. *************************************************************************

On Wed, Sep 15, 2010 at 8:36 PM, Jon Harrop <jona= thandeanharrop@googlemail.com> wrote:

> =A0 * Hacking a C generator inside Ocaml is non-triv= ial, because of the
> =A0 =A0 garbage collector, currified function calls, and tail recursio= n
> =A0 =A0 etc.

BTW, I was always surprised nobody had converted the bytecode interpr= eter
into a via-C compiler by unwinding the C code the interpreter goes through<= br> to execute a specific OCaml bytecode program. You could even use this with<= br> something like Clang to get JIT compilation to native code. Not very
efficient but surely much faster than interpreted bytecode...

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.

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 t= he problem with Transmeta; cheap compilation entails cheap performance.

Best,

--
Eray Ozkural, Ph= D candidate.=A0 Comp. Sci. Dept., Bilkent University, Ankara
http://groups.yahoo.com/group/= ai-philosophy
http://myspace.com/arizanesil= http://myspace.com/malfunct
--0016363b8f64cb0a140490505642-- 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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id EECCFBC58 for ; Wed, 15 Sep 2010 21:55:49 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYBAHPBkEw+BBBnlGdsb2JhbACiAwEBAQEJCwgJEQMfx14NgnYIgjYEhRw X-IronPort-AV: E=Sophos;i="4.56,372,1280700000"; d="scan'208";a="59338939" Received: from smtp-103-wednesday.nerim.net (HELO kraid.nerim.net) ([62.4.16.103]) by mail2-smtp-roc.national.inria.fr with ESMTP; 15 Sep 2010 21:55:49 +0200 Received: from hector.lesours (ours.starynkevitch.net [213.41.244.95]) by kraid.nerim.net (Postfix) with ESMTP id 2B3F0CF0C8; Wed, 15 Sep 2010 21:55:49 +0200 (CEST) Received: from glinka.lesours ([192.168.0.1] helo=glinka) by hector.lesours with smtp (Exim 4.72) (envelope-from ) id 1Ovy56-0001wy-SB; Wed, 15 Sep 2010 21:55:48 +0200 Date: Wed, 15 Sep 2010 21:57:03 +0200 From: Basile Starynkevitch To: Vincent Gripon Cc: Thomas Gazagnaire , caml-list@yquem.inria.fr Subject: Re: [Caml-list] Compiling Ocaml sources to c sources Message-Id: <20100915215703.d52b3875.basile@starynkevitch.net> In-Reply-To: <4C90C45E.70308@telecom-bretagne.eu> References: <4C8F660B.4060901@telecom-bretagne.eu> <1284468428.2252.400.camel@saorge.inria.fr> <4C90C45E.70308@telecom-bretagne.eu> X-Mailer: Sylpheed 3.1.0beta2 (GTK+ 2.21.7; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; basile:01 basile:01 ocaml:01 ocaml:01 syntax:01 planing:01 interp:01 trivial:01 syntax:01 cheers:01 faiencerie:01 92340:01 reine:01 wrote:01 wrote:01 On Wed, 15 Sep 2010 15:04:30 +0200 Vincent Gripon wrote: > Hi Thomas, > > Basile's suggestion allows us to use the whole OCaml syntax with no real > need for coding. That's why we are planing to use it. > Thank you for your solution. I am not sure to follow what you call "Basile's suggestion" exactly. If it is ocamljitrun.c it is just a tiny improvement over interp.c from ocaml distribution. Of course you don't need my permission to use ocamljitrun.c provided you respect its licence and its copyright owner (which is INRIA, which was my employer at the time I wrote it). And after glancing quickly at http://www.ieee.org/membership_services/membership/students/competitions/xtreme/index.html I was not able to easily find mention of a fixed set of languages like C, C#, Java, C++. However, perhaps in reality, your question becomes: what is source code in the eyes of an expert (the human jury of your competition). This don't have any easy or trivial answer. Maybe your answer should take into account the preference of the jury. The definition I usually like the most is that source code is the form of code which is preferred by the programmer (I think it is a GNU definition, or perhaps an FSF one). But again, this could be subject to interpretation, and lawyers or programmers have different views on it. And different programmers have different preferences (just think about the role of comments; there are probably important in your competition, but they don't mean anything to Ocaml.). Source code is not necessarily even a textual file (but in Ocaml or C it usually is; however I could be very pedantic and claim that source code for me is the code picture with syntax hightlighting and colors -as provided by my favorite editor's setting.). Likewise, I am not able to give a precise definition of what a text is (are two different translations or editions of the Bible the same text?). There used to be systems where source code was not textual. Long long time ago, at IRIA (the predecessor of INRIA) there used to be systems like Centaur... I also remember having a read a paper about Galaxy and hypertext programming (forgot the references). Good luck for the competition. Cheers. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} *** 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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 91E30BC58 for ; Wed, 15 Sep 2010 21:58:35 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AssAAKfCkEzCT4aZnGdsb2JhbACiAwEBAQEBCAsICREix2UNhTQEhRw X-IronPort-AV: E=Sophos;i="4.56,372,1280700000"; d="scan'208";a="59339096" Received: from smtp-153-wednesday.nerim.net (HELO maiev.nerim.net) ([194.79.134.153]) by mail2-smtp-roc.national.inria.fr with ESMTP; 15 Sep 2010 21:58:34 +0200 Received: from hector.lesours (ours.starynkevitch.net [213.41.244.95]) by maiev.nerim.net (Postfix) with ESMTP id 3ABF52E012; Wed, 15 Sep 2010 21:58:34 +0200 (CEST) Received: from glinka.lesours ([192.168.0.1] helo=glinka) by hector.lesours with smtp (Exim 4.72) (envelope-from ) id 1Ovy7m-0001xv-1V; Wed, 15 Sep 2010 21:58:34 +0200 Date: Wed, 15 Sep 2010 21:59:48 +0200 From: Basile Starynkevitch To: Vincent Gripon Cc: David MENTRE , caml-list@yquem.inria.fr Subject: Re: [Caml-list] Compiling Ocaml sources to c sources Message-Id: <20100915215948.9ad55a04.basile@starynkevitch.net> In-Reply-To: <4C90C7AF.2010902@telecom-bretagne.eu> References: <4C8F660B.4060901@telecom-bretagne.eu> <4C90C7AF.2010902@telecom-bretagne.eu> X-Mailer: Sylpheed 3.1.0beta2 (GTK+ 2.21.7; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; basile:01 basile:01 ocaml:01 compilation:01 ocaml:01 ocamlc:01 ocamlopt:01 gcc:01 cheers:01 faiencerie:01 92340:01 reine:01 wrote:01 compiles:01 caml-list:01 On Wed, 15 Sep 2010 15:18:39 +0200 Vincent Gripon wrote: > Hello David, > > This is a good idea. Basile made a just in time implementation which is > preferable to us as we do not know if the contest has time constraints > on the compilation of submitted sources. But my ocamljitrun.c still needs your ocaml sources to be compiled by ocamlc. And you could use ocaml instead. And ocamlopt compiles source code quite quickly in practice (faster that gcc is handling source code compiled with -O2). Did you ask the contest organizer if ocaml is a valid language? Cheers. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} *** 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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id A46EEBC58 for ; Wed, 15 Sep 2010 22:37:48 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlYBAErLkExKfVK0kGdsb2JhbACVNIwyCBUBAQEBCQkMBxEDH6xai0YBBY9NAQSFQQ X-IronPort-AV: E=Sophos;i="4.56,372,1280700000"; d="scan'208";a="69589874" Received: from mail-wy0-f180.google.com ([74.125.82.180]) by mail4-smtp-sop.national.inria.fr with ESMTP; 15 Sep 2010 22:37:48 +0200 Received: by wyb40 with SMTP id 40so552125wyb.39 for ; Wed, 15 Sep 2010 13:37:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:organization:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=/d8KvGR+00pJiJud5OhJE4McWUPqZl5KOb0F3i1Ni6o=; b=iP9b4Dr2cydH0LSBVJZUoREoORs7lKQlwbFZz3CSpY7z6SQdu7ekZlg/bKxr3Hbxph vQ6mtqlgMyboir7bolnfIO6PRc9o/I1ISEMHk+R0lloDAdhCXZqR1AP9asjekoh+K7M8 euk1mHAo0cC1I+gX0cj+vfckoMVErWKFjShVU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:organization :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; b=XUq5+HliS6NhUN1GBuEPKaLbTp0t8gHEgeRW7GgUCICX+XcdKTBS/mGuyMHFZZnywZ udY8SrbKO2ERx/GI4jLdDd+dbO0otqHjOUxa1wa41/ZHg6bvQd/dhqnaq4TiJhBCIs0N wa3ezlCLsk19OdrtLnFGMcT701TtfdnIb2jz4= Received: by 10.227.69.134 with SMTP id z6mr1778751wbi.201.1284583067488; Wed, 15 Sep 2010 13:37:47 -0700 (PDT) Received: from WinEight ([87.115.152.182]) by mx.google.com with ESMTPS id b23sm1602790wbb.16.2010.09.15.13.37.44 (version=SSLv3 cipher=RC4-MD5); Wed, 15 Sep 2010 13:37:46 -0700 (PDT) From: Jon Harrop To: "'Eray Ozkural'" , "'Jon Harrop'" Cc: "'Basile Starynkevitch'" , "'Vincent Gripon'" , References: <4C8F660B.4060901@telecom-bretagne.eu> <20100914124341.GA11500@hector.lesours> <004b01cb54fc$9c435020$d4c9f060$@com> In-Reply-To: Subject: RE: [Caml-list] Compiling Ocaml sources to c sources Date: Wed, 15 Sep 2010 21:37:05 +0100 Organization: Flying Frog Consultancy Message-ID: <006a01cb5515$c9c42420$5d4c6c60$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActVAjlPuIgFb/92QceJxAuxkEe8NwAD4SDQ Content-Language: en-gb X-Spam: no; 0.00; ocaml:01 bytecode:01 ocaml:01 real-world:01 speedup:01 compiler:01 compilation:01 cheers:01 caml-list:01 transmeta:01 data:02 compiling:02 seems:03 hmm:04 problem:05 > 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? Cheers, Jon. 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 EB74CBC59 for ; Thu, 16 Sep 2010 00:17:00 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0BADPjkEzAbHMMmWdsb2JhbACDG55YFQEBAQEBCAsKBxEitQCSOIRNdASNKg X-IronPort-AV: E=Sophos;i="4.56,373,1280700000"; d="vcf'?scan'208";a="57337940" Received: from coliposte.enst-bretagne.fr ([192.108.115.12]) by mail3-smtp-sop.national.inria.fr with ESMTP; 16 Sep 2010 00:17:00 +0200 Received: from localhost (localhost.localdomain [127.0.0.1]) by coliposte.enst-bretagne.fr (8.13.7/8.13.7/2009.11.10) with ESMTP id o8FMGx3v012610; Thu, 16 Sep 2010 00:16:59 +0200 Received: from courrier.enst-bretagne.fr (smtps.enst-bretagne.fr [10.29.90.4]) by coliposte.enst-bretagne.fr (8.13.7/8.13.7/2009.11.10) with ESMTP id o8FMGsOg012600; Thu, 16 Sep 2010 00:16:58 +0200 Received: from [192.168.0.26] (passerelle-interne.enst-bretagne.fr [192.108.117.210]) (user=vgripon mech=PLAIN bits=0) by courrier.enst-bretagne.fr (8.13.8/8.13.8/2010.02.22) with ESMTP id o8FMGiEq009108; Thu, 16 Sep 2010 00:16:49 +0200 Message-ID: <4C9145CC.4010809@telecom-bretagne.eu> Date: Thu, 16 Sep 2010 00:16:44 +0200 From: Vincent Gripon User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.10pre) Gecko/20100910 Shredder/3.1.4pre MIME-Version: 1.0 To: Basile Starynkevitch Cc: David MENTRE , caml-list@yquem.inria.fr Subject: Re: [Caml-list] Compiling Ocaml sources to c sources References: <4C8F660B.4060901@telecom-bretagne.eu> <4C90C7AF.2010902@telecom-bretagne.eu> <20100915215948.9ad55a04.basile@starynkevitch.net> In-Reply-To: <20100915215948.9ad55a04.basile@starynkevitch.net> Content-Type: multipart/mixed; boundary="------------020403090307080607040805" X-Virus-Scanned: amavisd-new at enst-bretagne.fr X-Spam: no; 0.00; ocaml:01 ocaml:01 ocamlc:01 ocamlopt:01 gcc:01 compiler:01 cheers:01 compile:01 compile:01 compiles:01 caml-list:01 compiling:02 compiling:02 functional:02 classical:03 X-Attachments: cset="utf-8" name="vincent_gripon.vcf" name="vincent_gripon.vcf" This is a multi-part message in MIME format. --------------020403090307080607040805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > But my ocamljitrun.c still needs your ocaml sources to be compiled by > ocamlc. And you could use ocaml instead. It appears to us simpler (but maybe it is not?) to compile and provide the ocamljit implementation than the ocaml classical interpreter. > And ocamlopt compiles source code quite quickly in practice (faster > that gcc is handling source code compiled with -O2). I was more concerned about the time to compile the compiler than the time for it to compile our sources. > Did you ask the contest organizer if ocaml is a valid language? It is hard to find this information on the website but only four languages are allowed: C/C++/C# and java. We emailed the organizers explaining that functional languages should also be proposed in the contest, and asked them whether it would be accepted to provide them with a C source code likely hard to read but compiling with minimal prerequisites and executing our program. As long as we accept to provide them with the original source code if they ask it, they find no objection to it. Hopefully if we manage to reach a high rank they will consider adding OCaml for next year contest ;) Cheers, Vincent. --------------020403090307080607040805 Content-Type: text/x-vcard; charset=utf-8; name="vincent_gripon.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vincent_gripon.vcf" begin:vcard fn:Vincent Gripon n:Gripon;Vincent org:Telecom Bretagne;Computer Science and Telecommunications adr:;;Telecom Bretagne - Technopole Brest Iroise;Brest Cedex 3;;29238;France email;internet:vincent.gripon@ens-cachan.org title:PhD Student tel;work:+0033 2 29 00 1586 url:http://perso.eleves.bretagne.ens-cachan.fr/~gripon version:2.1 end:vcard --------------020403090307080607040805-- 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-- 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 AE09ABC58 for ; Thu, 16 Sep 2010 11:08:54 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.56,375,1280700000"; d="scan'208";a="57358508" Received: from peermanence.saclay.inria.fr (HELO [195.83.212.205]) ([195.83.212.205]) by mail3-relais-sop.national.inria.fr with ESMTP; 16 Sep 2010 11:08:54 +0200 Message-ID: <4C91DDE0.2040105@inria.fr> Date: Thu, 16 Sep 2010 11:05:36 +0200 From: Fabrice Le Fessant User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100826 Thunderbird/3.0.7 MIME-Version: 1.0 To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Compiling Ocaml sources to c sources References: <4C8F660B.4060901@telecom-bretagne.eu> <20100914124341.GA11500@hector.lesours> <004b01cb54fc$9c435020$d4c9f060$@com> <006a01cb5515$c9c42420$5d4c6c60$@com> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; ocaml:01 compiler:01 reimplement:01 ocaml:01 appending:01 bytecode:01 eray:01 ozkural:01 compiler:01 abstraction:01 garbage:01 wrote:01 caml-list:01 functions:01 compiling:02 The problem is still the same: even if the code is compiled by a C compiler, there is still the need for the garbage collector. If you don't provide your own conservative GC (for which you would have to reimplement all the native functions of OCaml), then you need to use OCaml GC, and you would have to disable most optimizations to be sure that the GC knows where to find live references. At the end, you would get almost no performance improvement, compared to just appending the assembly code for each bytecode instruction (see Piumarta's work in PLDI'98). --Fabrice Eray Ozkural wrote, On 09/16/2010 02:38 AM: > 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. 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 8F6BBBC58 for ; Thu, 16 Sep 2010 12:46:18 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtEBAM6RkUzRVda0kGdsb2JhbACTaIV/AYgICBUBAQEBCQkMBxEDH6UEiTeCFIZqLYhUAQEDBYU8BIFagmuFZw X-IronPort-AV: E=Sophos;i="4.56,376,1280700000"; d="scan'208";a="57365523" Received: from mail-iw0-f180.google.com ([209.85.214.180]) by mail3-smtp-sop.national.inria.fr with ESMTP; 16 Sep 2010 12:46:17 +0200 Received: by iwn8 with SMTP id 8so1399395iwn.39 for ; Thu, 16 Sep 2010 03:46:16 -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=2KQ0Vhhei+4KHltN1bc1+g15lEMJvVKKKy2l1/A95QQ=; b=w0jjy042thruCtYLkhVNpq9DuFM6IrpGnsLvqB3yavuvKxQv/UPkymSRkbqmo8TG4B y8vXukDdbZLVDUgMWDccmAnhM64GNKe3HhChUCrfUwg/tRa3+OL9A0vGWkuBY68mqwaZ oxuKTTrN6UUq4UDkqc+cSvVKk+RuHg2TeUdQA= 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=VtLj9bR2rGjEs5Uhj5z1YnYjuNH/B/y8+asDnZKO7iGM8bm/JXpF7DwpjqKPnh3xkc 7fXbpebJ2cBRRTiB74lhmiHOPotNJ3e0vzrp/Ups8cgB8kTd8GHUmX/m5Fq5aZV7fAba 3kDqZgNx57PcPyr7DpX3myzHvRe2luroLLMAs= MIME-Version: 1.0 Received: by 10.231.159.203 with SMTP id k11mr3170149ibx.115.1284633975683; Thu, 16 Sep 2010 03:46:15 -0700 (PDT) Received: by 10.231.159.131 with HTTP; Thu, 16 Sep 2010 03:46:15 -0700 (PDT) In-Reply-To: <4C91DDE0.2040105@inria.fr> References: <4C8F660B.4060901@telecom-bretagne.eu> <20100914124341.GA11500@hector.lesours> <004b01cb54fc$9c435020$d4c9f060$@com> <006a01cb5515$c9c42420$5d4c6c60$@com> <4C91DDE0.2040105@inria.fr> Date: Thu, 16 Sep 2010 13:46:15 +0300 Message-ID: Subject: Re: [Caml-list] Compiling Ocaml sources to c sources From: Eray Ozkural To: Fabrice Le Fessant Cc: caml-list@yquem.inria.fr Content-Type: multipart/alternative; boundary=005045015627c9c85f04905e2710 X-Spam: no; 0.00; ocaml:01 eray:01 ozkural:01 ocaml:01 boehm:01 compiler:01 compiler:01 bytecode:01 hypothetical:01 reimplement:01 appending:01 bytecode:01 eray:01 ozkural:01 abstraction:01 --005045015627c9c85f04905e2710 Content-Type: text/plain; charset=ISO-8859-1 Yes, I've seen how wired the GC is in the ocaml sources. I had used the Boehm GC in a compiler project (not for the generated code but the compiler), do you mean that one would have to disable most optimizations in the ocaml bytecode compiler to make such a hypothetical bytecode-to-C compiler work with a C GC, or am I missing something crucial? It's great to be able to learn from actual ocaml compiler writers, BTW, your comments are much appreciated. Regards, On Thu, Sep 16, 2010 at 12:05 PM, Fabrice Le Fessant < fabrice.le_fessant@inria.fr> wrote: > The problem is still the same: even if the code is compiled by a C > compiler, there is still the need for the garbage collector. If you > don't provide your own conservative GC (for which you would have to > reimplement all the native functions of OCaml), then you need to use > OCaml GC, and you would have to disable most optimizations to be sure > that the GC knows where to find live references. At the end, you would > get almost no performance improvement, compared to just appending the > assembly code for each bytecode instruction (see Piumarta's work in > PLDI'98). > > --Fabrice > > Eray Ozkural wrote, On 09/16/2010 02:38 AM: > > 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. > > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > -- 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 --005045015627c9c85f04905e2710 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, I've seen how wired the GC is in the ocaml sources. I had used the=
Boehm GC in a compiler project (not for the generated code but the com= piler),
do you mean that one would have to disable most optimizat= ions in the ocaml bytecode

compiler to make such a hypothetical bytecode-to-C compiler work with = a C
GC, or am I missing something crucial? It's great to be a= ble to learn from actual=A0
ocaml compiler writers, BTW, your com= ments are much appreciated.

Regards,

= On Thu, Sep 16, 2010 at 12:05 PM, Fabrice Le Fessant <= fabrice.le_fessant@inria.fr<= /a>> wrote:

The problem is still the same: even if the = code is compiled by a C
compiler, there is still the need for the garbage collector. If you
don't provide your own conservative GC (for which you would have to
reimplement all the native functions of OCaml), then you need to use
OCaml GC, and you would have to disable most optimizations to be sure
that the GC knows where to find live references. At the end, you would
get almost no performance improvement, compared to just appending the
assembly code for each bytecode instruction (see Piumarta's work in
PLDI'98).

--Fabrice

Eray Ozkural wrote, On 09/16/2010 02:38 AM:

> Well, what I would do is to apply a fully optimizing= compiler from a
> proper hardware abstraction layer, whether it is JIT is irrelevant, bu= t
> I do not see why the system would not start doing this as soon as the<= br> > code is loaded in some place (and not when it starts to run). What is<= br> > certain is that some simple transformation will not speed things up mu= ch.

___________________________________= ____________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.in= ria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

--
Eray Ozkura= l, PhD candidate.=A0 Comp. Sci. Dept., Bilkent University, Ankara
http://groups.yahoo.com/g= roup/ai-philosophy
http://myspace.com/arizanesil= http://myspace.com/malfunct

--005045015627c9c85f04905e2710-- 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 mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 799EABC58 for ; Thu, 16 Sep 2010 13:11:31 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAJuYkUzRVdg0kGdsb2JhbAChcQgVAQEBAQkJDAcRAx+kc4tLhmaJAQEBAwWFPASKLIVfgyE X-IronPort-AV: E=Sophos;i="4.56,376,1280700000"; d="scan'208";a="67690185" Received: from mail-qw0-f52.google.com ([209.85.216.52]) by mail1-smtp-roc.national.inria.fr with ESMTP; 16 Sep 2010 13:11:30 +0200 Received: by qwf6 with SMTP id 6so1197055qwf.39 for ; Thu, 16 Sep 2010 04:11:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=A1F9FXQieenL5AJKDFoYM4pGxdo/6zjkqa3ngfJg8gA=; b=rGdGGHxkgQMbqCkv0dZTn4Ndz9VhHTDlxuvdwxGai6o0vGTuqKM7YjnCSodCWSlunG BhjKKBSgad10LixnW96HIoYQTJ5OZU0d0ptGviK2iu1XKBnH/udFe4r33KtjG4P1cmAk sQi4Y8Sy1MOT7nfU9QcUsa0At16ohmeRtY7AM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=TwHUCPuG5AO+BF7yfesNRav7KCXTBYvu3c/WNFWBsS1vko5c3QN5N4G1iEVnM1qufm HYatGa4LHGXKFtC4JBmt3NDJBDvdb6sPl5CIPfMuptm5XNOlK8kLSJqkMORqjx30MAmL FIZch1qqvq42dA8GoBWZkvOvNnFHjQwZrw/24= MIME-Version: 1.0 Received: by 10.229.250.193 with SMTP id mp1mr2143320qcb.129.1284635490351; Thu, 16 Sep 2010 04:11:30 -0700 (PDT) Sender: fabrissimo@gmail.com Received: by 10.229.48.85 with HTTP; Thu, 16 Sep 2010 04:11:29 -0700 (PDT) In-Reply-To: References: <4C8F660B.4060901@telecom-bretagne.eu> <20100914124341.GA11500@hector.lesours> <004b01cb54fc$9c435020$d4c9f060$@com> <006a01cb5515$c9c42420$5d4c6c60$@com> <4C91DDE0.2040105@inria.fr> Date: Thu, 16 Sep 2010 13:11:29 +0200 X-Google-Sender-Auth: VOt93bO7vqAG7tQXuCs4cpjemYA Message-ID: Subject: Re: [Caml-list] Compiling Ocaml sources to c sources From: Fabrice Le Fessant To: Eray Ozkural Cc: caml-list@yquem.inria.fr Content-Type: text/plain; charset=ISO-8859-1 X-Spam: no; 0.00; ocaml:01 bigloo:01 compiler:01 ocaml's:01 ocaml's:01 pointer:01 ocaml:01 pointers:01 compiler:01 pointers:01 computations:01 dependencies:01 bytecode:01 bytecode:01 eray:01 You could use Boehm's garbage-collector for such a project, indeed, that's what is done in Bigloo, to compile Scheme programs to C. Since Boehm's GC is conservative, it would probably work well in such a system, with or without compiler optimizations, but the GC itself would probably be much slower than OCaml's GC on monothreaded code. On the contrary, OCaml's GC is not conservative, so it really needs to know what is a pointer to OCaml data, and also to be warned when pointers to OCaml data are erased (what caml_modify does). If you leave the C compiler perform all its optimizations, you might end up with pointers to OCaml data that are not where they should be (typically, it can duplicate a variable to parallelize some computations when there are no dependencies between them, and the GC will only scan one of them). So, you have to limit the C compiler to only "safe" optimizations from that point of view. By the way, there are almost no optimizations performed in the Ocaml compiler on bytecode, most of the interesting ones are only performed in the native compiler. I think the philosophy behind this choice is that you want to compile very fast to bytecode (so, no time for optimization), and only use the native code compiler at the end for efficient code. --Fabrice On Thu, Sep 16, 2010 at 12:46 PM, Eray Ozkural wrote: > Yes, I've seen how wired the GC is in the ocaml sources. I had used the > Boehm GC in a compiler project (not for the generated code but the > compiler), > do you mean that one would have to disable most optimizations in the ocaml > bytecode > compiler to make such a hypothetical bytecode-to-C compiler work with a C > GC, or am I missing something crucial? It's great to be able to learn from > actual > ocaml compiler writers, BTW, your comments are much appreciated. > Regards, > On Thu, Sep 16, 2010 at 12:05 PM, Fabrice Le Fessant > wrote: >> >> The problem is still the same: even if the code is compiled by a C >> compiler, there is still the need for the garbage collector. If you >> don't provide your own conservative GC (for which you would have to >> reimplement all the native functions of OCaml), then you need to use >> OCaml GC, and you would have to disable most optimizations to be sure >> that the GC knows where to find live references. At the end, you would >> get almost no performance improvement, compared to just appending the >> assembly code for each bytecode instruction (see Piumarta's work in >> PLDI'98). >> >> --Fabrice >> >> Eray Ozkural wrote, On 09/16/2010 02:38 AM: >> > 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. >>