Merge of the "new ByNeed" branch

[Raphael Collet]

Hi Kostja and others,

> > I agree.  I have spend (lost?) some time the last weeks evaluating
> > some proposed optimizations.  I have managed to test them on
> > "serious" Oz programs, i.e., not toy examples.  My results convinced
> > me that Denys' proposals will not make a real difference.  Except
> > the emulator will be harder to maintain...  I suggest to forget
> > about those hacks, unless clear evidence can be made about their
> > usefulness.
> I think I believe you, but others out there will need a bit more
> elaborated report about that ;-)

Okay, here are a few figures.  The goal was to measure the impact of the
changes on real applications, in terms of execution time and memory
consumption.  I consciously avoided pathological programs that would
abuse laziness, for instance.

 - Execution time for recompiling the files in the 'share' directory.
   We compare the average (on five runs) of the user+sys times.

	old: 39.934
	new: 40.42

 - Execution time in milliseconds and total memory used in kilobytes
   (see {Property.get 'memory.heap'}) of an implementation of the
   program "compress".  Laziness in this program mainly regulates the
   flow of data from the input to the output.  I ran the program on the
   same big file (.tex source of Peter & Seif's book, 2.7Mb).  Figures
   are averages over 5 runs.  Percentages give the difference with the
   first line.  "Fut" uses former futures, "new" uses the new ByNeed,
   and "new*" uses a better expansion of "fun lazy" in terms of
   WaitNeeded (lazy tail calls don't create new threads).

	fut    time: 95278 (100%)    heap: 13110153 (100%)
	new    time: 96508 (+ 1%)    heap: 12971998 (- 1%)
	new*   time: 72556 (-24%)    heap:  8566335 (-35%)

 - Execution time and total memory used of a program that plays checkers
   (the computer implements both players).  This program plays 12 steps
   of the game, using a min-max algorithm with alpha-beta pruning.  The
   latter is based on John Hughes' article "Why Functional Programming
   Matters", and uses laziness for modularity purposes.  Semantics of
   figures is the same as before.

	fut    time: 226896 (100%)    heap: 22510679 (100%)
	new    time: 243422 (+ 7%)    heap: 14759132 (-34%)
	new*   time: 219906 (- 3%)    heap: 11363895 (-50%)

> > > Now, I'm more concerned with the fact that the "by-need" branch
> > > failed on me while doing the "oztest" (Redhat 7.3, gcc 3.3.2
> > > (compiled off sources), optimized emulator):
> > > 
> > > unix_write1: 
> > > Program received signal SIGSEGV, Segmentation fault.
> > > (...)
> > > 
> > > Curiously - and worryingly - it works fine with the "gdb" emulator.
> > > Anyone dare to comment??!
> > 
> > I haven't been able to reproduce this.
> that's not good.
> Could you tell me your setup exactly?

I tried it on a Debian (kernel 2.4.23), with gcc 2.95.4, and configured
with --enable-opt=yes.  But I did not spend a lot of time on this issue.

> > > Then, *after* the thing is merged, I'd still like to see the emulator
> > > clean-ups (as we discussed before).
> > 
> > I was rather thinking to making those clean-ups in the byneed branch
> > first, and then deal with the merge...
> oh, that looks good (could you summarize in two words what exactly
> did you clean up recently?)

The new-byneed-branch now contains a version with the former
implementation of futures and it associated builtins completely removed.
I am currently merging this version with the main trunk.  After that,
I'll make the "terminology" clean-ups in the emulator (mentioning
read-onlys instead of futures, etc.).


Cheers,

raph
-
Please send submissions to hackers at mozart-oz.org
and administriva mail to hackers-request at mozart-oz.org.
The Mozart Oz web site is at http://www.mozart-oz.org/.