[Numpy-discussion] Proposed Roadmap Overview

Sat Feb 18 00:00:20 EST 2012

Le 18 févr. 2012 04:37, "Charles R Harris" <charlesr.harris at gmail.com> a
écrit :
>
>
>
> On Fri, Feb 17, 2012 at 9:18 PM, David Cournapeau <cournape at gmail.com>
wrote:
>>
>>
>> Le 18 févr. 2012 03:53, "Charles R Harris" <charlesr.harris at gmail.com> a
écrit :
>>
>>
>> >
>> >
>> >
>> > On Fri, Feb 17, 2012 at 7:29 PM, David Cournapeau <cournape at gmail.com>
wrote:
>> >>
>> >>
>> >> Le 18 févr. 2012 00:58, "Charles R Harris" <charlesr.harris at gmail.com>
a écrit :
>> >>
>> >>
>> >> >
>> >> >
>> >> >
>> >> > On Fri, Feb 17, 2012 at 4:44 PM, David Cournapeau <
cournape at gmail.com> wrote:
>> >> >>
>> >> >> I don't think c++ has any significant advantage over c for high
performance libraries. I am not convinced by the number of people argument
either: it is not my experience that c++ is easier to maintain in a open
source context, where the level of people is far from consistent. I doubt
many people did not contribute to numoy because it is in c instead if c++.
While this is somehow subjective, there are reasons that c is much more
common than c++ in that context.
>> >> >
>> >> >
>> >> > I think C++ offers much better tools than C for the sort of things
in Numpy. The compiler will take care of lots of things that now have to be
hand crafted and I wouldn't be surprised to see the code size shrink by a
significant factor.
>> >>
>> >> There are two arguments here: that c code in numpy could be improved,
and that c++ is the best way to do it. Nobody so far has argued against the
first argument. i think there is a lot of space to improve things while
still be in C.
>> >>
>> >> You say that the compiler would take care of a lot of things: so far,
the main thing that has been mentionned is raii. While it is certainly a
useful concept, I find it ewtremely difficult to use correctly in real
applications. Things that are simple to do on simple examples become really
hard to deal with when features start to interact with each other (which is
always in c++). Writing robust code that is exception safe with the stl
requires a lot of knowledge. I don't have this knowledge. I have .o doubt
Mark has this knowledge. Does anyone else on this list has ?
>> >
>> >
>> > I have the sense you have written much in C++. Exception handling is
maybe one of the weakest aspects of C, that is, it basically doesn't have
any. The point is, I'd rather not *have* to worry much about the C/C++ side
of things, and I think once a solid foundation is in place I won't have to
nearly as much.
>> >
>> > Back in the late 80's I used rather nice Fortran and C++ compilers for
writing code to run in extended DOS (the dos limit was 640 KB at that
time). They were written in - wait for it - Pascal. The authors explained
this seemingly odd decision by claiming that Pascal was better for bigger
projects than C, and I agreed with them ;) Now you can point to Linux,
which is 30 million + lines of C, but that is rather exceptional and the
barriers to entry at this point are pretty darn high. My own experience is
that beginners can seldom write more than a page of C and get it right,
mostly because of pointers. Now C++ has a ton of subtleties and one needs
to decide up front what parts to use and what not, but once a well designed
system is in place, many things become easier because a lot of housekeeping
is done for you.
>> >
>> > My own concern here is that the project is bigger than Mark thinks and
he might get sucked off into a sideline, but I'd sure like to see the
experiment made.
>> >>
>> >> >> I would much rather move most part to cython to solve subtle ref
counting issues, typically.
>> >> >
>> >> >
>> >> > Not me, I'd rather write most stuff in C/C++ than Cython, C is
cleaner ;) Cython good for the Python interface, but once past that barrier
C is easier, and C++ has lots of useful things.
>> >> >>
>> >> >> The only way that i know of to have a stable and usable abi is to
wrap the c++ code in c. Wrapping c++ libraries in python  has always been a
pain in my experience. How are template or exceptions handled across
languages ? it will also be a significant issue on windows with open source
compilers.
>> >> >>
>> >> >> Interestingly, the api from clang exported to other languages is
in c...
>> >> >
>> >> >
>> >> > The api isn't the same as the implementation language. I wouldn't
prejudge these issues, but some indication of how they would be solved
might be helpful.
>> >>
>> >> I understand that api and inplementation language are not the same:
you just quoted the part where I was mentioning it :)
>> >>
>> >> Assuming a c++ inplementation with a c api, how will you deal with
templates ? how will you deal with exception ? How will you deal with
exception crossing dll/so between different compilers, which is a very
common situation in our community ?
>> >
>> >
>> > None of these strike me as relevant, I mean, they are internals, not
api problems, and shouldn't be visible to the user. How Mark would
implement the C++ API, as opposed to the C API I don't know, but since both
would be there I don't see the problem. But really, we need more details on
how these things would work.
>>
>> I don't understand why you think this is not relevant ? If numpy is in
c++, with a C API, most users of numpy C/C++ API will use the C API, at
least at first, since most of them are in C. Changes of restrictions on how
this API xan be used is visible.
>>
>> To be more concrete, if numpy is built by MS compiler, and an exception
is thrown, you will have a lots of trouble with an extension built with gcc.
>
>
> Why would you even see an exception if it is caught before it escapes? I
would expect the C API to behave just as it currently does. What am I
missing?

I believe that you cannot always guarantee that no exception will go
through even with a catch all at the c++ -> c layer. I will try to find
more about it, as I cannot remember the exact details I have in mind (need
to look at the customer's code).

David
>>
>> I have also observed some weird things in linux when mixing intel and
gcc. This will have significant impacts on how people will be able to use
extensions.
>>
>> I am a bit surprised by the claim.that abi and cross language API are
not an issue with c++: it is a widely shared issue even within c++
proponents.
>
>
> Chuck
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20120217/8359b412/attachment.html>