Comments for Steve on Image Processing with MATLAB https://blogs.mathworks.com/steve Steve Eddins is an enthusiastic amateur French horn player. Also, he has developed image processing and MATLAB software for MathWorks since 1993. Steve coauthored the book <i>Digital Image Processing Using MATLAB</i>. Sat, 02 Nov 2019 02:48:10 +0000 hourly 1 https://wordpress.org/?v=6.2.2 Comment on Documenting performance improvements by Steve Eddins https://blogs.mathworks.com/steve/2019/10/07/documenting-performance-improvements/#comment-45696 Fri, 11 Oct 2019 18:40:03 +0000 https://blogs.mathworks.com/steve/?p=3438#comment-45696 Michal—I have experimented with your code sample, and I’ve talked with other MATLAB language developers about your profiler experience.

I ran your code, with and without the profiler on, in both R2015a and R2019b. R2015a is the last version of MATLAB before the new execution engine was introduced. Some conclusions:

  • You have a good point about the profiler sometimes skewing the comparison between different implementations.
  • The skew is a lot less now than before the new execution engine.
  • Vectorization just for the sake of performance is often no longer useful.
  • R2019b is a LOT faster than R2015a for your example, for both the looped and the prod versions.

The looped version is 8 times faster in R2019b than R2015a. The prod version is 36 times faster. As a result of these speedups, the loop and prod version are equally as fast in R2019b.

In R2015a, turning on the profiler slows the loop version down by 320x, and it slows the prod version down by 8x, resulting in a relative measurement skew of 40x.

In R2019a, turning on the profiler slows the loop version down by 50x, and it slows down the prod version by 6x, resulting in a relative measurement skew of 8x.

Other MATLAB language developers tell me your loop code pretty much the worst case for profiler overhead: a small, tight loop containing only scalar indexing and simple arithmetic. For now, there’s no workaround that I know of. It is just a profiler characteristic to be aware of. Perhaps we’ll be able to improve upon this in a future release. In the meantime, enjoy the speedups, and don’t worry as much about vectorizing everything in sight.

]]>
Comment on Documenting performance improvements by Steve Eddins https://blogs.mathworks.com/steve/2019/10/07/documenting-performance-improvements/#comment-45690 Thu, 10 Oct 2019 11:33:27 +0000 https://blogs.mathworks.com/steve/?p=3438#comment-45690 Michal—Thanks very much for providing a detailed reproduction case for the problem you are seeing with the profiler. I will show this to the language development team.

]]>
Comment on Documenting performance improvements by Michal Kvasnicka https://blogs.mathworks.com/steve/2019/10/07/documenting-performance-improvements/#comment-45688 Thu, 10 Oct 2019 07:57:52 +0000 https://blogs.mathworks.com/steve/?p=3438#comment-45688 @Steve Let see the following code:

function [tloop,tvec] = prodeval(neval,nround)
% neval  ... size of problem
% nround ... number of rounds

prodval = 1;
prodval2 = 1;
x = ones(1,neval);

% for-loop product
tic;
for k = 1:nround
    for i = 1:neval
        prodval = prodval*x(i);
    end
end
tloop = toc;

% vectorized product
tic;
for k = 1:nround
    prodval2 = prodval2*prod(x);
end
tvec = toc;

end

Matlab R2019b produce following results:

>> profile on
>> [tloop,tvec] = prodeval(1e1,1e8)

tloop = 61.1934
tvec = 6.6288

with activated profiling the vectorized coce is significant faster than for-loop code.

But with de-activated profiler are results completely different:

>> profile off
>> [tloop,tvec] = prodeval(1e1,1e8)

tloop = 0.8389
tvec = 1.1821

So finally, profiler in this case produce results which does not correspond to the results with deactivated profiler.

]]>
Comment on Documenting performance improvements by Michal Kvasnicka https://blogs.mathworks.com/steve/2019/10/07/documenting-performance-improvements/#comment-45684 Thu, 10 Oct 2019 07:35:25 +0000 https://blogs.mathworks.com/steve/?p=3438#comment-45684 @Steve … I just test my problematic code examples with R2019b and I must say, that problems mentioned above (with R2016a(b) and 2017a) were eliminated. Thanks…

]]>
Comment on Documenting performance improvements by Steve Eddins https://blogs.mathworks.com/steve/2019/10/07/documenting-performance-improvements/#comment-45680 Wed, 09 Oct 2019 20:54:40 +0000 https://blogs.mathworks.com/steve/?p=3438#comment-45680 Michal—Well, I guess I feel better about the situation than that. I think that most users have seen their code execution times steadily increase over time without having to do anything to their code. In a small number cases where there have been unanticipated performance degradations, we have fixed them as soon as possible after hearing about them. If you have specific cases where your code is not performing as you expect, please let me know. In general, I would advise anyone to write code initially with the primary goals of correctness and clarity, and then revise code for performance only as suggested by a tool such as the profiler. I have spoken with language team developers about your comments regarding the profiler, and they are not aware of a problem like you describe. The profiler was overhauled at the same time as the execution engine with the intent to make it just as useful as before. If you have situations where that is not the case, then please let me know, and we will try to address whatever the issues are.

]]>
Comment on Documenting performance improvements by Yair Altman https://blogs.mathworks.com/steve/2019/10/07/documenting-performance-improvements/#comment-45678 Wed, 09 Oct 2019 20:41:23 +0000 https://blogs.mathworks.com/steve/?p=3438#comment-45678 The new documentation standard is indeed a welcome improvement. Previously, nobody could know under which circumstances the speedup occurred, and to which degree (10% speedup? 2x? 10x?). Now, when something (e.g. VideoReader) is known to have improved by 4x, there is a much greater incentive to modify the code to use the improved function, or simply to upgrade the Matlab release.

]]>
Comment on Documenting performance improvements by Michal Kvasnicka https://blogs.mathworks.com/steve/2019/10/07/documenting-performance-improvements/#comment-45674 Wed, 09 Oct 2019 16:15:46 +0000 https://blogs.mathworks.com/steve/?p=3438#comment-45674 There is another problem, too. During execution engine development over last few years is less and less clear what kind of programming is optimal from the performance point of view. Let say 10 years ago was situation much more simple. Vectorized code was nearly always faster then classic form of programming (loop over indices,for example). Now is situation more difficult, because in some cases is vectorized code significantly slower than it’s classic counterpart. So, there is no more one universal paradigm: vectorization is mostly the best way how to optimize the code performance.

Moreover, the profiling is now less meaningful, because profiling results are less relevant to real performance of the code running in non-profiling mode.

Finally, Matlab programmers are now in unpleasant situation, because profiling is not definitely the best way how to find performance bottlenecks in code.

Are there some plans how to solve this situation?

]]>
Comment on Color correction with a parula quilt by Christie Lin https://blogs.mathworks.com/steve/2019/07/08/color-correction-with-a-parula-quilt/#comment-45666 Fri, 04 Oct 2019 20:30:03 +0000 https://blogs.mathworks.com/steve/?p=3346#comment-45666 Rad teamwork! I love the physical colormap.

]]>
Comment on Using reshape to rearrange image color components by Steve Eddins https://blogs.mathworks.com/steve/2019/08/30/using-reshape-to-rearrange-image-color-components/#comment-45636 Fri, 06 Sep 2019 12:15:15 +0000 https://blogs.mathworks.com/steve/?p=3400#comment-45636 Bjorn—It would have been around 1995 when I put this image into the dev build for MATLAB 5. I don’t remember for sure, but I believe it was several years later before the Image Processing Toolbox team got a digital camera to experiment with, and it wasn’t that good. We didn’t have lab-grade hardware lying around MathWorks at that time. :-)

I did my graduate work in the late 1980s at Georgia Tech. Our digital signal processing lab had a film scanner, which I could never get to work. Mostly, we used the same couple of dozen 256×256 and 512×512 images that everybody else was using at the time.

]]>
Comment on Using reshape to rearrange image color components by Bjorn Gustavsson https://blogs.mathworks.com/steve/2019/08/30/using-reshape-to-rearrange-image-color-components/#comment-45626 Mon, 02 Sep 2019 18:54:42 +0000 https://blogs.mathworks.com/steve/?p=3400#comment-45626 Steve, I don’t know if this should make me feel too old or too young – I do feel less than intelligent. We used science-grade ccds around that time and I “just assumed” that there were a reasonable number of photographer-level cameras around…

]]>