Timing

[jbsnyder]

----- "Dado Sutter" <dadosutter at gmail.com> wrote:
>
>
>
> On Wed, Feb 18, 2009 at 02:19, James Snyder < jbsnyder at fanplastic.org > wrote:
>

So, one of the things I've been doing recently is tracking timing data for adcscope.lua when running it. I've found certain things that increase or decrease the amount of time spent getting samples, but I hadn't actually checked what the bare minimum time would be for a dry loop like the following:

>
> term.clrscr()
>
> while 1 do
> t1 = tmr.start(0)
> t2 = tmr.read(0)
> dtime = tmr.diff(0,t2,t1)
> term.gotoxy(1,1)
> term.putstr(string.format("Time (us): %06d",dtime))
> end
>
> For LM3S6965, I get 79 us. Is this correct?

> What is the MCLK freq on your board/kit pls ?

50 MHz :-)

tmr.getclock(0) shows the same.

tmr.mindelay(0) shows 0, indicating according to the description that delays should be accurate to sub microsecond levels...

> I'll check the timming on my EK-LM3S8962 asap.
>
> Thanks for showing me that we not always need a tmr.stop() !! :)
>
>

I get generally the same results if I start the timer outside the loop and do two subsequent reads.
> Making t1 and t2 locals shaves off a little but not much. If I make tmr.start and tmr.read locals, things get down to 13 us.

> Wow, what a difference ! I knew locals were faster (I think Roberto mentions this and other gems in http://www.lua.org/gems/sample.pdf ) but that seems quite a difference.

I was reading that yesterday when I was experimenting with this :-)

I hadn't realized until reading that that one could define functions as locals.

>
>

Does this jibe with everyone else's findings?

> asap
>
>

If I do a local function between the two timers like math.sqrt, I get a stable 48 us/cycle:

> Good !!! Determinism is welcome here :)
> (pls note this can obviously vary, depending on the function used here, at least for different arguments, as you've done in your example below)

Right. I just wanted to pick something that I figured would require more than a few machine instructions to perform. Doing something like adding a number to s2 is certainly faster. There are also many functions that would run slower.

>
>

term.clrscr()

>
> local t1, t2, s2
> local tstart = tmr.start
> local tread = tmr.read
> local speedfun = math.sqrt
>
> while 1 do
> s2 = 23
> t1 = tstart(0)
> s2 = speedfun(s2)
> t2 = tread(0)
> dtime = tmr.diff(0,t2,t1)
> term.gotoxy(1,1)
> term.putstr(string.format("Delay (us): %06d",dtime))
> en
>
> Making all the timing and sampling functions and variables local, here are the timings I'm looking at for adcscope.lua when getting samples from 4 channels.
>
> Pass table to getsamples, modify specified index ( adc.getsamples(v,1,adcvals,i ): 293 us (stable)
> Convert returned table to integer, insert into table (adcvals[i] = adc.getsamples(v,1)[1]): ~470 us (fluctuates)
> Replace nested table of values within adcvalues table (adcvals[i] = adc.getsamples(v,1)): ~450 (fluctuates, sometimes maybe up to 1000-2000 us)

> gc seems to be working on 3rd test :(

It may be going on the 2nd as well, I should log the maximum timing as well as mean and standar deviation to get some more statistics.

>

> Very nice !! Thanks for the precise report again !!
> Still, it seems a bit too slow to me :( for a Cortex-M3. I hope this is just a bad impression.

Yeah, I certainly expect a performance hit for running in an interpreted language, but I'm not sure if this is expected performance.

Of course this is for desktops, but here is a performance comparison between compiled C and lua from the Computer Language Benchmarks Game:
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=lua&lang2=gcc&box=1 

Of course this is a totally different chip and whatnot, but it is a single core performance comparison between C and Lua. Not sure if these ratios are similar for ARM or Thumb2 :-)

>
>

-jsnyder

> Dado
>
>
>
>
>

>


> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev 
>
>
> _______________________________________________ Elua-dev mailing list Elua-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/elua-dev 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090218/bcf032dc/attachment.html