Compiling Ocaml sources to c sources

Compiling Ocaml sources to c sources

[Vincent Gripon]

[-- Attachment #1.1: Type: text/plain, Size: 719 bytes --]

  Hello,

We are currently planing to participate to a programming contest. This 
contest allows the use of four languages (C/C#/C++/java) but not OCaml.

We would like to use Ocaml as it is to us the language that fits the 
most the kind of exercises proposed. The organizers don't mind if we use 
OCaml as long as we provide an easily compilable C source to them, even 
if it is not readable.

Is there any platform independent way to compile OCaml sources to C 
sources?  And if not, do you have any pointer (we gave a try at 
compiling OCaml sources to C object files using the -output-obj option 
but couldn't compile then the resulting file with our C compiler)?

Best,

Vincent <mailto:caml-list@yquem.inria.fr>

[-- Attachment #1.2: Type: text/html, Size: 1531 bytes --]

[-- Attachment #2: vincent_gripon.vcf --]
[-- Type: text/x-vcard, Size: 354 bytes --]

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

Re: [Caml-list] Compiling Ocaml sources to c sources [NC]

[Rabih CHAAR]

[-- Attachment #1: Type: text/plain, Size: 2745 bytes --]

Hello,
when compiling ocaml to bytecode with the -output-obj flag, a c file is 
created containing essentially the produced bytecode in a c array, which 
will be fed to caml via caml-startup functions.

This doesn't relate to generating C source with a translation for your 
functional code in Ocaml.

I don't have any knowledge of a tool that covers your need, but i am not 
an expert on these issues.

Sincerely,

Rabih Chaar



Vincent Gripon <vincent.gripon@telecom-bretagne.eu> 
Sent by: caml-list-bounces@yquem.inria.fr
14/09/10 02:09 PM


To
caml-list@yquem.inria.fr
cc

Subject
[Caml-list] Compiling Ocaml sources to c sources






Hello,

We are currently planing to participate to a programming contest. This 
contest allows the use of four languages (C/C#/C++/java) but not OCaml. 

We would like to use Ocaml as it is to us the language that fits the most 
the kind of exercises proposed. The organizers don't mind if we use OCaml 
as long as we provide an easily compilable C source to them, even if it is 
not readable.

Is there any platform independent way to compile OCaml sources to C 
sources?  And if not, do you have any pointer (we gave a try at compiling 
OCaml sources to C object files using the -output-obj option but couldn't 
compile then the resulting file with our C compiler)?

Best,

Vincent[attachment "vincent_gripon.vcf" deleted by Rabih CHAAR/fr/socgen] 
_______________________________________________
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

*************************************************************************
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.
*************************************************************************

[-- Attachment #2: Type: text/html, Size: 3879 bytes --]

Re: [Caml-list] Compiling Ocaml sources to c sources

[David MENTRE]

Hello,

2010/9/14 Vincent Gripon <vincent.gripon@telecom-bretagne.eu>:
> Is there any platform independent way to compile OCaml sources to C sources?

Probably stupid answer: compile to byte code and provide the source
code of the C OCaml byte code interpreter with the program embedded as
C structure?

Sincerely yours,
david

Re: [Caml-list] Compiling Ocaml sources to c sources

[Basile Starynkevitch]

On Tue, Sep 14, 2010 at 02:09:47PM +0200, Vincent Gripon wrote:
>  Hello,
> 
> We are currently planing to participate to a programming contest.

It would be interesting for us to know more about that contest.

> This contest allows the use of four languages (C/C#/C++/java) but
> not OCaml.

That does not mean much. What about libraries you are calling from C?

In particular:

  * can you use any library? This seems strange (because the
    organizers very probably won't have the same libraries or versions
    as you have).

  * do you have any restrictions on the libraries you are using?

  * at the extreme case, the competition might require you to provide
    all the sources of every non standard (in the sense of ISO C
    standard) libraries you are using, and a verified mean to build
    them. What about POSIX system calls?

> 
> We would like to use Ocaml as it is to us the language that fits the
> most the kind of exercises proposed. The organizers don't mind if we
> use OCaml as long as we provide an easily compilable C source to
> them, even if it is not readable.
> 
> Is there any platform independent way to compile OCaml sources to C
> sources? 

I don't see any easy way to do that. There are several issues

  * the Ocaml runtime environment, which not only includes its garbage
    collector but also all the ocaml runtime library.

  * Hacking a C generator inside Ocaml is non-trivial, because of the
    garbage collector, currified function calls, and tail recursion
    etc.

  * If you really insist on coding in Ocaml and if you don't care much
    about performance, you could take my bit-rotten Ocamljit work (I
    forgot where you can find it, and I don't have it anymore, but
    google should help finding it) and make something which transform
    the entire bytecode of an Ocaml program into a gigantic single C
    function (translating straightforwardly every byte code into a
    small chunk of C code). This is not easy to do, and it might not
    be fun neither. Very probably, a C compiler would have pain to
    optimize such a big function (by personal experience, the GCC
    compiler usually take O(n^2) time to optimize with -O2 a
    sufficiently large function of size n, and may also need O(n^2)
    memory). And such an approach might not produce portable code
    (perhaps there are some issues w.r.t. 32 vs 64 bits
    systems). Actually, portable C is a fiction: only ported C
    programs can exist.

Did you also consider using Scheme, it has several implementations
generating C code (Chicken & Stalin come to mind).

But still, programming in C does not mean much! What about
portability? building? external libraries? linking other stuff? target
system?

If you have complete freedom on what you link with your program, you
could hack a libocamlrun to be linkable, and link the bytecode as an
array, as suggested previously.

I would imagine that preparing stuff to make you code in Ocaml and fit
into the contest rules is a big lot of work.

Cheers.

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: [Caml-list] Compiling Ocaml sources to c sources

[Thomas Gazagnaire]

Hi Vincent!

you can try camloo [1] which compiles (old-syntax) caml-light to bigloo,
which is a scheme to C compiler. I reckon it would be quite easy to
update it to parse the ocaml syntax if you don't use
functors/objects/variants/labels/thread (ie. if you use only what is
available in caml-light).

Cheers,
Thomas

[1] http://www-sop.inria.fr/members/Thomas.Gazagnaire/


On Tue, 2010-09-14 at 14:09 +0200, Vincent Gripon wrote:
> Hello,
> 
> We are currently planing to participate to a programming contest. This
> contest allows the use of four languages (C/C#/C++/java) but not
> OCaml. 
> 
> We would like to use Ocaml as it is to us the language that fits the
> most the kind of exercises proposed. The organizers don't mind if we
> use OCaml as long as we provide an easily compilable C source to them,
> even if it is not readable.
> 
> Is there any platform independent way to compile OCaml sources to C
> sources?  And if not, do you have any pointer (we gave a try at
> compiling OCaml sources to C object files using the -output-obj option
> but couldn't compile then the resulting file with our C compiler)?
> 
> Best,
> 
> Vincent
> _______________________________________________
> 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

Re: [Caml-list] Compiling Ocaml sources to c sources

[Grant Rettke]

OCaml compiled by F# called by C#?

On Tue, Sep 14, 2010 at 7:47 AM, Thomas Gazagnaire
<thomas.gazagnaire@inria.fr> wrote:
> Hi Vincent!
>
> you can try camloo [1] which compiles (old-syntax) caml-light to bigloo,
> which is a scheme to C compiler. I reckon it would be quite easy to
> update it to parse the ocaml syntax if you don't use
> functors/objects/variants/labels/thread (ie. if you use only what is
> available in caml-light).
>
> Cheers,
> Thomas
>
> [1] http://www-sop.inria.fr/members/Thomas.Gazagnaire/
>
>
> On Tue, 2010-09-14 at 14:09 +0200, Vincent Gripon wrote:
>> Hello,
>>
>> We are currently planing to participate to a programming contest. This
>> contest allows the use of four languages (C/C#/C++/java) but not
>> OCaml.
>>
>> We would like to use Ocaml as it is to us the language that fits the
>> most the kind of exercises proposed. The organizers don't mind if we
>> use OCaml as long as we provide an easily compilable C source to them,
>> even if it is not readable.
>>
>> Is there any platform independent way to compile OCaml sources to C
>> sources?  And if not, do you have any pointer (we gave a try at
>> compiling OCaml sources to C object files using the -output-obj option
>> but couldn't compile then the resulting file with our C compiler)?
>>
>> Best,
>>
>> Vincent
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> 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
>



-- 
http://www.wisdomandwonder.com/
ACM, AMA, COG, IEEE

Re: [Caml-list] Compiling Ocaml sources to c sources

[Vincent Gripon]

[-- Attachment #1: Type: text/plain, Size: 3924 bytes --]

  Thanks for your answer,

On 09/14/2010 02:43 PM, Basile Starynkevitch wrote:
 > On Tue, Sep 14, 2010 at 02:09:47PM +0200, Vincent Gripon wrote:
 >>  Hello,
 >>
 >> We are currently planing to participate to a programming contest.
 > It would be interesting for us to know more about that contest.

We are entering the IEEEXtreme programming competition ( 
http://www.ieee.org/membership_services/membership/students/competitions/xtreme/index.html 
).

 >> This contest allows the use of four languages (C/C#/C++/java) but
 >> not OCaml.
 > That does not mean much. What about libraries you are calling from C?
 >
 > In particular:
 >
 >   * can you use any library? This seems strange (because the
 >     organizers very probably won't have the same libraries or versions
 >     as you have).
 >
 >   * do you have any restrictions on the libraries you are using?
 >
 >   * at the extreme case, the competition might require you to provide
 >     all the sources of every non standard (in the sense of ISO C
 >     standard) libraries you are using, and a verified mean to build
 >     them. What about POSIX system calls?

There is very little information on these aspects, it looks like only 
the basic gcc compilers are available. The proposed exercises will 
probably not require any library or complicated system call, as it is 
more an algorithmic contest than system one.

 >
 >> We would like to use Ocaml as it is to us the language that fits the
 >> most the kind of exercises proposed. The organizers don't mind if we
 >> use OCaml as long as we provide an easily compilable C source to
 >> them, even if it is not readable.
 >>
 >> Is there any platform independent way to compile OCaml sources to C
 >> sources?
 > I don't see any easy way to do that. There are several issues
 >
 >   * the Ocaml runtime environment, which not only includes its garbage
 >     collector but also all the ocaml runtime library.
 >
 >   * Hacking a C generator inside Ocaml is non-trivial, because of the
 >     garbage collector, currified function calls, and tail recursion
 >     etc.
 >
 >   * If you really insist on coding in Ocaml and if you don't care much
 >     about performance, you could take my bit-rotten Ocamljit work (I
 >     forgot where you can find it, and I don't have it anymore, but
 >     google should help finding it) and make something which transform
 >     the entire bytecode of an Ocaml program into a gigantic single C
 >     function (translating straightforwardly every byte code into a
 >     small chunk of C code). This is not easy to do, and it might not
 >     be fun neither. Very probably, a C compiler would have pain to
 >     optimize such a big function (by personal experience, the GCC
 >     compiler usually take O(n^2) time to optimize with -O2 a
 >     sufficiently large function of size n, and may also need O(n^2)
 >     memory). And such an approach might not produce portable code
 >     (perhaps there are some issues w.r.t. 32 vs 64 bits
 >     systems). Actually, portable C is a fiction: only ported C
 >     programs can exist.

We downloaded your software and it works perfectly well (with ocaml 
3.09). It seems perfectly suited for the contest rules and we are 
planing to use it in this regard if it does not bother you.

 >
 > Did you also consider using Scheme, it has several implementations
 > generating C code (Chicken & Stalin come to mind).
 >
 > But still, programming in C does not mean much! What about
 > portability? building? external libraries? linking other stuff? target
 > system?
 >
 > If you have complete freedom on what you link with your program, you
 > could hack a libocamlrun to be linkable, and link the bytecode as an
 > array, as suggested previously.
 >
 > I would imagine that preparing stuff to make you code in Ocaml and fit
 > into the contest rules is a big lot of work.

Thanks to your software, it should not be =)

Cheers.


[-- Attachment #2: vincent_gripon.vcf --]
[-- Type: text/x-vcard, Size: 354 bytes --]

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

Re: [Caml-list] Compiling Ocaml sources to c sources

[Vincent Gripon]

[-- Attachment #1: Type: text/plain, Size: 1732 bytes --]

  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.

Cheers!

On 09/14/2010 02:47 PM, Thomas Gazagnaire wrote:
> Hi Vincent!
>
> you can try camloo [1] which compiles (old-syntax) caml-light to bigloo,
> which is a scheme to C compiler. I reckon it would be quite easy to
> update it to parse the ocaml syntax if you don't use
> functors/objects/variants/labels/thread (ie. if you use only what is
> available in caml-light).
>
> Cheers,
> Thomas
>
> [1] http://www-sop.inria.fr/members/Thomas.Gazagnaire/
>
>
> On Tue, 2010-09-14 at 14:09 +0200, Vincent Gripon wrote:
>> Hello,
>>
>> We are currently planing to participate to a programming contest. This
>> contest allows the use of four languages (C/C#/C++/java) but not
>> OCaml.
>>
>> We would like to use Ocaml as it is to us the language that fits the
>> most the kind of exercises proposed. The organizers don't mind if we
>> use OCaml as long as we provide an easily compilable C source to them,
>> even if it is not readable.
>>
>> Is there any platform independent way to compile OCaml sources to C
>> sources?  And if not, do you have any pointer (we gave a try at
>> compiling OCaml sources to C object files using the -output-obj option
>> but couldn't compile then the resulting file with our C compiler)?
>>
>> Best,
>>
>> Vincent
>> _______________________________________________
>> 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
>

[-- Attachment #2: vincent_gripon.vcf --]
[-- Type: text/x-vcard, Size: 366 bytes --]

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

Re: [Caml-list] Compiling Ocaml sources to c sources

[Vincent Gripon]

[-- Attachment #1: Type: text/plain, Size: 627 bytes --]

  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.
Thank you for your answer.

Cheers.

On 09/14/2010 02:35 PM, David MENTRE wrote:
> Hello,
>
> 2010/9/14 Vincent Gripon<vincent.gripon@telecom-bretagne.eu>:
>> Is there any platform independent way to compile OCaml sources to C sources?
> Probably stupid answer: compile to byte code and provide the source
> code of the C OCaml byte code interpreter with the program embedded as
> C structure?
>
> Sincerely yours,
> david
>

[-- Attachment #2: vincent_gripon.vcf --]
[-- Type: text/x-vcard, Size: 354 bytes --]

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

RE: [Caml-list] Compiling Ocaml sources to c sources

[Jon Harrop]

>   * Hacking a C generator inside Ocaml is non-trivial, because of the
>     garbage collector, currified function calls, and tail recursion
>     etc.

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

Cheers,
Jon.

Re: [Caml-list] Compiling Ocaml sources to c sources

[Eray Ozkural]

[-- Attachment #1: Type: text/plain, Size: 1234 bytes --]

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

> >   * Hacking a C generator inside Ocaml is non-trivial, because of the
> >     garbage collector, currified function calls, and tail recursion
> >     etc.
>
> BTW, I was always surprised nobody had converted the bytecode interpreter
> into a via-C compiler by unwinding the C code the interpreter goes through
> to execute a specific OCaml bytecode program. You could even use this with
> 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/decode 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 the problem with Transmeta;
cheap compilation entails cheap performance.

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

[-- Attachment #2: Type: text/html, Size: 1781 bytes --]

Re: [Caml-list] Compiling Ocaml sources to c sources

[Basile Starynkevitch]

On Wed, 15 Sep 2010 15:04:30 +0200
Vincent Gripon <vincent.gripon@telecom-bretagne.eu> 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: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Re: [Caml-list] Compiling Ocaml sources to c sources

[Basile Starynkevitch]

On Wed, 15 Sep 2010 15:18:39 +0200
Vincent Gripon <vincent.gripon@telecom-bretagne.eu> 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: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

RE: [Caml-list] Compiling Ocaml sources to c sources

[Jon Harrop]

> 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.

Re: [Caml-list] Compiling Ocaml sources to c sources

[Vincent Gripon]

[-- Attachment #1: Type: text/plain, Size: 1180 bytes --]

  > 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.

[-- Attachment #2: vincent_gripon.vcf --]
[-- Type: text/x-vcard, Size: 354 bytes --]

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

Re: [Caml-list] Compiling Ocaml sources to c sources

[Eray Ozkural]

[-- Attachment #1: Type: text/plain, Size: 1985 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2600 bytes --]

Re: [Caml-list] Compiling Ocaml sources to c sources

[Fabrice Le Fessant]

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.

Re: [Caml-list] Compiling Ocaml sources to c sources

[Eray Ozkural]

[-- Attachment #1: Type: text/plain, Size: 2070 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3048 bytes --]

Re: [Caml-list] Compiling Ocaml sources to c sources

[Fabrice Le Fessant]

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 <examachine@gmail.com> 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
> <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.
>>