OK. What i mean is have a nice built-in configuration support forWhy do you think the former way of compiling is better?
mingw32-g++.exe first.cpp second.cpp -o output.dll -shared -Wl,--dll -s
versus what we get currently by default:
mingw32-g++.exe -c first.cpp -o first.o
mingw32-g++.exe -c second.cpp -o second.o
mingw32-g++.exe -shared -Wl,--dll first. o second.o -o output.dll -s
Isn't it what this thread was all about from the start?No it wasn't
Right... heheheC::B provides optimized builds when you use projects.... There is a release target that has -O2 switch by default.
I was looking for the option to compile multiple files at once in order to have optimized release builds. Since this feature in not present in cb....
The latter scales very well on a quad-, octa-, n-core machine. Can you say the same for the former?I haven't noticed that separate translation units would be compiled in parallel on my dual-core machine, at least not visually The output window does not indicated that in any way.
Using the -funit-at-a-time flag will allow the compiler to consider information gained from later functions in the file when compiling a function. Compiling multiple files at once to a single output file (and using -funit-at-a-time) will allow the compiler to use information gained from all of the files when compiling each of them.
I haven't noticed that separate translation units would be compiled in parallel on my dual-core machine, at least not visually The output window does not indicated that in any way.There is an option for the number of processes to use in Settings -> Compiler and Debugger -> Compiler -> Other (I think)
Can you prove that there is a gain? You can test two executables build using the two schemes and measure the difference in execution speed?Using the -funit-at-a-time flag will allow the compiler to consider information gained from later functions in the file when compiling a function. Compiling multiple files at once to a single output file (and using -funit-at-a-time) will allow the compiler to use information gained from all of the files when compiling each of them.
I believe that holds true if source code is compiled the way i have shown. Of course one has to include something like -O2 or -funit-at-a-time to have any benefit from it.
This is a very valid feature for an ide like cb is, not?
Can you prove that there is a gain? You can test two executables build using the two schemes and measure the difference in execution speed?
BTW, There is a chance that you'll get better speed/performance if you upgrade your compiler :)
p.s. also look at Link Time Object generation, or something like that in gcc 4.5
QuoteCan you prove that there is a gain? You can test two executables build using the two schemes and measure the difference in execution speed?
BTW, There is a chance that you'll get better speed/performance if you upgrade your compiler :)
p.s. also look at Link Time Object generation, or something like that in gcc 4.5
Yes, that is something of similar functionality like link time object generation. However I am not that lucky to have a freedom of changing compilers at will. There are such nasty things like build servers and then other engineers somewhere around the world, who are, so to say, not really into software development, but still need to be able to compile the source code. You should get the picture :) We did update to 4.4.0 in the beginning of it all however.
I do not have the proof for you. Is adding this functionality worth the effort? That was a part of my question - a codeblocks developer could quickly outline, how much effort there is to have that implemented.
For instance, SQLite is distributing it's source code primarily as an amalgamation - all code put into a single translation unit. They claim a 5%-10% performance gain from that alone. A db engine is quite a special case, I agree. Most of user applications would probably gain much less from it. Still, it is a feature supported by gcc and I guess all of the advanced optimizing compilers, so it would be good to have an option to quickly switch to this kind of configuration for making release builds.
For instance, SQLite is distributing it's source code primarily as an amalgamation - all code put into a single translation unit. They claim a 5%-10% performance gain from that alone. A db engine is quite a special case, I agree. Most of user applications would probably gain much less from it. Still, it is a feature supported by gcc and I guess all of the advanced optimizing compilers, so it would be good to have an option to quickly switch to this kind of configuration for making release builds.
// in main.cpp
// the only file that is added for compilation
// add
#include "file1.cpp"
#include "file2.cpp"
#include "file3.cpp"
.
.
.
#include "file_n.cpp"