Re: NSInteger vs int vs int32_t
Re: NSInteger vs int vs int32_t
- Subject: Re: NSInteger vs int vs int32_t
- From: David Duncan <email@hidden>
- Date: Mon, 02 Jul 2012 16:42:58 -0700
On Jul 2, 2012, at 4:34 PM, Kyle Sluder wrote:
> On Jul 2, 2012, at 4:32 PM, Jens Alfke wrote:
>
>>
>> On Jul 2, 2012, at 4:17 PM, Kyle Sluder wrote:
>>
>>>> It depends. 64-bit values are twice as big as 32-bit ones, so they use up twice as much L2 cache and RAM.
>>>
>>> I would be surprised if cache is managed at anything other than multiples of register width (64 bits).
>>
>> That's not the point. Data containing 64-bit values (in objects, structs, stack frames…) is obviously bigger than data containing smaller values.
>
> 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.
>
> Note that I'm only referring to cache here, not RAM.
I suspect you are both talking past each other.
Jens' assertion is that if you had a 128 byte cache, you could store either 8 64-bit integers or 16 32-bit integers in it. Whereas Kyle is asserting that the CPU need only read 32-bits at a time (or less) from the cache for opcodes that deal with 32-bits (or less) of data at a time.
Your both correct, but your looking at different parts of the same problem.
--
David Duncan
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden