Dirk Reiners wrote: > Hi Marcus, > > Marcus Lindblom wrote: >> Yeah, I've implemented my own weak-ptr handling as well. It's not >> extensively used hence not very efficient/tested. (every refobject has a >> std::vector<weak_ptr> and on destruction, it sets the weak_ptrs to zero, >> which isn't very thread-safe. It's is efficient for weak_ptr lookup, >> since a valid weak_ptr is guaranteed to be correct. I have some control >> over ref-handling in my threads, so I can manage this currently.) You >> could do it with an external object that is ref-counted by weak_ptrs and >> the refobject, and has a flag and/or back-ptr to the ref-object telling >> wheter it's still live or not, to avoid storing >> pointers-to-weak-pointers as I do. (I've probably lost you now, right?) :) > > A little, but I can still see your taillights. ;)
Goodie. :) I can send over what I've got at the moment, if it would be of any use to you. >> What is needed is a way to go from * to shared, you mean? Well, to do >> that you need to find the ref-count & deletor-storage for a certain ptr. >> With intrusive counting it's trivial, because it lies in the pointed to >> object. With non-intrusive mapping, you need a map somewhere. You could >> simply store a set of shared_ptr's and do a lookup there. That's what >> you're doing for FCPtr's anyway, no? (It'd be a bit awkward and not very >> efficient at all though to do that every time) > > For efficiency reasons I was thinking about doing intrusive anyway, so that > shouldn't be a problem. Right. Sounds good. >> However, boost::shared_ptr is quite slow compared to c-ptrs or >> intrusive_ptrs. I've done some measurements and it's quite horrible. It >> does matter in a few places if you use these pointers alot >> (stl-containers etc), due to cache trashing when accessing the ref-count >> value. > > Hm, that doesn't sound good. I was hoping to be able to reuse the > boost::shared_count pieces, because they have nice system-specific lock-free > threadsafe operations. But the way they implement the weak count doesn't > allow > actually including the sp_counted_base in the class, it has to be a pointer, > which is not needed for an intrusive version. I think the shared-count stuff is good enough to be reused, if possible. I also believe the a hybrid approach I outlined, where the ref-count is instrusive but the weak-count is not, might be the best of both worlds. (Add an assert to the weak-ptr's dereference method and you've got weak_ptr with very minimal runtime & space cost, yet reasonably safe.) > Where did you run into performance issues? I would hope that in general > there's > no need to access the refptr very often. I can see a problem for resizing > vectors and copying over all the contents, but I don't really expect to see a > lot of that in OpenSG, at least not for big vectors. The big stuff (vertices > etc.) won't be refcounted. For vectors there should be a way to use swap > instead > of copy to make the whole thing more efficient, but I haven't looked into the > very deeply. We used shared_ptr's in our dynamic matrix objects for our math library. That was not really a good idea, as it showed up on benchmarks. An intrusive solution worked better (the ptr-manip time became insignificant). I'll try to dig up the performance benchmark I wrote a year ago on that. (It's at work, so it'll have to wait til tomorrow). IIRC there was a factor 10-20 (ish) in favor of intrusive ref-count when doing pointer copy/assign stuff. (I use win32's atomic increment/decrement, very similar to shared_ptrs in boost 1.33). Raw pointers was again 10 times faster. Obviously, as soon as you need to touch the ref-count, you pay a cost, and that happens on every shared_ptr copy. And with non-intrusive ref-count, you need to pass the smartpointer. You could pass a reference to the pointer, which we do sometimes where we have shared_ptr (legacy code) but it doesn't "feel" right to do that and it's a bit unwieldy. Also, shared_ptr is two ptr's big, one for the object and one for the ref-count. It might be that it won't matter for big OpenSG-style objects, which arent' manipulated that heavily anyway, but there's lots of ptr-passing around already in OpenSG and it's showed up when I profile my app too, so I'm a bit wary about it. (On a side note, GetAspect() takes 10% of all cpu time used by OSGSystem.dll in my app, so the c-ptr improvement is very welcome :) Anyway, much of this is a bit of black-magic to me still. ;) Cheers, /Marcus ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
