On Wed, Oct 16, 2013 at 8:59 PM, Bennie Kloosteman <[email protected]>wrote:
> On Thu, Oct 17, 2013 at 3:00 AM, Jonathan S. Shapiro <[email protected]>wrote: > >> >> 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 string .. > I agree. > Can the 1:1 object concept be extended ( its pretty common ) with some > mechanism to know its not M:1 ? > In abstract: yes. This is exactly what linear types do. In this case, though, I think that worrying about the extra reference counts isn't very important. 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. > But that's my point. 15% (in concurrent it's *much* more than that) really * isn't* okay, and so you *need* those optimizations. > 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. >> > Yup. Until you raised that, my sense was to just align everything to 8 bytes and declare victory, because it's a minor pain if the allocator has to know about alignment requirements. The use case for SIMD is pretty compelling. But you don't need extra header words for this. What you do is align the * payload* and stick the object header above that. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
