On Sun, Feb 19, 2012 at 3:10 AM, Ben Walsh <[email protected]> wrote:
> > > > Date: Sun, 19 Feb 2012 01:18:20 -0600 > > From: Mark Wiebe <[email protected]> > > Subject: [Numpy-discussion] How a transition to C++ could work > > To: Discussion of Numerical Python <[email protected]> > > Message-ID: > > <CAMRnEmpVTmt= > [email protected]> > > 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 > my > > 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 > switch: > > 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 > to > > 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++: > http://gigamonkeys.wordpress.com/2009/10/16/coders-c-plus-plus/ > > 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 other thread: Consider a regression like this: http://mail.scipy.org/pipermail/numpy-discussion/2011-July/057831.html 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. Cheers, Mark > Cheers > > Ben > _______________________________________________ > NumPy-Discussion mailing list > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
