On Jul 2, 2012, at 4:34 PM, Kyle Sluder wrote: > Not necessarily. The CPU could just mask off the top 32 bits when executing > 32-bit opcodes on in-cache data. Each 32-bit value is still taking up 64 bits > of cache space. That's probably a lot easier and more efficient than making > it possible to address arbitrary 32-bit slices of cache.
I … I don't think we're talking about the same thing at all. I'm talking about the aggregate size of data structures, not how individual values are aligned in the cache. The cache stores big chunks of data like 256 bytes, anyway; it doesn't do anything like masking individual words. Here's a contrived example. Let's say I have a struct whose members include four NSIntegers. If I convert those to int32_t, I make the struct 16 bytes smaller*. If I have a million of those in memory, I've saved 16 megabytes of address space, which is a nontrivial fraction of the size of the L2 cache. —Jens * Assuming optimal packing and no padding by malloc. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
