how large of a buffer can I malloc

[LuisG]

Menchar,

As of today, CVI is a 32-bit application, and it can only build 32-bit executables. They can run in 32-bit Windows, or 64-bit Windows (Vista only), but because they're 32-bit apps, they're still limited to 2 Gb (3 Gb if you use the /3GB switch) until a version of CVI that can build 64-bit binaries is available.

This is not affected by whether you're using the native CVI compiler, or an external compiler.

Luis

[menchar]

Here we are two years later and I'm still fighting this problem with WinXp Pro, CVI 9.0, and the Intel C++ Compiler for Windows 11.1

I am trying to allocate  an array:

static short int iArray [512][480][640];

which sometimes works just fine, but other times generates a GPF when the application tries to access the array.

I've even managed to do this 

static short int iArray [1024][480][640];  //  630 MB array

and that works sometimes, and the Intel compiler generates code that goes through these hundreds of megabytes of array with remarkable speed (e.g. touch every value in the array several times in about 400 millliseconds!).

BUT the GPF's make this unreliable.  I can get GPF's sometimes with relatively small arrays.

If I malloc'd at least I'd know if the memory failed to allocate, but then can't use multiple dimension array notation to get to the values.

Does stack size or image base address affect this?

Should I use Win32HeapAlloc?

I'd like to reliably allocate a 700 MB array (or buffer) on WinXP Pro for a CVI application compiled with teh Intel 11.1 compiler.

Does anyone have any experience in this area?  What can I do in CVI to reliably allocate a large array?    Last time NI told me to wait for 64 bits - two years later and CVI still doesn't support 64 bit OS ...

Thanks

Menchar

Message Edited by menchar on 11-06-2009 04:45 PM

[menchar]

And here's another thought -

Does it matter if I run the relase executable from the CVI IDE?

If CVI schedules the target release executable as a child process, might there be some imposition on memory that causes the target executable to run differently, depending upon how it was scheduled?

I never have a problem with the compile or link, this is a run-time issue so I have to think the very same executable is seeing very different amounts of memory available wherever it gets memory for a module scope array   (static short int iArray [...] at the top level).

I had it fail without the static keyword (which makes the array module scope) .. I added static keyword and same array worked ...  then it wouldn't work ...

I can malloc a 1.3 GB block all OK, that hasn't changed over the years .... but it does make me wonder what in the heck is happening with the CVI memory manager.  Maybe when I use an external compiler the CVI memory manager isn't used?  

So many questions, so few answers ....

Menchar

[menchar]

And if I get it to run OK with module scope array, do I then know that it will always run OK?  I've never seen it fail if it runs OK the first time ...

Heck, I'm doing iArray[1000][480][640]  now and it's solid as a rock when I run it as a stand alone release executable ...  touches each value in this 614 MB array several time, does a multiply and add on each value, caclulates mean values on 1000 element vectors with a 256 element sliding window.. in under half a second on my two core core duo E8400 @ 3.00 GHz with 4 GB of physical memory ...

You know, I bet it could go fruit on me if I distribute it and the CVI RTE loads up tons of stuff into the dist kit  ...  could be it gets worse ...

I'll name my first child for anyone who can answer these questions ...

Menchar

[menchar]

How weird is this:

If I start CVI and create a release build of my application using the Intel 11.1 compiler, I can allocate and use a static short int iArray[1000][480][640] with no error,  no GPF, solid as a rock, whether I run the release executable from the IDE or launch the .exe file from Windows Explorer.

However, if I recompile the program in release mode during the same CVI session, the application GPF's every time, from the IDE or from Windows Explorer either one. 

It GPF's on any build after the first during a CVI session.  It doesn't seem to matter much how big the iArray is, even if I crank the size way down the executable still GPF's.  It's almost as if the allocated memory for the array (whereever it's coming from) isn't released after the first build and run.  But how do you explain that it acts the same way when the .exe is run from Windows Explorer?

Weird, huh.

[Eric_B.]

menchar,

As far as your CVI + 64-bit questions, this post from NickB indicates that 64-bit binary creation is coming in the next version of CVI, which is expected soon: http://forums.ni.com/ni/board/message?board.id=180&message.id=42697#M42697

[menchar]

Eric -

Yes, I understand CVI will soon (2009 supposedly) be able to support creating 64 bit applications, and, I imagine, become a 64 bit application itself along with all of the libraries.

I'd like to think that the answer to these questions isn't simply "wait for 64 bit" rather than support for the present 32 bit tool, but it looks like I'm going to be disappointed.

I think some of the issues I'm battling are related to deciions the CVI linker makes, and info on the linker seems hard to come by.

Menchar

[nickb]

Hey menchar - 

I've been looking into this the last day or so and may have an option for you.  I was able to reproduce what I think is the crash you've reported, and the root cause of the crash I reproduced was that internally, CVI does not align arrays on 16 byte boundaries but rather 4 bytes (32 bit) and 8 bytes (upcoming 64 bit).  Many of the optimizations the Intel 11.1 compiler makes assume 16 byte alignment.  

I found that passing the /Qvec- flag resolved the vast majority of issues I encountered.  This does disable vectorization, and so may have an impact on your performance, but I was unable to find another way to resolve this issue in the short term.

Just FYI, the only case I found (in what can not be considered extensive testing) where this did not resolve the issue was in the initialization of a char buffer - such as:

char tempBuf[512] = "initializing string";

I was unable to find a workaround for this besides simply not initializing the buffer in this manner.

NickB

National Instruments 

[menchar]

Nick -

Thanks for looking into this for me.  I don't know if the app I've built is using vectorization but I suspect that it is and that's what's allowing it to burn through these large arrays so quickly.

I think I can live with the problem - yesterday I built several times and it did not GPF - I guess it could be an alignment decision made at the start of a session that's affecting things, though just how that affects the Intel code is a bit of a mystery.

I imagine that if the Intel compiler is 16 byte aligning then they're likely doing it for a good reason, performance wise.

Do you know what affect the executable base address has?  I set it down to zero on the theory that if the application address space go to higher addresses there's more address space that way but I suspect I'm full of poop on this.

Menchar

[menchar]

The app does use vectorization, the Qvec- flag triples the run time of the application.  I wouldn't be surprised but that the 16 byte alignment is for vector instruction support.

But I don't understand how an alignment difference could cause the GPF problem:  if I rebuild the app in release mode, how can it be in alignment conflict with anything?

Strangely enough, the last two days I have been able to rebuild time and again with the Intel compiler in release mode with no GPF's. 

Menchar