0

I have a MATLAB code where I am using parfor to reduce the amount of time taken by for to do some image processing tasks. Basically,it is taking two images and after doing some mathematical calculations, it produces a scalar qunatity called EucDist. For this, one image is kept fixed and another image is generated by a FORTRAN code which is taking around 20 seconds to do that. Below is the outline of my code:

matlabpool open
gray1 = some_image(8192,200);

dep = 0.04:0.01:0.40;       % Parameter 1
vel = 1.47:0.01:1.72;       % Parameter 2

dist = zeros(length(dep),length(vel));

tic
parfor i = 1:length(dep)
    ans = zeros(1,length(vel));
    for j = 1:length(vel)

        % Updating the Input.txt file
        fname = sprintf('Input_%.2d%s',i,'.txt');
        fid=fopen(fname,'w');
        fprintf(fid,'%-5.2f\n%-5.2f\n%.2d',dep(i),vel(j),i);
        fclose(fid);

        % Running my fortran code to generate another .dat file (Note that I have already compiled this code outside these loops)
        system(['./editcrfl ' fname]);

        % Calling IMAGE_GEN script incorporating the above .dat file 
        system('IMAGE_GEN');

        system(sprintf('IMAGE_GEN %d',i));

        gray2 = some_image(8192,200);

        % Doing some mathematical calculations and getting a value say 'EucDist' 
        - - - - - - - 
        - - - - - - -
        ans(j) = EucDist; 

    end
    dist(i,:) = ans;
    fclose('all');
end
fprintf('Total time taken: %f\n',toc); 
matlabpool close

There are two major problems that I am facing with the above code.

First, the dist matrix is not able to store all the EucDist generated. Ideally dist matrix should be of size 37 X 26 but it is only 37 X 1 and all the values are zeros in that. Though I have checked that all 37 X 26 values are getting calculated but don't know why it is not getting stored in dist.

Second, the total time taken when I am using parfor is somewhere around 9.5 hours whereas for normal for it is taking only 5.5 hours.

Can someone please help me to get rid of the above two problems?
Thanks in advance.

nagarwal
  • 87
  • 1
  • 1
  • 7
  • 1
    I'd guess that many image processing functions are already parallelized (hard to say without full code or a minimal example), so you won't see a benefit. Also, since it looks like you're also doing file io, whether you get any speed-up will depend on your file system and if you physical media supports parallel access. – horchler May 28 '16 at 18:03
  • Actually I am calculating Euclidean distance between images using a new approach. So it's not a built in function and that's the reason I am trying to parallelizing it by my own. However while calculating this modified Euclidean distance, I am using several builtin MATLAB functions. You can find an outline of that algorithm [here](http://stackoverflow.com/questions/36985718/euclidean-distance-between-images). Also, I think my physical media fully supports parallel access as I have seen some significant running time improvement over few simple examples. – nagarwal May 30 '16 at 04:51
  • `fft2`/`ifft2` are intrinsically multithreaded, as are most linear algebra operations ([see here](http://www.mathworks.com/discovery/matlab-multicore.html) and [here](http://blogs.mathworks.com/steve/2009/04/17/multithreaded-fft-functions-in-matlab-r2009a/)). – horchler May 30 '16 at 18:36
  • I am sorry to say this but that is not my concern at all. You can see that in my code, I am generating an image using a particular `dep(i)` and `vel(j)` and this is the actual part which is causing a running time overhead for my program which takes around 20 sec for one image generation. That's the reason I thought of using `parfor` so that each processor can have their own copy of Image generation code and produce an image according to their `vel` & `dep` value. What I think is, ideally this should reduce the running time by 1/12 for 12 processor but that is not the case. Can u explain this? – nagarwal May 31 '16 at 06:07
  • Can someone please help me into this? – nagarwal Jun 02 '16 at 04:51

0 Answers0