[mercury-users] Bug in NT Version?

[Fergus Henderson]

On 22-Sep-1999, Ralph Becket <rbeck at microsoft.com> wrote:
> Two things.  [Context: this is using rotd-1999-08-13 compiled using the
> Cygnus tools under NT.]
> 
> 1. I've finally got the time to have a go at a coding challenge issued
> by a friend in systems, namely to reimplement the SPEC benchmark
> 129.compress in Mercury, in a readable style, without bailing out to C,
> and make it run no more than six times slower than the C version (which
> is an unholy mess that makes LLDS output look readable).
> 
> I've got the compression side working fine, but when I compiled in
> the default grade (asm_fast.gc) and put in a couple of calls to
> report_stats, I get the following (using EXTRA_MCFLAGS = -O 6):
> 
> $ cat /Mercury/mercury-compiler-rotd-1999-08-13/library/*.m | ./compress.exe
> > /tmp/foo
> [Time: +0.000s, 0.000s, D Stack: 0.031k, ND Stack: 0.023k,
> #GCs: 1, Heap used since last GC: 4244.371k, Total used: 5504.000k]
> [Time: +1.632s, 1.632s, D Stack: 0.031k, ND Stack: 0.023k,
> #GCs: 7, Heap used since last GC: 1582.520k, Total used: 6884.000k]
> 
> Now what's surprising to me here is that this code is totally
> deterministic, uses only tail recursion, and performs no structure
> creation other than to build a destructively updatable array at the
> start-of-day.  Therefore, there shouldn't be anything on the ND Stack
> nor should there be a need for any GCs (the array consists of 140,000
> ints).

The stuff on the ND stack is not suprising.  It's only 24 bytes.
The Mercury runtime startup creates a couple of frames on the
nondet stack.

The heap usage, however, is suprising.  Obviously your code _is_
allocating quite a bit of memory on the heap.

If you want to see where that memory allocation is coming from, you could
try compiling your application with memory profiling enabled.

[Alternatively, just search for `incr_hp' in the generated C code ;-)
For example,

	$ cat Mercury/cs/*.c | mdemangle | grep incr_hp
	tag_incr_hp_msg(r3, MR_mktag(1), (Integer) 2, <predicate 'cat:cat_file_list'/3 mode 0>, "list:list/1");
	...

This shows a memory allocation for the constructor list:list/1
in mode 0 (the first mode) of the predicate cat:cat_file_list.]

> 2. When I try to get rid of GC altogether, by specifying either
> `--gc none' or `--grade asm_fast' in EXTRA_GRADEFLAGS, I get the
> following:
> 
> $ mmake compress
...
> Mercury/os/compress_init.o(.text+0xe):compress_init.: undefined reference to
> `GC
> _add_roots'
> Mercury/os/compress_init.o(.text+0x2d):compress_init.: undefined reference
> to `G
> C_stackbottom'
> Mercury/os/compress_init.o(.text+0x47):compress_init.: undefined reference
> to `a
> ddress_of_init_gc'

The problem here is just that you are linking with a version of
`compress_init.o' that was compiled with GC enabled.
When you change the grade, you need to run `mmake clean'
to ensure that you don't mix things compiled in different grades.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------