2011/5/31 Dag Sverre Seljebotn <d.s.seljeb...@astro.uio.no>: > On 05/31/2011 01:07 PM, Vitja Makarov wrote: >> >> 2011/5/24 Stefan Behnel<stefan...@behnel.de>: >>> >>> Vitja Makarov, 23.05.2011 21:33: >>>> >>>> 2011/5/23 Stefan Behnel: >>>>> >>>>> However, once we really know which values change between yield calls, >>>>> i.e. >>>>> which ones need to be stored away, it will actually be less expensive >>>>> in >>>>> most cases. We currently pay the indirection penalty for each access, >>>>> even >>>>> read access, whereas the C compiler can then keep important variables >>>>> in >>>>> registers and only write them back once per yield. >>>>> >>>> >>>> I think that all not NULL variables should be saved/restored inside >>>> yield. >>>> I can not really track changes only assignments. >>> >>> I mean "assignments" when I write "changes". When a variable is being >>> assigned to, we should assume that its value changed. Users can be >>> expected >>> to be smart enough to avoid unnecessary assignments in most cases, >>> there's >>> no need to put work into optimising them away automatically. >>> >>> >>>> for i in a: >>>> yield i # j is NULL here >>>> for j in b: >>>> yield j # a, b, i ,j should be saved/restored >>> >>> Right. However, in general, we can expect that most variables will have >>> been >>> initialised on a yield. >>> >>> We can still avoid storing away C typed variables that are not being used >>> later on, because they are not reference counted. >>> >>> And if the user sets 'a' and 'i' to None between the loops, they won't >>> need >>> to be saved on the second yield either. But that's an optimisation, not a >>> requirement. >>> >> >> What about copying C++ structs and objects with constructor (and/or >> overloaded = method)? >> That wouldn't work well. > > Currently I believe C++ objects are only supported through pointers, which > of course are copyable. If or when we support C++ objects on the stack, then > we should definitely avoid copying them. > > If you declare a C++ class as a struct Cython-side then I think we should > assume that we can freely invoke the copy constructor and assignment > operator in this context. >
May be it's better to declare struct with all the locals and then copy it with memcpy()? Btw cpp still wouldn't love it :( So probably it's better to look forward for stack switching library... -- vitja. _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
