[cfe-dev] Building Clang on Windows
Fábio Picchi via cfe-dev
cfe-dev at lists.llvm.org
Sun Oct 7 16:29:41 PDT 2018
> The problem is that by default VS2017 builds Clang in parallel to how
many cores you have
That would explain my problem in building clang then as I have an eight
core Ryzen 7 1700X with only 8GB of RAM. I will try to build with parallel
But did ninja ignore these build options? Because I was able to build clang
using it without any problem.
I will look into it and post some results tomorrow.
On Sun, Oct 7, 2018 at 7:11 PM Bruce Hoult via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> 16GB is about the minimal amount of RAM you want for a quad core developer
> system these days -- I build mine with 32G in order to have room for a
> decent amount of disk caching. 16GB a completely crazy amount of RAM for 32
> cores. I wouldn't go with less than 128GB. This time last year I built a
> system with an i9 with 18 cores and 64GB and it was just barely enough --
> 32GB would have been tragic.
> I note that AWS "general purpose" instances (e.g. M4/M5) have 4 GB per
> vCPU (hyperthread). "Compute Optimised" have 2 GB per vCPU. I find the M5
> instances much better balanced for software development than the C5
> instances, at about a 12% price premium.
> On Sun, Oct 7, 2018 at 7:32 AM, Hussien Hussien via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>> The problem is that by default VS2017 builds Clang in parallel to how
>> many cores you have. When I build LLVM/Clang, I've noticed the default
>> setting will almost instantly consume 100% of my RAM and I have 16GB of RAM
>> and 32cores.
>> To turn off parallel building, mark the appropriate CMAKE variables:
>> Define the maximum number of concurrent compilation jobs.
>> Define the maximum number of concurrent link jobs.
>> Also in Visual Studio, in Tools > Projects and Solutions > Build and Run,
>> 'maximum number of parallel project builds to 1.
>> Hussien H.
>> On Sun, Oct 7, 2018 at 9:22 AM degski via cfe-dev <cfe-dev at lists.llvm.org>
>>> Sorry to barge in.
>>> >> I remember doing so at one point when I was still using Windows, and
>>> >> my system much more responsive overall. But that was ~10 years ago
>>> and I
>>> >> guess it's not a common setup.
>>> 10 years ago does not seem very relevant, both Windows and VS are very
>>> different now. Also "... found my system much more responsive overall ..."
>>> very much sounds like placebo/snake-oil.
>>> >> If msbuild is 32-bit, why would that cause the (64-bit?) cl.exe
>>> process to
>>> >> run out of memory?
>>> I doubt msbuild is allocating much memory at all, but is the 64-bit
>>> version of cl.exe being called from msbuild? You need to up the build
>>> output so you can see what compiler is being called. Sounds like ninja is
>>> calling the 64-bit version, while msbuild is (could be, I'm speculating)
>>> using the 32-bit version to cross-build [and runs out of addressable
>>> space]. The VS defaults are all 32-bit.
>>> *“If something cannot go on forever, it will stop" - Herbert Stein*
>>> cfe-dev mailing list
>>> cfe-dev at lists.llvm.org
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev