From: Robert S. <ta...@tr...> - 2013-10-24 23:01:36
|
On Wed, Oct 23, 2013 at 06:06:47PM +0100, William S Fulton wrote: > On 22/10/13 22:45, Robert Stone wrote: > > I mean that I think I can significantly reduce the risk of this > >feature by re-cutting my work as a set of enhancements that only affect > >wrappers when directors are enabled. I have been trying to deeply > >change the way SWIG handles Perl, but I think this might be a mistake. > >I have not been thinking about "-noproxy" mode much and I expect to find > >other compatibility problems. > Can't you just deal with -noproxy with "if (!blessed) ..." in > perl.cxx? That is pretty much how we cope with it in other > languages. The idea is that a flattened C interface is generated and > then the proxy classes are object oriented wrappers around it. Even > though you have moved the Perl proxy classes from being defined in > Perl code to C++ code, surely this concept still applies? The concept still applies. I should be able to bring it back. I thought the mode was deprecated and wasn't giving it a great deal of attention beyond the potential for crashes. > > Mechanically, this would be trying to change the proposal to a > >set of additions to the code wrapped in "if (directorsEnabled()) {}" > >conditions as much as possible. That would to make the static member > >function compatibility issue vanish, and solve the legacy destructor > >problem. It should also mean the code can continue to support perl v5.6 > >when directors are not needed. > > > What minimum version is required for your branch as it stands? Or in > other words, what minimum version is required to support directors > if taking the new approach in the above paragraph? The branch requires perl v5.8, but I should be able to retain v5.6 support back if I omit the new object wrappers. I forgot that master still runs on perl v5.6 until I was back reading the docs on the master branch about the explicit DESTROY invocation. > > One downside would be that SWIG_GetModule() wouldn't be able to > >share objects between director enabled and directorless modules. And, > >of course, enabling directors for existing code would trigger the > >altered static member function and destructor semantics. > > > What if someone turns on directors for a module. Will a user's > existing Perl code continue to work unaltered? In particular will > the creation and deletion of objects continue to work? I presume > that "delete obj" will work with and without this new approach? > Unless I understand this incorrectly, this sounds messy, ie use the > old wrapping approach with Perl code for proxy classes, then using > C++ defined proxy classes for directors. It sounds too different > when turning on directors when really all that should happen is > everything is much the same except for polymorphic upcall support > being added. This is correct, I was thinking that we might only use the new object wrappers and runtime semantics in director mode, but this would be a burden when directors are enabled on legacy code. If we omit the new object wrappers, then I suspect we could get to a point where full reverse compatibility is maintained. Directors would need SWIG specific mechanisms for subclassing, destructor methods, attribute declarations, and static member functions. I will investigate this route. > Overall it looks like a hard call as I think you are saying that > providing full backwards compatibility is hard in order to add > director support. I don't object to breaking backwards compatibility > if we really have to in order to take a few steps forwards. Clearly > directors are a big step forward. Are there other improvements in > the new proxy classes generation? I hope it doesn't seem like I'm being evasive. As you're asking me about these issues, I'm reevaluating if the costs are necessary. You reminded me of the hack I'd proposed in cwrap.c and I found a way around it that I never saw before. I think with more revelations like that one I can probably make directors work without an overhaul of the module. The main advantage of the branch is more performant, memory efficient, native Perl feeling objects that are less likely to trigger segfaults when used creatively. I'm really proud of what I've done there and have used it in production environments for a couple of large projects. The new object wrappers maintain a pointer cache and keep refcounts to better mimic the lifetimes of native Perl objects. This also allows %newobject and the DISOWN typemap to completely manage object ownership for nearly every use pattern I've encountered. The current perl5 wrapper runtime exposes all its guts to Perl, and consequently the wrapper code can do very little without trips into the interpreter. Something like: my $f = example::Foo->new(); $f->{i} = 12; my $g = example::Foo->new(); $g->{i} = 32; $g->DESTROY(); ${tied %$g} = ${tied %$f}; print $g->{i}, "\n"; $g->DISOWN(); actually works to make one wrapper alias another. That may seem like an abuse, but I wouldn't be surprised to see some variant of this used for array element access somewhere in the wild. Here are the benchmarks comparing master to the branch based on the current work: object creation: Rate trunk_new p5imp_new trunk_new 190934/s -- -48% p5imp_new 367991/s 93% -- attribute setter: Rate trunk_sa p5imp_sa trunk_sa 555474/s -- -93% p5imp_sa 8146970/s 1367% -- attribute getter: Rate trunk_ga p5imp_ga trunk_ga 543310/s -- -86% p5imp_ga 3814279/s 602% -- function call with native type arguments and return value: Rate trunk_nt p5imp_nt trunk_nt 5028510/s -- -4% p5imp_nt 5241261/s 4% -- function call with an object return value: Rate trunk_mkp p5imp_mkp trunk_mkp 380670/s -- -73% p5imp_mkp 1409188/s 270% -- function call with an object argument: Rate trunk_cvp p5imp_cvp trunk_cvp 4766252/s -- -14% p5imp_cvp 5534273/s 16% -- polymorphic function: Rate trunk_poly p5imp_poly trunk_poly 3260219/s -- -19% p5imp_poly 4034174/s 24% -- But I can't get these improvements in safety and performance without some dramatic retooling to lock control away from interpreter code. They ended up paired with the directors feature because it seemed necessary to get to directors at first, but now I'm not sure. |