Re: GCC Optimisation, Part 0: Introduction

[Basile Starynkevitch <basile at starynkevitch dot net>]

On Wed, Apr 27, 2011 at 04:06:48PM +0300, Dimitrios Apostolou wrote:
> Hello list,
> 
> I am Dimitris (IRC nick: jimis), and this summer I will be working
> on optimising GCC, under the umbrella of Google Summer of Code. My
> proposal involves profiling and benchmarking in order to detect
> hotspots in both CPU and memory usage, and improving or rewriting
> the respective parts. By combining many partial improvements in all
> layers of GCC, hopefully by the end of summer a significant gain
> will show up.

Please don't forget an essential factor: keep the GCC code maintainable, or
even improve its understandability and maintainability. In my opinion,
having the GCC code be more easier to understand and to improve is at least
as important than improving its performance by a few percents. Making a
heavy patch which sometimes improve the compilation time by a few percents
but which makes the code harder to maintain is in my opinion a mistake.
Remember that GCC developers and code reviewers are a scare resource (much
more expensive than the hardware used to run GCC).


> Here are some areas I'll look closer to, as shown by some early profiling
> I performed: 
>  * hash tables (both htab and symtab)

There is probably a lot of tuning possible around GCC hash tables. However,
I would imagine that tuned performance might depend on the particular
hardware running the so modified GCC. And C++ is becoming an acceptable
programming language inside GCC. So replacing current C hashtables by some
fancier C++ collections might be considered (but I have no idea if this will
be a performance win, perhaps no!; it could be a readability win.).

Perhaps some hashtables are used to associate data to important structures
(like gimple) which are difficult to change. Perhaps if you have strong
measurements that adding information inside gimple instead of keeping an
hashtable for it you might be able to remove some hashtables, but this is
difficult, since GCC essential data types have been very hand-optimized.

> * ggc_internal_alloc_stat() or maybe implementing proper memory
> management instead of garbage collection, for hottest callers

My opinion is that a garbage collector is (or can become) a proper memory
manager. I am not sure at all that replacing GTY-ed data inside GCC by
manually malloc-ed & free-d data will give a performance gain. And I am
pretty convinced that it will bring a huge maintenance nightmare: you might
be able to improve some performance, but the modified code will be much
harder to maintain. Manually free-ing memory in a five million lines
software is a nightmare (especially inside a compiler dealing with circular
and complex data structures in memory).

If you really want to switch back to manual memory management, please be
sure to make changes which will be easy to revert.

I believe that the current GCC garbage collector could be improved (but that
is very hard work!)




> Of course more areas for improvement will hopefully show up with
> further profiling. However at the present time I would appreciate
> the help of the community in the following areas:

An important question to address is what should you ignore. You cannot deal
with all the complexity of GCC. You need to make choices and to focus your
work. You need to know what you should not look into!

> 
> * what documentation should I read for understanding GCC, from a
> high level, architectural point of view?

Understand the passes, the pass manager, important GCC internal
representations (in particular GIMPLE, TREE, ...). Run gcc with the
-fdump-tree-all options on example code to understand what is happenning.

 
Good luck.

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***