I’m starting clang 2.9 to compile C code generated by vala.
So far, everything works fine, the compilation is fast, I love the enhanced error messages.
Well I don’t miss gcc one bit.
Anyway, I have a question about clang and the use of the multicore processor.
Is there a way (ie a command line) to take full advantage our multicore processors ?
I know that there is no way to do so with just gcc (we are supposed to give the number of jobs to make : make -j 3 ).
The trouble is if your build system doesn’t use make, your toasted (or you have to decompose your compilation into tasks).
So is there any magic “-j” command line to clang ?
(Or any another workaround not involving make)
PS : I know about the whole Unix philosophy, “do a simple task and do it well”
make doesn't care what compiler is being used. If -j3 works for gcc then it should work for clang or any other compiler for that matter. I'll assume you're using the cmake files to generate Makefiles - in which case they dependency resolution should be good and not cause problems with a parallel build
No answer ?
I guess it means “no there is actually no way to leverage your multicore CPU using the clang command line”
Anyway, keep up the good work guys.
And good luck with 3.0
Since no one else has answered:
There was some talk a year or two ago about designing some sort of build
server using clang, but I don't think anything came of it. There
certainly isn't any code in trunk to leverage multiple cores, and I am
not entirely sure how thread-safe LLVM/Clang are by default. I think
there is support for using the library from multiple threads, but I
think it boils down to using entirely seperate contexts for them.
Your question is non-sense and once again you should look at the your build system for build level parallelism.
IN PRINCIPAL - but I realize NOT YET in reality - clang could first
locate the beginning of each function definition in a source file,
then compile each function in a separate thread.
I don't doubt that would require major rearchitecture to accomplish.
Right, and it wouldn't necessarily actually be a significant performance win,
since we'd also need to carefully introduce concurrency controls on all the
shared data. And that's even discounting things like elaborated-type-specifiers
and extern function declarations that require coordination between functions.
Given the overhead costs, the language design, and the enormous burden
of switching established code to be concurrent (plus maintaining the
necessarily-more-complex concurrent code), it'd be really hard to justify
sub-translation-unit concurrency in the frontend.