Speed Optimization of C++ console application

dooley

@JonB Yes I saw it. I did try changing it to QMAKE_CXXFLAGS_RELEASE += -02 as suggested and saw no improvement. I will change it back if that is the correct way to insert it... like I said I am new to QT and saw the -= format in another post and was tying it.

Thanks for the response... do you have any other thoughts as to why I don't see an increase in speed?

Sorry it took so long to respond to you but since I am a new user I have to wait 600 seconds between posts.

aha_1980

@dooley

So are you actually building a release version?

Please show your compiler output so we see the flags passed to the compiler.

Sorry it took so long to respond to you but since I am a new user I have to wait 600 seconds between posts.

No longer, I gave you an upvote :)

Regards

dooley

@aha_1980 Here is the compiler output...

15:08:01: Running steps for project SF_1...
15:08:01: Configuration unchanged, skipping qmake step.
15:08:01: Starting: "C:\Qt1\Tools\QtCreator\bin\jom.exe" 
	C:\Qt1\Tools\QtCreator\bin\jom.exe -f Makefile.Release
15:08:01: The process "C:\Qt1\Tools\QtCreator\bin\jom.exe" exited normally.
15:08:01: Elapsed time: 00:00.

dooley

@aha_1980 This is probably more usefull :)

15:18:51: Running steps for project SF_1...
15:18:51: Starting: "C:\Qt1\Tools\QtCreator\bin\jom.exe" clean
	C:\Qt1\Tools\QtCreator\bin\jom.exe -f Makefile.Release clean
	del release\CVSReader.obj release\ComponentManagement.obj release\MatrixUtilities.obj release\Nodes.obj release\Pipes.obj release\Tanks.obj release\VectorUtilities.obj release\main.obj
	C:\Qt1\Tools\QtCreator\bin\jom.exe -f Makefile.Debug clean
	del debug\CVSReader.obj debug\ComponentManagement.obj debug\MatrixUtilities.obj debug\Nodes.obj debug\Pipes.obj debug\Tanks.obj debug\VectorUtilities.obj debug\main.obj
	del debug\SF_1.vc.pdb debug\SF_1.ilk debug\SF_1.idb
Could Not Find C:\Users\heath\Documents\build-SF_1-Desktop_x86_windows_msvc2017_pe_64bit-Release\debug\CVSReader.obj
Could Not Find C:\Users\heath\Documents\build-SF_1-Desktop_x86_windows_msvc2017_pe_64bit-Release\debug\SF_1.vc.pdb
15:18:52: The process "C:\Qt1\Tools\QtCreator\bin\jom.exe" exited normally.
15:18:52: Starting: "C:\Qt1\5.13.1\msvc2017_64\bin\qmake.exe" C:\Users\heath\Documents\SF_1\SF_1.pro -spec win32-msvc "CONFIG+=qtquickcompiler"
15:18:52: The process "C:\Qt1\5.13.1\msvc2017_64\bin\qmake.exe" exited normally.
15:18:52: Starting: "C:\Qt1\Tools\QtCreator\bin\jom.exe" -f C:/Users/heath/Documents/build-SF_1-Desktop_x86_windows_msvc2017_pe_64bit-Release/Makefile qmake_all

jom 1.1.3 - empower your cores

15:18:52: The process "C:\Qt1\Tools\QtCreator\bin\jom.exe" exited normally.
15:18:52: Starting: "C:\Qt1\Tools\QtCreator\bin\jom.exe" 
	C:\Qt1\Tools\QtCreator\bin\jom.exe -f Makefile.Release
	cl -c -nologo -Zc:wchar_t -FS -Zc:rvalueCast -Zc:inline -Zc:strictStrings -Zc:throwingNew -Zc:referenceBinding -Zc:__cplusplus -O2 -MD -O2 -W3 -w34100 -w34189 -w44996 -w44456 -w44457 -w44458 -wd4577 -wd4467 -EHsc -DUNICODE -D_UNICODE -DWIN32 -D_ENABLE_EXTENDED_ALIGNED_STORAGE -DWIN64 -DNDEBUG -I..\SF_1 -I. -I..\C++Libraries\Eigin3.3.7 -I..\..\..\..\Qt1\5.13.1\msvc2017_64\mkspecs\win32-msvc -Forelease\ @C:\Users\heath\AppData\Local\Temp\CVSReader.obj.4364.15.jom
CVSReader.cpp
	cl -c -nologo -Zc:wchar_t -FS -Zc:rvalueCast -Zc:inline -Zc:strictStrings -Zc:throwingNew -Zc:referenceBinding -Zc:__cplusplus -O2 -MD -O2 -W3 -w34100 -w34189 -w44996 -w44456 -w44457 -w44458 -wd4577 -wd4467 -EHsc -DUNICODE -D_UNICODE -DWIN32 -D_ENABLE_EXTENDED_ALIGNED_STORAGE -DWIN64 -DNDEBUG -I..\SF_1 -I. -I..\C++Libraries\Eigin3.3.7 -I..\..\..\..\Qt1\5.13.1\msvc2017_64\mkspecs\win32-msvc -Forelease\ @C:\Users\heath\AppData\Local\Temp\VectorUtilities.obj.4364.78.jom
VectorUtilities.cpp
..\SF_1\VectorUtilities.cpp(43): warning C4244: '=': conversion from '__int64' to 'int', possible loss of data
..\SF_1\VectorUtilities.cpp(55): warning C4244: '=': conversion from '__int64' to 'int', possible loss of data
..\SF_1\VectorUtilities.cpp(60): warning C4244: '=': conversion from '__int64' to 'int', possible loss of data
..\SF_1\VectorUtilities.cpp(70): warning C4189: 'tmp': local variable is initialized but not referenced
..\SF_1\VectorUtilities.cpp(96): warning C4189: 'tmp': local variable is initialized but not referenced
..\SF_1\CVSReader.cpp(16): warning C4189: 'numLines': local variable is initialized but not referenced
..\SF_1\CVSReader.cpp(14): warning C4189: 'newLine': local variable is initialized but not referenced
	cl -c -nologo -Zc:wchar_t -FS -Zc:rvalueCast -Zc:inline -Zc:strictStrings -Zc:throwingNew -Zc:referenceBinding -Zc:__cplusplus -O2 -MD -O2 -W3 -w34100 -w34189 -w44996 -w44456 -w44457 -w44458 -wd4577 -wd4467 -EHsc -DUNICODE -D_UNICODE -DWIN32 -D_ENABLE_EXTENDED_ALIGNED_STORAGE -DWIN64 -DNDEBUG -I..\SF_1 -I. -I..\C++Libraries\Eigin3.3.7 -I..\..\..\..\Qt1\5.13.1\msvc2017_64\mkspecs\win32-msvc -Forelease\ @C:\Users\heath\AppData\Local\Temp\Nodes.obj.4364.47.jom
Nodes.cpp
	cl -c -nologo -Zc:wchar_t -FS -Zc:rvalueCast -Zc:inline -Zc:strictStrings -Zc:throwingNew -Zc:referenceBinding -Zc:__cplusplus -O2 -MD -O2 -W3 -w34100 -w34189 -w44996 -w44456 -w44457 -w44458 -wd4577 -wd4467 -EHsc -DUNICODE -D_UNICODE -DWIN32 -D_ENABLE_EXTENDED_ALIGNED_STORAGE -DWIN64 -DNDEBUG -I..\SF_1 -I. -I..\C++Libraries\Eigin3.3.7 -I..\..\..\..\Qt1\5.13.1\msvc2017_64\mkspecs\win32-msvc -Forelease\ @C:\Users\heath\AppData\Local\Temp\ComponentManagement.obj.4364.15.jom
ComponentManagement.cpp
	cl -c -nologo -Zc:wchar_t -FS -Zc:rvalueCast -Zc:inline -Zc:strictStrings -Zc:throwingNew -Zc:referenceBinding -Zc:__cplusplus -O2 -MD -O2 -W3 -w34100 -w34189 -w44996 -w44456 -w44457 -w44458 -wd4577 -wd4467 -EHsc -DUNICODE -D_UNICODE -DWIN32 -D_ENABLE_EXTENDED_ALIGNED_STORAGE -DWIN64 -DNDEBUG -I..\SF_1 -I. -I..\C++Libraries\Eigin3.3.7 -I..\..\..\..\Qt1\5.13.1\msvc2017_64\mkspecs\win32-msvc -Forelease\ @C:\Users\heath\AppData\Local\Temp\MatrixUtilities.obj.4364.31.jom
MatrixUtilities.cpp
..\SF_1\MatrixUtilities.cpp(367): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data
..\SF_1\MatrixUtilities.cpp(437): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data
..\SF_1\MatrixUtilities.cpp(385): warning C4189: 'tFI_T': local variable is initialized but not referenced
..\SF_1\MatrixUtilities.cpp(456): warning C4189: 'Ed': local variable is initialized but not referenced
..\SF_1\MatrixUtilities.cpp(829): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data
..\SF_1\MatrixUtilities.cpp(829): warning C4189: 'loopcnt': local variable is initialized but not referenced
..\SF_1\MatrixUtilities.cpp(866): warning C4189: 'cheker': local variable is initialized but not referenced
..\SF_1\MatrixUtilities.cpp(860): warning C4189: 'end': local variable is initialized but not referenced
	cl -c -nologo -Zc:wchar_t -FS -Zc:rvalueCast -Zc:inline -Zc:strictStrings -Zc:throwingNew -Zc:referenceBinding -Zc:__cplusplus -O2 -MD -O2 -W3 -w34100 -w34189 -w44996 -w44456 -w44457 -w44458 -wd4577 -wd4467 -EHsc -DUNICODE -D_UNICODE -DWIN32 -D_ENABLE_EXTENDED_ALIGNED_STORAGE -DWIN64 -DNDEBUG -I..\SF_1 -I. -I..\C++Libraries\Eigin3.3.7 -I..\..\..\..\Qt1\5.13.1\msvc2017_64\mkspecs\win32-msvc -Forelease\ @C:\Users\heath\AppData\Local\Temp\Pipes.obj.4364.47.jom
Pipes.cpp
	cl -c -nologo -Zc:wchar_t -FS -Zc:rvalueCast -Zc:inline -Zc:strictStrings -Zc:throwingNew -Zc:referenceBinding -Zc:__cplusplus -O2 -MD -O2 -W3 -w34100 -w34189 -w44996 -w44456 -w44457 -w44458 -wd4577 -wd4467 -EHsc -DUNICODE -D_UNICODE -DWIN32 -D_ENABLE_EXTENDED_ALIGNED_STORAGE -DWIN64 -DNDEBUG -I..\SF_1 -I. -I..\C++Libraries\Eigin3.3.7 -I..\..\..\..\Qt1\5.13.1\msvc2017_64\mkspecs\win32-msvc -Forelease\ @C:\Users\heath\AppData\Local\Temp\Tanks.obj.4364.62.jom
Tanks.cpp
	cl -c -nologo -Zc:wchar_t -FS -Zc:rvalueCast -Zc:inline -Zc:strictStrings -Zc:throwingNew -Zc:referenceBinding -Zc:__cplusplus -O2 -MD -O2 -W3 -w34100 -w34189 -w44996 -w44456 -w44457 -w44458 -wd4577 -wd4467 -EHsc -DUNICODE -D_UNICODE -DWIN32 -D_ENABLE_EXTENDED_ALIGNED_STORAGE -DWIN64 -DNDEBUG -I..\SF_1 -I. -I..\C++Libraries\Eigin3.3.7 -I..\..\..\..\Qt1\5.13.1\msvc2017_64\mkspecs\win32-msvc -Forelease\ @C:\Users\heath\AppData\Local\Temp\main.obj.4364.94.jom
main.cpp
..\SF_1\main.cpp(33): warning C4101: 'my_documents': unreferenced local variable
	link /NOLOGO /DYNAMICBASE /NXCOMPAT /INCREMENTAL:NO /SUBSYSTEM:CONSOLE "/MANIFESTDEPENDENCY:type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' publicKeyToken='6595b64144ccf1df' language='*' processorArchitecture='*'" /MANIFEST:embed /OUT:release\SF_1.exe @C:\Users\heath\AppData\Local\Temp\SF_1.exe.4364.7000.jom
15:18:59: The process "C:\Qt1\Tools\QtCreator\bin\jom.exe" exited normally.
15:18:59: Elapsed time: 00:08.

dooley

@aha_1980 After having taken your and @aha_1980 direction on the annotation and rebuilding it appears to be working.

Thanks to everyone for the help. I am a civil engineer putting together some simple apps for calculations I use regularly more for fun and the interest in programming than anything else, so I don't know a whole lot and can use as much help as I can get.

fcarney

@dooley said in Speed Optimization of C++ console application:

civil engineer

Ah, a "target" maker. Welcome aboard!

beecksche

When building in Release mode, the optimization flag -O2 should be set by default.

If speed is an issue and using lots of loops you can also enable the logs for Auto-Vectorization:

QMAKE_CXXFLAGS_RELEASE += -Qvec-report:2

Then all vectorized and non-vectorized loops will be logged and you can see where loops can be imporved. For some loops it's neccessary to set

QMAKE_CXXFLAGS_RELEASE += -fp:fast

to be vectorized. But be careful with that!

Another way to speed up the program is to set the -Qpar flag for Auto-Parallelization:

QMAKE_CXXFLAGS_RELEASE += -Qpar

Then, if possible, loops will be parallelized. There is also an log flag for that -QPar-report:2.

Please note, only valid for MSVC compiler and CPU architure with SSE2, AVX, and AVX2.

kshegunov

@beecksche said in Speed Optimization of C++ console application:

QMAKE_CXXFLAGS_RELEASE += -fp:fast

Don't use this unless you really, really, really (and I can't emphasize that enough) know what you're doing (which is almost never). This can break promises made by the IEEE FP standard in regards to behavior and optimize out expressions that are not to be optimized. It can break proper rounding and error propagation, and floating point exceptions' diagnostics.

Kent-Dorfman

A code slowdown of a factor of 10 wouldn't be normal just with an optimization flag of -O0 vs -O2. Something else is going on here. The OP only states C++ in VS2017...No mention of CLR or native code generation in VS. Actually I'd expect the converse of the reported behaviour, where the native C++ QT runs faster if the VS C++ code is done as CLR and not native. If I had to WAG, I'd guess that the VS code is taking advantage of a .net library optimization that isn't present in native C++ QT. Without seeing the algorithms and the library links it's hard to know what exactly is going on. Heap managed memory could also play a large part in the time differences being reported.

Christian Ehrlicher

@Kent-Dorfman said in Speed Optimization of C++ console application:

A code slowdown of a factor of 10 wouldn't be normal just with an optimization flag of -O0 vs -O2.

Why not? Did you see the code? Maybe there are lots of asserts in there or other stuff... without code it's just wild guessing.

kshegunov

@Kent-Dorfman said in Speed Optimization of C++ console application:

A code slowdown of a factor of 10 wouldn't be normal just with an optimization flag of -O0 vs -O2.

Actually it can be pretty normal. I've at least two rather small codebases that exhibit such speedups between debug and release (i.e. -g -O0 vs -O2). There's nothing odd about it because debug mode represents what you wrote faithfully, which isn't at all true for release builds.

Something else is going on here.

Not necessarily. Depends on the type of code. If you have code with a lot of templates for example the debug build is going to put a call instruction on every function call and do the regular push, pop on the stack. When the optimizer runs almost, to all, of this gets stripped down and the code is inlined, to an extreme degree. So yes, 10 time speedup between debug and release is nothing to be suspicious about.

JonB

@dooley
What the others are saying about optimization vs debug is probably correct, you can be surprised by how much difference it can make depending.

However, if you are sure about your compiler flags etc. but are still stumped by speed behaviour, it may be time to compile/link for profiling your application. Both gcc & msvc have profiling (unless the free msvc does not, I don't know). This does take a bit of reading first time to set up and interpret output, but well worth it if you wish to investigate speed/performance over time in future.

Kent-Dorfman

@kshegunov I wrote absolutely nothing about "-g". I still maintain that simple -O0 vs -O2 is NOT going to divide performance by a factor of 10. I cannot begin to imagine how badly a person would have to design their algorithm to validate that level of performance hit. something other than compiler optimization is causing his hit...

kshegunov

@Kent-Dorfman said in Speed Optimization of C++ console application:

@kshegunov I wrote absolutely nothing about "-g".

Fair enough.

I still maintain that simple -O0 vs -O2 is NOT going to divide performance by a factor of 10. I cannot begin to imagine how badly a person would have to design their algorithm to validate that level of performance hit.

https://bitbucket.org/kshegunov/ans-utilities/src/master/hermite/

Knock yourself out, if you so desire. I'm certainly not investing the time to see if -g makes a significant difference, which I strongly suspect it doesn't.

aha_1980

@Kent-Dorfman said in Speed Optimization of C++ console application:

@kshegunov I wrote absolutely nothing about "-g". I still maintain that simple -O0 vs -O2 is NOT going to divide performance by a factor of 10. I cannot begin to imagine how badly a person would have to design their algorithm to validate that level of performance hit. something other than compiler optimization is causing his hit...

That strongly depends on the algorightm, I'd say.

Just imagine, a non optimized build that does not fit in the cache, so the CPU has to re-load stuff from memory all the time vs. the optimized build that runs fluently.

Factor 10 is probably not the normal case where you have to wait for I/O anyway, but for heavy computing it is easily possible.

Regards

fcarney

This is starting to sound like a coding challenge. Can you write an algorithm that is slow the compiler can optimize and make fast? Like turning lead to gold.

kshegunov

@fcarney said in Speed Optimization of C++ console application:

Can you write an algorithm that is slow the compiler can optimize and make fast? Like turning lead to gold.

As I wrote, any template nonsense you have (the deeper and nastier the better) fits into this category.

Kent-Dorfman

Eh, the OP kind of disappeared so I guess it isn't that important to him. I'm more interested in knowing whether the windoze version in this exercise was compiled to CLR bytecode, which he never answered, and which IMHO invalidates any real comparison.