From: Stefan Z. <ste...@am...> - 2010-10-25 18:01:11
|
Howdy, I'm using swig to wrap a very large API to python, perl, and ruby. As a general observation, I find that the ruby and perl wrappers are comparable in performance, but the python wrappers are 5-10x slower for most test cases. As an experiment, I tried hand-wrapping, in optimized C code, part of the API for perl. I found that, with a few tweaks, I could get the swig wrappers to within 30% of my "best effort" wrappers. I tried the same thing with python, and I found that the swig wrappers were more than 10x slower than my "best effort" wrappers; in some pathological cases, the swig wrappers were 100x slower! A few more experiments seem to indicate that the lion's share of the performance difference is attributable to the use of pure-python proxy classes by swig. That kind of performance drag is a show-stopper for this project. I seem to remember that in bygone versions of swig, the '-noproxy' option would disable the creation of proxy classes in python. However, that no longer seems to work. Is there any way to get that option back? Or can anyonse suggest any other remediation of this issue? Thanks, Stefan Zager |
From: Amaury F. d'A. <ama...@gm...> - 2010-10-25 18:55:53
|
Hi, 2010/10/25 Stefan Zager <ste...@am...>: > Howdy, > > I'm using swig to wrap a very large API to python, perl, and ruby. As a general > observation, I find that the ruby and perl wrappers are comparable in > performance, but the python wrappers are 5-10x slower for most test cases. > > As an experiment, I tried hand-wrapping, in optimized C code, part of the API > for perl. I found that, with a few tweaks, I could get the swig wrappers to > within 30% of my "best effort" wrappers. > > I tried the same thing with python, and I found that the swig wrappers were more > than 10x slower than my "best effort" wrappers; in some pathological cases, the > swig wrappers were 100x slower! A few more experiments seem to indicate that > the lion's share of the performance difference is attributable to the use of > pure-python proxy classes by swig. That kind of performance drag is a > show-stopper for this project. > > I seem to remember that in bygone versions of swig, the '-noproxy' option would > disable the creation of proxy classes in python. However, that no longer seems > to work. Is there any way to get that option back? Or can anyonse suggest any > other remediation of this issue? The '-noproxy' option just omits the proxy classes, and does not change the generated C code. The solution would be to directly create the classes in C code, but this is a considerable change. I did this once in a (very very) old version of Swig, and I managed to remove almost all code in the shadow python file. I did not benchmark it precisely at the time, but I remember a large library (wxPython) used to load 5 times faster after the changes. Since Swig changed so much since then, the complete work needs to be done again. But at least you know that this is possible ;-) I'll try to find my old copy of the code. -- Amaury Forgeot d'Arc |
From: Stefan Z. <ste...@am...> - 2010-11-20 08:13:30
|
As I threatened, I have modified the python module to add an option which will create python builtin classes. It's not 100% complete, and it has a couple of limitations, most importantly that it only works for type hierarchies with single inheritance. With my modifications, I have seen significant runtime improvements -- typically 4-6 times faster -- for a particular performance-critical API we use. Seems to me that this could be a very welcome enhancement to swig/python developers, and I'd like to find out what the process is for submitting it. Thanks, Stefan Zager On Mon, 25 Oct 2010, Amaury Forgeot d'Arc wrote: > Hi, > > 2010/10/25 Stefan Zager <ste...@am...>: > > Howdy, > > > > I'm using swig to wrap a very large API to python, perl, and ruby. As a general > > observation, I find that the ruby and perl wrappers are comparable in > > performance, but the python wrappers are 5-10x slower for most test cases. > > > > As an experiment, I tried hand-wrapping, in optimized C code, part of the API > > for perl. I found that, with a few tweaks, I could get the swig wrappers to > > within 30% of my "best effort" wrappers. > > > > I tried the same thing with python, and I found that the swig wrappers were more > > than 10x slower than my "best effort" wrappers; in some pathological cases, the > > swig wrappers were 100x slower! A few more experiments seem to indicate that > > the lion's share of the performance difference is attributable to the use of > > pure-python proxy classes by swig. That kind of performance drag is a > > show-stopper for this project. > > > > I seem to remember that in bygone versions of swig, the '-noproxy' option would > > disable the creation of proxy classes in python. However, that no longer seems > > to work. Is there any way to get that option back? Or can anyonse suggest any > > other remediation of this issue? > > The '-noproxy' option just omits the proxy classes, and does not change the > generated C code. > > The solution would be to directly create the classes in C code, but this is a > considerable change. > I did this once in a (very very) old version of Swig, and I managed to remove > almost all code in the shadow python file. > I did not benchmark it precisely at the time, but I remember a large library > (wxPython) used to load 5 times faster after the changes. > > Since Swig changed so much since then, the complete work needs to be done > again. But at least you know that this is possible ;-) > I'll try to find my old copy of the code. > > -- > Amaury Forgeot d'Arc > > |
From: Zager, S. <ste...@am...> - 2010-11-29 06:41:03
|
I haven't tried running the test suite yet; I still have some work to do to complete the implementation. However, I have tried running a few of our internal benchmarks with built-in classes (my changes); with the -O option; and with neither (numbers are elapsed seconds) : test builtin -O neither ----------------------------------- test1 5.37 8.39 13.64 test2 14.85 20.05 33.06 test3 2.55 6.53 7.64 The numbers do not include start-up time, and they run with the cache already warmed up. test3 is particularly interesting, because it mostly uses API calls that return very quickly in C++, so the runtime is weighted towards the wrapper overhead. If you are interested, the API in question is OpenAccess: http://www.si2.org/?page=69 Thanks, Stefan Zager ________________________________________ From: William Fulton [wi...@fu...] On Behalf Of William S Fulton [ws...@fu...] Sent: Thursday, November 25, 2010 11:38 AM To: Zager, Stefan Cc: Amaury Forgeot d'Arc; swi...@li... Subject: Re: [Swig-devel] python proxy class performance There isn't really a Python maintainer at the moment so there isn't much chance to peer review very well for submission, however, the SWIG test-suite must pass at a minimum. The changes sound good, but in order to assess it given the lack of Python people around, can you please provide statistics re performance vs the -O option for whatever code you benchmarked plus the test-suite. Any performance difference between Python 2.x and 3? When the code is ready for submission please provide a SF patch. Thanks William Stefan Zager wrote: > As I threatened, I have modified the python module to add an option which will > create python builtin classes. It's not 100% complete, and it has a couple of > limitations, most importantly that it only works for type hierarchies with > single inheritance. > > With my modifications, I have seen significant runtime improvements -- > typically 4-6 times faster -- for a particular performance-critical API we use. > Seems to me that this could be a very welcome enhancement to swig/python > developers, and I'd like to find out what the process is for submitting it. > > Thanks, > > Stefan Zager |
From: William S F. <ws...@fu...> - 2010-12-03 16:22:14
|
That's rather encouraging. I hope you find the time to get this patch up to standard so we can include it into future releases. William Zager, Stefan wrote: > I haven't tried running the test suite yet; I still have some work to do to complete the implementation. However, I have tried running a few of our internal benchmarks with built-in classes (my changes); with the -O option; and with neither (numbers are elapsed seconds) : > > test builtin -O neither > ----------------------------------- > test1 5.37 8.39 13.64 > test2 14.85 20.05 33.06 > test3 2.55 6.53 7.64 > > The numbers do not include start-up time, and they run with the cache already warmed up. test3 is particularly interesting, because it mostly uses API calls that return very quickly in C++, so the runtime is weighted towards the wrapper overhead. > > If you are interested, the API in question is OpenAccess: > > http://www.si2.org/?page=69 > > Thanks, > > Stefan Zager > > ________________________________________ > From: William Fulton [wi...@fu...] On Behalf Of William S Fulton [ws...@fu...] > Sent: Thursday, November 25, 2010 11:38 AM > To: Zager, Stefan > Cc: Amaury Forgeot d'Arc; swi...@li... > Subject: Re: [Swig-devel] python proxy class performance > > There isn't really a Python maintainer at the moment so there isn't much > chance to peer review very well for submission, however, the SWIG > test-suite must pass at a minimum. The changes sound good, but in order > to assess it given the lack of Python people around, can you please > provide statistics re performance vs the -O option for whatever code you > benchmarked plus the test-suite. Any performance difference between > Python 2.x and 3? When the code is ready for submission please provide a > SF patch. > > Thanks > William > > Stefan Zager wrote: >> As I threatened, I have modified the python module to add an option which will >> create python builtin classes. It's not 100% complete, and it has a couple of >> limitations, most importantly that it only works for type hierarchies with >> single inheritance. >> >> With my modifications, I have seen significant runtime improvements -- >> typically 4-6 times faster -- for a particular performance-critical API we use. >> Seems to me that this could be a very welcome enhancement to swig/python >> developers, and I'd like to find out what the process is for submitting it. >> >> Thanks, >> >> Stefan Zager > > |
From: Stefan Z. <ste...@am...> - 2010-10-25 19:06:19
|
On Mon, 25 Oct 2010, Amaury Forgeot d'Arc wrote: > Hi, > > 2010/10/25 Stefan Zager <ste...@am...>: > > Howdy, > > > > I'm using swig to wrap a very large API to python, perl, and ruby. As a general > > observation, I find that the ruby and perl wrappers are comparable in > > performance, but the python wrappers are 5-10x slower for most test cases. > > > > As an experiment, I tried hand-wrapping, in optimized C code, part of the API > > for perl. I found that, with a few tweaks, I could get the swig wrappers to > > within 30% of my "best effort" wrappers. > > > > I tried the same thing with python, and I found that the swig wrappers were more > > than 10x slower than my "best effort" wrappers; in some pathological cases, the > > swig wrappers were 100x slower! A few more experiments seem to indicate that > > the lion's share of the performance difference is attributable to the use of > > pure-python proxy classes by swig. That kind of performance drag is a > > show-stopper for this project. > > > > I seem to remember that in bygone versions of swig, the '-noproxy' option would > > disable the creation of proxy classes in python. However, that no longer seems > > to work. Is there any way to get that option back? Or can anyonse suggest any > > other remediation of this issue? > > The '-noproxy' option just omits the proxy classes, and does not change the > generated C code. > > The solution would be to directly create the classes in C code, but this is a > considerable change. > I did this once in a (very very) old version of Swig, and I managed to remove > almost all code in the shadow python file. > I did not benchmark it precisely at the time, but I remember a large library > (wxPython) used to load 5 times faster after the changes. > > Since Swig changed so much since then, the complete work needs to be done > again. But at least you know that this is possible ;-) > I'll try to find my old copy of the code. > > -- > Amaury Forgeot d'Arc That would be much appreciated. The API in question has a few features that make it very amenable to wrapping with new built-in types; in particular: - It has a large and deep class hierarchy, but only single inheritance - Most of the interesting classes don't have ctors/dtors; their memory is managed within the API, and they are passed as pointers. - This API isn't suitable for extending (either in C or in scripting). Don't know how common this case is, but it leaves a lot of performance lying on the floor. Thanks, Stefan |
From: William S F. <ws...@fu...> - 2010-10-25 20:49:06
|
Stefan Zager wrote: > Howdy, > > I'm using swig to wrap a very large API to python, perl, and ruby. As a general > observation, I find that the ruby and perl wrappers are comparable in > performance, but the python wrappers are 5-10x slower for most test cases. > > As an experiment, I tried hand-wrapping, in optimized C code, part of the API > for perl. I found that, with a few tweaks, I could get the swig wrappers to > within 30% of my "best effort" wrappers. > > I tried the same thing with python, and I found that the swig wrappers were more > than 10x slower than my "best effort" wrappers; in some pathological cases, the > swig wrappers were 100x slower! A few more experiments seem to indicate that > the lion's share of the performance difference is attributable to the use of > pure-python proxy classes by swig. That kind of performance drag is a > show-stopper for this project. > > I seem to remember that in bygone versions of swig, the '-noproxy' option would > disable the creation of proxy classes in python. However, that no longer seems > to work. Is there any way to get that option back? Or can anyonse suggest any > other remediation of this issue? > Marcelo did a lot of work optimising the python layer. But in order to utilise it, I think you need to use the -O option. It will be well worth your while browsing the CHANGES file to see the work he did in this area. swig -python -help shows this: -O - Enable the following optimization options: -modern -fastdispatch -nosafecstrings -fvirtual -noproxydel -fastproxy -fastinit -fastunpack -fastquery -modernargs -nobuildnone How much faster does it go with these turned on? William |
From: Stefan Z. <ste...@am...> - 2010-10-25 21:24:24
|
On Mon, 25 Oct 2010, William S Fulton wrote: > Stefan Zager wrote: > > Howdy, > > > > I'm using swig to wrap a very large API to python, perl, and ruby. As a general > > observation, I find that the ruby and perl wrappers are comparable in > > performance, but the python wrappers are 5-10x slower for most test cases. > > > > As an experiment, I tried hand-wrapping, in optimized C code, part of the API > > for perl. I found that, with a few tweaks, I could get the swig wrappers to > > within 30% of my "best effort" wrappers. > > > > I tried the same thing with python, and I found that the swig wrappers were more > > than 10x slower than my "best effort" wrappers; in some pathological cases, the > > swig wrappers were 100x slower! A few more experiments seem to indicate that > > the lion's share of the performance difference is attributable to the use of > > pure-python proxy classes by swig. That kind of performance drag is a > > show-stopper for this project. > > > > I seem to remember that in bygone versions of swig, the '-noproxy' option would > > disable the creation of proxy classes in python. However, that no longer seems > > to work. Is there any way to get that option back? Or can anyonse suggest any > > other remediation of this issue? > > > Marcelo did a lot of work optimising the python layer. But in order to > utilise it, I think you need to use the -O option. It will be well worth > your while browsing the CHANGES file to see the work he did in this area. > > swig -python -help shows this: > > -O - Enable the following optimization options: > -modern -fastdispatch -nosafecstrings -fvirtual -noproxydel > -fastproxy -fastinit -fastunpack -fastquery -modernargs -nobuildnone > > How much faster does it go with these turned on? Urg... '-O' appears to have problems with variable-length arguments. There's a class with these overloaded methods: class MyException; class MyString; typedef int MyInt; class MyClass { virtual void log(const char *format, ...); virtual void log(const MyException &excp); virtual void log(const MyString &fileName, const MyInt lineNumber, const MyException &excp); virtual void log(const MyString &fileName, const MyInt lineNumberStart, const MyInt lineNumberEnd, const MyException &excp); }; Leaving aside stylistic complaints, of which I have several (this is not my code), the swig-generated dispatch method has some faulty logic, such as: check_2: if (argc >= 2) { return _wrap_MyClass_log__SWIG_0(self, argc, argv); } if (argc == 4) { return _wrap_MyClass_log__SWIG_3(self, argc, argv); } if (argc == 5) { return _wrap_MyClass_log__SWIG_4(self, argc, argv); } As you can see, the second and third 'if' clauses are unreachable. I also get compilation errors, because the signature line of _wrap_MyClass_log__SWIG_0 is: SWIGINTERN PyObject *_wrap_MyClass_log__SWIG_0(PyObject *self, PyObject *args); ... which doesn't match the way it's invoked. Maybe you want to know this, maybe you don't. Please don't give it a lot of time on my account; I'm more interested in looking at Amaury's code. Thanks, Stefan |
From: Olly B. <ol...@su...> - 2010-10-26 00:31:04
|
On 2010-10-25, Stefan Zager <ste...@am...> wrote: > On Mon, 25 Oct 2010, William S Fulton wrote: >> -O - Enable the following optimization options: >> -modern -fastdispatch -nosafecstrings -fvirtual -noproxydel >> -fastproxy -fastinit -fastunpack -fastquery -modernargs -nobuildnone >> >> How much faster does it go with these turned on? > > Urg... '-O' appears to have problems with variable-length arguments. You could try using the explicit list of options which -O expands to, and omit each in turn to see which one is causing this problem, and what sort of performance gain the rest give. > the swig-generated dispatch method has some faulty logic, such as: > [...] > I also get compilation errors, because the signature line of > _wrap_MyClass_log__SWIG_0 is: > > SWIGINTERN PyObject *_wrap_MyClass_log__SWIG_0(PyObject *self, PyObject *args); > > ... which doesn't match the way it's invoked. > > Maybe you want to know this, maybe you don't. Please don't give it a lot of > time on my account; I'm more interested in looking at Amaury's code. It would be useful to have coverage for this in the testsuite, regardless of whether we switch to using Amaury's code or not - if it's been broken once, then chances are it's a likely area for future breakage. Cheers, Olly |
From: William S F. <ws...@fu...> - 2010-10-26 20:31:54
|
Olly Betts wrote: > On 2010-10-25, Stefan Zager <ste...@am...> wrote: >> On Mon, 25 Oct 2010, William S Fulton wrote: >>> -O - Enable the following optimization options: >>> -modern -fastdispatch -nosafecstrings -fvirtual -noproxydel >>> -fastproxy -fastinit -fastunpack -fastquery -modernargs -nobuildnone >>> >>> How much faster does it go with these turned on? >> Urg... '-O' appears to have problems with variable-length arguments. > > You could try using the explicit list of options which -O expands to, and > omit each in turn to see which one is causing this problem, and what sort > of performance gain the rest give. > >> the swig-generated dispatch method has some faulty logic, such as: >> [...] >> I also get compilation errors, because the signature line of >> _wrap_MyClass_log__SWIG_0 is: >> >> SWIGINTERN PyObject *_wrap_MyClass_log__SWIG_0(PyObject *self, PyObject *args); >> >> ... which doesn't match the way it's invoked. >> >> Maybe you want to know this, maybe you don't. Please don't give it a lot of >> time on my account; I'm more interested in looking at Amaury's code. > > It would be useful to have coverage for this in the testsuite, regardless > of whether we switch to using Amaury's code or not - if it's been broken > once, then chances are it's a likely area for future breakage. > The test-suite only has one problem with -O and it is a runtime problem in directors: env SWIG_FEATURES=-O make check-python-test-suite ... checking testcase director_protected (with run test) under python Traceback (most recent call last): File "./director_protected_runme.py", line 60, in <module> raise RuntimeError," bad FooBar::pong" RuntimeError: bad FooBar::pong make[1]: *** [director_protected.cpptest] Error 1 We'll have to add Stefan's overloaded methods with varargs into the test-suite and fix as this hasn't been logged as a bug before. William |
From: Amaury F. d'A. <ama...@gm...> - 2010-10-25 20:49:38
|
2010/10/25 Stefan Zager <ste...@am...>: > That would be much appreciated. The API in question has a few features that > make it very amenable to wrapping with new built-in types; in particular: OK, the patch is here: http://paste.pocoo.org/raw/281419/ Note that it's a patch against a *very* old version. The file CHANGES.current starts with the lines: Version 1.3.23 (working version) ================================= 11/15/04: mmatus .... It will certainly not apply to a newer version. Far too many things have changed. > - It has a large and deep class hierarchy, but only single inheritance > - Most of the interesting classes don't have ctors/dtors; their memory is > managed within the API, and they are passed as pointers. > - This API isn't suitable for extending (either in C or in scripting). > > Don't know how common this case is, but it leaves a lot of performance lying on > the floor. All these are not really necessary. Even C-written PyTypeObjects can: - have multiple bases (use tp_bases) - have constructors and finalizers - be inherited in Python code. -- Amaury Forgeot d'Arc |
From: Stefan Z. <ste...@am...> - 2010-10-25 21:00:34
|
On Mon, 25 Oct 2010, Amaury Forgeot d'Arc wrote: > > - It has a large and deep class hierarchy, but only single inheritance > > - Most of the interesting classes don't have ctors/dtors; their memory is > > managed within the API, and they are passed as pointers. > > - This API isn't suitable for extending (either in C or in scripting). > > > > Don't know how common this case is, but it leaves a lot of performance lying on > > the floor. > > All these are not really necessary. Even C-written PyTypeObjects can: > - have multiple bases (use tp_bases) > - have constructors and finalizers > - be inherited in Python code. Agreed -- but single inheritance allows for optimized up-casting without using the full swig type machinery; and no public ctors/dtors means that object ownership doesn't need to be tracked. I'm going to try the '-O' option, as suggested by William, and see how much of a difference it makes. But it's likely that I will also work on updating and incorporating your work. Thanks again, Stefan |
From: William S F. <ws...@fu...> - 2010-11-25 19:38:20
|
There isn't really a Python maintainer at the moment so there isn't much chance to peer review very well for submission, however, the SWIG test-suite must pass at a minimum. The changes sound good, but in order to assess it given the lack of Python people around, can you please provide statistics re performance vs the -O option for whatever code you benchmarked plus the test-suite. Any performance difference between Python 2.x and 3? When the code is ready for submission please provide a SF patch. Thanks William Stefan Zager wrote: > As I threatened, I have modified the python module to add an option which will > create python builtin classes. It's not 100% complete, and it has a couple of > limitations, most importantly that it only works for type hierarchies with > single inheritance. > > With my modifications, I have seen significant runtime improvements -- > typically 4-6 times faster -- for a particular performance-critical API we use. > Seems to me that this could be a very welcome enhancement to swig/python > developers, and I'd like to find out what the process is for submitting it. > > Thanks, > > Stefan Zager > > > On Mon, 25 Oct 2010, Amaury Forgeot d'Arc wrote: > >> Hi, >> >> 2010/10/25 Stefan Zager <ste...@am...>: >>> Howdy, >>> >>> I'm using swig to wrap a very large API to python, perl, and ruby. As a general >>> observation, I find that the ruby and perl wrappers are comparable in >>> performance, but the python wrappers are 5-10x slower for most test cases. >>> >>> As an experiment, I tried hand-wrapping, in optimized C code, part of the API >>> for perl. I found that, with a few tweaks, I could get the swig wrappers to >>> within 30% of my "best effort" wrappers. >>> >>> I tried the same thing with python, and I found that the swig wrappers were more >>> than 10x slower than my "best effort" wrappers; in some pathological cases, the >>> swig wrappers were 100x slower! A few more experiments seem to indicate that >>> the lion's share of the performance difference is attributable to the use of >>> pure-python proxy classes by swig. That kind of performance drag is a >>> show-stopper for this project. >>> >>> I seem to remember that in bygone versions of swig, the '-noproxy' option would >>> disable the creation of proxy classes in python. However, that no longer seems >>> to work. Is there any way to get that option back? Or can anyonse suggest any >>> other remediation of this issue? >> The '-noproxy' option just omits the proxy classes, and does not change the >> generated C code. >> >> The solution would be to directly create the classes in C code, but this is a >> considerable change. >> I did this once in a (very very) old version of Swig, and I managed to remove >> almost all code in the shadow python file. >> I did not benchmark it precisely at the time, but I remember a large library >> (wxPython) used to load 5 times faster after the changes. >> >> Since Swig changed so much since then, the complete work needs to be done >> again. But at least you know that this is possible ;-) >> I'll try to find my old copy of the code. >> >> -- >> Amaury Forgeot d'Arc >> >> > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today > http://p.sf.net/sfu/msIE9-sfdev2dev > > > ------------------------------------------------------------------------ > > _______________________________________________ > Swig-devel mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-devel |
From: Stefan Z. <ste...@am...> - 2010-11-30 20:02:21
|
On Thu, 25 Nov 2010, William S Fulton wrote: > There isn't really a Python maintainer at the moment so there isn't much > chance to peer review very well for submission, however, the SWIG > test-suite must pass at a minimum. The changes sound good, but in order > to assess it given the lack of Python people around, can you please > provide statistics re performance vs the -O option for whatever code you > benchmarked plus the test-suite. Any performance difference between > Python 2.x and 3? When the code is ready for submission please provide a > SF patch. I have verified that the test suite passes when the new -builtin option is *not* used (i.e., I haven't broken anything that was working before). But by default, the test suite doesn't exercise any of swig's options. What is the expectation for passing the test suite with various flags turned on? I noticed, for example, that the director_protected test fails when the '-fvirtual' option is used. It's likely that my changes won't be compatible with some of the existing tests and/or features. In particular, it's unlikely that my changes will mix with directors. It's easy enough to check for incompatible options in the code and croak, what are the expectations for getting through the test suite? BTW, I haven't tried this with python3, only python2. Thanks, Stefan Zager |
From: William S F. <ws...@fu...> - 2010-12-03 17:42:28
|
Stefan Zager wrote: > On Thu, 25 Nov 2010, William S Fulton wrote: > >> There isn't really a Python maintainer at the moment so there isn't much >> chance to peer review very well for submission, however, the SWIG >> test-suite must pass at a minimum. The changes sound good, but in order >> to assess it given the lack of Python people around, can you please >> provide statistics re performance vs the -O option for whatever code you >> benchmarked plus the test-suite. Any performance difference between >> Python 2.x and 3? When the code is ready for submission please provide a >> SF patch. > > I have verified that the test suite passes when the new -builtin option is *not* > used (i.e., I haven't broken anything that was working before). But by default, > the test suite doesn't exercise any of swig's options. What is the expectation > for passing the test suite with various flags turned on? I noticed, for > example, that the director_protected test fails when the '-fvirtual' option is > used. > > It's likely that my changes won't be compatible with some of the existing tests > and/or features. In particular, it's unlikely that my changes will mix with > directors. It's easy enough to check for incompatible options in the code and > croak, what are the expectations for getting through the test suite? > > BTW, I haven't tried this with python3, only python2. Okay, so the test-suite can be run with different options using the SWIG_FEATURES environment variable, for example: env SWIG_FEATURES=-O make check-python-test-suite BTW, I've just added this information to the test-suite documentation in Extending.html. Marcelo added this feature around the time he was testing these additional python optimisation features and the expectation is that the test-suite fully passes with -O. This has slipped us by so a fix is needed for the director_protected testcase. Clearly running with all the options is hard to achieve and given the huge number of permutations of swig options, compiler options, versions of the compilers, platforms, target languages etc, we can't test all the hundreds of permutations :( With regard to your -builtin option, I really would expect all the current tests to pass otherwise it is not up to the quality of the rest of the python module, certainly over time even if not at present. You are welcome to work in a branch until it is ready if you like. Directors are quite a popular feature, is there some technical reason why this won't work? William |
From: Stefan Z. <ste...@am...> - 2010-12-03 18:32:20
|
On Fri, 3 Dec 2010, William S Fulton wrote: > With regard to your -builtin option, I really would expect all the > current tests to pass otherwise it is not up to the quality of the rest > of the python module, certainly over time even if not at present. You > are welcome to work in a branch until it is ready if you like. Directors > are quite a popular feature, is there some technical reason why this > won't work? I don't know if there's a technical obstacle; I'll have to give that some thought. But director classes are somewhat anathema to what I'm doing: they imply a significant performance penalty for a kind of flexibility that's not typically needed when wrapping a third-party API which you use out of the box (i.e., you don't extend it; you use it as-is). I'll see if I can get directors to work with my changes. If you can set up a repository branch for me to work in, that would be great. Thanks, Stefan |
From: Stefan Z. <ste...@am...> - 2010-12-08 21:59:56
|
On Fri, 3 Dec 2010, William S Fulton wrote: > With regard to your -builtin option, I really would expect all the > current tests to pass otherwise it is not up to the quality of the rest > of the python module, certainly over time even if not at present. You > are welcome to work in a branch until it is ready if you like. Directors > are quite a popular feature, is there some technical reason why this > won't work? I'm happy to report that I have directors basically working with the -builtin option. I'm still in the process of plowing through the test suite; will keep you informed. Thanks, Stefan |