On Thu, Oct 17, 2013 at 3:00 AM, Jonathan S. Shapiro <[email protected]>wrote:
> 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. > As a special runtime case yes but not for a user defined stirng .. Can the 1:1 object concept be extended ( its pretty common ) with some mechanism to know its not M:1 ? eg if the object creates the internal object and the reference is always private then no ref check is needed ( extending this to multiple child objects is problematic as the reference can be passed around between them but if it wasnt than the whole tree would need one 1 ref count ) > > >> 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. > Dont follow the link . You dont need mutation for a ref count .. unless you expect nearly all reads to be optomized out ( which maybe possible) > > I think it's safe to say that naive reference counting - even when it is > not interlocked - has deadly performance. > ObjectiveC ? WinRT ? Rust etc etc Whats deadly Most C programmers think 15% , but this is not relevant as we can apply further optomization . What is relevant is unoptimized C++ in pointer vs unoptimized Java compared to non ref count give a good indication of the header approach vs the pointer approach. > 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++. > Agree but you need to compare apples to apples ( eg unoptomized vs unoptimized) , bitc will be a safe version closer to C++ and Java so those Java improvements will apply but is the "base cost" like Java or 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. > I went back to bytes because of bad usage in the x86 instruction set and if you run 32 bit on a modern system you still need to do 8 byte allignment. And the memory bandwifth is not greatly higher. > 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. > Yes > > 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. > Agree but ref counter in pointers with mask or 32 in 64 will have less wastage. There is no header.. I suspect your implying that some objects will have 4 byte left ( say an object with just an int ) , you can then 8 byte align the object and align the 4 byte header in teh hole . This is true but for a percentage of the cases and only if the header is < the object alignment size. Also if you have SIMD ( i had to get there ) SIMD requires 64 bit allignment so for high performance you really want to allign the object on 64 bit and place the data inside. This may mean more free header space. Tempted to modify some C++ tests to test the impact but dont have time at the moment. Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
