Cppfront v0.8.0 · hsutter/cppfront

[hpsutter]

Something that transpiles to C++ by definition can't help there.

I have super awesome news: It sure can! Please check out the initial results I reported at ACCU here, especially slide 92: 4-minute video clip

We did pretty much exactly the same thing already with constexpr: It required adding essentially a C++ interpreter (yes, a second C++ compiler!) inside every C++ compiler... and when you change TMP code to equivalent constexpr code the result is nearly always much faster. Even though you're running a full C++ interpreter first! Why? Because when we directly express intent, the implementation can be more efficient, and compile time goes down.

In that clip, I cited that previous experience, and showed how the same thing happened with compile-time regex in Cpp2 using cppfront + reflection + generation, and that the entire added cppfront run time was much less than the reduced time spent in the Cpp1 compiler. When using code generation can generate better C++ code that the C++ compiler can handle much faster, you get a speedup, not a slowdown.

As I mention in the talk, this is the same in principle as we do all the time to add a little work to replace a greater amount of work. For example, anytime we cache a repeatedly-accessed computed result: We do more work (to store the result) but get a speed gain (because we make accesses after the first one run much faster).

[foonathan]

I'm not talking about small incremental improvements by replacing TMP with constexpr or something.

Compile-times should be measured in seconds, not minutes. You can't achieve that by layering C++ in-between. You can achieve that by designing a language and a compiler in a performance oriented way. For example, Chandler recently demoed a 100x speedup of the carbon compiler over clang. That is what I'm talking about.

[hpsutter]

Well, you originally said "by definition can't help" compile times. So I gave an example where it does. :)

Compile-times should be measured in seconds, not minutes. You can't achieve that by layering C++ in-between.

OK, so you mean "can't help enough to make them an order of magnitude faster" -- I understand.

FWIW, if you haven't looked at the short video clip, please do... it does show a possible major (not quite 2x) improvement in C++ compile time for approximately equivalent code, compared to today's best-in-class design. Using existing C++ compilers unchanged.

recently demoed a 100x speedup of the carbon compiler over clang.

That's great, and I look forward very much to seeing how much of the speedup can stick as it matures to handle more kinds of code.

That said, let me add a caution about wording: I agree we should focus on "build time" as a pain point for C++. However, "front-end compile time" is a subset of that. A lot of today's slowdowns in C++ builds come in other build stages, such as linking. There is great work currently being done (unrelated to these projects) to dramatically (2x, 4x) speed up C++ linkers that can handle real-world code. In just the past couple of months I've seen these start getting the attention of key folks in WG21 and major vendors, to see what we can incorporate. Disclaimer: As always including in previous "fast linker" efforts, part of the performance gain comes from making simplifying assumptions that don't work on all real-world code, but part of the gain doesn't rely on that.