Re: [Caml-list] Is OCaml fast?

["Oliver Bandel" <oliver@first.in-berlin.de>]

...hmhhh..

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


Ciao,
   Oliver


P.S.:
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" <David.Teller@univ-orleans.fr>:

> 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" <info@gerd-stolpmann.de>:
>> [...]
>>> (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?
>>
>
>