The heap memory

[Fan_Y_]

Hello, I'm programming with Intel Cilk+ and encountered a obstacle. 

I developped two patterns. The second one shows its advantages when the problem size is bigger than 40000(float) which is very inadequate. I wanna see its development. However 50000 gives me a std::bad_alloc. 50000 * 50000 * 4 =10GB while I have 27GB MemFree (refers to my meminfo). Is there any possiblity to set a bigger heap memory?

I'm using icc version 13.1.0.

Thanks for your comments.

[Barry_T_Intel]

I'm not quite sure what you're asking for. Memory allocation functions are provided by your operating system. Perhaps if you included a program that demonstrates the problem (and specify which OS you're running on) we can suggest something. - Barry

[jimdempseyatthecove]

How many threads are in use?
What is the stack limit for threads?

Note, there is a general newbie inclination to specify unlimited stack for all threads. What this will do is carve up the virtual memory address space of the process leaving much less address space for the heap. The report you posted stated ~33GB for swap space. This is approximately equal to largest permitted virtual address range (actual allocation may be significantly less than this). You did not mention what your system was, lets assume 1P Core i7 with 8 HW threads. Some portion of the 33GB will go to code, some portion to initial heap, the remainder (less some reserved) will be divided up 8-ways. You have tuning parameters that can vary the proportions. Assume for example heap and 8-threads get equal partion of the available address space. This provides for 3.66GB in heap. The fix is to not use unlimited stack. Specify a reasonable stack size.

Jim Dempsey

[Fan_Y_]

jimdempseyatthecove wrote:

How many threads are in use?
What is the stack limit for threads?

Note, there is a general newbie inclination to specify unlimited stack for all threads. What this will do is carve up the virtual memory address space of the process leaving much less address space for the heap. The report you posted stated ~33GB for swap space. This is approximately equal to largest permitted virtual address range (actual allocation may be significantly less than this). You did not mention what your system was, lets assume 1P Core i7 with 8 HW threads. Some portion of the 33GB will go to code, some portion to initial heap, the remainder (less some reserved) will be divided up 8-ways. You have tuning parameters that can vary the proportions. Assume for example heap and 8-threads get equal partion of the available address space. This provides for 3.66GB in heap. The fix is to not use unlimited stack. Specify a reasonable stack size.

Jim Dempsey

Thanks. That does response to my expectations: One more doubt. In the case of cilk, I suppose that if I mallocate before the first spawn, there should be one heap size for the whole program, or process, which is then possible to be shared with spawned worker(thread). Openmp will be a similar case to the previous one? 

Actually, I haven't ever changed my stack size. My system is 2 SandyBridges with 32 logical cores(hyperthreading x2).

[Jim_S_Intel]

The Cilk Plus runtime creates and manages its own pool of 1MB stacks, and we should be placing an upper limit on the total # of stacks of roughly 10*P.     Even with a value of P = 128,  128 * 10 * 1 MB  = 1280 MB does not seem to me like it should cause the problem you are seeing....

The OS also allocates default stacks for each of the threads --- the starting program thread, and the P-1 worker threads the runtime creates.   The Cilk Plus runtime does not do anything special to set or limit the sizes of these stacks, so if there is an issue with the space used for stacks, these stacks might be the more likely culprit.

Do you have the same problem when running with smaller numbers of workers, e.g., when running with CILK_NWORKERS=1 or CILK_NWORKERS=2?

Cheers,

Jim

[jimdempseyatthecove]

Allocating before instantiating the thread pool will help. If you still need more heap size then reduce stack size and/or page file size and/or process limits.

Jim Dempsey