"Memory allocation error"

[jasonp]

32-bit windows allows 2GB of virtual memory per process. This is the most you can allocate no matter how much physical memory you have, and no matter how many threads you use (threads all use the same memory space). In practice you will never get all 2GB because program code and stack space also need to be allocated. When programs run, the libraries they need (runtime, network, etc) also have to carve out some of that budget. The amount you are allowed to use after all this overhead is accounted for is completely up to the OS, and could vary from machine to machine.

The same applies to 32-bit linux, except by default linux allows 3GB of VM for processes to use. There used to be a trivial patch to the kernel that allowed 3.5GB of VM, which was useful for people running memory-intensive programs.

[harlee]

Originally Posted by Mr. P-1

... make sure that you never have a small number left over for the final pass.

What do you consider as a small number? I'm currently in stage 2 and prime95 says "Processing 57 relative primes (114 of 480 already processed)." So if prime95 does 57 relative primes at time then I should have 24 relative primes on the final pass. Big question is how would I know this before starting stage 2 or do I need to let stage 2 start, look at the number of primes being processed and then change memory requirements to the final pass has enough primes?

[Mr. P-1]

Originally Posted by harlee

What do you consider as a small number? I'm currently in stage 2 and prime95 says "Processing 57 relative primes (114 of 480 already processed)." So if prime95 does 57 relative primes at time then I should have 24 relative primes on the final pass. Big question is how would I know this before starting stage 2 or do I need to let stage 2 start, look at the number of primes being processed and then change memory requirements to the final pass has enough primes?

24 isn't a small number, but your overall efficiency with 57 is no better than if you only had enough memory for 54 relative primes. If you'd started with 60, you could have completed in one fewer pass. Now you'd need to put it up to 62 from the next pass onward to be able to complete in one fewer pass.

I'm not sure how much benefit there is to be had from micromanaging this, but stage 2 restarts are expensive so I try to avoid them.

So for example, I'm currently processing 70 (347 out of 480). I started at 69, but this left me a bit tight and I wanted to reduce it. But why then put it up to 70? So that the last pass will now be 63 instead of 66, and I will be able to lower it further without restarting. So the next one will be done with 63, resulting in a final pass using just 39, and I'll then reduce it to 60, which is just about ideal for me.

[JuanTutors]

Originally Posted by jasonp

32-bit windows allows 2GB of virtual memory per process. This is the most you can allocate no matter how much physical memory you have, and no matter how many threads you use (threads all use the same memory space). In practice you will never get all 2GB because program code and stack space also need to be allocated. When programs run, the libraries they need (runtime, network, etc) also have to carve out some of that budget. The amount you are allowed to use after all this overhead is accounted for is completely up to the OS, and could vary from machine to machine.

The same applies to 32-bit linux, except by default linux allows 3GB of VM for processes to use. There used to be a trivial patch to the kernel that allowed 3.5GB of VM, which was useful for people running memory-intensive programs.

Good to know.

This seems to not be my problem though. I can't even make two copies of the prime95 folder in order to have it do P-1 testing on two different numbers with some appreciable amount of memory.