From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id HAA06134; Thu, 8 Jul 2004 07:50:28 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id HAA06565 for ; Thu, 8 Jul 2004 07:50:26 +0200 (MET DST) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i685oNEV031689; Thu, 8 Jul 2004 07:50:25 +0200 Received: from [192.168.1.200] (ppp214-48.lns1.syd2.internode.on.net [203.122.214.48]) by smtp3.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i685oHHY065784; Thu, 8 Jul 2004 15:20:19 +0930 (CST) Subject: Re: [Caml-list] Does Caml have slow arithmetics ? From: skaller Reply-To: skaller@users.sourceforge.net To: David Brown Cc: Xavier Leroy , caml-list In-Reply-To: <20040708034455.GB29942@davidb.org> References: <20040707091308.GA26172@bourg.inria.fr> <20040707145803.GB27498@yquem.inria.fr> <1089227778.29648.81.camel@pelican.wigram> <20040708034455.GB29942@davidb.org> Content-Type: text/plain Message-Id: <1089265816.29648.205.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 08 Jul 2004 15:50:17 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 40ECE09F.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 arithmetics:01 sourceforge:01 2004:99 44,:01 tail-rec:01 recursion:01 implemented:01 gcc:01 tail-rec:01 ocaml's:01 optimised:01 organise:99 gcc:01 optimised:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Thu, 2004-07-08 at 13:44, David Brown wrote: > > Of course that argument fails totally in one important > > case -- Q: if you wanted a loop why didn't you use one? > > A: tail-rec functional code is considered cute :) > > In some functional languages (Scheme, specifically), tail recursion is > required to be implemented iteratively. It is a common enough idiom, > and easy enough to implement, that it is generally done in functional > languages. In fact, gcc does it in C, with enough optimization. I'm aware of this, my point is that Xavier's argument that complex code generates inefficient code "what else do you expect?" is a bit weak. Whether you expect tail-rec optimisation or not depends on your knowledge of compiler implementation details. Felix for example has a functional subsystem which one could argue is "more functional" than Ocaml's since side effects are not permitted .. but it happens to generate C at the moment -- and I admit I myself have no idea whether tail calls in functions are optimised or not, or how to actually organise the generated C so as to encourage a compiler .. perhaps gcc, perhaps MSVC .. to actually perform the optimisation. Procedure calls ARE tail-rec optimised by Felix (guarranteed!) but the calling mechanism is quite different to that used for functions. Even experts are often surprised by generated code complexity. In C++ for example, the close connection between source and generated code is lost in some cases, particularly constructor calls: the cost of instantiating a class with virtual bases and functions derived from others can be extremely high and is silently hidden .. and C++ experts often miss the disparity between source and generated code. Note I'm not disputing Xaviers orientation here: I basically agree, I merely wish to point out that the argument isn't quite as strong as one might think. Higher level optimisations are also important IMHO. Chosing which ones to actually do is of course very hard :) -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners