Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!nntp.club.cc.cmu.edu!newsfeed.pitt.edu!godot.cc.duq.edu!news.duke.edu!news-feed-1.peachnet.edu!emory!swrinde!ihnp4.ucsd.edu!pacbell.com!amdahl!netcomsv!ix.netcom.com!netcom.com!hbaker
From: hbaker@netcom.com (Henry G. Baker)
Subject: Re: The expense of call/cc (was R4RS)
Message-ID: <hbakerCxEz5z.CEF@netcom.com>
Organization: nil
References: <36ut56$835@larry.rice.edu> <mhamburg-061094091103@macb022.mv.us.adobe.com> <1994Oct8.115151.17399@news.cs.indiana.edu>
Date: Sun, 9 Oct 1994 16:29:59 GMT
Lines: 72

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.
>
>The problem is that any cache system that reads the existing cache
>line from memory when a write miss occurs _will_ incur this penalty.
>Although the first-level cache system on many top-of-the-line (and
>future) processors may avoid this problem, the vast majority of
>workstations in use today will read the line while processing a write
>miss.  It is even possible that many low end systems in the future
>will still have this behavior as well due to the inherent
>implementation simplicity. The bottom line is that implementations
>with heap-based frames are not insensitive to cache implementation
>issues while implementations with stack-based frames are
>insensitive. This implies that implementations with heap-based frames
>are not portable (performance-wise) to as wide a range of platforms as
>are implementations with stack-based frames.
>
>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.

For this reason, SW people (especially programming language people)
should focus on issues other than brute efficiency on the existing
stock of HW processors.  Issues such as modularity, ease of
development and techniques that reduce and/or eliminate bugs should be
considerably higher on the list.

The reason why stacks work so well on modern architectures is that for
the 20 years from 1960 to 1980, CS professors pounded the idea into
their undergraduates that stacks were a _good thing_ for higher level
languages, where were also a _good thing_.  For the past 20 years or
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.

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.

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

