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.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id BBCF3BB84 for ; Sun, 22 Jun 2008 03:56:52 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4CAA9OXUjYi40IiGdsb2JhbACSaQEBAQ8gmlI X-IronPort-AV: E=Sophos;i="4.27,684,1204498800"; d="scan'208";a="12397833" Received: from mail-out8.nyct.net (HELO mail.nyct.net) ([216.139.141.8]) by mail2-smtp-roc.national.inria.fr with ESMTP; 22 Jun 2008 03:56:52 +0200 Received: from [192.168.42.2] (pool-96-250-32-237.nycmny.east.verizon.net [96.250.32.237]) (authenticated bits=0) by mail.nyct.net (8.14.2/8.14.1) with ESMTP id m5M1umgb033285 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Sat, 21 Jun 2008 21:56:50 -0400 (EDT) (envelope-from bhurt@spnz.org) Date: Sat, 21 Jun 2008 22:32:43 -0400 (EDT) From: Brian Hurt X-X-Sender: bhurt@localhost To: Warren Harris Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] cost of monads In-Reply-To: <3822B729-FD99-429E-8150-CEAA57E4D84F@gmail.com> Message-ID: References: <3822B729-FD99-429E-8150-CEAA57E4D84F@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam: no; 0.00; monads:01 ocaml:01 abstraction:01 transformers:01 monads:01 inlining:01 semantics:01 vaguely:01 warren:98 rear:98 wrote:01 partial:01 stack:01 caml-list:01 caml:02 On Sat, 21 Jun 2008, Warren Harris wrote: > I'm considering writing a moderate sized program with high performance needs > in a monad / monad transformer style in ocaml. Although I believe that this > abstraction will offer me benefits in hiding some complexity, some of the > monad transformers I would like to "stack" are quite simple (e.g. a > state-transition monad), and I'm concerned that my program will be paying a > high performance cost due to high function call overhead -- ones which cannot > be optimized away due to module boundaries. The performance hit of monads are two-fold: 1) generally, bind requires an allocation, and 2) functorization and partial application defeat inlining, and require more expensive call semantics (basically, you end up having to call caml_applyn where normally you'd just directly call, or even jump to, the function in question). How much of a penalty this is depends upon how often the monad layer is invoked, or how much work is performed per bind. If the cost of a bind is, say, 10 clocks, and on average you're doing a bind every 20 clocks, that's a huge hit- perfomance just dropped by a factor of 50%. But if you only bind every 200 clocks, then it's only a 5% hit, and it is much less a big deal. I pull these numbers out of me rear end, but they're probably vaguely close to correct. The point is that it's impossible to generally state what the performance hit of monads are, because that's dependent upon how they're used. For performance-sensitive code, I'd probably stay away from higher level abstractions. On the other hand, I'd also consider how performance sensitive the code really is- we programmers have a bad habit of wanting to assume that all code needs to be tuned to within an inch of it's life- but the reality is hardly any code needs to be tuned at all (witness the popularity of languages like Ruby, Python, and PHP- all of which make Java look like greased lightning). Brian