Date: Tue, 12 Dec 2023 17:10:28 +0000
* Microsoft's msbuild.exe does similar for other purposes.
But MSBuild isn’t the compiler and CL.exe isn’t going to grow a daemon tomorrow :-)
-- Gaby
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Tom Honermann via SG15
Sent: Tuesday, December 12, 2023 8:25 AM
To: sg15_at_[hidden]; Boris Kolpackov <boris_at_codesynthesis.com>
Cc: Tom Honermann <tom_at_[hidden]>
Subject: Re: [SG15] [Modules] Should the compiler try to build std module implicitly?
On 12/12/23 5:09 AM, Michael Spencer via SG15 wrote:
On Tue, Dec 12, 2023 at 1:11 AM Boris Kolpackov <boris_at_[hidden]<mailto:boris_at_[hidden]>> wrote:
Michael Spencer via SG15 <sg15_at_[hidden]<mailto:sg15_at_[hidden]>> writes:
> * Delete all the temp files at the end after linking
Building a hello-world example with Clang that imports libc++'s std
module (including building the BMI for it) takes about 1.5s on my
machine (i9-12900K). For comparison, the #include <iostream> version
takes 0.3s. Maybe this is acceptable but it will surely be painful
in the educational setting, where one will presumably be making a
lot of mistakes and thus doing a lot of recompilations.
Yep, this is about what I would expect. My extreme aversion to having the frontend cache things comes from years of dealing with the issues it causes. I'd prefer to use the module build daemon approach for handling caching for this situation as it gives a single process that can manage the cache instead of communicating over the filesystem between multiple Clang instances.
What prohibits Clang from moving to a single process daemon for managing the existing cache? Microsoft's msbuild.exe does similar for other purposes. The idea is that, when Clang is invoked, if a daemon isn't already running for the cache directory being used, then a daemon is started. The daemon then automatically shuts down after some timeout period during which it is unused. This approach works well generally. It can encounter permission related problems in some cases when the cache is shared among multiple users.
I agree that having multiple concurrently running processes collaboratively managing a cache invites considerable problems for little benefit.
Tom.
- Michael Spencer
_______________________________________________
SG15 mailing list
SG15_at_[hidden]<mailto:SG15_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/sg15
But MSBuild isn’t the compiler and CL.exe isn’t going to grow a daemon tomorrow :-)
-- Gaby
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Tom Honermann via SG15
Sent: Tuesday, December 12, 2023 8:25 AM
To: sg15_at_[hidden]; Boris Kolpackov <boris_at_codesynthesis.com>
Cc: Tom Honermann <tom_at_[hidden]>
Subject: Re: [SG15] [Modules] Should the compiler try to build std module implicitly?
On 12/12/23 5:09 AM, Michael Spencer via SG15 wrote:
On Tue, Dec 12, 2023 at 1:11 AM Boris Kolpackov <boris_at_[hidden]<mailto:boris_at_[hidden]>> wrote:
Michael Spencer via SG15 <sg15_at_[hidden]<mailto:sg15_at_[hidden]>> writes:
> * Delete all the temp files at the end after linking
Building a hello-world example with Clang that imports libc++'s std
module (including building the BMI for it) takes about 1.5s on my
machine (i9-12900K). For comparison, the #include <iostream> version
takes 0.3s. Maybe this is acceptable but it will surely be painful
in the educational setting, where one will presumably be making a
lot of mistakes and thus doing a lot of recompilations.
Yep, this is about what I would expect. My extreme aversion to having the frontend cache things comes from years of dealing with the issues it causes. I'd prefer to use the module build daemon approach for handling caching for this situation as it gives a single process that can manage the cache instead of communicating over the filesystem between multiple Clang instances.
What prohibits Clang from moving to a single process daemon for managing the existing cache? Microsoft's msbuild.exe does similar for other purposes. The idea is that, when Clang is invoked, if a daemon isn't already running for the cache directory being used, then a daemon is started. The daemon then automatically shuts down after some timeout period during which it is unused. This approach works well generally. It can encounter permission related problems in some cases when the cache is shared among multiple users.
I agree that having multiple concurrently running processes collaboratively managing a cache invites considerable problems for little benefit.
Tom.
- Michael Spencer
_______________________________________________
SG15 mailing list
SG15_at_[hidden]<mailto:SG15_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/sg15
Received on 2023-12-12 17:10:33