Announcement

Collapse
No announcement yet.

GCC 5 Is Compiling Faster, But Still Falls Short Of Clang

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • GCC 5 Is Compiling Faster, But Still Falls Short Of Clang

    Phoronix: GCC 5 Is Compiling Faster, But Still Falls Short Of Clang

    On Saturday I posted some LLVM Clang vs. GCC benchmark results of the packages found in Fedora 21 on an Intel Xeon system, but how does the performance compare if building the latest snapshot of GCC 5? Fortunately, I have some interesting GCC 5.0 benchmarks to make this Sunday morning interesting for compiler fans...

    http://www.phoronix.com/vr.php?view=MTgzNDE

  • Michael_S
    replied
    Originally posted by pal666 View Post
    you can force your views on your project or organization. language has nothing to do with it.
    Someone can force their views on their project or organization. They can't force their views on the entire ecosystem. That's fine when you write your entire stack in-house, but as soon as you pull in third party code you still have a problem.

    With Go and Python, you can grab open source code from anywhere and use snippets, hook into libraries, and so forth with the same idioms you'll have in your in-house or in-project code. And if your project is open source, other people in the same ecosystem can grab it and use it just as easily. I'd say that's essential reason that Python, which by most metrics is a pretty unremarkable language, is so popular.

    Even the Perl community has come to recognize the value of having a smaller number of coding coventions: the complete language redesign for Perl6 - which admittedly may never get off the ground - abandons the famous Perl TIMTOWTDI motto ("There Is More Than One Way To Do It") because of this exact problem with Perl 5. Now again, Perl6 does not, as far as I know, have a full implementation or much adoption. But I think that's due to other problems, not the move towards fewer syntactic oddities than Perl 5.

    Leave a comment:


  • pal666
    replied
    Originally posted by Michael_S View Post
    I completely disagree. The awesome thing about Python's syntax rules is that it makes reading almost anybody's Python a simple thing to do.

    Look at Perl and C++. Both are awesome languages. Both have tons of features. Both can do an incredible amount of things. Both can be written in clean, clear, easy-to-read ways. But to work professionally with Perl or C++, you have to be prepared to deal with outrageous abuses of Perl's implicit variables and syntax quirks and insane uses of the C++ preprocessor and a hundred other combinations of bizarre code.

    Forcing one convention in a development language might be limiting for each individual but it's better for the community.
    you can force your views on your project or organization. language has nothing to do with it.

    Leave a comment:


  • Michael_S
    replied
    Originally posted by curaga View Post
    I count "where to put the brace" as part of indent style, though maybe I should have said "GNU coding style" instead. Any language where the FAQ and interviews clearly show the designers' attitude to be "because fuck you, that's why" is a bad language. Compare with Stroustrup: "I felt I don't have the right to force my views on the developers". That right there is a huge, huge difference.

    Incidentally, that is also why I hate Python.
    I completely disagree. The awesome thing about Python's syntax rules is that it makes reading almost anybody's Python a simple thing to do.

    Look at Perl and C++. Both are awesome languages. Both have tons of features. Both can do an incredible amount of things. Both can be written in clean, clear, easy-to-read ways. But to work professionally with Perl or C++, you have to be prepared to deal with outrageous abuses of Perl's implicit variables and syntax quirks and insane uses of the C++ preprocessor and a hundred other combinations of bizarre code.

    Forcing one convention in a development language might be limiting for each individual but it's better for the community.

    Leave a comment:


  • curaga
    replied
    I count "where to put the brace" as part of indent style, though maybe I should have said "GNU coding style" instead. Any language where the FAQ and interviews clearly show the designers' attitude to be "because fuck you, that's why" is a bad language. Compare with Stroustrup: "I felt I don't have the right to force my views on the developers". That right there is a huge, huge difference.

    Incidentally, that is also why I hate Python.

    Leave a comment:


  • Zan Lynx
    replied
    Originally posted by curaga View Post
    Go certainly compiles fast, but that evens out in developer convenience because writing it is a PITA. Imagine writing C++ where the compiler would only let it build if you used the GNU indent style.
    Go doesn't care about the indent style. You may be thinking about some of the requirements it has because it doesn't use semicolons to end statements. It does need to know where the line ends and for that it requires that braces, commas, quotes, etc, be in the correct positions. This is no different than Python, but unlike Python you can indent however you want and use tabs or spaces in any combination.

    Go does have an official indent style and if you run "go fmt" it will rewrite your code into the official style. I appreciate this because it ends forever any arguments about where to put the braces and how many spaces code should have. Just run "go fmt" and the argument is over.

    Leave a comment:


  • Guest's Avatar
    Guest replied
    Originally posted by -MacNuke- View Post
    So GCC is useless for development... But really... GCC is not THAT much faster than clang. Just a litte if you compile for one CPU...
    I don't deny. I am aware Clang/LLVM has some advantages over GCC.

    Leave a comment:


  • Michael_S
    replied
    Originally posted by curaga View Post
    Go certainly compiles fast, but that evens out in developer convenience because writing it is a PITA. Imagine writing C++ where the compiler would only let it build if you used the GNU indent style.
    I haven't used Go in anger. I only played with D, but so far I like it a lot.

    Leave a comment:


  • curaga
    replied
    Go certainly compiles fast, but that evens out in developer convenience because writing it is a PITA. Imagine writing C++ where the compiler would only let it build if you used the GNU indent style.

    Leave a comment:


  • Michael_S
    replied
    Originally posted by Veerappan View Post
    And honestly, it doesn't matter what project I'm working on, or even the language I'm doing it in. When trying to develop software that requires iterating repeatedly through the compile/deploy/test process, you ALWAYS want a faster compiler. Faster built binaries is nice when you want to send something to a user/customer, but until then, speed of compilation is always more important than the performance of the produced binaries. Really.

    I do this 40+ hours a week during my day job, and then some more for fun in the evenings, and that's one of the major lessons that I learned very early on. Time is money, and a developer having to wait on a compile to finish is a waste of both.
    This is the selling point of Google's Go language and Walter Bright's D language - they're in the same family as C or C++, but they both compile substantially faster. Of course, Go has garbage collection so if you need manual memory management it won't work. D has garbage collection by default but you can use malloc and free if you want. Right now the D standard library uses garbage collection, but the main language designers are exploring changing that so that you can switch between garbage collection and manual memory management as you wish for the standard libary.

    I don't know how Rust fares on compilation speed.

    ... of course, none of this is useful to you if you've got a colossal existing codebase in C or C++.

    Leave a comment:

Working...
X