Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Saturday, December 16, 2017 4:22 PM
I am allocating a very large array in C# for a deep neural network application for which I need the network components to remain in memory because they are accessed constantly (I have an Intel i9 7940x CPU with 28 threads actively processing the neural net computations). The array is about 850 million array elements, each element containing two 32-bit (4 byte) floating point values, for a total of 6.7 gibibytes. I have 64 GB DRAM, Windows 10 Pro 64 bit, and am targeting x64 (any CPU) with .NET 4.7.1 in the project's Build properties in Visual Studio Community 2017. I can execute the application with no problem in Visual Studio, either with the debugger or without. The release version, however, gives an out-of-memory exception at the point where this array is allocated and terminates. I've tried using /LARGEADDRESSAWARE in Post Build Events but other sources indicate this is not necessary for x64 targeted builds and vsvars32.bat is not present so it's not likely this is functional anyway. I also have gcAllowVeryLargeObjects enabled in the configuration file though I think I've read this is also unnecessary when targeting x64. Why can I run the application from within Visual Studio but not as a release version? Are there any directives I can use to create a viable stand-alone release version?
All replies (7)
Monday, December 18, 2017 6:10 AM
Hi friend,
You may try to go to project properties > Build tab, and changed "Platform target".
Similar issue at this thread:
the answer form Joe White could be helpful.
Regards,
Fletcher
MSDN Community Support
Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact [email protected].
Monday, December 18, 2017 11:33 AM
Thank you for your response. I had previously read the thread you supplied. As I said in my question I am targeting x64 (both in debug and release versions) so this is not the problem. Also, I've had the version running without the debugger for several days whereas executing with the stand-alone release version fails instantly with the out-of-memory exception. So there must be some qualitative difference in how Visual Studio allocates memory to processes it is running in debug and nondebug mode. I would like to be able to allocate that memory in my release version so it can run outside of Visual Studio.
Tuesday, December 19, 2017 8:56 AM
If it's possible please share a sample of your code or project via OneDrive with us.
We may test it in our side to see whether some particular code or configuration of VS caused this issue.
Regards,
Fletcher
MSDN Community Support
Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact [email protected].
Tuesday, December 19, 2017 2:07 PM
Thank you for your support. You can view the (much simplified) text of my code on One Drive at https://1drv.ms/t/s!AtkYHEKYcTIQaGCQ8QGqBWpqxkw
You can download the executable version from One Drive at https://1drv.ms/u/s!AtkYHEKYcTIQaVoRRRi1xs0CizU
Please note that the memory allocated is 4394919936 bytes; allocations within this vicinity work when executed within Visual Studio but fail (this time with exception: Array dimensions exceeded supported range) when executed as a stand-alone release version.
Wednesday, December 20, 2017 9:20 AM
Even in debug mode with 64 bit build it still gave the exception:
it seems the array you specified is too large:
I change
longconnects =549364992;
to
longconnects =54936499;
Then it run fine in Release mode with 32 bit(64 bit is also ok):
So I'm afraid it could be the issue that related to C# Maximum Array arrange.
Regards,
Fletcher
MSDN Community Support
Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact [email protected].
Wednesday, December 20, 2017 2:00 PM
Yes, the array is too large unless you target x64 in both debug and release builds. The app.config file should also have gcAllowVeryLargeObjects enabled. Unless you assign both of these directives as I stated in my original question you will be unable to execute in debug mode from Visual Studio. Yes, I can certainly make the array a tenth of the size I need to make the code execute but I need an array of the stated size to accomplish my task. My original question was why am I able to execute this code as is from Visual Studio in debug mode but not as a stand-alone executable version? The answer is not to reduce the array size because even though that allows execution in the stand-alone version it doesn't tell me why I can execute my code with the original array size in debug mode. If I knew the answer to that question I may be able to do for my release version whatever it is Visual Studio does to allow me to execute in debug mode.
Thursday, December 21, 2017 9:56 AM
Thanks for your response.
To be honest, I still haven't figure it out how to help you with this issue.
I searched a lot, and I'm afraid it's related to our PC RAM size and restriction of .NET CLR,
Hope the thread could help.
Thanks for your understandings.
Regards,
Fletcher
MSDN Community Support
Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact [email protected].