Measure CPU time usage in Matlab (in milliseconds) - matlab

How can I measure the time used by Matlab in the execution of some commands? I am looking for something like linux time command, which returns the actual CPU used (user + sys), instead of the total time transcurred, which can vary depending on system usage by other processes.
Also, the time should be returned in milliseconds.

You can use cputime:
CPUTIME CPU time in seconds.
CPUTIME returns the CPU time in seconds that has been used
by the MATLAB process since MATLAB started.
For example:
t=cputime; your_operation; cputime-t
returns the cpu time used to run your_operation.
The return value may overflow the internal representation
and wrap around.
There's also timeit.
And you can also use tic/ toc (see Daniel's answer).
See some useful comments on measuring CPU time. According to the above link, tic / toc and timeit give more accurate estimations than cputime.

For a simple clock time solution, use tic and toc
profile provides a detailed report code per line, you can choose between cpu time and real time.

Related

Stopping simulation based on CPU time in Dymola/Modelica

In Dymola, I'm able to do something like:
when time > 100 then
assert(false,"Simulation taking too long");
end when;
to stop simulations based on the time variable itself.
However, what i'd like to do is stop the simulation based on elapsed CPU time. Dymola has a way to output the CPU time and it shows up in the results as CPUtime, but I don't know how to access the variable. In other words, this is what i'd like to do, but the CPUtime variable isn't in scope:
when CPUtime > 100 then
assert(false,"Simulation taking too long");
end when;
Any suggestions, either how to access CPUtime, or other workarounds to kill simulations based on cpu time?
As already noted:
You can set this in Dymola 2022 in the simulation setup, or alternatively by setting Advanced.Simulation.MaxRunTime.
It's wall-clock time, which means that if you have a parallel simulation it will stop after 10s has passed and not when the cores together have spent 10s, and if you for some weird reason have a long sleep-call in the model it will still end.
(This was already noted in the comment - thanks Priyanka. However, stackoverflow for some reason warns that answers in comments may be lost.)

Is there a way to do a millisecond level delay in matlab?

Help for 'PAUSE' says
PAUSE(n) pauses for n seconds before continuing, where n can also be a
fraction. The resolution of the clock is platform specific. Fractional
pauses of 0.01 seconds should be supported on most platforms.
But in my case pause(0.01) doesn't do anything at all (pause, pause(n) with whole number n works)
Is there any way to make a millisecond level delay (50 ms, 100 ~ 500 ms) delay in matlab?
Matlab version is
MATLAB Version 7.9.0.529 (R2009b)
64 bit on a Windows 10 64 bit Home edition
I see two options. Let's call them the looping option and the native option. The first is just using a while loop to check if your desired time to wait is already reached. You can do this with MATLAB's stopwatch timer tic and toc. This is the normal time (not the CPU-time). As you are writing a loop, which runs at maximum speed, you might encounter a high CPU-usage but this should be OK if it is only for a couple of milliseconds.
%% looping
% desired time to wait
dt_des = 0.001; % 1 ms
% initialize clock
t_st = tic;
% looping
while toc(t_st) < dt_des
end
% read clock
toc(t_st)
The native option is using pause (make sure that you have enabled it once with pause('on')). I assumed from your question that this does not always work -- however, it does on my system (R2019b, windows 10).
%% use pause()
tic
pause(0.001)
toc
The results of both are
Elapsed time is 0.001055 seconds.
Elapsed time is 0.001197 seconds.
It's not too accurate but you might get better results if you tune the numbers on your PC.
you can also use
java.lang.Thread.sleep(10);
if you are using an old matlab version, see discussion here.

Achieving 2 hertz data logging with Matlab serial

I am trying to use matlab for data acquisition with a licor820 instrument. The instrument outputs data at 2 hertz.
I have tried many different methods using infinite loops with asynchronous sampling (readasync) and timed readings but I am unable to get 2 hertz data. I am getting reads in the .51 s range. here are three examples of my methods. Any advice on what I may be doing wrong or how to properly sample at the highest frequency would be greatly appreciated!
example1: using readasync
tinit=tic; %initialization timer
s=serial('COM4') %,'InputBufferSize',40);
fopen(s)
while toc(tinit)<2 %allow time to initialize
end
while 1<2 %infinite loop for continuous sampling
readasync(s)
data=fscanf(s)
toc %allows me to see time between data acquisitions
tic
end
example 2: using bytes available.
My thinking here is to acquire data when I have the minimum amount of bytes necessary. Although I am unsure exactly how to determine how many bytes are necessary for my instrument, besides through visually looking at the data and narrowing it down to around 40 bytes:
while 1<2 %infinite loop for continuous sampling
if s.BytesAvailable >35
scandata=fscanf(s);
toc
tic
end
end
example 3: time forcing.
Since I need 2 hertz data my thinking here was to just force read the buffer every .49 seconds. The weird thing I see here is that it initially provides samples every .49 seconds, but while I monitor the bytes available at the port I see it steady dropping from 512 until it gets to 0 and then I stop getting .49 second samples. I guess I don't really understand how to use serial efficiently.
while 1<2 %infinite loop
if toc(t2)>=.49 %only sample after .49 seconds have passed
t2=tic; %reinitiate the tic for this forced time loop
bytes=s.BytesAvailable %to monitor how many bytes there are at the port
scandata=fscanf(s);
if ~isempty(scandata) && length(scandata)== 3 %checks for successful read
toc
tic
end
end
end
I feel there must be some way to sample completely in sync with the an instrument but I can't figure it out. Any help, suggestions, or ideas would be greatly appreciated! Thanks!
Dont rely on tic and toc. These functions use the time supplied by the OS calls. Mathworks claims to use high resolution timers, but do not rely on this! If you do not use a realtime OS these measurements are subject to unknown variation.
Sampling should be performed by realtime capable hardware. In your case I suspect that your sampling rate is actually controlled by your instrument. The output of the instrument is buffered by your serial interface. Therefore it seems to me that Matlab does not influence the sampling rate at all. (As long as the buffer does not overflow)
Try to acquire about 2000 samples or more and see how long it takes. Then divide the total time by the number of samples (-1) and compare this to the expected 0.5 s. If there is a difference, try adjusting the configuration of your instrument.

Show progress of a Matlab instruction execution

Is there any way to show the execution progress (even a rough estimation) of a Matlab instruction?
For example let's say I am computing distances using pdist:
D = pdist(my_matrix,'cosine');
and this computation takes hours, does Matlab provide any way to show periodically the execution progress?
Not intrinsically. You can of course do after-the-fact checking with the profiler or tic/toc.
If this is something you will be doing a lot for a single function, you could consider modifying the function and saving it in your path with a new name (I have a directory called "Modified Builtin" for just this purpose). In the case of pdist.m, you might save pdist_updates.m. Looking a the function, the actual distances are calculated starting around line 250 with a series of nested loops. Add in a line like:
disp(sprintf('Processing pair %d of %d',i,n-1));
at line 265. If you really wanted to get fancy, you could use tic and toc to time each loop and provide an estimate of how long the entire calculation would take so you would know how long you had to run to the coffee machine.
Of course this will cause problems if you end up cancelling your Statistics Toolbox license or if Mathworks upgrades the toolbox and changes the functionality, so use this approach sparingly.

fread() optimisation matlab

I am reading a 40 MB file with three different ways. But the first one is way faster than the 2 others. Do you guys have an idea why ? I would rather implement condition in loops or whiles to separate data than load everything with the first quick method and separate them then - memory saving -
LL=10000000;
fseek(fid,startbytes, 'bof');
%% Read all at once %%%%%%%%%%%%%%%%%%%%%%
tic
AA(:,1)=int32(fread(fid,LL,'int32'));
toc
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
fseek(fid,startbytes,'bof');
%% Read all using WHILE loop %%%%%%%%%%%%%
tic
i=0;
AA2=int32(zeros(LL,1));
while i<LL
i=i+1;
AA2(i,1)=fread(fid,1,'int32');
end
toc
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
fseek(fid,startbytes,'bof');
%% Read all using FOR loop %%%%%%%%%%%%%%%
tic
AA3=int32(zeros(LL,1));
for i=1:LL
AA3(i,1)=fread(fid,1,'int32');
end
toc
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Elapsed time is 0.312916 seconds.
Elapsed time is 138.811520 seconds.
Elapsed time is 116.799286 seconds.
Here are my two cents on this:
Is the JIT accelerator enabled?
Since MATLAB is an interpreted language, for loops can be quite slow. while loops may be even slower, because the termination condition is re-evaluted in each iteration (unlike for loops that iterate a predetermined number of times). Nevertheless, this is not so true with JIT acceleration, which can significantly boost their performance.
I'm not near MATLAB at the moment, so I cannot reproduce this scenario myself, but you can check yourself whether you have JIT acceleration turned on by typing the following in the command window:
feature accel
If the result is 0 it means that it's disabled, and this is probably the reason for the huge reduction in performance.
Too many system calls?
I'm not familiar with the internals of fread, but I can only assume that one fread call to read the entire file invokes less system calls than multiple fread calls. System calls are usually expensive, so this can, to some extent, account for the slowdown.