HassanSajjad-302 wrote: I have successfully implemented shared memory files for Windows. Currently, testing it for Linux. Now, the speed-up for boost debug is a little more to 2.5x from previously 2.3x. Shared memory files means that this also consumes 10 - 20% less memory.
> Please understand the concern for maintainability. It really scares me to see > a patch with 5k lines of change for a brand-new feature—especially since > human resources for Clang/C++ core developers are extremely limited. We have > to be careful. I fully understand it. Just want to say that there is a separation of concern and a clear front-end and backend. If the integration-test `IPC2978Test` in `clang/unittests/IPC2978/IPC2978Test.cpp` works, then you can just glance over the backend API. >Back to the patch itself: the most concerning/confusing point, in my >experience, is that the bottleneck of a build process generally comes from the >compiler itself, rather than the build system or the communication between the >compiler and the build system. In complex real-world projects I’ve seen, most >compilation time is spent on template instantiations and middle/back-end >optimizations. >Amdahl’s Law tells us that the overall speedup from optimizing a subsystem is >limited by the proportion of that subsystem within the whole system. My >concern is: is it worth introducing such a large feature to optimize the cold >part of the entire process—especially when the new model hasn’t been widely >proven yet? I would like to mention a [comment](https://www.reddit.com/r/cpp/comments/1jb8acg/comment/mhvvfva/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button) by a bigcheeesegs. This is a very insightful comment imo. They argue that the risk of using header-units for build-perf increase is worth it. They also mention that there is no easy way to move to modules with contemporary build-systems and with their build model. Easiest solution is a build-server. HMake is precisely this. This build-server model has been discussed [often](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1602r0.pdf) for a long time. However, none except HMake could actually implement it. >The proof consists of two parts: >We need to see the proportion of the cost of the build system itself and the >cost of communication between the build system and compilers within the entire >build process for large/complex projects. Then, we need to evaluate how good the new model actually is. >Aside from the new model, regarding HMake—I truly appreciate what you’ve done. >But to be honest, HMake needs more users and successful case studies to >demonstrate its value, so that more tools will support the new model it >introduces. Build systems aren’t hard in principle, but they are very complex >in practice. Due to this complexity, migrating to a new build system isn’t >easy. Nobody I know is eager to write build scripts. So I feel it’s hard for >HMake to attract new users today. Then I am sorry that creates a >chicken-and-egg problem if HMake really depends on this patch. But as I said, >we have to be careful. >If HMake is really, really good—and the changes in Clang are truly necessary—I >do think you could pursue it via a plugin or a fork first. That would be >simpler I promoted my software to the Boost community. Unfortunately, they think that the cost is not worth it. I plan to re-request them with more libraries completed and similarly I plan to reach-out to other projects as-well. I also request you to promote HMake. I believe that LLVM can be compiled >10x faster with my software. And the cost of switching is very minimal as well. I welcome anyone for a review. It is extensively tested. I can do a video-call desktop sharing presentation explaining all details, answering any questions. Reviewers will find my software 10/10 on all accounts. I believe that with the collaboration, the transition can be completed in less than 2 months. If the compilation fails, there will always be the option to fallback to conventional model or to point out the culprit header-unit and compile it as a header-file instead until the bug gets fixed. LLVM uses C++17. That means that the chances of breakage with hu are little. Boost-Example that I did is with C++26. Also, LLVM plans to move to C++20. In that case the perf-benefit further increases. I can myself compile clang + llvm (x86 backend only without tests or other supporting features docs etc) in 3 weeks provided the current build maintainers are willing to get in touch. Like, why the build might be failing. Or explaining some current build-system and code-generation steps. Then they can do a detailed review after 3 weeks for further adoption. On my system it takes around 8mints. It would take < 1mint. HMake is very extensible and A tier in code-generations, making test reports etc. Having full-context and vertical integration (between the traditionally separate build-system generator and the build-system) and the ability to modify the central DAG will allow for further optimizations to fully saturate the cores. I can't overstress how important that could be. If you ever thought about build-system supporting some custom features, HMake will probably be able to. I am ok if this pull-request is not merged. I can point potential HMake users to your comment and that you are willing to merge if they are willing to become HMake users. I would like to request the lead maintainer @AaronBallman for a comment. Please see [link](https://discourse.llvm.org/t/rfc-hmake-for-llvm/88997/4). I posted some screenshots and build log there. Again, CMake is the de-facto blockade as far as the adoption of modules goes. Boost effort is not going anywhere e.g. https://github.com/llvm/llvm-project/pull/147682 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
