Re: [C++-sig] Iterating over small objects

[Babak Khataee]

Okay cool thanks your input.

For any one else has a similar problem - writing a simple iterator function
in python (which is a generator) and assigning that to the __iter__ member
works well as an alternative. For me this turned out to be considerably
faster than using a c++ iterator/getitem iteration.

On 19 January 2012 19:37, Jim Bosch  wrote:

> On 01/19/2012 02:08 PM, babak wrote:
>
>> Hi guys,
>>
>> Has anyone encountered (what feels like) quite slow iteration when looping
>> over small containers ? I'm in a situation where I'm iterating over
>> 10+
>> 3d vectors and its taking much longer than I'd expect. The vector type is
>> bound via boost::python and has an iter method which uses range(being,
>> end)
>> for the iteration.
>>
>> I've attached a simple example binding and python test to illustrate what
>> I
>> mean more clearly. I'm under the impression that in a situation like this
>> the overhead of creating the iterator is greater than the actual
>> iteration,
>> but thats just a guess. Alternatively my perspective on what the iteration
>> speed should be might be completely skewed, so any help in clarifying
>> what's
>> going on here would be greatly appreciated.
>>
>>
> My sense is that this is something that really can't be expected to be
> efficient across the C++/Python boundary.  There is some overhead
> associated with creating the exposures, and there's also some overhead in
> converting the types, especially if those vectors aren't builtin numeric
> types.
>
> If you can redesign the C++/Python boundary to convert your vectors
> directly into Python lists or tuples instead of wrapped C++ vectors, I
> expect you'll see an improvement, because you'll be able to take advantage
> of whatever optimization the Python developers have put into iteration over
> those classes.  Of course, it's best by far to do whatever iteration you
> can in C++ if performance is important, but I'm guessing that's not an
> option here.
>
> Jim
>
>
> __**_
> Cplusplus-sig mailing list
> Cplusplus-sig@python.org
> http://mail.python.org/**mailman/listinfo/cplusplus-sig
>
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig

[C++-sig] A few questions on Boost.Python

[Bo Jensen]

Hi,

I have been looking into the best way for me to make a python wrapper for a
C++ library. Boost.Python looks nice and seem to fit my needs, but I have a
few questions before I dig in deep and do the implementation.

What I want to do :

I have a very thin header only C++ library, which is an extension on top of
a c library i.e some of the C++ functions call functions in a C dll/so. So
the C++ library only provides a nice way of using the C library with
operators and overloading etc. For this library I want to make an python
interface, which only should mimic the C++ classes and functions i.e there
will be a 1:1 mapping.

Questions :

1) Would Boost.Python be suited for such a task ?

2) What kind of speed can I expect ? I read somewhere that cython was much
faster (but it seems to be less portable and flexible).

3) Will I experience problems with types like wchar or long long ?

4) How do I link to my C library ?

5) I also read that Boost.Python is not thread safe, is that true and if
yes can it be fixed/hacked ?

6) Regarding portability, will I have to recompile for each python version ?

7) 64 bit is supported right ?

Thanks to anybody providing some insight.

/Bo
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] A few questions on Boost.Python

[Jim Bosch]

On 01/23/2012 02:35 PM, Bo Jensen wrote:

Hi,

I have been looking into the best way for me to make a python wrapper for a
C++ library. Boost.Python looks nice and seem to fit my needs, but I have a
few questions before I dig in deep and do the implementation.

What I want to do :

I have a very thin header only C++ library, which is an extension on top of
a c library i.e some of the C++ functions call functions in a C dll/so. So
the C++ library only provides a nice way of using the C library with
operators and overloading etc. For this library I want to make an python
interface, which only should mimic the C++ classes and functions i.e there
will be a 1:1 mapping.

Questions :

1) Would Boost.Python be suited for such a task ?



Almost definitely.  For this sort of task most people use Boost.Python, 
SWIG, or the raw Python C-API.


Boost.Python is my favorite, and probably the favorite of most people on 
this list.  The Python C-API (what I think you're calling "cython") is a 
lot less automatic; you'll find yourself writing a lot more code, and 
doing a lot more memory management.  SWIG can be much more automatic if 
your C/C++ interface is sufficiently simple, but it's generally less 
safe w.r.t. memory management, it chokes on complex C++, and I find it 
much more difficult to debug.



2) What kind of speed can I expect ? I read somewhere that cython was much
faster (but it seems to be less portable and flexible).



Note that none of these tools will work with Python interpreters other 
than the standard C one - no Jython, no IronPython.


The performance of any of these wrapper tools is largely determined by 
how often you cross the C++/Python boundary.  If you have a huge number 
of types, you may see more of a performance hit with Boost.Python or 
SWIG, because type conversions involve traversing a registry of all the 
types.  I wouldn't worry about performance of the wrapper layer unless 
you have a good reason to think you need to.



3) Will I experience problems with types like wchar or long long ?



I don't think wchar* will be automatically converted to Python str or 
unicode, the way char* is.


I'm pretty sure long long will be fine, but I have't really tested it much.


4) How do I link to my C library ?



Any of these tools will create a shared library (.dll, .so, .dylib, etc) 
that you link normally with other shared libraries.  Python will load 
that library when you import your wrapped module.



5) I also read that Boost.Python is not thread safe, is that true and if
yes can it be fixed/hacked ?



Other people on this list know a lot more than I do about this topic.  I 
believe the answer depends on whether the multithreaded programming 
crosses the C++/Python boundary.



6) Regarding portability, will I have to recompile for each python version ?



Yes, for Python major releases (2.6 -> 2.7).  No for minor releases 
(2.7.2 -> 2.7.3).  I believe this will be more or less the same for any 
Python wrapper tool.



7) 64 bit is supported right ?



Absolutely.


Thanks to anybody providing some insight.



Sure.  Good luck!

Jim
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] A few questions on Boost.Python

[Anders Wallin]

>> 5) I also read that Boost.Python is not thread safe, is that true and if
>> yes can it be fixed/hacked ?
>>
>
> Other people on this list know a lot more than I do about this topic.  I
> believe the answer depends on whether the multithreaded programming crosses
> the C++/Python boundary.


FWIW, it is quite straightforward to write C++ code that uses e.g.
OpenMP to do work in multiple threads, and then returns results to
python.
I've only done a case where we wait in python for the c++
function(that potentially uses OpenMP or other threading libs) to
finish before continuing.

AW
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig