Clang comparison page

Hi All,

I whipped up this page to help answer some commonly asked questions about how clang compares to other compilers:
http://clang.llvm.org/comparison.html

Comparisons like this are often very sensitive so please let me know if I am saying anything unfair/non-objective, or am forgetting anything.

Thanks!

-Chris

I have no stake in Elsa, and I've never used it, but my thoughts:

Elsa is not a compiler, so I'm not sure that the following point is appropriate:

"Elsa does not support native code generation."

Also the following point seems to be a political (and practical,
granted) rather than a technical criticism:

"The Elsa community is extremely small and major development work
seems to have ceased in 2005, though it continues to be used by other
projects (e.g. Oink). Clang has a vibrant community including
developers that are paid to work on it full time."

A small community is only a problem for those who do not have the
resources to contribute to the project themselves. Since as you say
Clang has plenty of resources, then I think Elsa could be adopted as
the C++ parser if there were no technical issues, or if the cost of
resolving the technical issues was less than the cost of a
reimplementation.

I just thought these two points may be unfair given the scope of this
doc is stated as "We restrict the discussion to very specific
technical points to avoid controversy where possible." Maybe its this
statement which should be changed, instead.

I have no stake in Elsa, and I've never used it,

Your opinion is welcome! I've made some edits in response to your feedback:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20071210/003255.html

but my thoughts:

Elsa is not a compiler, so I'm not sure that the following point is appropriate:

"Elsa does not support native code generation."

Right. This gets to the "differences in goals" aspect of the comparison. I should mention explicitly at the top that whether you consider one of these to be a big deal depends on what your personal goals are. I clarified this in the intro.

Also the following point seems to be a political (and practical,
granted) rather than a technical criticism:

"The Elsa community is extremely small and major development work
seems to have ceased in 2005, though it continues to be used by other
projects (e.g. Oink). Clang has a vibrant community including
developers that are paid to work on it full time."

A small community is only a problem for those who do not have the
resources to contribute to the project themselves.

I mention this because it is a very big disadvantage for a lot of people: it basically means that if you hit a bug in Elsa, you have to fix it yourself or just work around it. In clang, you can report the bug and it quite possible someone will fix it for you. This means that even if you *could* fix the bug yourself, you might find out that you don't have to, meaning you get more done in less of *your* time.

Since as you say
Clang has plenty of resources,

There is no such thing as "plenty" :slight_smile:

then I think Elsa could be adopted as
the C++ parser if there were no technical issues, or if the cost of
resolving the technical issues was less than the cost of a
reimplementation.

If a reader has the ability to reimplement an entire C++ compiler from scratch and has the desire to do so, presumably they wouldn't be looking at either clang or elsa :). The rest of the bullets explain technical problems that prevent clang from adopting Elsa.

I updated the bullet to try to make it more clear what I'm getting at, please take a look and let me know if it helps.

I just thought these two points may be unfair given the scope of this
doc is stated as "We restrict the discussion to very specific
technical points to avoid controversy where possible." Maybe its this
statement which should be changed, instead.

I think it is true that the Elsa community is "extremely small", do you disagree with that part?

-Chris

Chris Lattner wrote:

Hi All,

I whipped up this page to help answer some commonly asked questions about how clang compares to other compilers:
http://clang.llvm.org/comparison.html

Comparisons like this are often very sensitive so please let me know if I am saying anything unfair/non-objective, or am forgetting anything.
  

Hi Chris,
I think this is a fairly fair comparison. Would you mind mentioning my oink fork, pork? It addresses some of the shortcomings that you mentioned. The main differences between oink and pork are that
* Integrates with MCPP to allow to "accurately map from a source location in the AST to the original position before preprocessing.". Several Mozilla-specific refactoring tools are provided
* Is actively developed (some full-time developers)
* Provides a scriptable static analysis tool, Dehydra

Cheers,
Taras

Sure, since Pork is still evolving, I won't go into too much detail. How about including this at the end:

     <p>Note that there is a fork of Elsa known as "Pork". It addresses some of
        these shortcomings by loosly integrating a preprocessor. This allows it
        to map from a source location in the AST to the original position before
        preprocessing, providing it better support for static analysis and
        refactoring. If you are interested, please see the Pork page.</p>

From your blog, my understanding is that the preprocessor really isn't integrated: it emits a .i file and a log of expansion information (embedded into the source as comments?) which is then parsed by Elsa. This is right?

-Chris

Chris Lattner wrote:

Chris Lattner wrote:

Hi All,

I whipped up this page to help answer some commonly asked questions about how clang compares to other compilers:
http://clang.llvm.org/comparison.html

Comparisons like this are often very sensitive so please let me know if I am saying anything unfair/non-objective, or am forgetting anything.

Hi Chris,
I think this is a fairly fair comparison. Would you mind mentioning my oink fork, pork? It addresses some of the shortcomings that you mentioned. The main differences between oink and pork are that
* Integrates with MCPP to allow to "accurately map from a source location in the AST to the original position before preprocessing.". Several Mozilla-specific refactoring tools are provided
* Is actively developed (some full-time developers)
* Provides a scriptable static analysis tool, Dehydra

Sure, since Pork is still evolving, I won't go into too much detail. How about including this at the end:

    <p>Note that there is a fork of Elsa known as "Pork". It addresses some of
       these shortcomings by loosly integrating a preprocessor. This allows it
       to map from a source location in the AST to the original position before
       preprocessing, providing it better support for static analysis and
       refactoring. If you are interested, please see the Pork page.</p>

From your blog, my understanding is that the preprocessor really isn't integrated: it emits a .i file and a log of expansion information (embedded into the source as comments?) which is then parsed by Elsa. This is right?

Yes, MCPP embeds a macro expansion log into comments. I chose the "loose" integration in hopes that any projects that need to undo the preprocessor can reuse this instead of writing a preprocessor from scratch. Additionally, having annotated macro expansion is handy for debugging anything to do with macro expansions.

Your summary works for me.

Thanks,
Taras

From your blog, my understanding is that the preprocessor really isn't integrated: it emits a .i file and a log of expansion information (embedded into the source as comments?) which is then parsed by Elsa. This is right?

Yes, MCPP embeds a macro expansion log into comments. I chose the "loose" integration in hopes that any projects that need to undo the preprocessor can reuse this instead of writing a preprocessor from scratch. Additionally, having annotated macro expansion is handy for debugging anything to do with macro expansions.

Yeah, but the (compile-time) performance must be terrible :slight_smile:

Your summary works for me.

Done, thanks!

-Chris