|[2 earlier articles]|
|Re: Compiling with Continuations/Andrew Appel email@example.com (1992-01-27)|
|Re: Compiling with Continuations/Andrew Appel firstname.lastname@example.org (1992-01-27)|
|Re: Compiling with Continuations/Andrew Appel email@example.com (Vincent Delacour) (1992-01-28)|
|Re: Compiling with Continuations/Andrew Appel firstname.lastname@example.org (1992-01-29)|
|Re: Compiling with Continuations/Andrew Appel email@example.com (1992-01-29)|
|Re: Compiling with Continuations/Andrew Appel firstname.lastname@example.org (1992-01-29)|
|Re: Compiling with Continuations/Andrew Appel email@example.com (1992-01-30)|
|Keywords:||storage, optimize, ML, books|
|Organization:||Technische Universitaet Wien, Institut fuer Computersprachen|
|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, firstname.lastname@example.org email@example.com
(ulrich@vip.UUCP) +431 58801/4477 fax +431 5057838
TU Inst.f. Computersprachen E185/1 Argentinierstr.8/4, A-1040 Wien Austria
Return to the
Search the comp.compilers archives again.