My thanks to all who replied to my query.
Let me see if I can correctly summarise your advice.
All references to Mac memory as GB or MB refer to standard 8 bit bytes.
Mac 64-bit computing relates to the size of pointers into the address
space and a number of native data types such as NSInteger, NSUInteger
and CGFloat.
When working in a 64-bit architecture there is no need to stop using
standard c types such as char, int, float etc. These do not expand to
fill 64-bit space but retain their accepted sizes. If one wants to be
specific about the actual size of a type then use the types specified
in the International Standard ISO/IEC9899 :
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf
For instance, quote: "The typedef name intN_t designates a signed
integer type with width N, nopadding bits, and a two’s complement
representation. Thus, int8_t denotes a signed integer type with a
width of exactly 8 bits. "
One can discover the sizes of NSInteger, NSUInteger from the constants
NSIntegerMin, NSIntegerMax, and NSUIntegerMax.
It is a good idea to use NSInteger/NSUInteger and CGFloat for
parameters, and local variables.
It is also good normally to use NSInteger etc and not worry unless
working with large numbers of small integers that need to be packed
into as little memory as possible.
Also re the transition from X86 to X86-64:
The number of registers were doubled, and the calling conventions were
changed so that 80% of the time function/method arguments are stored
in CPU registers instead of being placed in a four-byte-aligned
position on the stack. And that 20% of cases only happen when you pass
in a structure larger than 128 bits, or pass in an unaligned
structure, or have a function that takes more than 6 arguments.
(Thus..) a program ported from X86 to X86-64 will run just slightly
faster, especially if the program passes around a lot of 64- bit
arguments.
I was glad to have my confusion about GC corrected, vis. in the
context of GC one need only concern oneself with how the pointers are
defined, e.g. only to use __strong as pointer to standard c types
rather than as I was doing: scattering __strongs amongst all my chars
and ints. Clearly I need to get out more.
I had not come accross the following bit of documentation:
http://developer.apple.com/documentation/Darwin/Conceptual/64bitPorting/intro/chapter_1_section_1.html
I'd been using
http://developer.apple.com/documentation/Cocoa/Conceptual/Cocoa64BitGuide/Introduction/chapter_1_section_1.html#/
/apple_ref/doc/uid/TP40004247-CH1-DontLinkElementID_26
and not seen the link to the preceding at the bottom of the page.
It is also a good idea to revisit Memory Usage Performance Guidelines
http://developer.apple.com/documentation/Performance/Conceptual/ManagingMemory/ManagingMemory.html
Runtime libraries use a lot of address space so "needing an address
space of more than 4GB" translates very roughly to "need to manipulate
more than about 2GB of data".
A useful optimisation technique is to do pointer arithmetic manually
rather than rely on built-ins and standard structures. If one is
working in different size architectures then use sizeof to get the
correct sizes for pointer arithmetic.
Finally I was advised to avoid premature optimisation and bit packing.
So my thanks to you all.
I return to the fray with mind much eased.
Thanks again
Julius
http://juliuspaintings.co.uk
_______________________________________________
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
