[flang-dev] Build Time Comparision

[Michael Kruse via flang-dev]

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


Am Do., 30. Juli 2020 um 03:28 Uhr schrieb David Truby <David.Truby at arm.com
>:

> 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
>
> On Tue, 2020-07-28 at 17:03 -0500, Michael Kruse via flang-dev wrote:
> > 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
> >
> >
> > _______________________________________________
> > flang-dev mailing list
> > flang-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/flang-dev/attachments/20200805/263d25a3/attachment.html>