how much RAM LabVIEW can handle ?

[TiTou]

Hi all,

I saw many thread (not on this forum) dealing with this subject but I couldn't find crystal clear answers to these questions :

  1. Apparently 2 Go of RAM is a limit for a LV application running on WinXP Pro 32bit ; and as far as I understood the limit comes from the OS, is there any way to push this limit on WinXP Pro 32bit ?

  2. I successfully installed a RT OS on a PC in the past to run a LV application without Windows, if I do the same on a PC with 4Go of RAM will LabVIEW be able to handle more than 2Go ?


What I'd like to have is a comparison across the different OS of the maximum RAM usable by a single process (e.g. LabVIEW), I found this website and I'd love to gather the same information for WinXP Pro 32bit, WinXP Pro 64bit, WinVista Ultimate 64bit, Linux 32bit, Linux 64bit, LV RT 32bit and LV RT 64bit.

In fact I guess I should search on Microsoft website.

[unclebump]

Have you searched 'large address aware' on the forums. Looks like 8.5 can go to 4Gb.

[TiTou]

Great link, thank you.

Surprisingly there is not a word about LV running on RT OS...

[Matt_W1]

The 4GB limit on labview 8.5 only applies in 64 bit windows. In a 32bit windows the os limits it to 3GB assuming you have the /3GB boot.ini flag set for 2000 and xp, and whatever the equivalent setting is in vista. I think this should be true even if you have a version of windows that really supports PAE (XP pre SP2, or the some of the expensive server editions). Note: the 3GB switch can really limit kernel resources, which can lead to problems if your system needs them. I think on linux it's 4GB on 64 bit and 3GB on 32 bit, but I could easily be mistaken. I don't know what the limit is in the real-time OSes, since the limit is OS specific. But on 32bit OS with x86 hardware no mater what, some of the address space(and on some systems this can exceed a gig) is mapped to your hardware.

The limitation comes from labview being only 32 bit, which maxes out at 4GB (in windows some applications can use AWE to get around this). The next limitation comes from how the OS divides up kernel address space from user address space (default 2GB/2GB in windows, the 3GB switch makes it 1GB/3GB). And a final limitation comes from how much of the address space is used by hardware.

Note: The kernel space also includes the mapped hardware, so if your setup for 1GB/3GB and have a vid card with a gig of ram (the video card ram is mapped into the kernel memory space so drivers can access it), then I suspect your system would be very unstable if it even boots, since the kernel doesn't have any address space to use.

[altenbach]

Have a look at the various links on the following page:

http://digital.ni.com/public.nsf/allkb/AC9AD7E5FD3769C086256B41007685FA

[Ben]

Hi Mug-bearer,

Ditto to all of the above.

Another factor that comes into play is LabVIEW wants contiguous blocks of memory for its buffers. If the memory is fragmented, attempts to allocate a buffer will fail.

So a bunch of smaller buffers are more likely to work while a single monster buffer may fail even thought the total available memory looks like there is enough.

Ben

[DFGray]

Be aware that LabVIEW indices to arrays are signed 32-bit, so you cannot have more than 2G elements in a single array (if you happen to be lucky enough to have a contiguous memory space that big).

Note that due to memory fragmentation issues and the position of DLLs, on a standard Windows system, the largest contiguous memory block you can allocate will be about 700MBytes.

[TiTou]

I successfully allocated close to 1.8Go of images for a fast acquisition 😉

I was told that I wouldn't be able to deallocate and reallocate but as long as I don't go over the top once, it's fine to deallocate/reallocate ; but if I once go beyond the limit by trying to allocate more images than I can (2Go) then LabVIEW has to be shutdown and re-open. That's why I posted this thread, maybe you can help me on this

😉

[Kevin_Price]

Dunno of this tidbit will help, but maybe...

One trick I once used under RT to avoid de-allocating and re-allocating involved the use of "Reshape Array" instead of using "Initialize Array."   See this old thread for details. 

-Kevin P.

[TiTou]

Thanks for the idea, in my case I'm working on images, so I use the "IMAQ Dispose" function to de-allocate all the images at the same time and then re-allocate the number of images I need, with the size and bit-depth I need.