Statalist The Stata Listserver


[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

RE: st: Weird problem with nested functions in Mata


From   "Ben Jann" <ben.jann@soz.gess.ethz.ch>
To   <statalist@hsphsun2.harvard.edu>
Subject   RE: st: Weird problem with nested functions in Mata
Date   Wed, 12 Apr 2006 22:50:07 +0200

Bill, the time required to look up functions does not seem to be 
the problem here, as is illustrated by the following timings:

	. mata: x = uniform(1000,1)
	r; t=0.00 22:24:32
	
	. mata: for (i=1;i<=1000;i++) {; z = x:*x:*x:*x:*x; }
	r; t=0.24 22:24:32
	
	. mata: for (i=1;i<=1000;i++) {; z = test1(x); }
	r; t=0.36 22:24:32
	
	. mata: for (i=1;i<=1000;i++) {; z = test2(x); }
	r; t=0.22 22:24:33
	
	. mata: for (i=1;i<=1000;i++) {; z = test3(x); }
	r; t=0.38 22:24:33
	
	. mata: for (i=1;i<=1000;i++) {; z = test4(x); }
	r; t=0.23 22:24:33
	
	. mata: for (i=1;i<=1000;i++) {; z = test5(x); }
	r; t=0.40 22:24:34
	
	. mata: for (i=1;i<=1000;i++) {; z = test6(x); }
	r; t=0.22 22:24:34

Note that I came across the problem in a very different 
context and then started to track it down. After a couple of 
tests it was clear that the problem had to do with nesting 
although this was hard to believe.

I assume that there is a problem with my computer or OS. 
I'll check using another machine.

ben

> -----Original Message-----
> From: owner-statalist@hsphsun2.harvard.edu [mailto:owner-
> statalist@hsphsun2.harvard.edu] On Behalf Of William Gould, Stata
> Sent: Wednesday, April 12, 2006 9:08 PM
> To: statalist@hsphsun2.harvard.edu
> Subject: Re: st: Weird problem with nested functions in Mata
> 
> Ben Jann <ben.jann@soz.gess.ethz.ch> has done an experiment in Mata
and
> observed execution times:
> 
> 	: real colvector test1(x) return(x:*x:*x:*x:*x)
> 
> 	: real colvector test2(x) return(test1(x))
> 
> 	: real colvector test3(x) return(test2(x))
> 
> 	: real colvector test4(x) return(test3(x))
> 
> 	: real colvector test5(x) return(test4(x))
> 
> 	: real colvector test6(x) return(test5(x))
> 
> test1() does something.  test2() does the same something, and so do
> test3(), test4(), and so on.  And yet, when Ben Jann writes down
> execution times, he gets strange results, with execution speeds
speeding
> up
> and slowing down.  He writes,
> 
> > This really puzzles me. What would be the logic behind this? Does
anyone
> > have an explanation?
> 
> I have repeated Ben's experiment, and I do not get the see-saw pattern
> of timings that Ben reports.  My timings are:
> 
>         . mata: z = x:*x:*x:*x:*x
> 	r; t=0.30 13:50:17
> 
>         . mata: z = test1(x)
> 	r; t=0.31 13:50:18
> 
>         . mata: z = test2(x)
> 	r; t=0.30 13:50:18
> 
>         . mata: z = test3(x)
> 	r; t=0.30 13:50:18
> 
>         . mata: z = test4(x)
> 	r; t=0.30 13:50:18
> 
>         . mata: z = test5(x)
> 	r; t=0.31 13:50:19
> 
> 	. mata: z = test6(x)
> 	r; t=0.30 13:50:19
> 
> If Ben really wishes to measure the time of nesting (it is close to
zero),
> Ben needs to set up experiments where the *SAME* routine is called
> over and over again, and he will need the number of calls to be in the
> 1,000s, or more.
> 
> That's because the time required to execute a function call is much
> greater
> the first time than subsequent times.  The first time a function is
> called,
> Mata must look up its address based on the function's name.  After
that,
> Mata
> remembers it.
> 
> For example:
> 
>          real colvector test5(x) return(text4(x))
> 
> The first time you call test5(), the function test4() will need to be
> looked
> up by name.  That linkage information (an address) is then stored with
> test5()'s compiled code, so that the next time test5() is called, the
> lookup
> can be skipped.
> 
> That happens within an execution.  So if test6() called test5() a
thousand
> times, the first call linkage would be slow, but the remaining 999
would
> be instant.
> 
> When Mata comes back to a prompt, all that linkage information is
thrown
> away,
> and Mata starts rebuilding it from scratch.  Why?  Because, at the
prompt,
> you
> might throw away the current test4() and write a new one.  The way to
> ensure
> that test5()'s table is updated to invalidate all the information in
all
> the
> tables.
> 
> -- Bill
> wgould@stata.com
> *
> *   For searches and help try:
> *   http://www.stata.com/support/faqs/res/findit.html
> *   http://www.stata.com/support/statalist/faq
> *   http://www.ats.ucla.edu/stat/stata/

*
*   For searches and help try:
*   http://www.stata.com/support/faqs/res/findit.html
*   http://www.stata.com/support/statalist/faq
*   http://www.ats.ucla.edu/stat/stata/



© Copyright 1996–2014 StataCorp LP   |   Terms of use   |   Privacy   |   Contact us   |   What's new   |   Site index