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=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 154A6BC6C for ; Wed, 3 Oct 2007 00:23:24 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAANVfAkfLENaMn2dsb2JhbACONgEBAQEHBAYHCBg X-IronPort-AV: E=Sophos;i="4.21,221,1188770400"; d="scan'208";a="3672560" Received: from ipmail01.adl2.internode.on.net ([203.16.214.140]) by mail3-smtp-sop.national.inria.fr with ESMTP; 03 Oct 2007 00:23:22 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAIldAkd5LHvc/2dsb2JhbAAM X-IronPort-AV: E=Sophos;i="4.21,221,1188743400"; d="scan'208";a="202847317" Received: from ppp121-44-123-220.lns10.syd6.internode.on.net (HELO [192.168.1.201]) ([121.44.123.220]) by ipmail01.adl2.internode.on.net with ESMTP; 03 Oct 2007 07:53:19 +0930 Subject: RE: [Caml-list] best and fastest way to read lines from a file? From: skaller To: David Allsopp Cc: 'kirillkh' , caml-list@yquem.inria.fr In-Reply-To: <004601c80539$6a8a4360$017ca8c0@countertenor> References: <779bf2730710011427g5983da4cw6ad8b715a9e38771@mail.gmail.com> <47016CEE.8010704@crans.org> <200710021239.l92CdwZ15641@virtutech.se> <47024002.2080206@janestcapital.com> <95513600710021323u762efd5k5ee6bdd03d7cc37@mail.gmail.com> <004601c80539$6a8a4360$017ca8c0@countertenor> Content-Type: text/plain Date: Wed, 03 Oct 2007 08:23:17 +1000 Message-Id: <1191363797.6668.103.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; 0100,:01 inherently:01 ocaml:01 recursive:01 compiler:01 semantics:01 minimise:01 ocamlopt:01 ackermann:01 mutable:01 degenerate:98 2.5:98 sourceforge:01 wrote:01 caml-list:01 On Tue, 2007-10-02 at 22:15 +0100, David Allsopp wrote: > > A little weird to see such inherently functional construct as fold > implemented imperatively. But it's fine with me, as long as it does the job. > I > > wonder, though, how would the performance of a line counter based on your > code compare with the one suggested by Brian. > > It's faster, though only slightly - I was going to post an imperative > solution earlier, too. Even in Ocaml, a recursive call (tail or otherwise) > has some costs not present in a simple loop. However, I don't agree that > it's more natural - "ugly" is more the word I'd use! In Felix, tail-rec calls are generally faster than loops. The reason is that the compiler is better able to reason about the semantics and so it can do better optimisations. OTOH loops degenerate to conditional goto-spaghetti and would require SSA analysis to recover. For example, given: fun f(x,y) ... f (a,b) the implementation generates var x,y; set_initial_values(x,y); start: ... paropt x,y = a,b; goto start; where 'paropt' serialises the parallel assignment using an optimisation algorithm which tries to minimise the number of assignments and temporaries used. this has a significant impact on performance .. Felix version of Ackermann's function is more then 2.5x faster than Ocamlopt, and almost 2x faster than C. Ackermann has 2 tail-rec calls. Trying to do this with loops is much harder because, unlike the tail-rec formulation, the 'inputs' and 'outputs' connected by the loops are not explicit, as they are when a function is used and parameters and arguments define the input/output relationship (and everything else local is a temporary with no persistence: Felix doesn't not allow functions to have side effects, so only local data is mutable). -- John Skaller Felix, successor to C++: http://felix.sf.net