Build Time Comparision

Subprojects Flang
1

At yesterday’s flang technical call, we wanted to have an additional data point for the build time of flang itself, by also getting the compilation time using msvc.

Methodology:
Using my personal notebook with Intel Core i7-7700HQ CPU @ 2.80GHz, 16GB RAM, Windows 10 1909. I could not find a reliable way to get the user/system time for a process tree under Windows, so I am using wall clock time and single threads (ninja -j1). To keep the build time reasonable, I only timed compilation flang itself and its f18 executable (ninja says 130 tasks after touching every file in the flang subdirectory, consistent with every compiler). -DCMAKE_BUILD_TYPE=Release. I was using the computer while taking the time. Peak resident/working set size was determined using python psutil.

Msvc has parallelized its code generation and uses 4 threads by default. To make numbers more comparable, I have another run where I switched this off (/cgthreads1).

Results:

GCC 7.5 (Ubuntu 18.04.4, WSL)
Wall clock duration: 0:45:47
Peak compiler resident size: 4042.9 MiB (by cc1plus PFTBuilder.cpp)
Peak linker resident size: 151.8 MiB (by ld.lld f18)

Clang 11.0.0 (release build 3e94943d, WSL)
Wall clock duration: 1:42:22
Peak compiler resident size: 3266.0 MiB (by clang++ PFTBuilder.cpp)

Peak linker resident size: 260.7 MiB (by ld.lld f18)

MSVC 19.26.28806 (Visual Studio 2019 16.6.5 – current latest)
Wall clock duration: 0:59:26
Peak compiler working set: 7915.9 MiB (by cl.exe f18.cpp)

Peak linker working set: 747.9 MiB (by link.exe f18.exe)

MSVC /cgthreads1

Wall clock duration: 1:32:19

Peak compiler working set: 7918.3 MiB (by cl.exe f18.cpp)

Peak linker working set: 747.9 MiB (by link.exe f18.exe)

I also tried Intel icc, which unfortunately failed: tablegen does recognize its command line argument. I assume the cl::opt command line registration static initializer does not work.

Michael

2

Hi Michael,

Thanks for these numbers, this data is useful and seems to match what I
see on Linux.
To add another observation: the truly pathological linker case only
comes up in Debug builds rather than Release builds, which is when I
start to see peak linker resident usage of upwards of 8GB on Linux. I
wonder if this is the same on Windows too?

Thanks!
David Truby

3

Linking a debug build was always an issue under Linux, less so with msvc because

  1. Incremental linking
  2. Debug info not embedded into the binary, but a separate pdb file
  3. The pdb is built by another process (mspdbsrv.exe) that the compiler communicates to via IPC.

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.

Michael