Chez Scheme allocation

[Eduardo Cavazos]

Hello,

See question at:

http://stackoverflow.com/questions/2378743/chez-scheme-allocation-program-vs-script

Feel free to answer here or there. :-)

Ed

[William D Clinger]

Just a guess: I'm guessing that the --script option disables
some of the more powerful optimizations, and that the --program
option enables those optimizations.

Then a plausible optimizer might move a side-effect expression
whose value is used only once to the site at which that value
is used, in hope of that site never being executed. For your
program, that would move (iota n) from outside the timed
expression to inside the timed expression.

In support of that explanation, notice that the allocation
increases to 800000, not to 800008. That means the optimizer
probably realized that there is no need to allocate a closure
for the lambda expression inside the timed expression.

Will

[Eduardo Cavazos]

I updated the original post with a reply from Kent.

Ed

[Eduardo Cavazos]

On Mar 4, 10:53 am, William D Clinger <cesur...@yahoo.com> wrote:

> Just a guess:  I'm guessing that the --script option disables
> some of the more powerful optimizations, and that the --program
> option enables those optimizations.
>
> Then a plausible optimizer might move a side-effect expression
> whose value is used only once to the site at which that value
> is used, in hope of that site never being executed.  For your
> program, that would move (iota n) from outside the timed
> expression to inside the timed expression.
>
> In support of that explanation, notice that the allocation
> increases to 800000, not to 800008.  That means the optimizer
> probably realized that there is no need to allocate a closure
> for the lambda expression inside the timed expression.

Thanks Will.

I wanted to run a similar test of allocation in Larceny, but it's hard
to get 'time' to register any allocation at all:

~ $ larceny
Larceny v0.97 "Funny in the Head" (Aug 19 2009 06:31:24,
precise:Linux:unified)
larceny.heap, built on Wed Aug 19 06:33:35 EDT 2009

> (time (cons 3 4))
Words allocated: 0
Words reclaimed: 0
Elapsed time...: 0 ms (User: 0 ms; System: 0 ms)
Elapsed GC time: 0 ms (CPU: 0 in 0 collections.)
(3 . 4)

Any tips for how to get allocation info from Larceny?

Ed

[William D Clinger]

Eduardo Cavazos wrote:
> I wanted to run a similar test of allocation in Larceny, but it's hard
> to get 'time' to register any allocation at all:

With Larceny's time macro and the default generational collector,
the allocation is measured at the very coarse resolution of the
nursery size, which now defaults to 4 megabytes. The easiest way
to improve the resolution is to reduce the nursery size, but that
is likely to degrade performance (especially if taken to extremes).

The better way is to increase your problem size or the number of
iterations to the point where a 4-megabyte resolution provides
adequate information.

Running your benchmark 1000 times takes about 5.5 seconds on
my laptop. Dividing the reported allocation by 1000, I'm seeing
about 5.6 megabytes of allocation per iteration in Larceny v0.97
with the native IA32 code generator, which is about 1 gigabyte
per second.

Will

[Eduardo Cavazos]

Thanks for the explanation Will.

Here's a program and some results on Chez, Ikarus, and Larceny:

http://gist.github.com/322038

The '(dharmalab misc time entry)' library is just a wrapper of the
various systems 'time' macro:

http://github.com/dharmatech/dharmalab/tree/master/misc/time

Ed

[William D Clinger]

Oops, this didn't make sense. I wrote:
> Then a plausible optimizer might move a side-effect expression
> whose value is used only once to the site at which that value
> is used, in hope of that site never being executed.

I meant to say "side-effect-free expression". As we now know
from Kent's explanation, my guess was incorrect anyway.

Will