32-bit LV app runs poorly on 64-bit box

[Cat]

I've got an app that reads in and displays spectra files. When I wrote it originally eons ago, it was running on a laptop running WinXP, 32-bit, 2 GB memory. It could pull in 20-ish spectra (~1MB per spectra) before blowing up.

We recently got some hot mini desktops for the analysts. Windows 7, 64 bit, 8GB memory. I was all excited to see how many plots could be displayed at one time (the analysts would like an infinite number).

It choked on 10 plots. Lots of "LabVIEW not reponding" errors and eventually had to abort the application (with only 2.2 GB mem actually being used).

I'm wondering if I've just been bitten with the real world problem of running a 32-bit app on a 64-bit machine. Maybe Win7 eats up tons of that lower memory, leaving less for 32-bit apps.

I'll load LV10 on a 64-bit box, and rebuild the app to test out this theory. This kinda sux for my current development paths, tho. I really DO NOT want to move from v8.6.1 to v9 or 10 (sorry NI, I love ya, but...) and 8.6.1 doesn't come in 64-bit. I'm pinning my hopes on a stable LV11, but that's a year away (never upgrade until the first SP).

Anywho, just wondering if anyone else out there who works with memory-hogging apps has had this problem running a 32-bit LV app on a 64-bit machine.

[Sparc]

hot mini desktops

These aren't the Big Box Specials where they advertise some awesome spec (9 GHz Octocore CPU!!!) and then cripple the entire box reduce cost with some unadvertised component (66 MHz, single channel memory bus)?

I've haven't yet had a 32 bit app run worse on a 64 bit machine. I've had them run the same, better, or not at all -- but never worse (at least never so much worse that I noticed).

My hunch is the new computers don't have better hardware in all the right places. For instance the existing PCs might be 4 GHz single core and the new PCs 2 GHz Quad core.

Edited March 10, 2011 by Sparc

[Mark Smith]

Take a look at this for some info things that might effect 32 bit performance on 64 bit windows

http://msdn.microsoft.com/en-us/library/aa384219%28v=vs.85%29.aspx

Also, are you running from a built app on these machines? If so, check out this link since you're running 8.6

http://digital.ni.com/public.nsf/allkb/1203A9B2930B7961862576F00058F94E

Mark

[ShaunR]

Maybe Win7 eats up tons of that lower memory, leaving less for 32-bit apps.

Bingo!

It's not really an x32 on x64 problem. It's an x32 in windows7 problem. there is only a finite number of addresses that can be gotten with a 32 bit number. Problem is, they are all towards the top end of the range since Win7 hogs most of the bottom.

Without switching to X64. you will still be limited in the address space so 20 is probably the best you can hope for. The trick is, how to offset those addresses against the Windows7 OS to claw back some memory for your app.

Try having a read of this. It works on Windows 7 (I believe and have been told, but never tried).

(never upgrade until the first SP).

where have I heard that before

Edited March 10, 2011 by ShaunR

[Cat]

My hunch is the new computers don't have better hardware in all the right places.

No, trust me, most of the folks here build their own computers from the ground up, so we know how to spec these things out.

Old computer:

Intel Pentium M, 1.73 GHz, 1.49GB RAM

New computer

Intel i7, 3GHz, 8GB 1333MHz DDR3

[Cat]

While I'm waiting on software and hardware to try out Shaun's and Mark's suggestions, I've been porting my 32-bit code to a 64-bit machine and rebuilding. While maintaining 2 different versions of my code is not necessarily a *good* solution to my problem, it is *a* solution, anyway.

So, I ran my 64-bit executable. I loaded up 8 plots, no problem. Clicked on the 9th and....

**Choke**

I repeated this yesterday a couple times and always got the same result. LabVIEW not responding. In disgust I left it running over night. When I came in this morning it was running fine! I loaded up a bunch of plots with no problem! Whisky Tango Foxtrot (as they say in the Navy) ?!?!

So after a few more tests, here are some numbers to quantify this problem.

1) Each plot added consistantly takes about 11MB of memory.

2) After plot8 my app is using approx 360MB memory

3) Going from plot8 to plot9 grabs 30-ish MB and that number fluctuates during the "LabVIEW Not Responding" time until it settle down to the usual 11MB

4) During this time the computer's 8 CPUs are averaging ~12% with one of them at ~65%

5) The "LabVIEW Not Responding" time is approximately ONE HOUR (!!!)

After that, I've gotten 250 plots up with a minor amount of thrashing (not surprising since my current machine only has 4GB memory).

Any clues about what's going on? My thought is that LV initially grabbed a bunch of memory, uses it all up at 360MB and then needs to grab more. But why in the world would that take an entire hour??

Cat

[Cat]

So I "fixed" the problem today. I replaced the XYGraph I was using to display the data with a ... (wait for it) ... XYGraph.

Yup, this was one of those funny () situations with LabVIEW where if you delete non-working code, and rewrite it the exact same way, it works fine. In this case, I just right-clicked on the graph and literally replace it with the same thing. A couple key-strokes to make it the right size and set up the cursors and it works great.

I noticed a few days ago that even the 32-bit app on my 32-bit system took a loong time (20s) to do that ninth plot. It would make it thru it (unlike any other variation of apps) but it definitely had to think about it for awhile. This said to me it wasn't a 64-bit or probably even a memory problem. So, after a day and a half of trying everything I could think of, the actual fix took about 5 minutes. Sigh...

I still don't have a clue *why* it's hanging at that ninth plot, but at least it's not doing it anymore.