MATLAB Answers

Running Code on GPU Seems much Slower than Doing so on CPU

21 views (last 30 days)
Hi there,
I am using a Thinkpad W550, and my GPU is Quadro K620M. As I simply ran the following code, the profile showed that running on the GPU was much slower.
function Test_GPU()
a = [10^8, 18^8];
h = a;
c = conv2(h, a, 'full');
% Running in doube precision got a similar result
aa = single(gpuArray([10^8, 18^8]));
hh = aa;
cc = conv2(hh, aa, 'full');
So I ran the official gpuBench()
The result is astonishing! Running on the GPU IS slower, much much more slower.
The first picture shows the result from GPU, and the second, CPU.
I will be very grateful if anyone could tell me why. Many thanks


Theron FARRELL on 27 May 2019
A follow-up question. After gpuBench finished running, no HTML report was given.
Anything with browser setting, etc.?
Jan on 27 May 2019
a = [10^8, 18^8] is a [1x2] vector. For a speed comparison, this job is too tiny.

Sign in to comment.

Accepted Answer

Andrea Picciau
Andrea Picciau on 29 May 2019
Edited: Andrea Picciau on 29 May 2019
You don't need to disable JIT acceleration. Rather, you need to measure using timeit and gputimeit like so:
% CPU data
a = ones([100, 100], 'single');
h = a;
% GPU data
aa = gpuArray(a);
hh = gpuArray(h);
% Measuring CONV2 with one output
cpuTime = timeit(@() conv2(h, a, 'full'), 1);
gpuTime = gputimeit(@() conv2(hh, aa, 'full'), 1);
Why you might want to do this:
  • MATLAB uses lazy evaluation to schedule the operations on your GPU, which introduces some asynchronicity in the GPU's behaviour. The same mechanism is not used on the CPU.
  • gputimeit takes lazy evaluation into consideration and also repeats the measure several times, weighing caching effects, overheads, and first-time costs.
  • timeit also repeats the measure several times, but it doesn't take lazy evaluation into consideration.
  • tic/toc neither repeat the measure nor takes lazy evaluation into consideration.
  • the profiler is somewhat similar to tic/toc but it also introduces some overhead in the measurement because it has to trace the whole call stack (which is why is useful for investigating rather than extracting rigorous measurements).
What results do you get? Let us know.
Given your setup, it woudln't be strange if gpuTime>cpuTime. Laptop GPUs are usually not optimized for computing, and it might be the case that yours is driving the graphics too.


Show 2 older comments
Theron FARRELL on 30 May 2019
I see. So generally speaking, as I optimise actual code for work, which approach shall I adopt?
tic toc, profile, or gputimeit()?
Walter Roberson
Walter Roberson on 30 May 2019
profile is probably best suited for determining how many times a line was invoked, and for determining which general sections of code are the most time consuming.
However, the actual amount of computation required might be substantially less if only the Just In Time compiler had not been turned off by profiling -- and that in turn means that in some cases the most expensive section of code is not what it appears at first. Once you have identified a general section of code as being expensive then unless it makes obvious sense that one particular line will certainly be the most expensive part, it might be better to rewrite the section into smaller functions to narrow down costs and so restrict your optimization efforts to functions that are disproportinately expensive.
To narrow down which of several different implementations is most efficient for a purpose, create test functions for each variety and time them with timeit(). Repeat the timeit() a number of times as the timings can vary a fair bit. Be careful on interpreting the results: if you have two different routines you are calling timeit() on and the first one seems to be more expensive, then sometimes the real issue is something to do with JIT. This leads me to doing tests such as
N = 50;
timesA1 = zeros(1,N); timesA2 = zeros(1,N); timesB1 = zeros(1,N);
FA = @FirstVariation; FB = @SecondVariation
for K = 1 : N; timesA1(K) = timeit(FA, 0); end
for K = 1 : N; timesB1(K) = timeit(FB, 0); end
for K = 1 : N; timesA2(K) = timeit(FA, 0); end
It is common for timesA1 to trend much higher than timesB1 and then for timesA2 to show times much closer to timesB1 -- that is, re-testing exactly the same thing can sometimes end up much faster for reasons that are not at all clear.
For timing tests on variations involving GPU use, always use gputimeit()

Sign in to comment.

More Answers (2)

Walter Roberson
Walter Roberson on 27 May 2019
The Quadro 620M was a Maxwell architecture, GM108 chip. That architecture does double precision at 1/32 of single precision.
MTimes operations are delegated to LAPACK by MATLAB for sufficiently large arrays. LAPACK automatically uses all available CPU cores.
My CPU shows up as faster for double precision MTIMES and backslach than my GTX 780M does, but the GPU was much faster for single precision, and is faster for double precision FFT than my CPU measures as.


Show 4 older comments
Theron FARRELL on 29 May 2019
Hi Andrea,
Thanks for your help. What I am concenred about is not the time occupied by allocation, but the line #20 ran faster than line #22, that is, code runing on CPU ran faster than on GPU even when I used arrayfun. However, I think tic/toc might be mire accurate, which I will try.
BTW, how will I be able to disable JIT acceleration in the profile? Cheers.
Andrea Picciau
Andrea Picciau on 29 May 2019
@Jan: Sorry, I meant to say "Theron". I changed my previous comment to fix that.
Jan on 29 May 2019
@Theron: I do not undestand, why you expect arrayfun to have a positive effect on the processing speed. The opposite is expected.
Starting the profiler disables the JIT accleration automatically, because the JIT can re-oreder the commands if it improves the speed, but then there is no relation between the timings and te code lines anymore. This means, that running the profiler can affect the run time massively, especially for loops. Of course this sounds to be counter-productive for the job of a profiler - and it is so, in fact. Therefore the profiler and tic/toc should be used both, because they have different advantages and disadvantages. For measuring the speed of single commands or elementary loops, the profiler is not a good choice.

Sign in to comment.





Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!