On Wed, Oct 16, 2013 at 10:31 AM, Bennie Kloosteman <[email protected]>wrote:
> On Wed, Oct 16, 2013 at 2:28 AM, Jonathan S. Shapiro <[email protected]>wrote: > >> I'm not sure why ref counting should have any impact on string >> implementation. The question of whether the string payload immediately >> follows the header or is stored separately has more to do with relocation >> concerns than with GC/RC in my mind. Above a certain size, you really don't >> want the string payload stored contiguously. >> > >> Can you explain what you see as the relationship between GC/RC and string >> design? >> > > With RC every time you have a string reference the algorithm needs to put > the internal char array object reference on the stack to work on it ( note > i used the term array reference ) .. that introduces a count . With an > embeded array your really looking at string[0]. > > Now if the internal array is a seperatly allocated value type then its > not an issue as its really a pointer not a reference ( and leads into > whether internal referances can be supported or wthether they are really > pointers or reference offsets ) , > You are confusing two things here. Even if the payload is stored separately, it has a "unique descendent" relationship to the string object. No reference count is needed. This case (and the corresponding case for vectors) can and should be handled as a special case. The reference count on the string object itself is sufficient. > The key point though is it becomes much worse to to have an object store > another object hence RC has an impact on design . WHich IMHO will make it > preform better as the libs mature . > I don't think the data on old-heap mutation rates supports this assertion. > Im not convinced of that ...ref counting on C++ does exactly that and the >>> basic implimentation C++ is much faster than Java using bits in the header( >>> yet alone a new header field) . >>> >> >> > > Im also saying we should measure it ... We do know the cost of headers is > also very significant. And in my experience on modern hw asumptions are > often wrong trading memory for CPU is nearly always good and improves > overal cache performance ( which is an asumption :-) ) > I think it's safe to say that naive reference counting - even when it is not interlocked - has deadly performance. I also think it is safe to say that many of the optimizations that can be used to defer reference counts are difficult to do in C++. > for your own system yes you can add 1 64 bit or maybe even 32 bit . But > the header is determined by the runtime on 64 bit CLR thats 16 bytes... > I think it is cleaner to think of this in terms of words rather than bytes. Also, we need to be careful to understand which space is not recoverable. If object have a 64 bit alignment restriction, for example, the object header on a 32-bit system will be two words even if you don't use the "other" word. The alignment requirement means you can't get rid of it. On 64-bit systems, however, most of those multiword alignment restrictions are eliminated. In 32-bit systems they were mainly induced by double precision floats having a 64-bit alignment requirement, but that is the natural alignment on a 64-bit system in any case. My point is that on the one hand we shouldn't blame the object system for non-negotiable wastage, and on the other hand we should not hesitate to make effective use of space that we are obliged to spend anyway. > Finally, I'm not at all convinced that the per-object header can be >> eliminated when fat pointers are used. You only have to need a single bit >> for object forwarding to require a full word of object header. >> > > Maybe ...there are other ways .. and its a bonus for URC not needing it . > I'm still working my way through the URC paper. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
