[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
cputime and parallel computing
From: |
Anton Dereventsov |
Subject: |
cputime and parallel computing |
Date: |
Thu, 6 Sep 2018 14:35:03 -0500 (CDT) |
I've noticed that cputime() does not measure time correctly with parallel
package.
For instance, in the following script I multiply two random 1000-by-1000
matrices 10 times and time the execution using tic-toc and cputime. I use a
standard 'for' cycle, an 'arrayfun' function, and a 'pararrayfun' function:
N = 1000;
K = 10;
t0 = tic; t1 = cputime;
for i = 1 : K
rand(N)*rand(N);
endfor
printf('wall time: %.6f | cpu time: %.6f\n', toc(t0), cputime-t1);
t0 = tic; t1 = cputime;
arrayfun(@(n) rand(N)*rand(N), 1:K, 'UniformOutput', 0);
printf('wall time: %.6f | cpu time: %.6f\n', toc(t0), cputime-t1);
pkg load parallel
t0 = tic; t1 = cputime;
pararrayfun(nproc, @(n) rand(N)*rand(N), 1:K, 'VerboseLevel',
0);
printf('wall time: %.6f | cpu time: %.6f\n', toc(t0), cputime-t1);
Here is the output:
wall time: 5.190973 | cpu time: 5.228000
wall time: 5.373872 | cpu time: 5.404000
wall time: 3.517548 | cpu time: 0.116000
This code was executed in Octave 4.4.1 on Ubuntu 16.04 and the results are
consistent with each run, however the last cpu time measurement does not
seem to be correct. I would expect all three cpu times to be very similar
since the computed problem is the same. Moreover, the last measurement is
far too small (it becomes even more obvious if N is increased).
Is there a way to correctly measure cpu time on parallelized chunks of code?
Also, how come that the cpu time is slightly bigger that the wall time in
the first two measurements even though they are executed on a single core?
Thanks,
Anton
--
Sent from: http://octave.1599824.n4.nabble.com/Octave-General-f1599825.html
- cputime and parallel computing,
Anton Dereventsov <=