[m-dev.] Performance of collect

[Erwan Jahier]

| On 22-Sep-2000, Erwan Jahier <Erwan.Jahier at irisa.fr> wrote:
| > I am still in the process to understand why collect(nop, _) (where nop define 
| > a monitor that does nothing) is so slow.
| > 
| > Currently, with 11-queens (34 000 000 events) the timings are:
| > 
| > off line, no trace info: ~4s
| > mdb ./queens11 < finish: ~20s
| > collect(nop, Result)   : ~200s (now) 
| > collect(nop, Result)   : ~800s (before I move MR_COLLECT_filter to MR_trace_real()) 
| 
| On what architecture?

SunOS cripure 5.7 Generic_106541-12 sun4u sparc SUNW,Ultra-250

| In what grade?

asm_fast.gc
 
| > If I remove the call to filter in mercury_trace_external: 80s
| >  
| > If I remove the call to filter in mercury_trace_external
| > *AND* I remove the save_regs/restore regs statements    : 20s
| > 
| > So the save_regs/restore regs statements seems to cost me 40s, and the call to
| > *filter_ptr() (which does nothing with nop monitor) seems to cost 120s.
| > 
| > Why is this call so expensive? 
| 
| You're calling from C to Mercury.  In our current implementation (LLDS back-end),
| this is fairly expensive.  

So what about the HLDS back-end then?

Is it ready to use?
What would be its overhead? I suppose it does not explicitly make use of 
registers etc., so there is no need to save and restore them with this back-end 
no?

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