Re: Compiling with Continuations/Andrew Appel

ulrich@mips.complang.tuwien.ac.at
Thu, 30 Jan 1992 19:37:10 GMT

          From comp.compilers

Related articles
[2 earlier articles]
Re: Compiling with Continuations/Andrew Appel norman@parc.xerox.com (1992-01-27)
Re: Compiling with Continuations/Andrew Appel carlton@husc10.harvard.edu (1992-01-27)
Re: Compiling with Continuations/Andrew Appel delacour@parc.xerox.com (Vincent Delacour) (1992-01-28)
Re: Compiling with Continuations/Andrew Appel bimbart@cs.kuleuven.ac.be (1992-01-29)
Re: Compiling with Continuations/Andrew Appel boehm@parc.xerox.com (1992-01-29)
Re: Compiling with Continuations/Andrew Appel oz@ursa.sis.yorku.ca (1992-01-29)
Re: Compiling with Continuations/Andrew Appel ulrich@mips.complang.tuwien.ac.at (1992-01-30)
| List of all articles for this month |

Newsgroups: comp.compilers
From: ulrich@mips.complang.tuwien.ac.at
Keywords: storage, optimize, ML, books
Organization: Technische Universitaet Wien, Institut fuer Computersprachen
References: 92-01-101 92-01-115
Date: Thu, 30 Jan 1992 19:37:10 GMT

In article 92-01-115, Vincent Delacour writes:
|> A legitimate question is also whether it represents a good model for
|> the compilation of *any* language. See below.
|>
|> | The continuation-style method basically converts the source language
|> | into executable code for a machine model _with_a_heap_.
[...]
|> Sorry if I break down a myth for some people, but the fact is that sml-nj
|> is a real hog, and for that reason, people should be careful before they
|> suggest that it represents a _model_ that every compiler writer should


While it is true that the optimizing SML-NJ is a virtual memory hog for
bigger programs this true as well for ordinary compilers! If the number of
basic blocks is too large also a C-compiler turns out to be a horrible
memory hog. In this case, C-compilers don't "allocate like crazy", but
allocate once a big chunk and then "reference like crazy". On a DECstation
with 16MB memory some compilations with -O2 take more than 24 hours!
(please note that the ordinary cc will do this within a minute with many
local optimizations already applied).


On a major collection for compilation SML-NJ reports in average that about
50% of memory is still alife. (Please note that CPS does not increase the
cells that remain alife, it only increases the volatile data). So with 3
times more memory than required to represent your data, no page fault will
occur at all. And in this case, the numbers (5-20% overhead) apply.
--
Ulrich Neumerkel, ulrich@dec4.wu-wien.ac.at ulrich@mips.complang.tuwien.ac.at
(ulrich@vip.UUCP) +431 58801/4477 fax +431 5057838
TU Inst.f. Computersprachen E185/1 Argentinierstr.8/4, A-1040 Wien Austria
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.