Hello John. John Criswell <criswell at illinois.edu> writes: [snip]> I did not use CMake but the standard autoconf + Makefile build. > > Not sure if this helps, but here it is, for what it's worth.Very interesting, thanks! CMake introduces more parallelism and it would be great to see how much impact it makes. If you can, please run the cmake build with -j32, just to compare with the `make' build. If you simply ran `configure && time make' for the autoconf build, that builds the Debug+Asserts mode. For replicating it on cmake, run mkdir build-directory && cd build-directory cmake -DCMAKE_BUILD_TYPE=Debug path/to/llvm/source/root time make -j32 Thanks again.
Just for informational purposes on a smaller system (Core 2 Duo MacBook Pro): make none X86.td X86InstrInfo.cpp real 11.568 217% 76.283 177% 34.435 169% user 7.726 141% 70.659 100% 25.608 116% sys 3.234 111% 3.992 100% 6.438 104% make -j2 none X86.td X86InstrInfo.cpp real 7.7346 145% 43.138 100% 25.77 127% user 7.6072 139% 70.414 100% 26.589 121% sys 3.2492 111% 3.984 100% 6.671 107% cmake none X86.td X86InstrInfo.cpp real 9.604 180% 92.127 214% 30.874 152% user 5.751 105% 84.993 121% 21.628 98% sys 3.053 104% 3.998 100% 6.246 100% cmake -j2 none X86.td X86InstrInfo.cpp real 5.321 100% 46.723 108% 20.324 100% user 5.481 100% 85.392 121% 21.995 100% sys 2.924 100% 3.833 96% 6.217 100% The numbers are in seconds and are an average of five runs. The file names indicate the file that was modified (via touch) to cause the rebuild. The change of the file X86.td cause tablegen to run but no source file compilation and no executable or library linking. The change of X86InstrInfo.cpp caused several files to be recompiled and many executables and libraries to be relinked. One thing that I noticed (not in this table) was that tablegen is about 300% faster on my machine when building a Release build vs. a Debug build, lowering the build time for the X86.td rebuild from 46 seconds to 15 seconds. This obviously adds up quickly when there are more tablegen files being regenerated. Perhaps tablegen should always be compiled with optimizations even in Debug Mode? I assume the need to debug tablegen itself is relatively rare. -- Wesley Peck University of Kansas SLDG Laboratory
Wesley Peck <peckw at wesleypeck.com> writes:> Just for informational purposes on a smaller system (Core 2 Duo MacBook Pro):That's a dualcore laptop, isn't it? [snip]> One thing that I noticed (not in this table) was that tablegen is > about 300% faster on my machine when building a Release build vs. a > Debug build, lowering the build time for the X86.td rebuild from 46 > seconds to 15 seconds. This obviously adds up quickly when there are > more tablegen files being regenerated. > > Perhaps tablegen should always be compiled with optimizations even in > Debug Mode? I assume the need to debug tablegen itself is relatively > rare.The cmake build already supports building an extra tblgen for the build, although that is currently used only when cross-compiling. I guess that the Makefile-based build does the same. Expanding its application for debug builds is simple, although some time measurements should be performed before adding the feature. In the meantime, interested users can set the LLVM_TABLEGEN variable, which allows to use an arbitrary tblgen executable. So if you have an optimized tblgen around, you can already use it for debug builds.
On 11/1/11 8:49 PM, Óscar Fuentes wrote:> Hello John. > > John Criswell<criswell at illinois.edu> writes: > > [snip] > >> I did not use CMake but the standard autoconf + Makefile build. >> >> Not sure if this helps, but here it is, for what it's worth. > Very interesting, thanks! > > CMake introduces more parallelism and it would be great to see how much > impact it makes. If you can, please run the cmake build with -j32, just > to compare with the `make' build. > > If you simply ran `configure&& time make' for the autoconf build, that > builds the Debug+Asserts mode. For replicating it on cmake, run > > mkdir build-directory&& cd build-directory > cmake -DCMAKE_BUILD_TYPE=Debug path/to/llvm/source/root > time make -j32 > > Thanks again.Autoconf + GMake: 16: 1681.512u 189.706s 2:48.96 1107.4% 0+0k 0+0io 0pf+0w 32: 1698.817u 209.073s 2:02.88 1552.6% 0+0k 0+0io 0pf+0w CMake: 32: 1700.340u 222.174s 1:38.27 1956.3% 0+0k 0+0io 0pf+0w -- John T.
Wesley Peck <peckw at wesleypeck.com> writes:> Perhaps tablegen should always be compiled with optimizations even in > Debug Mode? I assume the need to debug tablegen itself is relatively > rare.Oh no, not at all. I debug tblgen all the time. :) -Dave
John Criswell <criswell at illinois.edu> writes:> Autoconf + GMake: > > 16: 1681.512u 189.706s 2:48.96 1107.4% 0+0k 0+0io 0pf+0w > > 32: 1698.817u 209.073s 2:02.88 1552.6% 0+0k 0+0io 0pf+0w > > > > CMake: > > 32: 1700.340u 222.174s 1:38.27 1956.3% 0+0k 0+0io 0pf+0wThanks, John. The cmake build is much more parallel: 16-core make : 1107%, 32-core make : 1552% 32-core cmake: 1956% I assume that on the cmake trials the note about two cores used by other processes still applies. So the 32-core cmake build scales almost linearly against the 16-core make build. The 1956% CPU usage is far from the optimum 3000% that we could expect. I think there is a I/O bottleneck due to the large object files and libraries generated in debug mode and the huge executables that results from them. I suspect that a release build may be faster. Thanks again.