[Numpy-discussion] Proposed Roadmap Overview
Mon Feb 20 11:28:19 CST 2012
2012/2/19 Nathaniel Smith <email@example.com>
> On Sun, Feb 19, 2012 at 9:16 AM, David Cournapeau <firstname.lastname@example.org>
> > On Sun, Feb 19, 2012 at 8:08 AM, Mark Wiebe <email@example.com> wrote:
> >> Is there a specific
> >> target platform/compiler combination you're thinking of where we can do
> >> tests on this? I don't believe the compile times are as bad as many
> >> suspect, can you give some simple examples of things we might do in
> >> you expect to compile slower in C++ vs C?
> > Switching from gcc to g++ on the same codebase should not change much
> > compilation times. We should test, but that's not what worries me.
> > What worries me is when we start using C++ specific code, STL and co.
> > Today, scipy.sparse.sparsetools takes half of the build time of the
> > whole scipy, and it does not even use fancy features. It also takes Gb
> > of ram when building in parallel.
> I like C++ but it definitely does have issues with compilation times.
> IIRC the main problem is very simple: STL and friends (e.g. Boost) are
> huge libraries, and because they use templates, the entire source code
> is in the header files. That means that as soon as you #include a few
> standard C++ headers, your innocent little source file has suddenly
> become hundreds of thousands of lines long, and it just takes the
> compiler a while to churn through megabytes of source code, no matter
> what it is. (Effectively you recompile some significant fraction of
> STL from scratch on every file, and then throw it away.)
In fact Boost tries to be clean about this. Up to a few minor releases of
GCC, their headers were a mess. When you included something, a lot of
additional code was brought, and the compile-time exploded. But this is no
longer the case. If we restrict the core to a few includes, even with
templates, it should not be long to compile.
Information System Engineer, Ph.D.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion