<div dir="ltr"><div>Linking a debug build was always an issue under Linux, less so with msvc because </div><div>1. Incremental linking</div><div>2. Debug info not embedded into the binary, but a separate pdb file</div><div>3. The pdb is built by another process (mspdbsrv.exe) that the compiler communicates to via IPC.</div><div><br></div><div>Item 2. can also be done with clang/gcc sing the -gsplit-dwarf flag  -DLLVM_USE_SPLIT_DWARF=ON). Item 3 was discussed for clang at some point.</div><div><br></div><div>Michael</div><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Do., 30. Juli 2020 um 03:28 Uhr schrieb David Truby <<a href="mailto:David.Truby@arm.com">David.Truby@arm.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Michael,<br>
<br>
Thanks for these numbers, this data is useful and seems to match what I<br>
see on Linux.<br>
To add another observation: the truly pathological linker case only<br>
comes up in Debug builds rather than Release builds, which is when I<br>
start to see peak linker resident usage of upwards of 8GB on Linux. I<br>
wonder if this is the same on Windows too?<br>
<br>
Thanks!<br>
David Truby<br>
<br>
On Tue, 2020-07-28 at 17:03 -0500, Michael Kruse via flang-dev wrote:<br>
> At yesterday's flang technical call, we wanted to have an additional<br>
> data point for the build time of flang itself, by also getting the<br>
> compilation time using msvc.<br>
> <br>
> Methodology:<br>
> Using my personal notebook with Intel Core i7-7700HQ CPU @ 2.80GHz,<br>
> 16GB RAM, Windows 10 1909. I could not find a reliable way to get the<br>
> user/system time for a process tree under Windows, so I am using wall<br>
> clock time and single threads (ninja -j1). To keep the build time<br>
> reasonable, I only timed compilation flang itself and its f18<br>
> executable (ninja says 130 tasks after touching every file in the<br>
> flang subdirectory, consistent with every compiler).<br>
> -DCMAKE_BUILD_TYPE=Release. I was using the computer while taking the<br>
> time. Peak resident/working set size was determined using python<br>
> psutil.<br>
> <br>
> Msvc has parallelized its code generation and uses 4 threads by<br>
> default. To make numbers more comparable, I have another run where I<br>
> switched this off (/cgthreads1).<br>
> <br>
> Results:<br>
> <br>
> GCC 7.5 (Ubuntu 18.04.4, WSL)<br>
> Wall clock duration: 0:45:47<br>
> Peak compiler resident size: 4042.9 MiB (by cc1plus PFTBuilder.cpp)<br>
> Peak linker resident size: 151.8 MiB (by ld.lld f18)<br>
> <br>
> Clang 11.0.0 (release build 3e94943d, WSL)<br>
> Wall clock duration: 1:42:22<br>
> Peak compiler resident size: 3266.0 MiB (by clang++ PFTBuilder.cpp)  <br>
> Peak linker resident size: 260.7 MiB (by ld.lld f18)  <br>
> <br>
> MSVC 19.26.28806 (Visual Studio 2019 16.6.5 -- current latest)<br>
> Wall clock duration: 0:59:26<br>
> Peak compiler working set: 7915.9 MiB (by cl.exe f18.cpp)<br>
> Peak linker working set: 747.9 MiB (by link.exe f18.exe)<br>
> <br>
> MSVC /cgthreads1<br>
> Wall clock duration: 1:32:19<br>
> Peak compiler working set: 7918.3 MiB (by cl.exe f18.cpp)<br>
> Peak linker working set: 747.9 MiB (by link.exe f18.exe)<br>
> <br>
> I also tried Intel icc, which unfortunately failed: tablegen does<br>
> recognize its command line argument. I assume the cl::opt command<br>
> line registration static initializer does not work.<br>
> <br>
> Michael<br>
> <br>
> <br>
> _______________________________________________<br>
> flang-dev mailing list<br>
> <a href="mailto:flang-dev@lists.llvm.org" target="_blank">flang-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev</a><br>
</blockquote></div></div>