Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Parallel builds
IvanBatrakov:
yes, number in Settings was changed to 1000, it helps to make parallel build of ONE project in workspace but other projects have to wait first project in queue.
So 3 CPU cores are sleeping at 0% CPU usage almost constantly.
All projects are without dependencies between them, only common files used like header files included.
Also dependencies of header files included to project even shown in file tree in project do not work at all.
As solution manually change .CPP file in project then build is ok.
Jenna:
I use 3 processes on my core2duo and both processors are used to compile.
IvanBatrakov:
Quantity of projects in workspace helps to understand situation.
Yes, parallel build works for ONE project in workspace but other projects are waiting ONE build to be ended.
It is queue, not parallel build and code in function int CompilerGCC::DoRunQueue() shows it.
thomas:
Ok, but who cares? The point in doing parallel builds is reducing build times. The current "non-parallel" parallel build does that by running more than one compiler instance on a build-target scope. It works, and it is robust.
A "true parallel" build will likely not be any faster, and possibly be slower due to caching effects, since unrelated files are compiled concurrently and will less likely share the same headers and their object files will be less likely found in caches at link time. It will also be less robust.
Alpha:
--- Quote from: thomas on November 13, 2011, 08:14:00 pm ---A "true parallel" build will likely not be any faster, and possibly be slower due to caching effects, since unrelated files are compiled concurrently and will less likely share the same headers and their object files will be less likely found in caches at link time.
--- End quote ---
There is a situation in which I would find this method parallel compiling to be faster. When I have tested various modifications to the core of a program (for example, Code::Blocks), many of the extra plugins must be re-linked to the sdk, but not necessarily re-compiled (if they do not include a modified header). When running on multiple cores, this results in only a single core being used for the majority of the time.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version