Actually lets expand on this .. We have always mutable "rw" objects , these are objects with lots of mutations - they should be few , they override teh default everything is const setting. If a method states explicitly ro then its a compile error to pass in such an object . Objects mutated in a multi threaded environment without a lock ( eg lockless code) should be rw. Also objects which frequently change ( eg some complex counter object ) should be rw and hence not incur freeze / thaw costs . There are not many of these objects outside of micro benches ( and in micro benches you have little forwarding)
We now have objects that are rarely mutable including frozen after init construction functions default to ro. When its set to rw , the compiler inserts the a conditional , a bitset and bit clear around the mutating instruction , it may be possible to bulk these sets but that makes integrating with locks more complicated. And i think in those cases where you are making lots of changes in a loop you should use rw objects. The forwarding conditional would be If forwarding on this object is being done ( very very rare ) yield delay 1 micro until its finished . You now have nearly all objects immutable at any one point far more than readonly objects and in fact readonly objects become less meaningfull since the user explicitly indicates where changes to that object are. There would be a peformance penaly but its greatly out weighted by code quality and further optomizations and very hot objects can be explictly marked so the penalty can be optomized out quite easily. . I also like this discussion : Why did you use mutable code .. it was easy for the algo or i copied it from C++ ..ok , If the answer i wanted it fast .. then its premature op and If you need high perf why are you not using SIMD ? Ben On Sat, Oct 19, 2013 at 8:14 PM, Bennie Kloosteman <[email protected]>wrote: > > >> >> >>> Also what about defaulting to shallow const on all objects which would >>> then freeze and thaw as needed. >>> >> >> Unfortunately that creates a race condition. Suppose I forward an >> immutable object. I don't force a read barrier, because they're both >> equally good. If somebody "upgrades" the object to mutable, I retroactively >> need a read barrier. Depending on the mechanism used to implement the read >> barrier, I may or may not be able to put one in place that flexibly. >> > > In that scenario i was thinking of no user setting / freezing but all > setting being done by the compiler.. you could use a count ( too expensive > this needs to be ultra cheap) but there may be a better way as you only > care if its the last setter of the object and in does not need to be > precise if a few objects stay mutable thats fine ( as this mutable is not > language ) ., it will be reset when they exit the next mutable function .. > ( the reverse would be an issue) .. Its a bit late to nut this out but i > think there is a good chance an effective solution can be found . Actually > as many mutations have locks this may work fine. > > Ben >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
