From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Israelsson Tampe Newsgroups: gmane.lisp.guile.devel Subject: function application in rtl Date: Tue, 01 Oct 2013 19:13:22 +0200 Message-ID: <5396052.yUjgtlP8oi@warperdoze> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit X-Trace: ger.gmane.org 1380647633 6470 80.91.229.3 (1 Oct 2013 17:13:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 1 Oct 2013 17:13:53 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Oct 01 19:13:56 2013 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VR3WG-0002Jn-3W for guile-devel@m.gmane.org; Tue, 01 Oct 2013 19:13:56 +0200 Original-Received: from localhost ([::1]:60254 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VR3WF-0002LN-M5 for guile-devel@m.gmane.org; Tue, 01 Oct 2013 13:13:55 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58561) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VR3W4-0002KC-0m for guile-devel@gnu.org; Tue, 01 Oct 2013 13:13:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VR3Vv-00078I-IU for guile-devel@gnu.org; Tue, 01 Oct 2013 13:13:43 -0400 Original-Received: from mail-lb0-x236.google.com ([2a00:1450:4010:c04::236]:42888) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VR3Vv-000781-7b for guile-devel@gnu.org; Tue, 01 Oct 2013 13:13:35 -0400 Original-Received: by mail-lb0-f182.google.com with SMTP id c11so6067489lbj.41 for ; Tue, 01 Oct 2013 10:13:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:user-agent:mime-version :content-transfer-encoding:content-type; bh=WQt7POdwbqVhW/G7wIcwkiiPoXgmXMvfW2EdsIp4xWI=; b=A6NB6cd26S759RCqN/+PpHGesAbUDMPpQfsPmjzHdUqRt1GqQRvOIf4rlU1NdwqqPm yaTB6GcE/qaVvFX5/wKa0mQPCrCYd45PHfbzt7KWWbZvi8WzT+guqXznikQI9cmLuyP5 tRMFZmtBRbB7D/NWNqArNiOZm0H7LNi0LroX2E4yTgyaXaHBBufVDLe6+aNsBCC9GNgA 8aI45qBTj/vj0rXOpuuyzmZhprkksXbNZQZHgMN8Z4frInaHiQDF0m1F95s6JSUxqj2H 98DlJFwdmSuAWt8r+NT6k7cz5FzQRs41UDbMWLvP19Dm76gJhuRgjA7z9Es7OQHhQ5HI sang== X-Received: by 10.112.28.109 with SMTP id a13mr27980089lbh.3.1380647613352; Tue, 01 Oct 2013 10:13:33 -0700 (PDT) Original-Received: from warperdoze.localnet (1-1-1-39a.veo.vs.bostream.se. [82.182.254.46]) by mx.google.com with ESMTPSA id zw2sm4641161lbb.14.1969.12.31.16.00.00 (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Oct 2013 10:13:32 -0700 (PDT) User-Agent: KMail/4.9.5 (Linux/3.5.0-30-generic; KDE/4.9.5; x86_64; ; ) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c04::236 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:16660 Archived-At: Hi, As I understand, currently in rtl loops get's faster but function application intense code becomes less effective. Function application is currently quite expensive, but we might get it done faster in native compiled code e.g. after we have focused on optimizing that one. Of cause it's not the primary task right now to do this, but the function call semantics can be good to settle before the realease. So some points. 1. Moving data to and from a new function frame and then calling shows some innefficiency. And we shold try to avoid this as much as possible. This will be a problem later. A solution might be to allocate a scratch region at the end of the frame where we simply evaluate expressions with a simulated stack but using direct adresses. The problem is we need to add information about where the frame ends when returning from a funciton call. The only sane solution is to add that number as a meta data to the function call. This might look like a non nice solution but in practice I doubt it to be an issue. We can keep the same number at the first function call which means that we do not need to write it to a new function is evaluated the second time. Of cause this trick cant't be used for g in (f (g x)) but still it would make the problem less of an issue. 2. A good way of programming is to use monad like techniques to transport state information. So if we use state S1, ..., Sk one typically end up with code like (let-values* (((S1 ... Sk X) (f R1 ... Rk Z)) ((T1 ... Tk Y) (g S1 ... Sk Q X)) ...) ...) And one can sort of define a parse combinator like language to handle the streaming. Now moving all the arguments to the end of the function frame then all the values back and continue like this is really crazy, because one can have say 10 states and just one state at the time is touched by the generator etc. Now what we would like to do is to keep the state information on the same locations in the stack and just change the memory positions touched by e.g. f,g,X,Y,Z. My intention is to make sure that guile can handle this pattern effectively. 3. A minor optimization in a stack based expression is to let the first memory position in a function frame be the first return value that means that in (f (g X) (h Y)) we do not need to move the return value of g and h after they have been evaluated. A small but perhaps useful optimisation. WDYT? Regards Stefan