Jump to content


Photo
- - - - -

What are the *real* system requirements for LabVIEW?


  • Please log in to reply
12 replies to this topic

#1 Justin Goeres

Justin Goeres

    The 500 club

  • JKI
  • 684 posts
  • Version:LabVIEW 2012
  • Since:1997

Posted 16 March 2011 - 02:38 PM

One of my customers asked me a simple question the other day, and I realized I didn't have a good answer. He's writing some LabVIEW code that is doing some pretty intensive plotting, and it's crushing his (admittedly anemic) CPU. So he wants to know: Will a faster/better computer fix it, and what features should it have?

Now obviously, the standard answers here are:
  • Debug the code to find bottlenecks and/or acceptable tradeoffs, then optimize.
  • Buy the fastest/biggest thing you can afford; computers are cheap.
It occurs to me that I'd like a better answer than that, though. NI's LabVIEW requirements page recommends a Pentium 4/M (and elsewhere implies 4/M at >= 866 MHz) with at least 1 GB of RAM. That's fine, but it's only part of the story. Can anyone help me fill in the rest? Here's what I'm looking for:
  • In general, what's the biggest limiting factor in LabVIEW's execution? Is it RAM? CPU speed? Bus speed?
  • Specifically with regard to graphing/UI stuff, what's the biggest limiting factor? Is it the UI controls themselves? Does accelerated graphics ever matter at all to LabVIEW?
  • Given a problem with CPU railing during intensive plotting (not 3D picture control), what's the best way to tackle the problem other than code changes?


#2 neBulus

neBulus

    LV Survivalist

  • Members
  • PipPipPipPipPipPip
  • 1,389 posts
  • Version:LabVIEW 2009
  • Since:2009

Posted 16 March 2011 - 03:01 PM

... Can anyone help me fill in the rest? Here's what I'm looking for:

  • In general, what's the biggest limiting factor in LabVIEW's execution? Is it RAM? CPU speed? Bus speed?
  • Specifically with regard to graphing/UI stuff, what's the biggest limiting factor? Is it the UI controls themselves? Does accelerated graphics ever matter at all to LabVIEW?
  • Given a problem with CPU railing during intensive plotting (not 3D picture control), what's the best way to tackle the problem other than code changes?


I can optimize code or deploy to more than one CPU so Virtual address space is the limit I hit most often. Even the Bus speed can be worked-around by designng hte app to run on more than on machine (devide and conquer).

UI thread is single threaded. Accelerated graphics really made a big difference in my 3D graphing speed. Even the old 3D graph (that only used a single code to render the graphics) got much quicker when I used my new top of the line laptop.

You last question is rather limiting but ... Hiding the FP of a LV app realy can speed up a screen update.

Ben

#3 Justin Goeres

Justin Goeres

    The 500 club

  • JKI
  • 684 posts
  • Version:LabVIEW 2012
  • Since:1997

Posted 16 March 2011 - 03:05 PM

You last question is rather limiting but ... Hiding the FP of a LV app realy can speed up a screen update.

I'm confused by this suggestion... hiding the front panel (which is where the graph is being drawn) would kind of defeat the purpose of trying to show the data in the first place, no? Am I misunderstanding?

#4 hooovahh

hooovahh

    Just because I don't care doesn't mean I don't under

  • Moderators
  • 1,256 posts
  • Version:LabVIEW 2013
  • Since:2004

Posted 16 March 2011 - 03:20 PM

I'm confused by this suggestion... hiding the front panel (which is where the graph is being drawn) would kind of defeat the purpose of trying to show the data in the first place, no? Am I misunderstanding?

I can't answer for neBulus, but I read that to mean using the Defer Front Panels property, then do stuff, then enable front panel updates (using the same property) I've seen alot of improvements using this with trees, and UIs that have alot of changes (control properties and such).

In my experience RAM is a big part of it. LabVIEW can eat up alot of RAM, and Windows will do funky things with virtual memory and may allocate LabVIEW to use page file RAM even when there is several hundred MB of physical RAM available. The more physical RAM available the less likely it is for Windows to use the page file. There are ways to not use any page file (or make it smaller) but it's there for a reason, like when you run out of physical RAM, I just wish Windows managed it a little better.

"Maybe Hoovah is really Crelf's alter-ego, which he uses to irk people?" - Gary Rubin
"Seemingly minor changes....can mean the difference between a working app and a quivering heap of unresponsive code." - David Boyd
"Using unofficial features of LabVIEW is cat nip laced with poison."


#5 neBulus

neBulus

    LV Survivalist

  • Members
  • PipPipPipPipPipPip
  • 1,389 posts
  • Version:LabVIEW 2009
  • Since:2009

Posted 16 March 2011 - 03:22 PM

I'm confused by this suggestion... hiding the front panel (which is where the graph is being drawn) would kind of defeat the purpose of trying to show the data in the first place, no? Am I misunderstanding?

In parenthesis, you ruled out code changes, So I offered a suggestion that did not require code changes. How can it help?

I have code that renders the CAT scan we often see as a gif of a human head (looks like Hova's vatar) as 3D image. It let me turn that gif around so I could see the guy's face. On my old laptop, it would take about an hour to render the image in 3D. On my new laptop it only takes about 15 minutes to udate the screen if i watch the updates but if I minimize the screen and watch the CPU (windows task manager) I can see that the update will complete in about two minutes.

So...

It did not require code changes
It did increase the renering speed.

If you lifted the "no code change" restiction, I suggest defer FP updates, hide the widget, update the widget, show the widget undefer updates.

BTW: Using Defer FP update when trying to update a chart on a tab control results in no update as of LV 2009.

Ben

#6 Tim_S

Tim_S

    The 500 club

  • Members
  • PipPipPipPipPip
  • 596 posts
  • Location:Michigan
  • Version:LabVIEW 2012
  • Since:1994

Posted 16 March 2011 - 03:22 PM

We put together test equipment. General rules for what to get in a PC for us are:
- 4 GB RAM, possibly more if it's a NVH application
- Faster dual-core processor. The only time we used 4 cores was with a LabVIEW 8.0 application and 3+ cores slowed the test by ~40% due to multi-threading. We've not tried more than two cores since, so I can't comment on what the improvement has been since.
- Does the PC has enough ISA/PCI/PCIe slots (yes, we still occassionally use one ISA card... baffling)

Video cards have only come up once when a customer wanted 4 monitors from one PC. Otherwise, the screens don't update that much information that disabling updates for a moment doesn't take care of performance issues. The performance issues I run into is with multi-column list boxes when doing something like setting colors of individual cells (red=fail, green=pass), and populating tables. Graphs don't give me issues; I've tested putting 10,000 waveforms of 16k points each on a graph and had a slight performance hit when zooming in and out.
Tim

"If this was easy our kids would be doing it." - Coworker

#7 Cat

Cat

    The 500 club

  • Members
  • PipPipPipPipPip
  • 776 posts
  • Location:Maryland, USA
  • Version:LabVIEW 2012
  • Since:1994

Posted 16 March 2011 - 04:02 PM

If you are dealing with large amounts of data, memory is going to be a real problem. It gets even worse if you're plotting it. Why? 1) LV doesn't handle large data sets well, and 2) 8.6 (the version you have listed) isn't "large address aware" Check out the following if you're using a built app:

http://digital.ni.co...62576F00058F94E

(thanks to mesmith here for that link. I haven't had a chance to check out the suggestions he or ShaunR made yet)

IOW, sure, getting a faster CPU should help with number crunching, but optimizing memory use will go far, too.
"It's only funny until someone gets hurt... then it's hilarious!"

#8 neBulus

neBulus

    LV Survivalist

  • Members
  • PipPipPipPipPipPip
  • 1,389 posts
  • Version:LabVIEW 2009
  • Since:2009

Posted 16 March 2011 - 04:08 PM

...UI thread is single threaded. ...

Ben


I'd like to add an outlandish statement re: the UI thread.

THe UI thread is over-used. It is now ime for NI to seriously consider getting all GUI updates out of the UI thread so that they can happen in parallel. It was a clever move when first implemented but the time has come to fix the UI Bottleneck.

Ben

#9 Neville D

Neville D

    The 500 club

  • Members
  • PipPipPipPipPip
  • 751 posts
  • Version:LabVIEW 2011
  • Since:1996

Posted 16 March 2011 - 04:54 PM

In the past, having graphs/charts transparent and overlaid caused the drawing updates on panels to be drastically slowed down when LV tries to draw and then redraw the layers above. Try to avoid transparency or else make sure transparent elements are not overlaid on each other.

But I agree, panel drawing routines especially for charts/graphs have been a performance bottle-neck for ages. In this day of streaming video, and using video cards as co-processors for FFT's, having an application fall to its knees when plotting data is a bit ridiculous.

NI really need to work on improving performance in this area.


N.

#10 Justin Goeres

Justin Goeres

    The 500 club

  • JKI
  • 684 posts
  • Version:LabVIEW 2012
  • Since:1997

Posted 16 March 2011 - 07:00 PM

Thanks, everybody, for all the feedback. Everything is pretty much along the lines of what I already suspected, but it's good to see the discussion.

We've been discussing this internally at JKI, too, and I've sort of come to the following take-home points:
  • Good code always beats bad code (this is obvious, and yes, I ruled this out in the original question, on purpose)
  • A faster computer will definitely help in the case I specified. Also, more RAM never hurt anyone.
  • Being careful about transparency and tab controls (especially nested ones) will probably help, too.
  • A powerful graphics card will probably not change things much.


#11 neBulus

neBulus

    LV Survivalist

  • Members
  • PipPipPipPipPipPip
  • 1,389 posts
  • Version:LabVIEW 2009
  • Since:2009

Posted 16 March 2011 - 07:11 PM

Thanks, everybody, for all the feedback. Everything is pretty much along the lines of what I already suspected, but it's good to see the discussion.

We've been discussing this internally at JKI, too, and I've sort of come to the following take-home points:

  • Good code always beats bad code (this is obvious, and yes, I ruled this out in the original question, on purpose)
  • A faster computer will definitely help in the case I specified. Also, more RAM never hurt anyone.
  • Being careful about transparency and tab controls (especially nested ones) will probably help, too.
  • A powerful graphics card will probably not change things much.


On that last point.

I suspect that very little of LV graphics can take advantage of the accelerator on high-end graphics cards.

The New 3D picture may be the exception. I am getting good response from it and have not totally ruled out (yet) including the 3D graphics as a realtime update.

So if the app is using the 3D picture, a good graphics card may pay off.

Ben

#12 Justin Goeres

Justin Goeres

    The 500 club

  • JKI
  • 684 posts
  • Version:LabVIEW 2012
  • Since:1997

Posted 16 March 2011 - 07:14 PM

The New 3D picture may be the exception. I am getting good response from it and have not totally ruled out (yet) including the 3D graphics as a realtime update.

That's my understanding too, but I also have never tested it to see for sure.

#13 Mark Smith

Mark Smith

    Extremely Active

  • Premium Member
  • 322 posts
  • Location:Utah
  • Version:LabVIEW 2011
  • Since:1995

Posted 16 March 2011 - 07:51 PM

I'll throw one other thing in - SSD's have improved performance most everywhere I've used them - for instance, if you do get memory paging, it will be a lot faster than if you have to page to a disk. It's kind of an expensive alternative, but it almost always helps.

Mark
Mark Smith, Certified LabVIEW Architect
www.mooregoodideas.com