| |||||||||||||
Van Rossum: Python is not too slow (InfoWorld)Van Rossum: Python is not too slow (InfoWorld)Posted Mar 19, 2012 19:17 UTC (Mon) by elanthis (guest, #6227)In reply to: Van Rossum: Python is not too slow (InfoWorld) by foom Parent article: Van Rossum: Python is not too slow (InfoWorld)
There are compilers that can do full ahead-of-time compilation of Java. And C#. And various other static languages.
C++'s compilation speeds have almost nothing to do with being statically typed. It comes down to a combination of the pre-processor include system used for hooking files together and the prevalence of templates. The combination of the two means that every .cpp file can have megabytes and megabytes of identical code that has to be recompiled for each source file, only to have most of it thrown away by the linker.
The ahead-of-time optimization passes of a C++ compiler are rarely the biggest bottleneck in compilation. There's talk of getting a module system in the next C++, which will help tremendously with compilation speeds. In the meantime, learning how to use precompiled headers effectively will drastically improve compile times.
I have a couple large C++ game engines that can compile with full optimizations in less time than many small UNIX tools, largely just because I put in the little bit of time it takes to get a sane and optimized build environment. (hint: autotools, scons, cmake, and so on were not invited to the party)
(Log in to post comments)
Van Rossum: Python is not too slow (InfoWorld) Posted Mar 19, 2012 20:45 UTC (Mon) by HelloWorld (guest, #56129) [Link]
> (hint: autotools, scons, cmake, and so on were not invited to the party)
Well, who was?
Van Rossum: Python is not too slow (InfoWorld) Posted Mar 19, 2012 21:59 UTC (Mon) by cmccabe (guest, #60281) [Link]
> I have a couple large C++ game engines that can compile with
> full optimizations in less time than many small UNIX tools, > largely just because I put in the little bit of time it takes > to get a sane and optimized build environment. (hint: autotools, > scons, cmake, and so on were not invited to the party)
It is true that careful programmers can often achieve reasonable build times with C++ by minimizing unecessary dependencies. Sometimes you have to sacrifice some perfomance too, by using things like the pImpl idiom.
I think it's unfair to stigmatize cmake as slow. CMake actually compares very favorably with hand-written makefiles. autotools and scons are indeed slow, and should basically not be used by anyone.
There are ways to speed up your autotools build. One of them is to combine all of your Makefile.am files into one giant file (modularity? What's that?). If you write your makefile.am in the natural way, though, it will be very slow. And even with optimizations it takes 15 seconds just to get rolling after you type "make."
Van Rossum: Python is not too slow (InfoWorld) Posted Mar 20, 2012 11:31 UTC (Tue) by RCL (guest, #63264) [Link]
Joining several .cpp files into single one (e.g. by creating files that consist purely of
#include <blah.cpp>
also known as "Unity builds") helps C++ compilation times as well (and also allows for better optimization for non-globally optimizing compilers).
Van Rossum: Python is not too slow (InfoWorld) Posted Mar 21, 2012 12:55 UTC (Wed) by jwakely (subscriber, #60262) [Link]
But they break anon namespaces and entities with static linkage and cause the entire world to be rebuilt if you touch one file. They're a hack, an abhorrent one, to work around the lack of a decent build environment and sensible control of dependencies.
|
|||||||||||||