Problem----std::bad_alloc at memory location 0x0012fc4c

[uurmp]

I hadsome applicationsusing tbb.They work on my oldcomputer which hasduo cores.
While some of them do not work on my new computer which has eight cores.
The new computer has bigger memory than old one.
I 'm wonderinghow this memory problem comes.

"Main_iterate_fitting_parallel_128.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x0012fc4c.."

Any suggestion will be welcome.
Thanks!

[Alexey-Kukanov]

Since there are virtually no details, I can only say that bigger number of cores means also bigger number of worker threads created by TBB. In case your tasks independently allocate significant amount of memory, its total size might increase proportionally with the number of cores.

You can try to experiment with the amount of worker threads TBB creates, by explicit specification of the number of worker threads to create which should be passed to the constructor of tbb::task_scheduler_init object, e.g.
tbb::task_scheduler_init my_tbb_init(2);
This will to some extent emulate the behavior on a dual-core system.
You might try initializing TBB with different numbers (e.g. 1, 2, 4, 8) and check if the total amount of memory used by your application increases as well, and whether the system really runs out of memory with 8 threads. If not, then more information, better a reproducer test, is necessary to investigate what's going on.

[uurmp]

Quoting - Alexey Kukanov (Intel)

Since there are virtually no details, I can only say that bigger number of cores means also bigger number of worker threads created by TBB. In case your tasks independently allocate significant amount of memory, its total size might increase proportionally with the number of cores.

You can try to experiment with the amount of worker threads TBB creates, by explicit specification of the number of worker threads to create which should be passed to the constructor of tbb::task_scheduler_init object, e.g.
tbb::task_scheduler_init my_tbb_init(2);
This will to some extent emulate the behavior on a dual-core system.
You might try initializing TBB with different numbers (e.g. 1, 2, 4, 8) and check if the total amount of memory used by your application increases as well, and whether the system really runs out of memory with 8 threads. If not, then more information, better a reproducer test, is necessary to investigate what's going on.

Thank you very much!
The new computer (8 CPUs)has16GB RAM, and the old one (2 CPUs)only have 2GB RAM.
I checked the windows task manager. the PF usage is about 1.5GB. I don't know how it runs out of memory.
Ispecified the working threads as you suggest, but it still not work.
However, it works when Iinduce the dimension of the mainmatrix in the application.
Doesn'tthe multcores need the RAM linear with the number of cores?
Andtheyuse some RAM butnot show on PF usage ?

Thanks again

[Alexey-Kukanov]

If you reduced the number of threads but the problem did not went away, it must be different from linear usage growth with the number of cores.

Is your application 32-bit or 64-bit? 32-bit applications can not address more than 4GB in principle (no matter how much is physically available), and by default only 2GB of those are possible to use for data (including heap).

[uurmp]

Quoting - Alexey Kukanov (Intel)

If you reduced the number of threads but the problem did not went away, it must be different from linear usage growth with the number of cores.

Is your application 32-bit or 64-bit? 32-bit applications can not address more than 4GB in principle (no matter how much is physically available), and by default only 2GB of those are possible to use for data (including heap).

Thecomputer installed XP 64-bit and Visual Studio 2005. I don't know if the VC2005 is 32-bit or 64-bit.
While thereis amenu under Visual Studio Tools:
...
Visual Studio 2005 command Prompt,
Visual Studio 2005 Remote Debugger,
Visual Studio 2005Remote Debugger(x64),
...

do it means the VC2005 is 64-bit?

Or I need towrite a 64-bit application? If so, Could you pleasegive somesuggestion about how tolearn 64-bit programming?Any basic 64-bit source? I have no idea about 64-bit programing.
Thank you so much!

[uurmp]

Quoting - Alexey Kukanov (Intel)

If you reduced the number of threads but the problem did not went away, it must be different from linear usage growth with the number of cores.

Is your application 32-bit or 64-bit? 32-bit applications can not address more than 4GB in principle (no matter how much is physically available), and by default only 2GB of those are possible to use for data (including heap).

I installed 64-bit visual studio 2005, and set the applications to 64-bit. Then, it works.
Right now, I can define even bigger matrix, and fully use the 16 GBRAM.

Thank you so much!

[Alexey-Kukanov]

Yes you need to write a 64-bit application in order to utilize memory over 4 GB.

The very first thing to try would be to build it as 64-bit. For that, in the drop-down toolbar list (next to Debug/Release selection) change the usual Win32 platform to X64. Ensure you use 64-bit TBB binaries - look for "em64t" in the TBB paths for this project configuration (e.g.something like %TBB21_INSTALL_DIR%em64tvc8lib);if you use the TBB integration plugin you might be already fine, but double-checking won't hurt. And then you might be lucky and everything might just compile and run :)

If you are not that lucky, you could try some tools that promise help; I recall a tool called Viva64 was advertised in the ISN communityby its authors as a help in porting to 64 bit (I did not try it so can't say anything specific), and there might be other tools available. Of course any TBB related issues might be raised here; possibly there are some discussion groups on Google, or other places to ask for general help.

[Alexey-Kukanov]

Quoting - uurmp

I installed 64-bit visual studio 2005, and set the applications to 64-bit. Then, it works.
Right now, I can define even bigger matrix, and fully use the 16 GBRAM.

Thank you so much!

Seems I was writing my previous answer for too long :)
Glad to heareverything works fine for you now.

[uurmp]

Quoting - Alexey Kukanov (Intel)

Seems I was writing my previous answer for too long :)
Glad to heareverything works fine for you now.

Hehe, Your answer is really welcome! I learned a lot from ,and I'm lust as lucky as you said.
The problem just be solveddireclty.

I also gottheanswerin this forumlast time. I'm so happy to come here.

Thank youvery much!