From: Jan Simon on 25 Jun 2010 11:57 Dear us, > here's a bit of information... > http://www.mathworks.com/access/helpdesk/help/techdoc/matlab_prog/f8-790895.html Thanks for this hint. It is clear and acceptable, that CPUTIME has limitations for measuring a period of time. TIC/TOC has severe problems also, if you run Matlab in a virtual machine - as any kind of internal speed measurement. Multi-, hyper-threading and machines with different speeds for multiple cores are simply not a good base for a physically meaningful definition of "tics per second". Even the value of CLOCK is controlled by the OS, e.g. when an NTP server updates the internal clock. In consequence, the *relative* times measured by two calls of CLOCK have a limited meaning. However, even the *absolute* value of the 1/1000 seconds replied by CLOCK and CPUTIME are dubious. (sorry for repeating myself again) Jan
From: Greg Heath on 26 Jun 2010 04:03 On Jun 25, 10:27 am, "Jan Simon" <matlab.THIS_Y...(a)nMINUSsimon.de> wrote: > Dear Matlab users, > > Obviously the precision of CPUTIME and and CLOCK is not so important for the members of this newsgroup. I'm going to ask the support for an explanation. > > Kind regards, Jan I remember getting all timings as integer multiples of 1/60 = 1.6666666666666667e-2 Hope this helps. Greg
First
|
Prev
|
Pages: 1 2 Prev: convolution matrix Next: read xls files with name 00000.xls and 00001.xls |