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

  • 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:


  • Veerappan
    replied
    Originally posted by pal666 View Post
    don't enable optimizations during development ffs

    stop using macos then. linuxes have modern gcc versions, which have better error reporting and better intergation with their dev environment
    Stop using MacOS? What does that have to do with my use case?

    For the people who are saying, "Don't use optimizations", I just ran a full rebuild of LLVM using both GCC (4.9.1) and Clang (3.6svn)... Guess what, not only does GCC get faster without optimizations, but SO DOES LLVM.

    Un-optimized Configuration: CFLAGS=-O0 ../llvm/configure --enable-assertions=no --with-python=/usr/bin/python2 --enable-shared --enable-targets=x86,r600 --prefix=/usr/local --with-optimize-option=-O0

    Followed by: time CFLAGS=-O0 make -j6

    And then I did one with the default optimization level. Note: These are with debug symbols/assertions in the build binaries DISABLED. The compile times get proportionally longer with those enabled.

    LLVM/Clang 3.6svn -O0 Default Optimization Level
    real 10m36.558s 13m36.660s
    user 54m21.323s 68m40.130s
    sys 2m39.728s 3m58.685s
    GCC 4.9.1
    real 16m40.785s 20m36.600
    user 86m35.194s 104m15.452
    sys 6m10.038s 8m7.835s
    So 10m32s for an -O0 clang-based build vs 16m40s for GCC -O0. That's a significant time savings by just swapping out the compiler. Keep in mind that debug builds with assertions intact can be significantly slower, and that time savings can grow.

    For reference, the hobby project that I'm working on is the OpenCL built-in library implementation for Clover and the r600g/radeonsi gallium drivers in my GNU/Linux distro of choice.

    In order to get meaningful work done, I often end up pulling changes from upstream llvm and then have to compile those changes so that I can then rebuild libclc and then fairly often I end up rebuilding mesa. Those upstream llvm changes often include new instructions that have been implemented for the Evergreen or SI architectures (i.e. necessary updates in order to then use those instructions in the library functions). And given that I only have an hour or so maybe 1 or 2 nights a week, spending 20+ minutes rebuilding software before I can really get started has a large impact on the amount I can get done, and 20 minutes is usually on the short end. Adding in assertions and full debugging capabilities to the built binaries does not help compile times at all.

    All of this is done on machines running some variant of GNU/Linux, usually running the latest kernel/X/mesa/llvm (most built from git/svn).

    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.

    Leave a comment:

Working...
X