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: Re: a rehash of the question of optimizing some prompt ideoms Date: Sun, 1 Sep 2013 22:34:35 +0200 Message-ID: References: <2849568.naTrYEPBA4@warperdoze> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bea3b144c7ea604e55862fa X-Trace: ger.gmane.org 1378067685 5876 80.91.229.3 (1 Sep 2013 20:34:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 1 Sep 2013 20:34:45 +0000 (UTC) To: guile-devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Sep 01 22:34:49 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 1VGEMA-0001X4-Dn for guile-devel@m.gmane.org; Sun, 01 Sep 2013 22:34:46 +0200 Original-Received: from localhost ([::1]:35572 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VGEM7-0004by-TX for guile-devel@m.gmane.org; Sun, 01 Sep 2013 16:34:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39003) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VGEM3-0004bp-FQ for guile-devel@gnu.org; Sun, 01 Sep 2013 16:34:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VGEM1-0007kc-MK for guile-devel@gnu.org; Sun, 01 Sep 2013 16:34:39 -0400 Original-Received: from mail-pb0-x236.google.com ([2607:f8b0:400e:c01::236]:42725) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VGEM1-0007kT-9Z for guile-devel@gnu.org; Sun, 01 Sep 2013 16:34:37 -0400 Original-Received: by mail-pb0-f54.google.com with SMTP id ro12so3927490pbb.41 for ; Sun, 01 Sep 2013 13:34:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=9aWMhHGE+HMJEgI1sELNSiwCHJXvqsfTDmOkJ8017Wk=; b=nRJp6ldvD9z/WrlN0Xqi4wkwwVtSHSVzxZxiBL+tJgTa+BOr2MPe6ZOolgYp+tFvn9 4vKQsP+9VW2JwvJOd0ynH/kQIpi3+IXJm8II6Qq0SkJkxr2m4KbUjT5DmJZ5axMf3S7/ hULWd57Ig5Ainf12CrllKrQyI43C6wgx89bB16HbCwhXfEkaXuqMYTtJ1HQxfNKyHAqe yGmnxVSOGbbByf9UEw5HfvmjtnZdHV45S+dY2jolRZkDz0EIKdWMnrr2aXb7+w3ggUaq Qwy1eDZSXi+nZ92/odRT5W81BDSgR+yhxdik2VFeNYhLtBRaOJGfPlJzrCOlZunTsLQe kZEw== X-Received: by 10.66.169.172 with SMTP id af12mr23034576pac.23.1378067675903; Sun, 01 Sep 2013 13:34:35 -0700 (PDT) Original-Received: by 10.70.2.34 with HTTP; Sun, 1 Sep 2013 13:34:35 -0700 (PDT) In-Reply-To: <2849568.naTrYEPBA4@warperdoze> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400e:c01::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:16606 Archived-At: --047d7bea3b144c7ea604e55862fa Content-Type: text/plain; charset=ISO-8859-1 Hi, To note in e.g. logic programming one can inline a lot of code and the final result of peval is that it will and should not expand the lambdas at site due to code explosion. What happens now, as I understand, is that closures are created at a resulting quite hefty overhead. In stead if one employed local functions inside the stack and issued a goto to these functions and a corresponding return to the call site with return value in appropriate slot we would be much better off because we would simply not need to create closures on the heap and have very low overhead in the argument handling and function dispatch. To make this work we would only need to have named gotos, the rest should be handled by the scheme in scheme compiler. So there are good arguments to have 1. Named goto operations in the VM 2. A notion of local execution unit that are of two kinds i) Stateless aka functions, can reuse register space ii) Statefull aka need to allocate a fixed register space to the local funciton WDYT? On Fri, Aug 30, 2013 at 8:54 PM, Stefan Israelsson Tampe < stefan.itampe@gmail.com> wrote: > Hi all, > > In the wake of the wowely code Andy Mark and Noah have been producing > I want to lift the question of what we can do to compile some > delimeted continuation code effeciently. > > Delimeted continuations can be looked upon as a generalization of > common lisps tagbody e.g. it's trivial to produce tagbody semantics > with the help of prompts. Now a quesiton is how we should make sure > that most sane code that can be compiled to goto's in the rtl backend > really get that far. As I understand the cps compiler is well suited > to take on this task. But we should not aim towards atgbody, but also > generators and similar constructs. To see what kind of semantics to > support maybe the code in > > https://gitorious.org/guile-coroutines/guile- > > coroutines/source/fc49d41dfa0cc0647aaeeddf8fb15d55dc2fb6ef:stis/coroutine.scm > > Can help as well as the example in the same repo, > > https://gitorious.org/guile-coroutines/guile- > > coroutines/source/fc49d41dfa0cc0647aaeeddf8fb15d55dc2fb6ef:stis/coroutine/test.scm > > So what can we do in rtl that we cannot do before? To note here is > that in rtl we can basically allocate a region of the register space > for e.g. a generator. The nice thing with rtl is that all functions > are executed at the end of the register space and therefore we could > basically use named gotos to jump between the different > generators located at different stack areas. This is not possible in a > stack based VM. So not only do we skip expensive function call's but > tear down and setup of the stack is not needed. Of cause to be > able to take advantage of this not all generators can be used in such > a scheme. (It would be nice to get Academic references for this) but > it should be doable. > > We would need some more one more instruction from RTL, namely named > gotos. > > It's also perhaps possible to enlarge the ideas to separate where > functions are evaluated and where the "local rigister area" of the > generator is > situated. E.g. An area allocated from the heap. But this lead to a > complete redesign of RTL but it would could be a cool concept. > > WDYT? > > --047d7bea3b144c7ea604e55862fa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

To note in e.g. l= ogic programming one can inline a lot of code and=A0
the final result o= f peval is that it will and should not expand the lambdas at site=A0
<= div> due to code explosion. What happens now, as I understand, is that closures<= /div>
are created at a resulting quite hefty overhead. In stead i= f one employed
local functions inside the stack and issued = a goto to these functions and a
corresponding return to the call site with return value in appro= priate slot we=A0
would be much better off because we would= simply not need to create closures
on the heap and have ve= ry low overhead in the argument handling and function
dispatch. To make this work we would only need to have named got= os, the rest
should be handled by the scheme in scheme comp= iler.

So there are good arguments to h= ave
1. Named goto operations in the VM
2. A notion o= f local execution unit that are of two kinds
=A0 =A0i) =A0S= tateless aka functions, can reuse register space
=A0 =A0ii)= Statefull =A0aka need to allocate a fixed register space to the local func= iton

WDYT?

=


On Fri, Aug 30, 2013 at 8:54 PM, Stefan Israelsson Tampe <stefan.= itampe@gmail.com> wrote:
Hi all,

In the wake of the wowely code Andy Mark and Noah have been producing
I want to lift the question of what we can do to compile some
delimeted continuation code effeciently.

Delimeted continuations can be looked upon as a generalization of
common lisps tagbody e.g. it's trivial to produce tagbody semantics
with the help of prompts. Now a quesiton is how we should make sure
that most sane code that can be compiled to goto's in the rtl backend really get that far. As I understand the cps compiler is well suited
to take on this task. But we should not aim towards atgbody, but also
generators and similar constructs. To see what kind of semantics to
support maybe the code in

=A0 https://gitorious.org/guile-coroutines/guile-
coroutines/source/fc49d41dfa0cc0647aaeeddf8fb15d55dc2fb6ef:stis/coroutine.s= cm

Can help as well as the example in the same repo,

https://gitorious.org/guile-coroutines/guile-
coroutines/source/fc49d41dfa0cc0647aaeeddf8fb15d55dc2fb6ef:stis/coroutine/t= est.scm

So what can we do in rtl that we cannot do before? To note here is
that in rtl we can basically allocate a region of the register space
for e.g. a generator. The nice thing with rtl is that all functions
are executed at the end of the register space and therefore we could
basically use named gotos to jump between the different
generators located at different stack areas. This is not possible in a
stack based VM. So not only do we skip expensive function call's but tear down and setup of the stack is not needed. Of cause to be
able to take advantage of this not all generators can be used in such
a scheme. (It would be nice to get Academic references for this) but
it should be doable.

We would need some more one more instruction from RTL, namely named
gotos.

It's also perhaps possible to enlarge the ideas to separate where
functions are evaluated and where the "local rigister area" of th= e
generator is
situated. E.g. An area allocated from the heap. But this lead to a
complete redesign of RTL but it would could be a cool concept.

WDYT?


--047d7bea3b144c7ea604e55862fa--