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
Keit hi,
On 12 Jan 2009, at 22:51, Schultz Keith J. wrote:
Hi Julius,
If I understand your problem correctly you are:
1) processing a very large amount of intergers
2) using highly optimized code that is:
a) you are manipulating the data directly via pointers
On 12 Jan 09, at 14:51, Schultz Keith J. wrote:
Far as stuffing two 32-bit values into a 64-bit value to avoid
possible context
switching is probaly a very bad trade off as the handling to such
values and doing
any kind of math with will hurt you badly speed wise with no space
savings.
"Pr
On Jan 12, 2009, at 5:51 PM, Schultz Keith J. wrote:
Hi Julius,
If I understand your problem correctly you are:
1) processing a very large amount of intergers
2) using highly optimized code that is:
a) you are manipulating the data directly via pointers
b
Hi Julius,
If I understand your problem correctly you are:
1) processing a very large amount of intergers
2) using highly optimized code that is:
a) you are manipulating the data directly via pointers
b) the data in memory is expected to be in a specific
On Jan 12, 2009, at 9:23 AM, Michael Ash wrote:
That's it! Pointer size and native 64-bit integers are the only
difference between the two!
In addition to what Mike said, the transition from X86 to X86-64
includes a few other benefits besides larger pointers and native
integers. The numb
>> leads me to believe that if I need an address space of more than 4GB then I
>> should be using 64 bit computing.
>
> True.
Also note that loading of various runtime libraries will take up a big chunk
of address space, so "needing an address space of more than 4GB" translates
very roughly to "n
On Mon, Jan 12, 2009 at 9:50 AM, julius wrote:
> Yes, but my understanding is that this will change when we go into a full 64
> bit architecture and as a one man band I would prefer to write code that
> anticipates the change than to have to change everything later.
Well, that's wrong.
> Also, t
On Mon, Jan 12, 2009 at 6:50 AM, julius wrote:
>
> On 12 Jan 2009, at 02:32, "Michael Ash" 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
On Jan 12, 2009, at 9:50 AM, julius wrote:
So let me then ask: under the 64 bit architecture, will the standard
c types like int, char etc still be available and not give me
problems under garbage collection given I define them as strong?
Currently I'm defining most my variables as type NSInt
On 12 Jan 2009, at 02:32, "Michael Ash" 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
effectivel
It's important to note that the reason for this peculiarity is that in
computer science we use powers of 2 extensively. As an electrical
engineer, I find the use of kilo, mega, giga, etc. prefixes irritating
as these are defined by the SI system to be 10^3, 10^6 and 10^9,
respectively. See
On Sun, Jan 11, 2009 at 4:44 PM, julius wrote:
> About This Mac says that I have 2GB of internal memory.
> Is this 2GB of 64-bit words or 2GB of 8-bit bytes?
> I appreciate that GB is Giga Byte but ..
Others have covered this adequately but I just want to reinforce that
there's essentially no
On 11 Jan 2009, at 22:19, Jacob Rhoden wrote:
Depending on what sort of data you has, you could try allocating all
of your memory on startup, organised into related "zones". That way
you are not constantly allocating/deallocating anything. Just
overwriting values. This can provide an unbeli
On Jan 11, 2009, at 5:26 PM, Benjamin Dobson wrote:
On 11 Jan 2009, at 22:04:09, Kenneth Bruno II wrote:
In actuality a gibibyte (GiB) is 2^20 bytes but it's not used in
all the places it should be used.
It's rarely used at all, for several reasons. One is that it makes
little sense to
On 11 Jan 2009, at 22:04:09, Kenneth Bruno II wrote:
In actuality a gibibyte (GiB) is 2^20 bytes but it's not used in all
the places it should be used.
It's rarely used at all, for several reasons. One is that it makes
little sense to your average consumer, but the more amusing reason
th
Depending on what sort of data you has, you could try allocating all of
your memory on startup, organised into related "zones". That way you are
not constantly allocating/deallocating anything. Just overwriting
values. This can provide an unbelievable speed inprovement, and low
memory overheads
On Jan 11, 2009, at 5:04 PM, Kenneth Bruno II wrote:
On Jan 11, 2009, at 4:44 PM, julius wrote:
About This Mac says that I have 2GB of internal memory.
Is this 2GB of 64-bit words or 2GB of 8-bit bytes?
I appreciate that GB is Giga Byte but ..
Similarly with respect to the L2 Cache, I ha
On Jan 11, 2009, at 4:44 PM, julius wrote:
About This Mac says that I have 2GB of internal memory.
Is this 2GB of 64-bit words or 2GB of 8-bit bytes?
I appreciate that GB is Giga Byte but ..
Similarly with respect to the L2 Cache, I have 12 MB per processor,
is that 12 MB by 8 bits or 64
On 11 Jan 2009, at 21:44, julius wrote:
About This Mac says that I have 2GB of internal memory.
Is this 2GB of 64-bit words or 2GB of 8-bit bytes?
8 bits. Always 8 bits.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post adm
Hi,
Not sure if I'm addressing the right list for this topic.
I'm just trying to get a notion of my memory requirements for a
program I am designing to run on my Mac Pro. I will have large volumes
of data passing through the program and I'm worrying about minimising
page collisions
I've ha
21 matches
Mail list logo
