Beginner's problem with MEX -files
in [Matlab]
|
From: Jan Simon on 5 Jul 2010 15:58 Dear James, > Note that max(max(A)) is just max(A(:)) ... saves some overhead. In the OPs problem A is small (4x4, 8x8). For larger matrices, MAX(MAX(A)) can be faster than MAX(A(:)), as I have learned from a comment of Urs. The benefits from multi-threading beat the drawback of calling overhead. Jan
From: James Tursa on 5 Jul 2010 17:05 "Jan Simon" <matlab.THIS_YEAR(a)nMINUSsimon.de> wrote in message <i0tdgc$92h$1(a)fred.mathworks.com>... > Dear James, > > > Note that max(max(A)) is just max(A(:)) ... saves some overhead. > > In the OPs problem A is small (4x4, 8x8). For larger matrices, MAX(MAX(A)) can be faster than MAX(A(:)), as I have learned from a comment of Urs. The benefits from multi-threading beat the drawback of calling overhead. > > Jan Interesting. I must have missed that thread. Thanks. Do you know how large the matrices have to be to see the benefit? And it sounds like it only applies for later versions of MATLAB where max is multi-threaded. True? Of course, there is no reason why max(A(:)) can't be multi-threaded behind the scenes also ... but that is up to TMW. James Tursa
From: Jan Simon on 5 Jul 2010 18:01 Dear James, > > For larger matrices, MAX(MAX(A)) can be faster than MAX(A(:)), as I have learned from a comment of Urs. > Interesting. I must have missed that thread. No, James, you did not miss a thread. It was in the FEX: http://www.mathworks.com/matlabcentral/fileexchange/25625 There Urs posted (and started to call me <jan>): % ic2/2*2.6ghz/2gb/winxp.sp3/r2009b x=rand(1000); tic;for i=1:1000;min(x(:));end;toc % Elapsed time is 1.469955 seconds. tic;for i=1:1000;min(min(x));end;toc % Elapsed time is 1.491293 seconds. for smaller xes, its even faster... > Do you know how large the matrices have to be to see the benefit? This depends on the exact method to divide the problem into threads. If the different columns are distributed between the threads, not the size of the array is most important, but the remainder of the number of columns and cpu cores. E.g. for two cores, MAX(RAND(10000, 3)) would take the same time as MAX(RAND(10000, 4)). For MAX(RAND(1, 1e7)) it would be helpful to split the row into parts. e.g. as in the mutli-threaded SUM of Matlab 2009a. Unfortunately TMW decided not to check, if the cpu has multiple cores at all. So on my old Pentium-M SUM(1:89000) is remarkably slower than SUM(1:88999) in 2009a/b, but not in 2010a. The magic limit 89000 seems to be independent from the number of cpu cores. Kind regards, thanks to Urs, Jan
From: James Tursa on 6 Jul 2010 04:40 "Jan Simon" <matlab.THIS_YEAR(a)nMINUSsimon.de> wrote in message <i0tkn0$kjm$1(a)fred.mathworks.com>... > > > > For larger matrices, MAX(MAX(A)) can be faster than MAX(A(:)), as I have learned from a comment of Urs. > > > Interesting. I must have missed that thread. > > No, James, you did not miss a thread. It was in the FEX: > http://www.mathworks.com/matlabcentral/fileexchange/25625 Thanks. Looks like I have another learning project ahead of me! Do you know if anyone has compiled a list of when functions (max, min, sum, etc) were multi-threaded? James Tursa
From: Steve Eddins on 6 Jul 2010 07:01
On 7/3/2010 11:02 AM, Rune Allnor wrote: > On 3 Jul, 16:14, "Aristeidis "<aris...(a)hotmail.com> wrote: >> > Trying to use C and C++ without knowing what you do, is >> >> >> >> >> >>> like the sourcerer's apprentice playing with fire in the >>> gunpowder arsenal. >> >>> Stop what you are doing and learn whatever language, be >>> it C or C++, first. As somebody wrote where some time >>> ago, >> >>> http://groups.google.no/group/comp.soft-sys.matlab/msg/72e63bfc8f1a78... >> >>> "Re rogue pointers--that is *exactly* what happens. After >>> one of these crashes Matlab becomes completely unpredictable. >>> Sometimes I can keep going. Other times (and at other >>> stages of debugging) it will close immediately, Windows >>> will give me a (fatal) runtime error, or--my favorite--it >>> won't return to the command line and won't let me close it, >>> either, giving me an error message when I try to do so." >> >>> Rune >> >> Thanks for the reply and advice Rune. >> >> I didn't say I am not familiar with C++ hence why I chose to write a MEX. I would classify my knowledge on C++ as basic. Besides, the cell computations I hope I d be able to write are quite elementary. > > If you say so... > >> However, I never had to write a MEX-file before and the tutorials I have found are rather general and vague. > > There are a number of example files shipped with matlab. > While not exhaustive, they are quite useful as starting points, > *provided* you already know your C or C++. > > I suggested to TMW staff to make these files easier to find > than they have been - I have no idea whether this suggestion > has been acted upon. > > Rune Here's where you can find links to various MEX-file examples in the documentation: Documentation - MATLAB - User Guide - External Interfaces - Creating C/C++ Language MEX-files - Examples of C/C++ Source MEX-Files This page includes links to example files timestwo.c, timestwoalt.c, revord.c, xtimesy.c, phonebook.c, arrayFillGetPr.c, arrayFillSetPr.c, arrayFillSetData.c, convec.c, doubleelement.c, findnz.c, fulltosparse.c, sincall.c and mexcpp.cpp. --- Steve Eddins http://blogs.mathworks.com/steve/ |