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 33FD5BCBC for ; Mon, 22 Nov 2010 18:23:40 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0DAMI16kzAbSoIYGdsb2JhbACiXwsfJQQevV+FSwQ X-IronPort-AV: E=Sophos;i="4.59,237,1288566000"; d="scan'208";a="79987946" Received: from einhorn.in-berlin.de ([192.109.42.8]) by mail4-smtp-sop.national.inria.fr with ESMTP; 22 Nov 2010 18:23:39 +0100 X-Envelope-From: oliver@first.in-berlin.de Received: from localhost (okapi.in-berlin.de [192.109.42.117]) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id oAMHNctD027110; Mon, 22 Nov 2010 18:23:38 +0100 Received: from e178005123.adsl.alicedsl.de (e178005123.adsl.alicedsl.de [85.178.5.123]) by webmail.in-berlin.de (Horde Framework) with HTTP; Mon, 22 Nov 2010 18:23:38 +0100 Message-ID: <20101122182338.3867381u5h2p4f8a@webmail.in-berlin.de> Date: Mon, 22 Nov 2010 18:23:38 +0100 From: "Oliver Bandel" To: "David Rajchenbach-Teller" Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Is OCaml fast? References: <1290434674.16005.354.camel@thinkpad> <20101122180203.2126497sau3zukgb@webmail.in-berlin.de> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) 4.3.3 X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 X-Spam: no; 0.00; bandel:01 in-berlin:01 ocaml:01 usr:01 gcc:01 -wall:01 usr:01 gcc:01 afaik:01 ocaml's:01 univ-orleans:01 bandel:01 gerd:01 stolpmann:01 ocaml:01 ...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 =20 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=3Dnative =20 -fopenmp -D_FILE_OFFSET_BITS=3D64 -I/usr/include/apr-1.0 -lapr-1 -lgomp =20 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 =20 > 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? >> > >