Parallelizing GCC's Internals Continues To Be Worked On & Showing Promising Potential

[phoronix]

Phoronix: Parallelizing GCC's Internals Continues To Be Worked On & Showing Promising Potential

One of the most interesting Google Summer of Code projects this year was the student effort to work on better parallelizing GCC's internals to deal with better performance particularly when dealing with very large source files. Fortunately -- given today's desktop CPUs even ramping up their core counts -- this parallel GCC effort is being continued...

http://www.phoronix.com/scan.php?page=news_item&px=Parallelize-GCC-Cauldron-2019

[jacob]

1.6x speedup is something that users will certainly notice. This is great news; compilation speed is one area where GCC has always been lagging behind Clang.

[ms178]

Welcome in the multi-core world, GCC. I don't know if I should rant about software not making good use of already available hardware ressources or compliment the GSoC developer to do something meaningful for a lot of people with his project which should have been done by more seasoned GCC developers in the first place a long time ago. I guess I should do both. So congrats on this achievement!

[lucasbekker]

1.6x speedup is something that users will certainly notice. This is great news; compilation speed is one area where GCC has always been lagging behind Clang.

Is clang parallelized in the same way that this GSoC project is pursuing for GCC?

[carewolf]

1.6x speedup is something that users will certainly notice. This is great news; compilation speed is one area where GCC has always been lagging behind Clang.

It has been years since clang was faster than gcc. They ended up being equally fast around the time the optimizations started being comparable.

[discordian]

Outside of linking, if you compile 4 files on 4 cores you get a near 4 times speedup.
Compiling 1 file 2.52 times faster doesn't sound so promising, if those 4 cores could otherwise give you a larger speedup?

[rene]

1.6x speedup is something that users will certainly notice. This is great news; compilation speed is one area where GCC has always been lagging behind Clang.

well, a decade ago clang was faster, but nowadays LLVM+clang became so large, it is pretty hard to even build them in an optimised enough way for clang to be faster: https://www.youtube.com/watch?v=aZGV_7TfKy8

[pyler]

Lol, yt’s guy is using clang rc2 self build which is of course slower than tuned official releases (which are PGOed and LTOed heavily).

[Venemo]

How does this affect make's -j argument? If every GCC process can now use 4 threads, does that mean that it's better to use fewer jobs with make now?

[tchiwam]

Like I said before, a load aware gcc like make -l would be more beneficial...
Or then keep all threads on one core, that makes it 4 threads per core on the new EPYC