3 ms·

I think the conclusion section should indicate that they are based entirely on GCC 16's behavior and current implementation. We should avoid generalizing one co

by jsd1982 5mo ago

I think the conclusion section should indicate that they are based entirely on GCC 16's behavior and current implementation. We should avoid generalizing one compiler's behavior and performance. Curious how this same test would behave once clang ships C++26 reflection.

bluGill 5mo ago
I was thinking the same thing. Modules are still not widely used, it is a reasonable guess that there are a lot of optimization opportunities left.
- SuperV1234 5mo ago
  That is true, but on the other hand Modules were standardized more than 6 years ago. Promises and claims have been made for longer than that on how Modules would have improved compilation times and made everyone's lives easier. In 2026, I still have to see any real evidence of that, especially when PCH + unity builds are much easier to use (except on damn Bazel, which supports neither) and deliver great results. If after 6+ years of development Modules are still so far behind, it is fair to question if the problem is with the design/implementability of the feature itself.
  - spacechild1 5mo ago
    > it is fair to question if the problem is with the design/implementability of the feature itself. The module story is just insane. How was it possible to get such a big feature into the standard without any working reference implementation? Isn't this the requirement for standard proposals to get accepted? If I compare this with how they treated JeanHeyd and his #embed proposal, the difference is staggering. To me it seems like a few powerful comittee members wanted to get modules into C++20 at any cost. This was just irresponsible.
    - bluGill 5mo ago
      There was in visual studio which has had it other than minor details.the real problem is tools are needed to make modules work and those needed a lot of work. The work was already partially there because it's the same work that Fortran needs which tools supported but there were just enough details different to be annoying. Fortran modules were something that were always an afterthought and when tools started realizing that this is going to be a big deal, they decided they had to do it right, which took a lot of time too. Maybe you forget Hacker News of 10 years ago, but in 2015-2016, everyone was complaining C++ doesn't have modules and how awful it must be because they're not modules. Now that C++ has modules, they're complaining about how it has modules.
      - spacechild1 5mo ago
        I don't remember because I wasn't there :) People are not complaining about the fact that C++ has modules, but about their usability and effectiveness. The compile time benefits seem modest and I have seen reports that it breaks Intellisense. (Maybe that's not true anymore?) As Vittorio said, if it takes compiler vendors so long to implement them properly, maybe the design wasn't that good after all? My point was: if you add such a big feature, shouldn't the standard require a sufficiently complete implementation? Otherwise, how can they assess whether the proposal actually works in practice and lives up to its promises?
        bluGill 5mo ago
        Again, they had a sufficiently complete implementation. That implementation was in Visual Studio, clang had a very different implementation. The standard decided to take the Microsoft version. There are pros and cons to both and I will not fault the decision but either way one of the two had to lose and there is no surprise that for something complex it will take a long time to reimplement it to whatever the new standard is.
        spacechild1 5mo ago
        If the implementation really was sufficiently complete, then this is even worse! Why did they choose to vote something into the standard that is very complex and difficult to implement, but does not live up to the promises? Maybe they thought it would improve in the future, but isn't this a huge gamble? I have heard rumors that certain people in the Visual Studio team have exaggerated the state of their modules implementation to speedrun the standardization process. I have no idea if that is really true, but it would explain a lot of things... I'm not the only one who is asking these questions: > I don’t know if they exaggerated their claims at the time, or if they didn’t properly fund the Visual Studio team since or what, but you can’t tell me 8 years wasn’t enough to make syntax highlighting work with modules. And if it is, then maybe there was something deeply wrong in their proposal and the committee should have asked to see the receipts before voting yes. https://mropert.github.io/2026/04/13/modules_in_2026/ https://mropert.github.io/2026/04/13/modules_in_2026/
SuperV1234 5mo ago
I explicitly mentioned that GCC 16.1 was the compiler used in the benchmarking section, do you think I also need to add a disclaimer in the conclusion section as well? Regardless, I don't think things are going to differ much with Clang. Without PCH/modules, standard header inclusion is still the "slow part" of C++ compilation, regardless of the compiler used and the standard library used (libstdc++ vs libc++). `#include` is fundamentally the same on any modern compiler. Because the reflection feature itself seems quite fast on GCC (compared to the cost of the header), I predict the results will be similar on Clang as well.
pjmlp 5mo ago
Or VC++ if ever, which has the best modules support, but it is still trailing behind in C++23.

by jsd1982 5mo ago

bluGill 5mo ago

I was thinking the same thing. Modules are still not widely used, it is a reasonable guess that there are a lot of optimization opportunities left.

SuperV1234 5mo ago
That is true, but on the other hand Modules were standardized more than 6 years ago. Promises and claims have been made for longer than that on how Modules would have improved compilation times and made everyone's lives easier. In 2026, I still have to see any real evidence of that, especially when PCH + unity builds are much easier to use (except on damn Bazel, which supports neither) and deliver great results. If after 6+ years of development Modules are still so far behind, it is fair to question if the problem is with the design/implementability of the feature itself.
- spacechild1 5mo ago
  > it is fair to question if the problem is with the design/implementability of the feature itself. The module story is just insane. How was it possible to get such a big feature into the standard without any working reference implementation? Isn't this the requirement for standard proposals to get accepted? If I compare this with how they treated JeanHeyd and his #embed proposal, the difference is staggering. To me it seems like a few powerful comittee members wanted to get modules into C++20 at any cost. This was just irresponsible.
  - bluGill 5mo ago
    There was in visual studio which has had it other than minor details.the real problem is tools are needed to make modules work and those needed a lot of work. The work was already partially there because it's the same work that Fortran needs which tools supported but there were just enough details different to be annoying. Fortran modules were something that were always an afterthought and when tools started realizing that this is going to be a big deal, they decided they had to do it right, which took a lot of time too. Maybe you forget Hacker News of 10 years ago, but in 2015-2016, everyone was complaining C++ doesn't have modules and how awful it must be because they're not modules. Now that C++ has modules, they're complaining about how it has modules.
    - spacechild1 5mo ago
      I don't remember because I wasn't there :) People are not complaining about the fact that C++ has modules, but about their usability and effectiveness. The compile time benefits seem modest and I have seen reports that it breaks Intellisense. (Maybe that's not true anymore?) As Vittorio said, if it takes compiler vendors so long to implement them properly, maybe the design wasn't that good after all? My point was: if you add such a big feature, shouldn't the standard require a sufficiently complete implementation? Otherwise, how can they assess whether the proposal actually works in practice and lives up to its promises?
      - bluGill 5mo ago
        Again, they had a sufficiently complete implementation. That implementation was in Visual Studio, clang had a very different implementation. The standard decided to take the Microsoft version. There are pros and cons to both and I will not fault the decision but either way one of the two had to lose and there is no surprise that for something complex it will take a long time to reimplement it to whatever the new standard is.
        spacechild1 5mo ago
        If the implementation really was sufficiently complete, then this is even worse! Why did they choose to vote something into the standard that is very complex and difficult to implement, but does not live up to the promises? Maybe they thought it would improve in the future, but isn't this a huge gamble? I have heard rumors that certain people in the Visual Studio team have exaggerated the state of their modules implementation to speedrun the standardization process. I have no idea if that is really true, but it would explain a lot of things... I'm not the only one who is asking these questions: > I don’t know if they exaggerated their claims at the time, or if they didn’t properly fund the Visual Studio team since or what, but you can’t tell me 8 years wasn’t enough to make syntax highlighting work with modules. And if it is, then maybe there was something deeply wrong in their proposal and the committee should have asked to see the receipts before voting yes. https://mropert.github.io/2026/04/13/modules_in_2026/ https://mropert.github.io/2026/04/13/modules_in_2026/

SuperV1234 5mo ago

I explicitly mentioned that GCC 16.1 was the compiler used in the benchmarking section, do you think I also need to add a disclaimer in the conclusion section as well? Regardless, I don't think things are going to differ much with Clang. Without PCH/modules, standard header inclusion is still the "slow part" of C++ compilation, regardless of the compiler used and the standard library used (libstdc++ vs libc++). `#include` is fundamentally the same on any modern compiler. Because the reflection feature itself seems quite fast on GCC (compared to the cost of the header), I predict the results will be similar on Clang as well.

pjmlp 5mo ago

Or VC++ if ever, which has the best modules support, but it is still trailing behind in C++23.