From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id EFAA8BC88 for ; Tue, 8 Feb 2005 18:55:20 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j18HtKUm019390 for ; Tue, 8 Feb 2005 18:55:20 +0100 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 SAA32577 for ; Tue, 8 Feb 2005 18:55:20 +0100 (MET) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j18HtIsM019365 for ; Tue, 8 Feb 2005 18:55:19 +0100 Received: from [192.168.1.200] (ppp212-197.lns2.syd3.internode.on.net [203.122.212.197]) by smtp3.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id j18Ht6YV070535; Wed, 9 Feb 2005 04:25:17 +1030 (CST) Subject: Re: [Caml-list] paralell assignment problem From: skaller Reply-To: skaller@users.sourceforge.net To: "Marcin 'Qrczak' Kowalczyk" Cc: caml-list In-Reply-To: <87r7jrrp56.fsf@qrnik.zagroda> References: <1107832025.13571.260.camel@pelican.wigram> <87r7jrrp56.fsf@qrnik.zagroda> Content-Type: text/plain Message-Id: <1107885305.5022.211.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 09 Feb 2005 04:55:06 +1100 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 4208FD08.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 4208FD06.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 sourceforge:01 wrote:01 sourceforge:01 rec:01 ackermann:01 elif:01 glebe:01 061:98 writes:01 nsw:01 tail:01 tail:01 functions:01 functions:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Level: On Wed, 2005-02-09 at 03:29, Marcin 'Qrczak' Kowalczyk wrote: > skaller writes: > > > x1,x2,x3..xn = e1,e2,e3 .. en > > > > where ei might contain the variables xj. (Note = here is assignment). > > If they contain calls to unknown functions, they might depend on these > variables indirectly. This is true, and I need to ensure that this doesn't cause a problem, which can be done, for example, by evaluating the call to the unknown function first, and then using that value. In this case, you'd be quite right that subsequent optimisation would probably be worthless (calling a function through a variable in Felix is quite expensive) > So I'm not convinced that it's worth to eliminate > temporaries in those rare cases when it's possible. After all, people > rarely assign the value of a variable to another variable. That may be so, however many function calls are direct, that is, to known functions. In particular tail rec calls typically involve passing 'old value - 1' or something similar where no temporary is required. The actual example which prompted this investigation is ackermann, which has two tail-rec calls: fun ack(x:int,y:int):int => if x == 0 then y + 1 elif y == 0 then ack(x-1, 1) else ack(x-1, ack(x, y-1)) endif ; No temporaries are needed in either tail call, and either order of assignment will work. But my actual code created 2 temporaries for each tail call, unnecessarily. -- 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