for review: stack dumps.

[Tyson Dowd]

On 04-Mar-1998, Peter Schachte <pets at students.cs.mu.OZ.AU> wrote:
> On Wed, 4 Mar 1998, Andrew Bromage wrote:
> > Tyson Dowd wrote:
> > > > Could it try dumping the stack from the bottom up rather than
> > > > from the top down?
> > > 
> > > No, because there are no `succip's to follow upwards to find out what
> > > procedure was called. You'd have to add more information to the stack
> > > frame to be able to do this. 
> 
> Can't you traverse down the stack dumping stack info for frames you
> recognize and ignoring those you don't?  Or can't you traverse at all if you
> don't have the stack frame info?
> 

You need to know the size of each stack frame.  As long as you have
that, you can traverse the whole stack frame (assuming succip is always
stored in the same place in the stack frame). Presently the size of
each stack frame is only available in the stack_layouts.


> > As a matter of interest, do you know approximately how much slower
> > Mercury runs with the stack dump code in?  It might be worth leaving
> > it compiled in by default if it's not very much worse.
> 
> As long as the size increase isn't too great, either.

Here's a comparison.

I have trouble believing the figures myself.

Size:
without stack traces:
-rwx------   1 trd      mercury  5046272 Mar  4 19:38 mercury_compile*
with stack traces:
-rwx------   1 trd      mercury  17367040 Mar  5 11:17 mercury_compile*

Ok, so it's 12Mb bigger.  A lot of string constants.  I'm confident this
can be reduced quite a bit.

Speed:

ws1 contains March 4 compiler, compiled without anything
in Mmake.params.

murlibobo 11:16 compiler 0 >time lmc ws1 -C make_hlds.m
58.951u 0.691s 1:02.00 96.1%        7+335k 324+199io 0pf+0w
murlibobo 11:21 compiler 0 >time lmc ws1 -C make_hlds.m
58.600u 0.717s 1:00.27 98.4%    7+335k 16+190io 0pf+0w
murlibobo 11:22 compiler 0 >time lmc ws1 -C make_hlds.m
58.816u 0.736s 1:00.60 98.2%    7+335k 0+197io 0pf+0w
murlibobo 11:28 compiler 1 >time lmc ws1 -C make_hlds.m
59.166u 0.717s 1:01.13 97.9%    7+334k 36+207io 0pf+0w


ws2 contains March 4 compiler, compiled with --stack-traces

murlibobo 11:20 compiler -126 >time lmc ws2 -C make_hlds.m
53.436u 0.881s 0:55.30 98.2%    49+395k 36+173io 0pf+0w
murlibobo 11:21 compiler 0 >time lmc ws2 -C make_hlds.m
52.968u 0.775s 0:53.92 99.6%    49+394k 0+211io 0pf+0w
murlibobo 11:22 compiler 0 >time lmc ws2 -C make_hlds.m
53.053u 0.921s 0:54.41 99.1%    49+392k 3+216io 0pf+0w
murlibobo 11:23 compiler 0 >time lmc ws2 -C make_hlds.m
53.243u 0.821s 0:55.27 97.8%    49+394k 37+170io 0pf+0w

Installed compiler (compiled with -O2 I think)

murlibobo 11:25 compiler 0 >time mmc -C make_hlds.m
54.277u 0.617s 0:55.36 99.1%    7+345k 23+189io 0pf+0w
murlibobo 11:26 compiler 0 >time mmc -C make_hlds.m
53.568u 0.662s 0:54.94 98.6%    7+347k 23+210io 0pf+0w

I was expecting the speed difference to be negligible (stack traces
just adds a lot of static data, and doesn't actually do any extra work
until it is time to dump the stack).  I'm not sure how to explain the
10% speedup.

-- 
       Tyson Dowd           # There isn't any reason why Linux can't be
                            # implemented as an enterprise computing solution.
     trd at cs.mu.oz.au        # Find out what you've been missing while you've
http://www.cs.mu.oz.au/~trd # been rebooting Windows NT. -- InfoWorld, 1998.