Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Is OCaml fast?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2010-11-22 (17:23)
From: Oliver Bandel <oliver@f...>
Subject: Re: [Caml-list] Is OCaml fast?


...looks like they are biased...

.... not that we are not ;)

...but... as the GC-stuff is available FROM WITHING the language,
in the standard-lib, this is nothing added on later.

And I think it should also be allowed to be used.

To reject environment variables, I can see as acceptable in this case,
but rejecting the GC-stuff does not make sense, because, as just  
mentioned, it is avalable by the programmer from within the code.

What about compiling parameters?
I mean: in C you can use -O for optimization.
This should also be forbidden then.... Is it?

There are so much possibilities to influence the results,
that blocking Gc-module is idiotic, IMHO.


I looked at one of the C-makefiles:

usr/bin/gcc -pipe -Wall -O3 -fomit-frame-pointer -march=native  
-fopenmp -D_FILE_OFFSET_BITS=64 -I/usr/include/apr-1.0 -lapr-1 -lgomp  
binarytrees.gcc-7.c -o binarytrees.gcc-7.gcc_run
rm binarytrees.gcc-7.c

So, -O3 is allowed.
AFAIK with O3 and higher, inline does work.
__inline__ must be forbidden as well as -O3

Optimization should be switched off completely, if
OCaml's optimizations are also not allowed.

Zitat von "David Rajchenbach-Teller" <>:

> I can confirm that old code-snippets were removed (and that both  
> faster solutions and environment variable tweaks were rejected).
> On Nov 22, 2010, at 6:02 PM, Oliver Bandel wrote:
>> Zitat von "Gerd Stolpmann" <>:
>> [...]
>>> (I remember Ocaml was #1
>>> at the shootout a few years ago, faster than C.) So maybe a good
>>> opportunity to post better Ocaml solutions there?
>> [...]
>> Yes I also remember that.
>> I hope that the new OCaml compilers did not
>> make OCaml lessperformance by enhancing other features.
>> And I don't realy think so.
>> But were the old code-snippets emoved, or what was going on,
>> that OCaml degraded that much?