8 ms·

Now let's compare performance after implementing 2 decades worth of missing program optimization techniques (edit: downvotes? I'm sorry to ruin the romanticizi

Now let's compare performance after implementing 2 decades worth of missing program optimization techniques (edit: downvotes? I'm sorry to ruin the romanticizing, but surely it should come as no surprise that these old compilers aren't fast due to black magic)

melling 6y ago
I only want that on a few of my builds. Most days I could be happy with 1 second builds. Considering that I don’t have a million lines of code, I think 100,000 lines of code a second should cover it.
- Gibbon1 6y ago
  My prat comment about C++ is the compiler writers are stuck in a trap. Because compiling C++ is slow they add optimizations to the compiler (also written in C++) to make the code faster. But that makes the compiler even slower. So they add even more optimizations to the compiler to make it run faster...
  - higerordermap 6y ago
    No. C++ is slow to compile due to some historical decisions like preprocessor. But the C++ standard committee has come to rely on optimizing compilers with powerful inliners and optimizers, to implement new "zero cost" [sic] abstractions as convoluted template libraries with lot of corner cases (neglecting incomprehensible error messages and debug build performance as well). Efficiently compiling C++ effectively __requires__ a top notch optimizer because of the disconnect between standards committee and implementers. Moreover, relying on optimizers often results in non obvious performance traps. The stupidity of standards committee and their sheer insistence on nothing but being able to sell more books every years is why even modern C++ is such a horrible development experience.
    - ncmncm 6y ago
      This description is absolutely at variance with the reality of C++ Standard activity. Compiler and Standard Library implementers are intimately involved in all phases of standardization. Book sales have much less effect than authors would like; they would prefer many fewer changes. Furthermore, C++ coding experience improves markedly with each new Standard, released on a 3-year cadence. C++20 is nicer than '17, which is nicer than '14, which is nicer than '11, which is much nicer than '03, which is a little nicer than '98. '23 will be nicer than all of them.
      - higerordermap 6y ago
        Eh? I don't understand which kind of involvement. I occassionally read C++ proposals, and also read blogs from some very good C++ programmers. The "everything implemented as library" pattern so pervasive in new C++ releases is not doing any good to the language. All those are half-baked implementation of what exists as a simple orthogonal language feature in languages like OCaml. The "implement as library" sentiment has gone too far that it hurts, among other things: * Debug build performance * Compilation times (a big thing) * Quality of error messages * Reliance on not-so-reliable optimizations, often causing performance regressions (there are many instances of this happening). Even if clang / gcc developers are involved, probably they don't bother about 1000::template shittery because their compilers have already got comparable quality inliners, and it is hard for a competition to surface here. Or they might bother but can't be sufficiently involved into the C++ standard committee crowd. > Furthermore, C++ coding experience improves markedly with each new Standard, released on a 3-year cadence. And don't tell me my knowledge of last standard is obsolete and I have to read the new shiny c++ book to learn Modern C++. Another consequence is the scarcity of freely available resources accessible to students, due to rapid change.
        ncmncm 6y ago
        You may invent whichever activities suit your imagination, but I can state with absolute authority of decades' experience that they are utterly divorced from any objective reality. Most people learning the newer features of C++ do not turn first to books, but rely on cppreference.com, blog posts, and on conference videos easily found on youtube. The best way to learn the new features is to use them.
psykotic 6y ago
For C compilers like gcc and clang it's comparing against -O0. Anyway, there are two issues with that long-term trend in compiler design from my perspective. The first is that the optimizing path is too slow and they don't offer an intermediate point on the Pareto frontier that reflects my trade-off preferences because too much of the slowness is architectural in origin. But the second and much worse problem is that the non-optimizing path is barely any faster. You can't make a fast non-optimizing or somewhat-optimizing compiler by taking the architecture of a heavyweight optimizing compiler and setting some internal flags and skipping a few passes. You need the fast compilation path to completely dictate the architecture from end to end, with the constraint of still supporting optimizing backends, and you need a development culture that treats the fast path's performance as inviolate and sacrosanct.
tomjen3 6y ago
I don't care about optimizations, I just want it to compile fast so that I can test if my new code solves the bug. Before final release to QA, we can run the compiler over night on the CI and get a hyper-optimized build. Or not, since it is a compiled language it will likely be fast enough anyway.

melling 6y ago

I only want that on a few of my builds. Most days I could be happy with 1 second builds. Considering that I don’t have a million lines of code, I think 100,000 lines of code a second should cover it.

Gibbon1 6y ago
My prat comment about C++ is the compiler writers are stuck in a trap. Because compiling C++ is slow they add optimizations to the compiler (also written in C++) to make the code faster. But that makes the compiler even slower. So they add even more optimizations to the compiler to make it run faster...
- higerordermap 6y ago
  No. C++ is slow to compile due to some historical decisions like preprocessor. But the C++ standard committee has come to rely on optimizing compilers with powerful inliners and optimizers, to implement new "zero cost" [sic] abstractions as convoluted template libraries with lot of corner cases (neglecting incomprehensible error messages and debug build performance as well). Efficiently compiling C++ effectively __requires__ a top notch optimizer because of the disconnect between standards committee and implementers. Moreover, relying on optimizers often results in non obvious performance traps. The stupidity of standards committee and their sheer insistence on nothing but being able to sell more books every years is why even modern C++ is such a horrible development experience.
  - ncmncm 6y ago
    This description is absolutely at variance with the reality of C++ Standard activity. Compiler and Standard Library implementers are intimately involved in all phases of standardization. Book sales have much less effect than authors would like; they would prefer many fewer changes. Furthermore, C++ coding experience improves markedly with each new Standard, released on a 3-year cadence. C++20 is nicer than '17, which is nicer than '14, which is nicer than '11, which is much nicer than '03, which is a little nicer than '98. '23 will be nicer than all of them.
    - higerordermap 6y ago
      Eh? I don't understand which kind of involvement. I occassionally read C++ proposals, and also read blogs from some very good C++ programmers. The "everything implemented as library" pattern so pervasive in new C++ releases is not doing any good to the language. All those are half-baked implementation of what exists as a simple orthogonal language feature in languages like OCaml. The "implement as library" sentiment has gone too far that it hurts, among other things: * Debug build performance * Compilation times (a big thing) * Quality of error messages * Reliance on not-so-reliable optimizations, often causing performance regressions (there are many instances of this happening). Even if clang / gcc developers are involved, probably they don't bother about 1000::template shittery because their compilers have already got comparable quality inliners, and it is hard for a competition to surface here. Or they might bother but can't be sufficiently involved into the C++ standard committee crowd. > Furthermore, C++ coding experience improves markedly with each new Standard, released on a 3-year cadence. And don't tell me my knowledge of last standard is obsolete and I have to read the new shiny c++ book to learn Modern C++. Another consequence is the scarcity of freely available resources accessible to students, due to rapid change.
      - ncmncm 6y ago
        You may invent whichever activities suit your imagination, but I can state with absolute authority of decades' experience that they are utterly divorced from any objective reality. Most people learning the newer features of C++ do not turn first to books, but rely on cppreference.com, blog posts, and on conference videos easily found on youtube. The best way to learn the new features is to use them.

psykotic 6y ago

For C compilers like gcc and clang it's comparing against -O0. Anyway, there are two issues with that long-term trend in compiler design from my perspective. The first is that the optimizing path is too slow and they don't offer an intermediate point on the Pareto frontier that reflects my trade-off preferences because too much of the slowness is architectural in origin. But the second and much worse problem is that the non-optimizing path is barely any faster. You can't make a fast non-optimizing or somewhat-optimizing compiler by taking the architecture of a heavyweight optimizing compiler and setting some internal flags and skipping a few passes. You need the fast compilation path to completely dictate the architecture from end to end, with the constraint of still supporting optimizing backends, and you need a development culture that treats the fast path's performance as inviolate and sacrosanct.

tomjen3 6y ago

I don't care about optimizations, I just want it to compile fast so that I can test if my new code solves the bug. Before final release to QA, we can run the compiler over night on the CI and get a hyper-optimized build. Or not, since it is a compiled language it will likely be fast enough anyway.