From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL autolearn=disabled version=3.1.3 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 BCA8EBBCB for ; Tue, 13 May 2008 15:18:18 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnADACIyKUhDWxLCbmdsb2JhbACBU5A9NppE X-IronPort-AV: E=Sophos;i="4.27,478,1204498800"; d="scan'208";a="12534413" Received: from ip67-91-18-194.z18-91-67.customer.algx.net (HELO server1.bertec.net) ([67.91.18.194]) by mail3-smtp-sop.national.inria.fr with ESMTP; 13 May 2008 15:18:01 +0200 Received: from kuba.bertec.net (kuba.bertec.net [192.168.2.16]) by server1.bertec.net (Postfix) with ESMTP id 1BA21CDFA6 for ; Tue, 13 May 2008 09:18:00 -0400 (EDT) From: Kuba Ober To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Re: Why OCaml sucks Date: Tue, 13 May 2008 09:17:59 -0400 User-Agent: KMail/1.9.9 References: <200805090139.54870.jon@ffconsultancy.com> <200805120901.54129.ober.14@osu.edu> <74cabd9e0805121218r75725b23g906282a09dfd00d3@mail.gmail.com> In-Reply-To: <74cabd9e0805121218r75725b23g906282a09dfd00d3@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805130917.59305.ober.14@osu.edu> X-Spam: no; 0.00; ocaml:01 ocaml:01 iirc:01 gcc:01 emits:01 cheers:01 pet:98 wrote:01 caml-list:01 arithmetic:01 explicitly:02 argument:02 functional:02 optimization:03 optimization:03 On Monday 12 May 2008, you wrote: > > Yet, if you look at things in the light of "optimization is > > depessimization", > > you'd much rather have easier to read code, than code which is ugly > > because > > you preoptimized it by hand. This is why, for me, Ocaml has a long way to > > go > > to make it useful for run-of-the-mill production code. My pet peev is > > performance penalty paid for writing in functional style where it > > actually makes sense -- say passing an arithmetic operator to a map-style > > function. > > What do you mean by this? What language would not incur this kind of > performance hit? Is F# able to optimize this out or were you referring to > something else? It's not much about the language, but about implementation. IIRC some Lisps can do this kind of an optimization, gcc could do it as well -- whenever the value of the argument to a function is known, a potentially call-site-specific version of the function can be generated, and in such cases it'd be much simpler, emitted-code-wise, than the version which explicitly emits the arguments and calls the operator. Cheers, Kuba