Meaningful LabView versions speed benchmarks - anybody?

[MichaelS]

Did anybody try to come up with meaningful speed benchmarks for different (5, 6, 6.1, 7) LabView versions?

Meaningful means time of most important LabView subunits would be compared. Most important subunits are, for example, time to execute a .dll based native VI, time to perform build array operation, time to call a global, FFT, DFFT, IMAQ FFT, etc.

NI provided "comparison" between 6.0, 6.1 and C for some applications. This comparison is not convincing and outdated.

The suggested benchmarking is a simple and easy task to accomplish, given all versions of LabView are installed on the same machine. Wonder why there is no info on that anywhere.

Micahel

[JRA]

This is a good question. I have not seen any stats like this anywhere. You could always contact NI and ask them.

[MichaelS]

Yes, I could always contact NI, and I did contact NI before posting. That is why I posted. NI "does not have" this information.

Am I onto something or is it just my wrong sense of conspiracy theories??

[pn2500]

> Yes, I could always contact NI, and I did contact NI before posting.
> That is why I posted. NI "does not have" this information.
>
> Am I onto something or is it just my wrong sense of conspiracy
> theories??

yes, you are onto something.

That which is not discussed, is usually for a reason, imho and/or imle.

Labview has historically been quite slow, due
to being an interpreted 'language'.

Used to be, one used NI's CVI 'C' product for
realtime speed in data acquisition / signal processing.
Labview was for cute, simple, and very slow ATE apps.

things are different now, I hope?

Though, the 'Realtime Labview' marketease seems a bit of a puzzle to decipher.

[Greg_McKaskle2]

> Labview has historically been quite slow, due
> to being an interpreted 'language'.

Just to be clear, LV has not been interpreted since 1990. It does
generate rather different code that is capable of multitasking, but it
is a compiler.

Greg McKaskle

[Greg_McKaskle2]

> Am I onto something or is it just my wrong sense of conspiracy
> theories??

Years ago, NI wrote a large set of VIs that did low level timings of
things like file I/O, math, analysis, and UI elements. We did this to
give us a measure of what needed to be sped up, and by how much it changed.

We still use those benchmarks internally, and since they were just VIs,
they still work today. I know that they are still on the ftp site in
the support/labview/windows/3.1/benchmark directory.

So, perhaps we addressed this long long ago and it isn't a conspiracy at
all. Of course it's always a bit difficult to predict the future, so
the benchmark is a plugin and you are welcome to add your own task for
timing across machines and LV versions.


Greg McKaskle

[MichaelS]

Thank you for understanding my question and suggesting to do something NI is expected to provide.

Wouldn�t you say benchmarking of performance between LV versions is a valid and important technical spec for a version? Why then you expect a user to come up with it, given all inconveniencies of installing and uninstalling different LV versions on the same machine?

It makes me suspect NI does not want to disclose that the addition of new bells and whistles to a new version usually comes up at a price. It slows LV down. Isn�t it the truth? And where are the benchmarks?

Michael

[Dennis_Knutson]

The slowdown isn't necessarily true at all. Doing a search for benchmark in the NI Developer Zone came up with the page here [broken link removed]. From 6.0 to 6.1, some things got better, some things got worse, and some things stayed the same. I would recomend doing your own benchmarks because the tasks that you do a lot of are more important than what womeone else chooses to benchmark. You can have multiple versions of LabVIEW installed on the same computer so it should be something easy to try. Be aware that that different versions of NI-DAQ and NI-GPIB can also have a great affect on what numbers you come up with. Some programs can a
lso greatly benefit from a rewrite. An example is user interface tasks. A user interface that doesn't use events should be rewritten to use them to see the benefit of a new LabVIEW feature.

[MichaelS]

I am sorry, Dennis, but you missed the point.

1. The user DOES NOT KNOW if there is any slowdown in relevant subunits between the versions (see the original post). It is a responsibility of NI to provide user with this information.

2. As I mentioned before, the example you referred to is inconclusive and outdated at least. It compares something not worth comparing - applications that depend, as you rightly noticed, on user interface, programming style etc.

What I asked for is info on comparison of LV "subunits" for versions 6, 6.1, 7: array building speed, dll calls etc. These are programming independent. These are the only elements worth benchmarking.

*And* NI does not disclose this benchmarking information.


For your information, installing multiple versions of LV on the same machine at the same time is usualy prohibited by the end user license. Also, LV then frequently becomes very unstable. Sometimes NI recommends to completely uninstall previous version before installing a newer one.

Have a nice day.

[Dennis_Knutson]

I wouldn't agree that the benchmarks for file i/o, array manipulation, fft speed aren't relevant becasue they certainly are to what I do. Are they complete? Of course not. Should NI add more? Yes. Should you be responsible for a set of your own benchmarks? Probably, because NI will never be able to satisfy all of its users and the infinite number of applications that are possible.

As far as the end user license, for you information the 6.1 agreement says:

"Upgrades. If the SOFTWARE is an Upgrade, you may only use the SOFTWARE if you have (at the time you receive the Upgrade) a valid license to use the pre-existing SOFTWARE. Further, the license agreement accompanying the Upgrade applies to your use
of the Upgrade. While you may continue to use the pre-existing SOFTWARE, you may only use it on the same machine upon which the Upgrade is used and the license that accompanied the pre-existing SOFTWARE will continue to apply to your use of the pre-existing SOFTWARE. "

I would interpret the statement "you may continue to use the pre-existing SOFTWARE" to mean just that and have always left the older version on my system until I've converted all older programs (which have sometimes taken a great deal of time).