P4 Hyper-Threading and LabVIEW7Express

[raeletro]

Does anyone has performance comparison reports on the performance of the LabVIEW7 when using P4 and Xeon Hyper-Threading single and dual processors ?

[Greg_McKaskle2]

> Does anyone has performance comparison reports on the performance of
> the LabVIEW7 when using P4 and Xeon Hyper-Threading single and dual
> processors ?

I don't know if there are any official reports on the web site, but we
are constantly looking at this sort of thing. I have a dual processor
(mac), and LV programs can often get a boost from the second processor.
From the numbers we have seen on hyper threaded machines, they often
get cache conflicts running VIs and run slower than a single processor
computer.

We are looking to see if there is something that we can change about how
our code is generated or scheduled to improve the hyperthreading
performance, but until then, my suggestion is to not stick to
traditional sigle or dual processor mach
ines. Hyperthreading isn't the
same as an additional processor. If you have one of these systems, you
might use the processor affinity to try things out with and without
hyperthreading to see if your are getting a boost or paying a penalty.

Greg McKaskle

[bboeke]

I have had programs that don't run correctly with Hyperthreading turned on. I asked NI about this and they say that they know LabVIEW doesn't work with Hypertheading!! For some reason they don't think it is important enough to mention on their web site. This is the message I got from NI:

Hello Bruce,

Thank you for contacting National Instruments. The behavior you are seeing with relation to hyperthreading on the newest Pentium 4s is the expected
behavior. LabVIEW (regardless of version) does not currently support hyperthreading. Until now, CPUs have had distinct threads even when multiprocessing, so an entire process always occurred on one 'processor'.
Now, hyperthreading allows even one processor to 'pretend' like it is two, but the process can be shar
ed between the two. We are currently working to
determine whether LabVIEW can or should develop compatibilty in its execution structure to support the hyperthreading technology.

Please let me know if there is any specific problems we might be able to help you with, that may not have to do with hyperthreading, or if there is
any additional information you determine to be important. I hope this helps! Have a great day!

Sincerely,

Elizabeth Fausak
Applications Engineer
National Instruments

[waldemar.hersacher]

I tested a application at home (PII) an found it is never running OK. Then I tested it in the office (P4 with Hyperthreading) and found it was running OK or not. The configuration was not always written when closing the app.

By design the app is multithreaded. There is a thread which loads and stops all modules and another thread which has to do with configuration data.

On my single processor machine the configuration thread is never able to write the data, but on the hyperthreading machine it will succeed nearly half of the tests I made.

I think LV will get a little performance boost from hyperthreading if the application is designed properly for multithreading.

Waldemar

[bboyce]

I have similar problems with ActiveX VB DataSocket component and DataSocket Server. I have a dual processor XEON machine and if I enable either the second processor, or hyper threading then the application in the auto-read mode (answering interrupts that are sent from the server to a subscriber) will often miss interrupts. After a couple are missed then things seem to be all jammed up and no more interrupts are answered. However, this is only for transfers of large data arrays and does not seem to affect transfers without interrupts of boolean attributes. Have not tried all other permutations of varible types and attribute types, but I think it is clear from the other comments (especially Elisabeths's) that hyper threading and/or dual processors can not be relied on
.

Brad Boyce

[Greg_McKaskle2]

> turned on. I asked NI about this and they say that they know LabVIEW
> doesn't work with Hypertheading!! For some reason they don't think it
> is important enough to mention on their web site.


Just to be clear, "doesn't work" may imply that a LV program will get
the wrong answer. This is not the case. A LV diagram will run on any
Pentium compatible processor from 486 to Xeon and get the same results.
The differences you will see will be in performance.

The combination of the Windows thread libraries and the hyperthreaded
architecture seem to throw a few curves to applications running on them.
In particular, the caches on these chips seem prone to being flushed
quite often and quite easily compared to a true multiCPU computer. The

strange things is that the behavior is somewhat different on linux.
After much investigation, we think we have cornered the problem,
reported it to MS and intel, and developed a solution. The upcoming
version of LV should show better performance on hyperthreaded computers
running Windows, but again, the current version, even version 5.0 should
give correct results, correct answers.

From our investigation, it also seems that the MS thread libraries
could be tweaked to give this boost to other multithreaded applications.
We don't have any word yet, but it is worth retesting as new MS
patches become available.

Greg McKaskle

[bboyce]

Elizabeth,

I agree with Bruce, it is frustrating trying to use the NI site to answer questions about compatibility. Or what is the latest version. For instance, see if you can find the answer to the question does DataSocket server work with XPpro? With Hyperthreading? With XEON processors? With dual processors? What is the latest version number for Measurement Studio for Visual Basic? How do I check to see if I have the latest? I have found the answer to these questions only after hours of searching!

That said, on the balance the NI product is super.

Brad Boyce

[Greg_McKaskle2]

> I have similar problems with ActiveX VB DataSocket component and
> DataSocket Server. I have a dual processor XEON machine and if I
> enable either the second processor, or hyper threading then the
> application in the auto-read mode (answering interrupts that are sent
> from the server to a subscriber) will often miss interrupts. After a
> couple are missed then things seem to be all jammed up and no more
> interrupts are answered. However, this is only for transfers of large
> data arrays and does not seem to affect transfers without interrupts
> of boolean attributes. Have not tried all other permutations of
> varible types and attribute types, but I think it is clear from the
> other comments (especially Elisabeths's) that hyper threading an
d/or
> dual processors can not be relied on.
>

As I mentioned in my previous post, LV itself should perform correctly
on multi and hyper CPU'ed computers. Of course there could be some NI
components that don't. If you suspect this, please file it as a bug
report and maybe they can get you a new version of the component that is
correct. I know that recently MS introduces the virtual user desktop
feature, and this threw some of the components for a loop. They want to
start up one server,and with this new feature, the thing they were
relying on to make sure there is only one server changed from beneath
them, and this could cause problems. When these things are
discovered/reported, they take a pretty high priority.

Greg McKaskle