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

[Erwan Jahier]

| Oh, OK, I understand.  The reason I was confused was that I missed step (2).
| Those calls are needed there for the same reason that they're needed
| in MR_trace_event().  The reason is so that the use of the Mercury
| registers by the called Mercury code doesn't stuff things up for the
| code being debugged, as explained in trace/README.
| 
| But the factor of 5 seems a bit large.  Is that on x86 or on sparc?

I had another look at... You are rigth, the factor of 4 that I measured was not
only due to the MR_copy_regs_to_saved_regs() and MR_copy_saved_regs_to_regs()
calls.


I've added a case (MR_CMD_COLLECT) in the swith on MR_trace_ctrl.MR_trace_cmd
in MR_trace_real().

	switch (MR_trace_ctrl.MR_trace_cmd) { 
		case MR_CMD_COLLECT:
		  {
		    
		    MR_Event_Info	event_info;
		    Word		*saved_regs = event_info.MR_saved_regs;
		    int		max_r_num;
		    const char	*path;
		    bool    	stop_collecting = FALSE;
		    
		    port = (MR_Trace_Port) layout->MR_sll_port;
		    max_r_num = layout->MR_sll_entry->MR_sle_max_r_num;
		    if (max_r_num + MR_NUM_SPECIAL_REG > MR_MAX_SPECIAL_REG_MR) {
		      event_info.MR_max_mr_num = max_r_num + MR_NUM_SPECIAL_REG;
		    } else {
		      event_info.MR_max_mr_num = MR_MAX_SPECIAL_REG_MR;
		     }		
		    path = layout->MR_sll_entry->MR_sle_module_layout
		      ->MR_ml_string_table + layout->MR_sll_goal_path;

		    MR_copy_regs_to_saved_regs(event_info.MR_max_mr_num, saved_regs);		    
		     MR_COLLECT_filter(seqno, depth, 
		    	      port, layout, path, &stop_collecting);
		    
		    if (stop_collecting) {
		    	MR_send_collect_result();
		    	MR_send_message_to_socket("execution_continuing");
		    	}
		    		    
		    MR_copy_saved_regs_to_regs(event_info.MR_max_mr_num, saved_regs);
		    
		    return NULL;

		  }			
		case MR_CMD_GOTO:
 		...


with queens-11, I have measured (on sparc) the following timings
 * filter + save-and-restore-regs (see the chunk of code above) : 227 s
 * save-and-restore-regs:  72 s
 * {} : 56 s

The reason why I though that this last timings was 20 s is because when
MR_trace_ctrl.MR_trace_cmd is set to MR_CMD_GOTO (finish command of mdb), the
execution lasts 20 s.

This seems to be due to some kind of optimisation that Zoltan made, but I do 
not understand how it can be more efficient than only have a `return NULL'.
In other words, I don't undestand how ...

	switch (MR_trace_ctrl.MR_trace_cmd) { 
		case MR_CMD_COLLECT:
		   return NULL;		
		case MR_CMD_GOTO:
			if (MR_trace_event_number >=
					MR_trace_ctrl.MR_trace_stop_event)
			{
				port = (MR_Trace_Port) layout->MR_sll_port;
				return MR_trace_event(&MR_trace_ctrl, TRUE,
						layout, port, seqno, depth);
			} else {
				goto check_stop_print;
			}
 		...

...if MR_trace_ctrl.MR_trace_cmd is set to MR_CMD_COLLECT, the execution takes 56s
whereas it takes 20s if it is set to MR_CMD_GOTO. 


-- 
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
--------------------------------------------------------------------------