This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC - Alternatives to gengtype
On Sat, Nov 17, 2012 at 12:35 AM, Basile Starynkevitch
<basile@starynkevitch.net> wrote:
> On Fri, Nov 16, 2012 at 07:44:12PM -0800, Xinliang David Li wrote:
>> >
>> >
>> > My strong belief is that a compiler project as gigantic as GCC needs some kind
>> > of garbage collection
>>
>> Can you name another compiler written in C/C++ using GC ? :)
>
> First, C or C++ is not the best language to write a compiler in, and actually GCC is not entirely
> hand written in C or C++; As http://www.cse.iitb.ac.in/grc/ (i.e. the great work of Uday Khedker and colleagues, India) demonstrate, GCC is a framework with a significant amount of meta-programs, i.e. specialized C code generators. So GCC is not entirely hand-written in C or C++
>
> And several compilers or static analyzers of C programs have a garbage collected implementation,
> in particular those written in Ocaml: the frama-c.com static analyzer and the CompCert certified compiler.
My main point is that other main open source compilers like
clang/llvm, open64 and some main commercial compilers I know do not
use GC, which proves that GC is not a must for a compiler to be easy
to work with or to be a good open code analysis framework.
>
> I know people working on these projects quite well (Frama-C is developped by my current colleagues at CEA, LIST; CompCert is leaded by Xavier Leroy, and I worked one year in his Cristal team in 2004).
> They all say that the garbage collector of Ocaml is an essential piece.
>
> And when I measure with -ftime-report some long, optimized, compilation by GCC I see that GC takes
> a small fraction (often less than 5 or 10%) of the whole time.
For an optimized build, 5-10%, in my opinion is a lot. Besides,
without explicit memory managent, the memory footprint and data
working set tends to be larger and this contributes the compile time
to all the other passes indirected due to increased paging activities,
TLB misses, and d-dache misses.
>
> And if we switch to memory pool, that will take time also. Actually, if every dynamic memory allocation
> in GCC was done with malloc+free or new+delete, we may have issues in measuring them
> (because libstdc++ might not have hooks to measure that)
> but they won't be free.
tcmalloc (http://goog-perftools.sourceforge.net/doc/tcmalloc.html) is
a very good allocator. We have measured before that it beats system
malloc and other open source allocators in performance even for single
threaded applications (SPEC, SPEC06).
Besides it provide very good support for heap profiling and sampling,
and supports heap check such leaks.
David
>
> Regards.
>
> --
> 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} ***