Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!MathWorks.Com!yeshua.marcam.com!charnel.ecst.csuchico.edu!csusac!csus.edu!netcom.com!hbaker
From: hbaker@netcom.com (Henry G. Baker)
Subject: Re: The expense of call/cc (was R4RS)
Message-ID: <hbakerCxL9vx.AAx@netcom.com>
Organization: nil
References: <1994Oct8.115151.17399@news.cs.indiana.edu> <hbakerCxEz5z.CEF@netcom.com> <CxKA9E.CHp@cerc.wvu.edu>
Date: Thu, 13 Oct 1994 02:07:09 GMT
Lines: 104

In article <CxKA9E.CHp@cerc.wvu.edu> fuchs@cerc.wvu.edu (Matthew Fuchs) writes:
>Henry G. Baker (hbaker@netcom.com) wrote:
>: In article <1994Oct8.115151.17399@news.cs.indiana.edu> "Carl Bruggeman" <bruggema@cs.indiana.edu> writes:
>: >In article <mhamburg-061094091103@macb022.mv.us.adobe.com>,
>: >Mark Hamburg <mhamburg@mv.us.adobe.com> wrote:
>: >>Repeating the instruction cost table from Appel and Shao's paper:
>: >>
>: >>                   Heap        Stack
>: >>
>: >>Frame creation      3.1          1.0
>: >>Frame pointers      2.0          0.0
>: >>Copying, sharing    0.0          3.4
>: >>Cache read misses   0.1          0.0
>: >>Disposal (pop)      0.2          1.0
>: >>
>: >>I have left out the possibility of a charge for cache write misses which
>: >>costs the heap strategy 10 instructions and is free for the stack
>: >        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>: >>implementation because it only afflicts some architectures.
>: >
>: >Appel's paper clearly demonstrates that we cannot simply dismiss the
>: >idea of heap-based frames as "obviously" more inefficient than
>: >stack-based frames. The issues must be examined and measured much more
>: >carefully. Although Appel presents an interesting set of numbers that
>: >shows that the respective costs (on the proper platforms) may be quite
>: >similar, I think that it is premature for non-research oriented
>: >implementers to assume that heap-based frames have the same
>: >approximate cost as stack-based frames.
>
>: I think that one should keep in mind that architecture designs are
>: extremely sensitive to the current set of benchmarks.  The moment that
>: Micro$oft or Unix incorporates a heap-based strategy into the vast
>: numbers of machines running this software, you will see the HW vendors
>: fall all over themselves to make this stuff run fast.
>
>Henry,
>
>These benchmarks, it seems, are all based on Appel's SML compiler.
>Would you care to speculate (or have you attempted to determine) how
>your "Cheney on the MTA" (some of us got the joke) Scheme would do
>for this (where heap is stack is heap is....)?

My test program is available in my ftp directory as cheneymta.c if you like.

The results from a wide variety of machines were fairly good, although
there is some sensitivity of the 'stack buffer' on the size of the cache.
In the case of sparc register windows, one must go to some effort to take
out the offending instructions from the compiled code before it is assembled,
or pay a 3X performance penalty.  On other machines, one must make sure to
use the 'lightweight' versions of setjmp/longjmp, or one may end up paying
a noticeable penalty.  Other than these issues, 'cheneymta'/'pushy' seems
to work well, especially on architectures such as the MIPS and the Alpha.

>: For this reason, SW people (especially programming language people)
>: should focus on issues other than brute efficiency on the existing
>: stock of HW processors.  
>
>True, except that Appel is a compiler designer, not a language designer.

You should give him a bit more credit!

>: so, people like Hewitt, Sussman, Friedman, Wise and Wand have been
>: extolling the virtues of continuation-based programming.  They've made
>: some small progress -- the 'call-back' style of programming is nearly
>: ubiquitous in modern window systems, and this has already forced Ada
>: to retreat from its 'no functions as arguments' stone age philosophy.
>
>The "call-back" style of GUI programming is mostly an ugly kluge forced
>by the lack of recognition that call-backs are continuations and that 
>GUIs inherently have more than one thread of control and are therefore
>unimplementable on a single stack.  The "reactive" programming style is
>really a twisted CPS transformation forced on GUI programmers since they
>cannot use the stack.  Much of the use of objects in GUI programming is 
>to replace heap-based stack frames with objects.  In my Scheme-based
>GUI I can avoid a lot of call-back functions by explicitly using
>call/cc to create continuation callbacks.  Makes life a lot easier.

I'd love it if someone would produce a really good
paper/monograph/book which shows how one could really program a GUI
truly _elegantly_ in Scheme using closures, continuations, etc.  I can
readily believe that your GUI is better, but I'd love to see a really
good and compelling description, complete with pretty pictures, etc.

>: As the MIT/Indiana/Princeton/... students wend their way to Seattle
>: and Silicon Valley, I expect that they will eventually incorporate
>: these ideas into the guts of a popular operating system and/or
>: language.  When this happens, you can expect the HW vendors to quickly
>: adjust their architectures to suit.
>
>Mach already uses continuations, of a sort, for threading in the kernel,
>and I believe that has been extended to the user-level threading 
>API.
>
>Matthew Fuchs
>fuchs@cerc.wvu.edu

As you no doubt already know, there are serious problems trying to integrate
the concept of continuations with multiple threads.  I haven't studied this
issue nearly as much as some people, but I still have to believe that there
is something more elegant than what I have seen proposed so far.

      Henry Baker
      Read ftp.netcom.com:/pub/hbaker/README for info on ftp-able papers.

