Could someone with cmake clue, please, take a look at:
https://github.com/russellallen/self/issues/141 "precompiled header rule misses build type flags"
(Never mind my follow-up ramblings about -include - those have been fixed)
Alternatively, the problematic rule to actually precompile the precompiled header can be disabled so that _precompiled.hh is just processed as a normal header and the problem is just dodged. The speed gain from the precompiled header is probably barely above the statistical noise (even now, when the compilation time is down an order of magnitude with the pragma fixes). But I guess the fix shouldn't be that hard for someone who groks cmake.
Thanks in advance.
-uwe
We went with Cmake a while back because we needed something which would generate a MacOS XCode project for us - my hope was we could finish off the half done attempt at a proper Cocoa app. Ironically we can't run on MacOS anymore, so I half wish we had stayed with make!
I'm inclined to remove magic if it isn't buying us much, especially if we don't really understand how it is working (... or not working)
- Russell
On 18/8/23 11:46, Valery Ushakov wrote:
Could someone with cmake clue, please, take a look at:
https://github.com/russellallen/self/issues/141 "precompiled header rule misses build type flags"
(Never mind my follow-up ramblings about -include - those have been fixed)
Alternatively, the problematic rule to actually precompile the precompiled header can be disabled so that _precompiled.hh is just processed as a normal header and the problem is just dodged. The speed gain from the precompiled header is probably barely above the statistical noise (even now, when the compilation time is down an order of magnitude with the pragma fixes). But I guess the fix shouldn't be that hard for someone who groks cmake.
Thanks in advance.
-uwe _______________________________________________ Self-interest mailing list -- self-interest@lists.selflanguage.org To unsubscribe send an email to self-interest-leave@lists.selflanguage.org
Hi
I would have done without the PCH stuff, too. However, there was some interest in keeping the traditional Header style.
This includes the makeDeps program
https://github.com/russellallen/self/blob/master/vm/build_support/makeDeps.c...
Which processes a file of "well-known" header dependencies as specified in
https://github.com/russellallen/self/blob/master/vm/build_support/includeDB....
and builds a dependency graph, and subsequently a huge header files which is necessary to be compiled as PCH.
When this scheme was originally conceived some 30 years ago, it bought down the overall build time quite considerably.
10 years ago, the speedup was nowhere near as substantial as it was before, but for one or two reasons, we kept the scheme.
We (in this case, Chris Double) already looked into removing makedDeps altogether (https://github.com/russellallen/self/compare/master...remove_makedeps )
and maybe now is the time to follow through with it?
Best regards -Tobias
On 31. Aug 2023, at 07:28, Russell Allen mail@russell-allen.com wrote:
We went with Cmake a while back because we needed something which would generate a MacOS XCode project for us - my hope was we could finish off the half done attempt at a proper Cocoa app. Ironically we can't run on MacOS anymore, so I half wish we had stayed with make!
I'm inclined to remove magic if it isn't buying us much, especially if we don't really understand how it is working (... or not working)
- Russell
On 18/8/23 11:46, Valery Ushakov wrote:
Could someone with cmake clue, please, take a look at:
https://github.com/russellallen/self/issues/141 "precompiled header rule misses build type flags"
(Never mind my follow-up ramblings about -include - those have been fixed)
Alternatively, the problematic rule to actually precompile the precompiled header can be disabled so that _precompiled.hh is just processed as a normal header and the problem is just dodged. The speed gain from the precompiled header is probably barely above the statistical noise (even now, when the compilation time is down an order of magnitude with the pragma fixes). But I guess the fix shouldn't be that hard for someone who groks cmake.
Thanks in advance.
-uwe _______________________________________________ Self-interest mailing list -- self-interest@lists.selflanguage.org To unsubscribe send an email to self-interest-leave@lists.selflanguage.org
Self-interest mailing list -- self-interest@lists.selflanguage.org To unsubscribe send an email to self-interest-leave@lists.selflanguage.org
On Thu, Aug 31, 2023 at 09:22:17 +0200, Tobias Pape wrote:
We (in this case, Chris Double) already looked into removing makedDeps altogether
(https://github.com/russellallen/self/compare/master...remove_makedeps )
and maybe now is the time to follow through with it?
If this is considered for the merge, #pragma interface/implementation should be preserved. They are orthogonal to the jumbo header issue and they help immensly, at least for gcc. Without them every object file has a ~300K copy of object code for the inline functions. It will probably be less (b/c less headers will be pulled in), but still a lot of code to compile/emit only to g/c at link time. Build times on my laptop went down from ~20 minutes to ~2 minutes with the pragma fixes. Similar 10x speedup on other architectures too.
-uwe
Hi,
On 31. Aug 2023, at 17:36, Valery Ushakov uwe@stderr.spb.ru wrote:
On Thu, Aug 31, 2023 at 09:22:17 +0200, Tobias Pape wrote:
We (in this case, Chris Double) already looked into removing makedDeps altogether
(https://github.com/russellallen/self/compare/master...remove_makedeps )
and maybe now is the time to follow through with it?
If this is considered for the merge, #pragma interface/implementation should be preserved. They are orthogonal to the jumbo header issue and they help immensly, at least for gcc. Without them every object file has a ~300K copy of object code for the inline functions.
I am very surprised, as the GCC docu says:
"Note: These #pragmas have been superceded as of GCC 2.7.2 by COMDAT support and the “key method” heuristic mentioned in Vague Linkage. Using them can actually cause your program to grow due to unnecessary out-of-line copies of inline functions."
https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Interface.html
It seems to be very discouraged…
-Tobias
It will probably be less (b/c less headers will be pulled in), but still a lot of code to compile/emit only to g/c at link time. Build times on my laptop went down from ~20 minutes to ~2 minutes with the pragma fixes. Similar 10x speedup on other architectures too.
-uwe _______________________________________________ Self-interest mailing list -- self-interest@lists.selflanguage.org To unsubscribe send an email to self-interest-leave@lists.selflanguage.org
On Thu, Aug 31, 2023 at 17:42:38 +0200, Tobias Pape wrote:
On 31. Aug 2023, at 17:36, Valery Ushakov uwe@stderr.spb.ru wrote:
On Thu, Aug 31, 2023 at 09:22:17 +0200, Tobias Pape wrote:
We (in this case, Chris Double) already looked into removing makedDeps altogether
(https://github.com/russellallen/self/compare/master...remove_makedeps )
and maybe now is the time to follow through with it?
If this is considered for the merge, #pragma interface/implementation should be preserved. They are orthogonal to the jumbo header issue and they help immensly, at least for gcc. Without them every object file has a ~300K copy of object code for the inline functions.
I am very surprised, as the GCC docu says:
"Note: These #pragmas have been superceded as of GCC 2.7.2 by COMDAT support and the ?key method? heuristic mentioned in Vague Linkage. Using them can actually cause your program to grow due to unnecessary out-of-line copies of inline functions."
https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Interface.html
It seems to be very discouraged?
Unfortunately I probably won't be able to experiment with this as I'll be on the road until the end of the next week. But if I get the COMDAT reference right, it's exactly "let's emit code everywhere and then g/c duplicates at link time".
It will probably be less (b/c less headers will be pulled in), but still a lot of code to compile/emit only to g/c at link time. Build times on my laptop went down from ~20 minutes to ~2 minutes with the pragma fixes. Similar 10x speedup on other architectures too.
-uwe
-uwe
self-interest@lists.selflanguage.org
-
Russell Allen -
Tobias Pape -
Valery Ushakov