[cfe-dev] Building Clang on Windows
Bruce Hoult via cfe-dev
cfe-dev at lists.llvm.org
Sun Oct 7 15:11:43 PDT 2018
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:
>
> LLVM_PARALLEL_COMPILE_JOBS:STRING
> Define the maximum number of concurrent compilation jobs.
> LLVM_PARALLEL_LINK_JOBS:STRING
> Define the maximum number of concurrent link jobs.
>
> Also in Visual Studio, in Tools > Projects and Solutions > Build and Run,
> set
> '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>
> wrote:
>
>> Sorry to barge in.
>>
>> >> I remember doing so at one point when I was still using Windows, and
>> found
>> >> 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.
>>
>> degski
>> --
>> *“If something cannot go on forever, it will stop" - Herbert Stein*
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181007/7bfb0cdf/attachment.html>
More information about the cfe-dev
mailing list