Prev: Pass large matrices accross matlab functions
Next: RGB 2D slice in a 3D plot
From: Rune Allnor on 22 Feb 2010 08:34
On 22 Feb, 13:05, "Jan Simon" <matlab.THIS_Y...(a)nMINUSsimon.de> wrote:
> Dear Rune!
>
> > > My current solution is a trivial C-Mex function for calculating the sum: For 1000 elements it is 40% slower than Matlab's SUM (thanks TMW!),
>
> > It's not TMW that are that good; it's probably you who
> > haven't configured your C compiler correctly.
>
> I let Open Watcom 1.8, LCC 2.4 (shipped with Matlab), LCC 3.8 (from the net) and BCC 5.5 compile my C-code.
> The speed of the executables created by these compilers can differ remarkably. E.g. LCC 3.8 is really fast for accessing a vector by a moving pointer ("Sum += *X++;"), while BCC can handle indices efficiently ("Sum += X[i]"). So it is not the configuration of the compiler, but finding a formulation of the algorithm, which matchs the compilers optimizer best.

So you have a number of freeware and obsolete (BCC) C compilers?

Hardly a good sample for discussing speed. Those optimizations
are the kind of thing that a shrewed compiler vendor might
reserve his paying customers...

Rune
From: Jan Simon on 22 Feb 2010 09:30
Dear Rune!

> So you have a number of freeware and obsolete (BCC) C compilers?
> Hardly a good sample for discussing speed. Those optimizations
> are the kind of thing that a shrewed compiler vendor might
> reserve his paying customers...

I've asked for the speed of SUM built-in in Matlab, not about C-compilers. Surprisingly even a "cheap" or "obsolete" compiler beats Matlab's SUM for vectors with 1E7 elements. Nevertheless, this will be discussed elsewhere.

It would be very kind, if you could answer my question about the time consumption of SUM(ones(89000, 1)) and SUM(ones(88999, 1)) on a multi-thread machine.

Thanks, Jan
From: Rune Allnor on 22 Feb 2010 11:46
On 22 Feb, 15:30, "Jan Simon" <matlab.THIS_Y...(a)nMINUSsimon.de> wrote:
> Dear Rune!
>
> > So you have a number of freeware and obsolete (BCC) C compilers?
> > Hardly a good sample for discussing speed. Those optimizations
> > are the kind of thing that a shrewed compiler vendor might
> > reserve his paying customers...
>
> I've asked for the speed of SUM built-in in Matlab, not about C-compilers. Surprisingly even a "cheap" or "obsolete" compiler beats Matlab's SUM for vectors with 1E7 elements.

Maybe they do.

Before you draw your conclusions, check out a simple test I
made. The C file testsum.c (attached below) was compiled with
the LCC compiler that comes with matlab R2006a, and the MS
Visual Studio 2008 C compiler. The two executables are named
testsumlcc and testsummsvc, respectively.

Do note that my MSVC compiler is set up with the /arch:SSE2
flag, which the standard MEX configuration for MSVC compilers
did not include (at least not back in early 2006).

As you can see, the MSVC code runs in less than 10% of the time
of the free LCC codes.

So if these numbers are representative for C compilers, your
program, compiled with freeware, runs a factor 10'ish too slow.
Which, by induction, might suggest that matlab runs a factor 5'ish
slower than the fast C code.

If correct - one would need to confirm your numbers by compiling
your code with a state-of-the-art compiler - the question becomes
why matlab runs that slow in the first place.

Rune

%%%% Output

Elapsed time is 0.008697 seconds. % testsum.c compiled with LCC
Elapsed time is 0.000525 seconds. % testsum.c compiled with MSVC

%%%%%%%%%%%%%%%%%%%%%%%%%%%
clc
tic; testsumlcc; toc;
tic; testsummsvc; toc;
%%%%%%%%%%%%%%%%%%%%%%%%%%%

/*************** testsum.c *********************************/
#include <math.h>
#include "mex.h"

extern void _main();

void mexFunction(
int nlhs,
mxArray *plhs[],
int nrhs,
const mxArray *prhs[]
)
{
double x[1000000];
int i;
double sum;

for (i = 0; i< 1000000; ++i)
{
x[i] = i;
}
sum = 0;
for (i = 0; i< 1000000; ++i)
{
sum+=x[i];
}

return;
}
/******************************************************************/
From: freund on 22 Feb 2010 02:21
Jan,

System:
Intel(R) Core(TM)2 Duo CPU
E6850 @ 3.00GHz
3.00 GHz, 3.24 GB RAM
Physical Address Extension

Both execution times = 0.2703 seconds.

Regards,

Iz
From: Jan Simon on 22 Feb 2010 12:37
Dear Rune!

> Before you draw your conclusions, check out a simple test I
> made.

Thank you for answering and spending time to discuss about C-compilers.
I really appreciate to discuss this interesting and important topic in another thread if I find some time.

I'm currently just interested in knowing the behaviour of SUM as it exists in Matlab. The C-compiler is not my problem, if the main reason for the speed of SUM depends on the fact that I run a modern Matlab 2009a on a single thread computer - a dinosaur!

So before I start to check your tests, it would be nice if you start my tests...

Thanks, Jan
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Pass large matrices accross matlab functions
Next: RGB 2D slice in a 3D plot