Confusion with tic-toc and run times

I am trying to figure out how long a simulation will take. I desire to run multiple simulations and average out the result as is descrbide in the code below

tic
repeats = 10; %number of times we repeat the simulation

n = 800; %number of particles

diam = 1/sqrt(n); %diameter of a particle

k = 5; %grid denisty

uppertime = 0.2; %simulation time

timesteps = 40; %number of frames in simulation

MultipleP = zeros(repeats,timesteps+1);

times = zeros(1,repeats+1);

times(1) = toc;

for i = 1:repeats
    tic
    MultipleP(i,:) = shorttimeoptimised(n,uppertime,timesteps,k);
    times(i+1) = toc;
end
time = sum(times);

AverageP = mean(MultipleP);

When I run the above code I get a time value of about 1.2 seconds where if I time the above code with the spot watch on my phone I get about 47 seconds which including my human error at the very lowest the actual run time is 40 seconds. Why is there such a huge dissparity between matlabs run time and my stopwatch timed run time? Additionally, how would I compute the run time for shorttimeoptimised. I have tried giving the function a second output variable which i call time and then introduce a tic and toc at the begining and end of the function. However, when doing this tic toc produces a run time of 0.1 second which is noticably not true.

I appreciate that the variable time doesn't caputre the time taken to go from the end of each for loop to the beginning of next. But I would have thought that this time is negligible for a for loop of length 10.

Furthemore, I am intrested in how the run time for say repeats = 3000. I am not sure if there is some sort of initialising going on at the begining that causes and initial time delay or whether therun time really would be about 40*300 seconds?

Many Thanks,

Milos

[the cyclist]

Because we don't your shorttimeoptimised function, I replaced it with a calculation of the eigenvalues of a large random matrix, such that the "wall clock" time of your code took about 1 minute (actually 59.92 seconds).

Your time variable ended up with 59.47 seconds, very close to wall time, as expected.

Is your shorttimeoptimised function calling tic again?

[Milos]

Hi, Thank you for the reply. No the function does not call tic and toc. Also I'm sorry I didn't provide "shorttimeoptimised" since it is a much larger function calling on many custom functions and I didn't think the community would appreciate pages of out of context code. I can post the code if you like? Furthemore, none of the custom functions call tic or toc.

Answer 1

[Jim Riggs]

You might consider commenting out the "tic" command inside the for loop. This will make all of the "times" values relative to the start of the script (the initial "tic" command) and also eliminate 10 "tic" commands. Note that if you are getting tic/toc measurements in the 0.1 second range, these are not reliable. (see toc command, and also Measuring the performance of your code)

[Milos]

Thank you for the info. I did think that the tic/toc times of 0.1 were wrong. I have also checked out your second link and the timeit function seems to require variables to be preassigned. I preassigned the variables n,uppertime,timesteps,k but it still asks for different variables to be preassigned that should be computed from these four variables. I don't understand why this is?

Answer 2

[Steven Lord]

What does your shorttimeoptimised function return? Does it return how long the operation took to run or does it return the results of those calculations? If the latter, comparing the time variable and the AverageP variable is like comparing apples and oranges.

You may also want to run your shorttimeoptimised function using timeit and let timeit determine how many times it needs to run the code to get an accurate estimate of its average execution time.

[Milos]

Hi. shorttimeoptimised returns a vector where ith entry is the number of particles that havn't undergone a collision by time i*uppertime/timesteps. So it doesn't compute the time at all. I am not worried how long it will take to compute AverageP, infact I probably should have taken that out to avoid confusion. What I want to know is how long it take to run the function shorttimeoptimised.

I have tried using timeit as well and still very in accurate awnsers. I wrote the following code;

n=1600;
uppertime = 0.3;
timesteps = 30;
k=5;


g = @()shorttimeoptimised(n,uppertime,timesteps,k);

timeit(g)

which gives me an output of about 0.21 seconds. While the trying to time it with my phones stopwatch yeilds about 10 seconds. There is o tic or toc inside the function shorttimeoptimised or any of the functions it calls upon.

[Steven Lord]

From the timeit documentation: "In order to perform a robust measurement, timeit calls the specified function multiple times and returns the median of the measurements. If the function runs fast, timeit might call the function many times."

10/0.21

ans = 47.6190

Without seeing what shorttimeoptimised is doing it's not clear to me that there is a problem. timeit calling the function 50 or so times to obtain a robust measurement doesn't seem unreasonable to me.