| | |
c++ compiled program much slower than g++
Thread Solved |
•
•
Join Date: Aug 2008
Posts: 4
Reputation:
Solved Threads: 0
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:
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:
And in visual c++ 6.0:
My PC is a Pentium 4 intel 3.2 Ghz 3.2 Ghz 512 Mb RAM.
The program uses <vector> and does a convolution:
C++ Syntax (Toggle Plain Text)
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:
C++ Syntax (Toggle Plain Text)
-O0 -g3 -Wall -c -fmessage-length=0
And in visual c++ 6.0:
C++ Syntax (Toggle Plain Text)
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!
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)
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)
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
--
If your code lacks code tags, you will be IGNORED
--
If your code lacks code tags, you will be IGNORED
•
•
Join Date: Aug 2008
Posts: 4
Reputation:
Solved Threads: 0
•
•
•
•
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)
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.
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.
Last edited by Narue; Aug 27th, 2008 at 4:36 pm.
In case you were wondering, yes, I do hate you.
>>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.
yes, you can use most any compiler that targets MS-Windows version 2000 or later.
The most important thing in the Olympic Games is not to win but to take part, just as the most important thing in life is not the triumph but the struggle. The essential thing is not to have conquered but to have fought well.
-Pierre de Coubertin, The Olympic Creed Inspired by Bishop Ethelbert
-Pierre de Coubertin, The Olympic Creed Inspired by Bishop Ethelbert
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.
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.
Last edited by Salem; Aug 27th, 2008 at 4:49 pm.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
--
If your code lacks code tags, you will be IGNORED
--
If your code lacks code tags, you will be IGNORED
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:
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:
C++ Syntax (Toggle Plain Text)
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.
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.
Last edited by Ancient Dragon; Aug 28th, 2008 at 5:29 pm.
The most important thing in the Olympic Games is not to win but to take part, just as the most important thing in life is not the triumph but the struggle. The essential thing is not to have conquered but to have fought well.
-Pierre de Coubertin, The Olympic Creed Inspired by Bishop Ethelbert
-Pierre de Coubertin, The Olympic Creed Inspired by Bishop Ethelbert
![]() |
Similar Threads
- was windows made with BASIC? (Legacy and Other Languages)
- Windows on a mac?! (Mac Rumors and Reports)
- 2d-c++ graphics guide PLZ! (C++)
- How to improve program with string compairing? (C++)
- Programming FAQ - Updated 1/March/2005 (Computer Science)
- Forum lurkers, introduce yourself ... !! (Community Introductions)
- real world uses of C++ and Java (IT Professionals' Lounge)
Other Threads in the C++ Forum
- Previous Thread: Array with Variable Size in a Structure
- Next Thread: Compositional C++ Has anybody heard about it?
Views: 1035 | Replies: 11
| Thread Tools | Search this Thread |
Tag cloud for C++
6 algorithm array arrays assignment beginner binary browser c++ c/c++ calculator char class classes code compile compiler constructor conversion convert count delete dll dynamic encryption error file files filestream forms fstream function functions game givemetehcodez graph graphics gui homework iamthwee input int lazy link linker list loop looping loops math matrix member memory newbie number object objects opengl operator output parameter path pointer pointers problem program programming project python random read reading recursion recursive reference server sort spoonfeeding string strings struct student studio template templates text time tree undefined url variable vc++ vector video visual win32 window windows winsock wxwidgets






