The same source code is compiled with g++ (linux) and with visual c++. I found that the program runs much slower on the second one (0.03 seconds vs 0.359 seconds).

The program uses <vector> and does a convolution:

void DSP_fir_gen1
(
    vector < double > *x,
    double *h,
    vector < double > *r,
    int nh,
    int nr
)
{
	int i, j;
	double sum;
	(*r).clear();
	for (j = 0; j < nr; j++)
	{
	    sum = 0;
	    for (i = 0; i < nh; i++)
	    {
	        sum += (*x)[i + j] * h[i];
	    }
	    (*r).push_back(sum);
	}
}

The aprox. "x" width is about 36656 doubles and "h" is between 2 and 25. I don't understand why the program compiled in visual c++ 6 is so painfully slow.
When I compile in linux I use the options:

-O0 -g3 -Wall -c -fmessage-length=0

And in visual c++ 6.0:

kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /subsystem:console /incremental:yes /pdb:"Debug/QRSdetectMain.pdb" /debug /machine:I386 /out:"Debug/QRSdetectMain.exe" /pdbtype:sept

My PC is a Pentium 4 intel 3.2 Ghz 3.2 Ghz 512 Mb RAM.

I would suspect all that debug code in the VC++ options, and it doesn't look like you have many optimizations enabled either...

Go to your project options and disable debug info and enable all the optimizations you can, and see if that doesn't make a difference.

(I still can't get VC++ to install on my machine... so I can't help more... I just updated to SP3 so maybe I'll get that pesky .NET 3 to work now.)

Good luck!

A couple of things.
1. VC6 is probably 10 years older than your Linux compiler.

2. Have you considered using reserve() to allocate all the space up front, then just subscript your accesses (rather than push_back)

A couple of things.
1. VC6 is probably 10 years older than your Linux compiler.

2. Have you considered using reserve() to allocate all the space up front, then just subscript your accesses (rather than push_back)

1. I have considered it, but I believed that It shouldn't be so important. Do you think that an old compilator can differ a magnitude order from the new one?

2. You are right! this time I can use reserve without problems because I know the size before. It can improve slightly the speed. thanks.86

There is something I'm not sure about:

My goal is to do a dll library in windows OS -and I am not used to work in windows-. Can I do easily a dll for windows without using Microsoft Visual C++ compilator?

>Do you think that an old compilator can differ a magnitude order from the new one?
Yes. Especially since Visual C++ 6.0's STL implementation was extremely weak.

>Can I do easily a dll for windows without using Microsoft Visual C++ compilator?
Writing DLLs in Windows is not difficult. Though I would highly recommend upgrading your Visual C++ to 2005 or 2008. Visual C++ 6.0 is painful if you plan on making use of templates.

>>Can I do easily a dll for windows without using Microsoft Visual C++ compiler ?
yes, you can use most any compiler that targets MS-Windows version 2000 or later.

Since there is virtually nothing in common (different compiler, different operating systems, different eras), it's very hard to make an objective comparison based solely on one small test of one aspect of one feature of the STL.

It might be an order of magnitude, but it's still the blink of an eye (in human perception terms).

Also, the STL only makes statements about complexity, not performance. If you try your test with 3000 elements and 300,000 elements, you might get a different ratio of performance.

> Do you think that an old compilator can differ a magnitude order from the new one?
Apparently, it can. More inline code, better optimisation and a better allocation strategy - yeah, perhaps it could.


As for your last question, Visual Studio Express is
a) far more up to date
b) far more standard compliant
c) $0 in price.

Thank you to all!
I usually work under linux and It's my first time I have to make a dll library under windows. I will test all alternatives you posted and post my results.
Anyway, thanks again!

Because of this thread is not closed yet, allow me to add some remarks.
On my AMD 5000+ (~2.6 MHz) with VC++ 2008 (release, optimize for speed) this function runs ~3.8 milliseconds (data sizes are 36656 and 25).
It's interesting that a variant of this function with std::valarray<double> data runs ~1.3 milliseconds only:

void DSP_fir_gen1v
(
    valarray <double>& x,
    valarray <double>& h,
    valarray <double>& r,
    int nh,
    int nr
)
{
    double sum;
    //(*r).clear();
    for (int j = 0; j < nr; j++)
    {
        sum = 0;
        for (int i = 0; i < nh; i++)
        {
            sum += x[i + j] * h[i];
        }
        r[j] = sum;
        //(*r).push_back(sum);
    }
}

>>Because of this thread is not closed yet
We don't close threads unless we have to normally when someone starts behaving badly or flaming starts.

Please post the whole program so we can run it and compare execution times with different computers.

Probably the better word was "solved": it's my terrible English, sorry...

Some remarks.
Naturally, I have used my stop-watch class based on the Performance Counter Windows API (see URL in the source). I have tested it with VC++ 2008 only.
On other platforms we need time interval measurement tools based on non-standard API because of the best standard RTL timing clock() function has too low precision.

/* I have #include "stdafx.h" with
#include <iostream>
#include <valarray>
#include <vector>
*/
/// Original function (std:: prefix added)
void DSP_fir_gen1
(
    std::vector < double > *x,
    double *h,
    std::vector < double > *r,
    int nh,
    int nr
)
{
    int i, j;
    double sum;
    (*r).clear();
    for (j = 0; j < nr; j++)
    {
        sum = 0;
        for (i = 0; i < nh; i++)
        {
            sum += (*x)[i + j] * h[i];
        }
        (*r).push_back(sum);
    }
}

typedef std::vector<double>   Vector;
typedef std::valarray<double> Valarray;

/// Based on std::valarray:
void DSP_fir_gen1va
(
    const Valarray& x,
    const Valarray& h,
    Valarray& r,
    int nh,
    int nr
)
{
    //int i, j;
    double sum;
    //(*r).clear();
    for (int j = 0; j < nr; j++)
    {
        sum = 0;
        for (int i = 0; i < nh; i++)
        {
            sum += x[i + j] * h[i];
        }
        r[j] = sum;
        //(*r).push_back(sum);
    }
}

const int NR = 36656;
const int NH = 25;

// StopWatch = http://www.daniweb.com/code/snippet916.html

void TestDSP()
{
    StopWatch tick;
    double t;
    {
        Vector x(NR,1.0);
        Vector r(NR,2.0);
        Vector h(NH,3.0);

        tick.reset();
        DSP_fir_gen1(&x,&h[0],&r,h.size(),x.size()-h.size());
        t = tick.millis();
        std::cout << "std::vector\t" << t << " msec\n";
    }
    {
        Valarray x(1.0,NR);
        Valarray r(2.0,NR);
        Valarray h(3.0,NH);

        tick.reset();
        DSP_fir_gen1va(x,h,r,h.size(),x.size()-h.size());
        t = tick.millis();
        std::cout << "std::valarray\t" << t << " msec" 
            << std::endl;
    }
}
/** Output:
std::vector     3.77227 msec
std::valarray   1.28061 msec
*/

I have already tested the modified program using VC express 2008. The final program being:

void DSP_fir_gen1
(
    vector < double > *x,
    double *h,
    vector < double > *r,
    int nh,
    int nr
)
{
	int i, j;
	double sum;
	(*r).resize(nr - nh + 1);
	for (j = 0; j < nr - nh + 1; j++)
	{
	    sum = 0;
	    for (i = 0; i < nh; i++)
	    {
	        sum += (*x)[i + j] * h[i];
	    }
	  	(*r)[j] = sum;
	}
}

Without changing default build options the program lasts about 0.8 each loop. However, adding Optimization options and disabling some Runtime Checks, it lasts about 0.028!
To optimize it I've used:

  • Maximise Speed (/02)
  • Only Inline (/0b1)
  • Favor Fast Code (/0t)

And I've disabled:

  • Basic Runtime Checks (/RTCs) : Incompatible with Optimization
  • Debug Information Format
This question has already been answered. Start a new discussion instead.