LabVIEW 5 and multicore processors

[Steve Morris]

Hi All,

I've searched the LAVA archives and the NI website and haven't been able to find anything related to my issue, so I'm hoping someone here can provide some insight.

I'm supporting a client who has a piece of production equipment that is controlled by LV5.0.1 in the development environment. As we've added functionality to the code it has started to bog down and that is impacting the production throughput. The code has been worked on by many people over the last decade and is sorely in need of a complete overhaul. The overhaul, if it happens, won't be quick so I'm am looking at what we can do in the short term to improve the situation.

Does anyone have experience running LV5 on a mulicore processor? When LV5 was released, it was touted as "hyperthread capable", but that was before multicore processors entered the mainstream. Is LV5 capable of taking advantage of multiple cores, or will it just run on one of the cores?

Our current PC configuration:

Dell Workstation PWS370

Pentium 4, 2.8GHz, 1GB RAM

WinXP Pro Version 2002, SP2

Does anyone have any experience to share?

Thanks,

Steve

[Tim_S]

Does anyone have any experience to share?

I don't have anything with LV 5 (it's been, what, 12 or 13 years since I've seen LV 5...), but my experience with LV 8.0 was a performance degradation with more than 2 processors. I expect you won't have an issue with multiple processors and that the application will split between the two.

Tim

[crelf]

How big of a "system" is it? Would it be prohibitive to have someone come in and fix the issue, rather than throwing better hardware at it (which might actualy make it worse)? What's the OS that's it's running on? Unfrotuntately, upgrading a system isn't usually just about a new processor, it's about all the things that come along with it

[hooovahh]

I might be wrong but I think 8.2 was the first to take advantage of multicore PCs and only up to 4 cores. Then in the next major release of LabVIEW they supported more cores, I think 16 or 32, some number much greater than I was concerned with.

[Steve Morris]

How big of a "system" is it? Would it be prohibitive to have someone come in and fix the issue, rather than throwing better hardware at it (which might actualy make it worse)? What's the OS that's it's running on? Unfrotuntately, upgrading a system isn't usually just about a new processor, it's about all the things that come along with it

The full system consists of:

Stage 1

WinXP Pro 2002 SP2 with LV5 running on a Pentium 4 2.8GHz and 1GB RAM

SCXI chassis with (1) 1163R relay card driving 22 solenoids/actuators, (2) 1162HV input cards reading 44 limit switches, and (1) 1122 reading a handful of thremocouples

18 serial ports

Stage 2 (my details here are a little sketchy since we've been concentrating on Stage 1)

WinXP running LV7.1

SCSI chassis with (1) 1163 relay card driving 15 solenoids/actuators, (1) 1162HV inpu card reading 30 limit switches, and (1) 1122 reading a handful of thermocouples

PCI-IMAQ-1409 analog video board (now obsolete)

VIdeo switch

9 video cameras

Upgrading the PC is only being considered as an interim incremental fix for Stage 1 throughput. The whole system is in need of an overhaul as there have been many bells/whisles/warts added over the years by many different hands. The client has been reluctant to upgrade from 5 and 7.1 because they want to squeeze everything out of what they have and are afraid of the effort and risks of upgrading. We've just discovered that there are no drop in replacements for the video board in Stage 2, so we may be forced to upgrade that portion of the system. Right now we are trying to identify what we need to do to sustain and maintain the equipment going forward. And to answer your question, no it wouldn't necessarily be prohibitive to have someone come in and 'fix' the issue(s) -- but first we've got to figure out what the issues are.

[Tim_S]

The client has been reluctant to upgrade from 5 and 7.1 because they want to squeeze everything out of what they have and are afraid of the effort and risks of upgrading.

One issue we've had is the device drivers only support some versions of LabVIEW. This might not be an issue between 5 and 7.1, but should be checked.

Tim

[crelf]

PCI-IMAQ-1409 analog video board (now obsolete)

...

We've just discovered that there are no drop in replacements for the video board in Stage 2, so we may be forced to upgrade that portion of the system.

Wow - so when I first read that I thought, surely not: depending on what you're doing, the 1410 and 1411 could be good replacements, but on looking at NI's site, it looks like all of their analog frame grabbers are listed as obsolete...

[Steve Morris]

One issue we've had is the device drivers only support some versions of LabVIEW. This might not be an issue between 5 and 7.1, but should be checked.

Tim

Thanks for the reminder. It might be an issue if we end up bringing the code all the way up to current.

Wow - so when I first read that I thought, surely not: depending on what you're doing, the 1410 and 1411 could be good replacements, but on looking at NI's site, it looks like all of their analog frame grabbers are listed as obsolete...

Yes, this is apparently a somewhat recent development. When we reviewed the spares list a year ago we identified the 1410 as a drop in replacement. Per NI, you can still order a 1410, but you may not get it as they are having component supply issues.

[Mr Mike]

So, I just talked to someone who would know about LabVIEW's behavior on hyperthreaded machines. According to him the OS presents a single hyperthreaded core as two separate cores. This means that it should treat two threads on one core no differently than two threads on multiple cores. He did mention a performance issue that was discovered in LV 6 or 7 related to multicore environments, but that wouldn't turn up from growing an application.

Have you tried using the profiling window? The oldest version I have access to (easy access, that is) is LV 5.1 and that has it (under Project -> Show Profile Window). In LV 7.1 it's under Tools -> Advanced -> Profile VIs...). You can see where your slowdowns are.

- Mike Benza

[Steve Morris]

So, I just talked to someone who would know about LabVIEW's behavior on hyperthreaded machines. According to him the OS presents a single hyperthreaded core as two separate cores. This means that it should treat two threads on one core no differently than two threads on multiple cores. He did mention a performance issue that was discovered in LV 6 or 7 related to multicore environments, but that wouldn't turn up from growing an application.

Have you tried using the profiling window? The oldest version I have access to (easy access, that is) is LV 5.1 and that has it (under Project -> Show Profile Window). In LV 7.1 it's under Tools -> Advanced -> Profile VIs...). You can see where your slowdowns are.

- Mike Benza

Mike,

Thank you for the info on LV and multiple cores. It isn't entirely clear that this performance issue hasn't been around in the code for a while since this is the first time (or at least the first time anyone currently involved knows of) that we've looked this deep into what is happening with the code.

And an extra thank you for reminding me to use the profiling window (it is under Project -> Show Profile Window in 5.0.1 also) -- one of those tools I tend to forget about. I will use it the next time I'm in the plant.

Steve

[joshxdr]

I believe you can load lv5.1 code with lv7.0, and then open lv7.0 with lv7.1. I have done something similar before, it did not seem to impact the functionality, your experience may vary of course.

My experience may not be typical, but I have seen old systems that were built by a new grad as his first ever software project, and a revolving door of semi-skilled engineers performs copy/paste/bandaid edits until the code is an unreadable unreliabile mess. Then years pass and everyone assumes that the old system is perfect, like scripture handed down from the ancients. If this is the case, do the right thing, put that monster out of its misery and build a real system. You may find that magically your quality, throughput, and development cycle times magically improve and you get to be the hero.