Re: Alternative C compilers on x86_64 Linux?

On 28/09/2016 18:16, BartC wrote:
> On 28/09/2016 00:36, rugxulo@gmail.com wrote:
>
>> TCC hasn't had a release in recent years either. It's fast because
>> it does everything in one pass, and it does include it's own
>> assembler and linker. It doesn't optimize well, though.


> (And because this is not for C, I can use all of that throughput instead
> of wasting it repeatedly compiling the same header files.)


> These fast compilers (the byte-code one I've completed, and the possible
> native code one) will only compile an entire project at once.


> The C
> language does put some obstacles in the way (the same header needs to
> processed for the 50th time in case something comes out different), but
> I think there is plenty that can be done.
>
> TCC does a good job, but it's a shame about the code generation. (My own
> native code compiler has a naive non-optimising code generator but is
> still much better than TCC's code.)
>
> (One one test of the fast compiler, my own code can manage 800Klps.
> Converting to C intermediate code then putting it through gcc -O3 gets
> it up to 1Mlps. But compiling with TCC gets it down to 350Klps (TCC is
> not good with switch statements). Not so bad, but still ...)


> [Back when I was publishing the Journal of C Language of Translation,
> people did some interesting
> stuff with C header files, saving a precompiled version for the usual
> case that subsequent
> runs don't change any preprocessor stuff that would affect the code. -John]


Yes, George Neuner's post has a link to how gcc's precompiled headers
can be used. Maybe, if a compiler is already sluggish, they can make a
difference.


But I don't know if they would help to get the fastest speeds: loading
and decoding a precompiled header file doesn't sound that much less work
to me than just parsing a normal header anyway.


Most C compilers seem to support multiple C source files as input. This
is similar to my scheme of compiling multiple sources one after the
other. So if the input to a compiler looks like this:


        gcc -c A.c B.c C.c


where each of A, B and C include the same header file H.h, then once H.h
has been processed for A.c, the results of that (symbol tables and so
on) could be re-used for B and C without needing to process either H.h
or H.pch again.


Of course, a compiler can be so slow, and/or a header can be so large,
than even processing H.h /once/ can be a bottleneck! Then maybe
precompiled headers might be an easier option than making the compiler
itself faster, which is never going to happen in the case of gcc.


(I can tokenise C source code at some 10M lines per second on my PC
(this excludes symbol table lookups; just raw tokenising). But gcc might
process the same source at only 10K lines per second, even excluding
dealing with headers.


That's around a thousand times slower. People like to excuse it by
pointing to its superior code generation as the reason, but I think
that's only a small part of it. For a start, you can turn off
optimisation and it's still pretty slow. I think it's just too big and
complex.)


--
Bartc
[Tokenizing 10M lines/sec is pretty impressive. In compilers that don't do heavy optimization
the lexer is usually the slowest part since it's the only thing that has to touch each
character of the source code individually. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.