Prev: why it is invalid syntax
Next: Matlab & Threads ?
From: Jan Simon on 4 Aug 2010 17:19 Dear David, > Most of the time is spent in computing the fft2 and ifft2. So I guess there is not much that I can do here :( Why not? Create a copy of IFFT2 and look, what could be omitted: - error(nargchk(1, 4, nargin, 'struct')) - remove it! - Usage of the powerful but slow VARARGIN? Replace it by the hard coded inputs. - "[m_in, n_in] = size(f)" is faster than calling SIZE twice - numel(varargin) - not needed, you know the number of inputs already - Omit the check for 'nonsymmetric' - No need to cast the inputs to DOUBLE - Use the debugger to check, if the (m_out~=m_in) part is used at all - Finally the acutual calculation is "ifft(ifft(...". If you can reduce the number of lines to 6, inline them to your function, because calling a funktion has a certain overhead ever. Do the same for FFT2, which is unfortunately very lean already. Do not hesitate to dig in Matlab's toolbox functions. You can accelerate even trivial functions like NOW, FILEPARTS, BLANKS and IND2RGB. Good luck, Jan
From: Walter Roberson on 4 Aug 2010 17:34 David Romero-Antequera wrote: > Is there any starting point to read about the accuracy? http://docs.sun.com/source/806-3568/ncg_goldberg.html http://docs.sun.com/source/806-3568/ncg_math.html > For example, how do I know how accurate is the > exp function in MATLAB? I am finding mixed information on that. One recent IEEE paper about arbitrary precision indicates that IEEE 754 does not mandate any precision for the transcendential functions; the other places I look indicate that IEEE 754 requires the calculation to be correct down to the last bit. A paper with several different implementations of exp() can be found at http://www.convict.lu/Jeunes/ultimate_stuff/exp_ln_2.htm
From: David Romero-Antequera on 5 Aug 2010 09:40 "Jan Simon" <matlab.THIS_YEAR(a)nMINUSsimon.de> wrote in message <i3clg8$d8r$1(a)fred.mathworks.com>... > Dear David, > > > Most of the time is spent in computing the fft2 and ifft2. So I guess there is not much that I can do here :( > > Why not? Create a copy of IFFT2 and look, what could be omitted: > - error(nargchk(1, 4, nargin, 'struct')) - remove it! > - Usage of the powerful but slow VARARGIN? Replace it by the hard coded inputs. > - "[m_in, n_in] = size(f)" is faster than calling SIZE twice > - numel(varargin) - not needed, you know the number of inputs already > - Omit the check for 'nonsymmetric' > - No need to cast the inputs to DOUBLE > - Use the debugger to check, if the (m_out~=m_in) part is used at all > - Finally the acutual calculation is "ifft(ifft(...". > If you can reduce the number of lines to 6, inline them to your function, because calling a funktion has a certain overhead ever. > > Do the same for FFT2, which is unfortunately very lean already. > > Do not hesitate to dig in Matlab's toolbox functions. You can accelerate even trivial functions like NOW, FILEPARTS, BLANKS and IND2RGB. > > Good luck, Jan Thanks for the suggestion. It was actually even more simple. As I am expecting 1D-vectors or 2D-matrices ONLY, I could replace ifft2 by ifftn and I saved that time. Thanks a lot for this suggestion! I've realized that I have a very complete error control at the beginning of my routine, so basically I can drop any other check in the routines that I am calling the most.
From: Steven_Lord on 5 Aug 2010 10:06 "Jan Simon" <matlab.THIS_YEAR(a)nMINUSsimon.de> wrote in message news:i3clg8$d8r$1(a)fred.mathworks.com... > Dear David, > >> Most of the time is spent in computing the fft2 and ifft2. So I guess >> there is not much that I can do here :( > > Why not? Create a copy of IFFT2 and look, what could be omitted: > - error(nargchk(1, 4, nargin, 'struct')) - remove it! > - Usage of the powerful but slow VARARGIN? Replace it by the hard coded > inputs. > - "[m_in, n_in] = size(f)" is faster than calling SIZE twice > - numel(varargin) - not needed, you know the number of inputs already > - Omit the check for 'nonsymmetric' > - No need to cast the inputs to DOUBLE > - Use the debugger to check, if the (m_out~=m_in) part is used at all > - Finally the acutual calculation is "ifft(ifft(...". > If you can reduce the number of lines to 6, inline them to your function, > because calling a funktion has a certain overhead ever. > > Do the same for FFT2, which is unfortunately very lean already. > > Do not hesitate to dig in Matlab's toolbox functions. You can accelerate > even trivial functions like NOW, FILEPARTS, BLANKS and IND2RGB. But if you choose to do this, make sure you make a backup copy of the unmodified function and/or copy the function to a file with a different name and change the new file. While ripping out error checking code and code to handle the most general cases can improve performance, those sections of code weren't in there simply to take up space in the file -- the function will no longer have a "safety net" to catch you with a (hopefully informative) error message if you make a mistake. -- Steve Lord slord(a)mathworks.com comp.soft-sys.matlab (CSSM) FAQ: http://matlabwiki.mathworks.com/MATLAB_FAQ To contact Technical Support use the Contact Us link on http://www.mathworks.com
From: David Romero-Antequera on 5 Aug 2010 10:46
"Jan Simon" <matlab.THIS_YEAR(a)nMINUSsimon.de> wrote in message <i3clg8$d8r$1(a)fred.mathworks.com>... > Dear David, > > > Most of the time is spent in computing the fft2 and ifft2. So I guess there is not much that I can do here :( > > Why not? Create a copy of IFFT2 and look, what could be omitted: > - error(nargchk(1, 4, nargin, 'struct')) - remove it! > - Usage of the powerful but slow VARARGIN? Replace it by the hard coded inputs. > - "[m_in, n_in] = size(f)" is faster than calling SIZE twice > - numel(varargin) - not needed, you know the number of inputs already > - Omit the check for 'nonsymmetric' > - No need to cast the inputs to DOUBLE > - Use the debugger to check, if the (m_out~=m_in) part is used at all > - Finally the acutual calculation is "ifft(ifft(...". > If you can reduce the number of lines to 6, inline them to your function, because calling a funktion has a certain overhead ever. > > Do the same for FFT2, which is unfortunately very lean already. > > Do not hesitate to dig in Matlab's toolbox functions. You can accelerate even trivial functions like NOW, FILEPARTS, BLANKS and IND2RGB. > > Good luck, Jan Thanks for the suggestion. It was actually even more simple. As I am expecting 1D-vectors or 2D-matrices ONLY, I could replace ifft2 by ifftn and I saved that time. Thanks a lot for this suggestion! I've realized that I have a very complete error control at the beginning of my routine, so basically I can drop any other check in the routines that I am calling the most. |