On Mon, Jan 12, 2009 at 6:50 AM, julius <jul...@juliuspaintings.co.uk> wrote: > > On 12 Jan 2009, at 02:32, "Michael Ash" <michael....@gmail.com> 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 clarkc...@gmail.com _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
