Re: Mac Pro memory sizes
Re: Mac Pro memory sizes
- Subject: Re: Mac Pro memory sizes
- From: Clark Cox <email@hidden>
- Date: Mon, 12 Jan 2009 08:02:11 -0800
On Mon, Jan 12, 2009 at 6:50 AM, julius <email@hidden> wrote:
>
> On 12 Jan 2009, at 02:32, "Michael Ash" <email@hidden> wrote:
>>
>>
>>> In thinking about memory usage, where previously I would think of my
>>> program
>>> in terms of 8 or 16 or 32 bit words should I now be thinking in terms of
>>> 64
>>> bit words?
>>> That is, should I think of my available internal memory space as
>>> effectively
>>> being 500MB words?
>>
>> No, this makes no sense. You have 2GB of memory. If you're working
>> with 64-bit words then it makes sense to think of your memory as being
>> roughly 256 million words (note: not 500) but that's not the same as
>> "500MB words".
>
> Yes, of course. Silly mistake.
>>
>>
>>> Similarly, say that I had 100MB of 2 x 8-bit byte integers to save to
>>> disk,
>>> should I now think that this will be saved as 100MB by 64 bit (i.e. 8 x
>>> 8-bit byte) integers?
>>> If it is 100MB by 64 bit integers then should I think of compressing the
>>> data so as to reduce bandwidth requirements?
>>
>> Just because your machine has a 64-bit processor doesn't mean you're
>> suddenly required to work with 64-bit quantities everywhere. You can
>> still work with 8, 16, or 32-bit quantities as you need.
>
> Yes, but my understanding is that this will change when we go into a full 64
> bit architecture
Not true.
> and as a one man band I would prefer to write code that
> anticipates the change than to have to change everything later.
> Also, the documentation
> http://tinyurl.com/6ceoqz
> leads me to believe that if I need an address space of more than 4GB then I
> should be using 64 bit computing.
True.
>>
>> Which one is
>> the most appropriate choice, I couldn't say, but you seem to have this
>> strange idea that your 8-bit integers will somehow magically take up
>> 64 bits of storage just because you're running on a Core2
>> architecture. It's simply not the case.
>
> I'm glad you've flagged this up because one of the reasons for my asking
> the question was to increase my understanding of what I should and should
> not be thinking about in this regard.
>
> So let me then ask: under the 64 bit architecture, will the standard c types
> like int, char etc still be available
Of course they will. Removing these types would render a C compiler useless.
> and not give me problems under garbage
> collection given I define them as strong?
Garbage collection has nothing to do with integers, only pointers.
There is no reason to define an int or char as strong.
> Currently I'm defining most my variables as type NSInteger and CGFloat. Is
> that wrong?
No, it isn't wrong, but it my be wasteful. My recommendation is to use
NSInteger/NSUInteger and CGFloat for parameters, and local variables.
However for things in structures or arrays, think carefully about
whether or not you actually *need* a 64-bit type, otherwise, you could
be wasting space.
> Or should I be implementing my numbers as NSNumber? I thought the main
> purpose of NSNumber was as a wrapper to enable us to put numbers into
> NSArray etc. Would not using it as the main representation seriously affect
> computation speed ? What are other people doing?
> If you have any good links or advice they'd be much appreciated.
--
Clark S. Cox III
email@hidden
_______________________________________________
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