[m-dev.] Please help... once more

[Erwan Jahier]

| On 21-Sep-2000, Erwan Jahier <Erwan.Jahier at irisa.fr> wrote:
| > are (roughly) the overhead I get:
| > 
| > with 10 000 evts there is no overhead, 
| > with 100 000 evts, there is a small overhead, 
| > ...
| > with 2 000 000 evts, there is an overhead factor of 120, 
| > with 4 000 000 evts, there is an overhead factor of 230,
| > ...
| > 
| > Then it seems to stabilize; with 200 000 000 events, it still have a factor
| > that is around 230: so at least there is a good news... )-;
| 
| Precisely what overhead are you measuring, and what units do these numbers
| have?

I have divided the execution time of a program compiled with no trace
information by the execution time of a program compiled trace information
(external+internal events) executed under the control of a collect monitor that
does nothing (initialize(""). filter(_, A, A, continue).) I run small programs
1000 times, so that they last at least several seconds. 

I measured the real time, on a very lowly loaded i686 machine (no X, no
networks). I know I'd better use user+sys times, but the command I use (from
eclipse) does not take into account the time spend in forked process...

| In any case, a program that generates only 10 000 events will execute so
| quickly that timings from it are meaningless; you would be measuring the
| clock granularity, not the speed of the code.

Ok. I should have said, no overhead is noticeable.
 
| > (3) During while, a certain number of calls to functions that save and restore
| > registers, heaps, etc. are made to collect probably don't need:
| >    - restore_transient_registers(),
| >    - save__transient_registers(), 
| >    - MR_saved_global_hp(saved_regs), 
| >    - MR_copy_saved_regs_to_regs(), 
| 
| If you are still working on SPARCs, then you need these calls *more* than

I work on both actually ;-)

| those of us who work on x86s. The lack of them in the proper place can easily
| get you bus errors. So don't delete them if you don't understand them.
| 
| I think it is very likely that your core dump is caused by the absence of
| a restore_transient_registers() in e.g. MR_COLLECT_filter.

MR_COLLECT_filter calls filter_ptr() using the macro MR_TRACE_CALL_MERCURY()
which does such a call.

| save_transient_registers, restore_transient_registers and their relatives
| are defined in runtime/mercury_regs.h, but that file doesn't contain any
| documentation on what circumstances they should be used in. Fergus, do you
| know of any such documentation? 
| 
| > +    switch (MR_trace_ctrl.MR_trace_cmd) {
| > +	case MR_CMD_COLLECT:
| > +             port = (MR_Trace_Port) layout->MR_sll_port;
| > +	      path = layout->MR_sll_entry->MR_sle_module_layout
| > +		    ->MR_ml_string_table + layout->MR_sll_goal_path;
| > +	      MR_COLLECT_filter(seqno, depth, port, layout, 
| > +                   path, &stop_collecting);
| > +	      if (stop_collecting) {
| > +		MR_send_collect_result();
| > +		MR_send_message_to_socket("execution_continuing");
| > +		}
| > +		return NULL;	
| > +	  
| > 	case MR_CMD_FINISH:
| 
| This looks like the right code, modulo formatting.
| 
| > (gdb) b MR_COLLECT_filter
| > Breakpoint 1 at 0x52960: file mercury_trace_external.c, line 1486.
| > (gdb) r
| > Starting program: /home/terre/d02/lande/jahier/these/./queens
| > 
| > Breakpoint 1, MR_COLLECT_filter (seqno=0, depth=4290683468, port=1356800, 
| >     layout=0x1520d8, path=0x16 <Address 0x16 out of bounds>, 
| >     stop_collecting=0xff1c84c0 "") at mercury_trace_external.c:1486
| > 1486            if (MR_collect_arguments) {
| 
| This already shows several errors: the values of seqno, depth, port and path
| all look invalid. Have a look at values of the variables from which the values
| of these arguments are computed in the caller.


This is very strange, because the current working version gives the same kind
of values for the first call to MR_COLLECT_filter, and still it produces the
rigth result. e.g. 
> initialise(""). 
> filter(Event, A0, A, continue) :- (call(Event) = 1 -> A = "ok" ; A = A0). 
produces "ok".

Could gdb be abused some ways?

-- 
R1.


--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------