[Numpy-discussion] How a transition to C++ could work
Sun Feb 19 03:52:22 CST 2012
On Sun, Feb 19, 2012 at 3:10 AM, Ben Walsh <firstname.lastname@example.org> wrote:
> > Date: Sun, 19 Feb 2012 01:18:20 -0600
> > From: Mark Wiebe <email@example.com>
> > Subject: [Numpy-discussion] How a transition to C++ could work
> > To: Discussion of Numerical Python <NumPy-Discussion@scipy.org>
> > Message-ID:
> > <CAMRnEmpVTmt=
> > Content-Type: text/plain; charset="utf-8"
> > The suggestion of transitioning the NumPy core code from C to C++ has
> > sparked a vigorous debate, and I thought I'd start a new thread to give
> > perspective on some of the issues raised, and describe how such a
> > transition could occur.
> > First, I'd like to reiterate the gcc rationale for their choice to
> > http://gcc.gnu.org/wiki/gcc-in-cxx#Rationale
> > In particular, these points deserve emphasis:
> > - The C subset of C++ is just as efficient as C.
> > - C++ supports cleaner code in several significant cases.
> > - C++ makes it easier to write cleaner interfaces by making it harder
> > break interface boundaries.
> > - C++ never requires uglier code.
> I think they're trying to solve a different problem.
> I thought the problem that numpy was trying to solve is "make inner loops
> of numerical algorithms very fast". C is great for this because you can
> write C code and picture precisely what assembly code will be generated.
What you're describing is also the C subset of C++, so your experience
applies just as well to C++!
> C++ removes some of this advantage -- now there is extra code generated by
> the compiler to handle constructors, destructors, operators etc which can
> make a material difference to fast inner loops. So you end up just writing
> "C-style" anyway.
This is in fact not true, and writing in C++ style can often produce faster
code. A classic example of this is C qsort vs C++ std::sort. You may be
thinking of using virtual functions in a class hierarchy, where a tradeoff
between performance and run-time polymorphism is being done. Emulating the
functionality that virtual functions provide in C will give similar
performance characteristics as the C++ language feature itself.
> On the other hand, if your problem really is "write lots of OO code with
> virtual methods and have it turned into machine code" (probably like the
> GCC guys) then maybe C++ is the way to go.
Managing the complexity of the dtype subsystem, the ufunc subsystem, the
nditer component, and other parts of NumPy could benefit from C++ Not in a
stereotypical "OO code with virtual methods" way, that is not how typical
modern C++ is done.
> Some more opinions on C++:
> Sorry if this all seems a bit negative about C++. It's just been my
> experience that C++ adds complexity while C keeps things nice and simple.
Yes, there are lots of negative opinions about C++ out there, it's true.
Just like there are negative opinions about C, Java, C#, and any other
language which has become popular. My experience with regard to complexity
and C vs C++ is that C forces the complexity of dealing with resource
lifetimes out into all the code everyone writes, while C++ allows one to
encapsulate that sort of complexity into a class which is small and more
easily verifiable. This is about code quality, and the best quality C++
code I've worked with has been way easier to program in than the best
quality C code I've worked with.
Looking forward to seeing some more concrete examples.
In the interests of starting small, here's one that I mentioned in the
Consider a regression like this:
Fixing this in C would require switching all the relevant usages of
NPY_MAXARGS to use a dynamic memory allocation. This brings with it the
potential of easily introducing a memory leak, and is a lot of work to do.
In C++, this functionality could be placed inside a class, where the
deterministic construction/destruction semantics eliminate the risk of
memory leaks and make the code easier to read at the same time.
> NumPy-Discussion mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion