GCC "-fparallel-jobs" up to ~1.9x speedup when compiling individual files in parallel

[Germano Massullo]

I think soon we will have a big boost in Koji performances thanks to
Giuliano Belinassi and his work on addressing GCC parallelization
bottlenecks. According to Phoronix, compiling individual files in
parallel may have up to ~1.9x speedup:
https://www.phoronix.com/scan.php?page=news_item&px=GCC-fparallel-job...

[Daniel P. Berrangé]

On Sat, Aug 22, 2020 at 12:53:24PM +0200, Germano Massullo wrote:
>  I think soon we will have a big boost in Koji performances thanks to
>  Giuliano Belinassi and his work on addressing GCC parallelization
>  bottlenecks. According to Phoronix, compiling individual files in
>  parallel may have up to ~1.9x speedup:
>  https://www.phoronix.com/scan.php?page=news_item&px=GCC-fparallel-job...
AFAICT, that is referring to parallelizing single file compilation to
make use of multiple cores. That's only useful if the other cores on
your host are otherwise idle.

In koji we use parallel make (or equivalent) so that multiple files
are compiled in parallel. Thus most of the time all cores will be fully
utilized.

IOW, don't get too excited by the x1.9 speedup claim. I doubt we'll
see that in kojki except in niche scenarios where a project's build
is bottlenecked by a serialization point on compiling one file.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[Jeff Law]

On Tue, 2020-08-25 at 10:17 +0100, Daniel P. Berrangé wrote:
>  On Sat, Aug 22, 2020 at 12:53:24PM +0200, Germano Massullo wrote:
>  > I think soon we will have a big boost in Koji performances thanks to
>  > Giuliano Belinassi and his work on addressing GCC parallelization
>  > bottlenecks. According to Phoronix, compiling individual files in
>  > parallel may have up to ~1.9x speedup:
>  > https://www.phoronix.com/scan.php?page=news_item&px=GCC-fparallel-job...
>  
>  AFAICT, that is referring to parallelizing single file compilation to
>  make use of multiple cores. That's only useful if the other cores on
>  your host are otherwise idle. 
Correct.  It's going to be most helpful when
there's a large TU with many
functions and there's nothing else going on to keep the cores/threads busy.

>  
>  In koji we use parallel make (or equivalent) so that multiple files
>  are compiled in parallel. Thus most of the time all cores will be fully
>  utilized. 
RIght.  Except for those which override the parallel make flags because
they're
missing dependencies.  But these are very much the exception, not the rule.

>  IOW, don't get too excited by the x1.9 speedup claim. I doubt
> we'll
>  see that in kojki except in niche scenarios where a project's build
>  is bottlenecked by a serialization point on compiling one file. 
Right.  Also note
the code isn't accepted upstream yet.  I strongly suspect
there's going to be more work required to make what Guiuliano's work ready for
prime time.

On a positive note, my understanding from talking to Giuliano last year was that
he was trying to parallelize GCC itself which I thought was untractable for a
student project given the amount of unprotected global state.  Instead I think he
ended up using the LTO partitioning code to find TU split points, then feeds
those into distinct fork/exec'd copies of GCC which is a much simpler problem to
solve.

So there may be uses for his work.  Obviously the GCC team will continue to
monitor and if/when we think there's a change we should make for Fedora to
exploit Giuliano's work we'll propose it.

jeff
>

[Jakub Jelinek]

On Tue, Aug 25, 2020 at 08:17:57AM -0600, Jeff Law wrote:
>  > IOW, don't get too excited by the x1.9 speedup claim. I
> doubt we'll
>  > see that in kojki except in niche scenarios where a project's build
>  > is bottlenecked by a serialization point on compiling one file.
>  Right.  Also note the code isn't accepted upstream yet.  I strongly suspect
>  there's going to be more work required to make what Guiuliano's work ready for
>  prime time.
>  
>  On a positive note, my understanding from talking to Giuliano last year was that
>  he was trying to parallelize GCC itself which I thought was untractable for a
>  student project given the amount of unprotected global state.  Instead I think he
>  ended up using the LTO partitioning code to find TU split points, then feeds
>  those into distinct fork/exec'd copies of GCC which is a much simpler problem to
>  solve.
>  
>  So there may be uses for his work.  Obviously the GCC team will continue to
>  monitor and if/when we think there's a change we should make for Fedora to
>  exploit Giuliano's work we'll propose it. 
Yeah.  E.g. in the GCC tree itself we have a couple of large generated
sources that are known to be parallelization bottlenecks (even if they are
started to be compiled as soon as possible, they finish often last), and so
instead of enabling it for everything which probably would only slow things
down, it might be useful to enable this only for *-match.c, selected insn-*.c
and perhaps the libsanitizer asan_interceptors.cpp.

	Jakub