mathscript, speed, os-x vs windows

[Jon_S.]

Hey everyone,

I ran a couple of tests on the on my end as well.  I noticed that you were comparing various versions of LabVIEW.  I should note that one of the main things that has been improved with the MathScript node is execution and compile time.

Here are the results of my tests.  All of these were done on Windows XP.

LV 8.6

MathScript 41.9

LV 7.5

LV 8.5

MathScript 47.3

LV 12.9

LV 8.0

MathScript 84.1

LV 14.7

I would attribute the differences in execution time on your systems to be more influenced by the version of LabVIEW than on the operating system.

[chaosguy]

Sorry, in my original message, I should have made clear that I was talking about execution times for the same LabVIEW version (8.6).  It was just a coincidence that the times looked like LabVIEW versions!  The hardware and software are identical for all the tests.

Thus, my original question still stands:

1)  Why does Mathscript show such different execution times under OS-X vs XP?

2)  Why are these factors reversed depending on what is tried?  (Below, there is a 3x advantage to fft under OS-X.  In my original vi -- not as nice as the present one -- I also compared the lsim operation and found a 3x advantage for XP.)

I've recopied the message below, putting in these clarifications: 

Good points.  I quickly checked your version.  In LV8.6, I get (avg. over 100 iterations, done 3 times):

under OS-X:      Mathscript:  42.5 ms/iteration   Lv nodes:  6.8  ms/iteration

under XP:          Mathscript:  137  ms/iteration   Lv nodes:  8.0  ms/iteration

So in running "native" LabVIEW code, the OS-X version is slightly faster, which would be consistent with the idea that you pay a bit of a price for running XP on the Mac.

 The second general point is that the mathscript node is considerably slower, also consistent with previous remarks about overhead being involved.

But there is still a 3x difference between XP and OS-X.  I would imagine that my lsim result would continue to hold (faster on XP than on OS-X), although the practical conclusion would obviously be that if you care about speed, use the native LabVIEW nodes.       

[jattas]

I haven't investigated this issue in depth so I can't give any definitive answers, but here are some things to consider.

The MathScript implementation of 'fft' calls the LabVIEW FFT VI. The LabVIEW implementation of FFT is different on Mac and Windows. On Windows, it calls Intel's MKL while on Mac it calls vecLib. It is very possible that they have different performance characteristics (see this Knowledge Base article for a bit of information about this).

The 'lsim' function has the same implementation on Mac and Windows. So one possible explanation for the numbers you're seeing is that 'lsim' is slower on Windows because of the cost of running under virtualization while 'fft' is slower on Mac because vecLib is slower than MKL (so much so that it trumps the cost of virtualization). This is just a theory, but one that fits with the data we have so far.

One way to test this would be to try benchmarking other MathScript or LabVIEW functions. If Mac is generally faster than Windows for functions with the same implementation then I would attribute the difference to virtualization. If you see other functions that are faster on Windows, we could check whether there are implementation differences under the hood.

Good luck!

jattas

LabVIEW MathScript R&D

[chaosguy]

Sorry for the confusion.  I think I may have gotten myself confused in the times for the first post.  The lsim operation is 3x FASTER under XP (virtualized) than under OS-X, which goes against your theory.  (The OS-X fft is then 3x faster than XP, too.)

Attached is the (zipped) improved test, benchmark1a.  On my hardware, I get (averaging over 100 iterations)

XP -- 91 ms/iteration

OS-X  260 ms/iteration

Note that the control addon is needed to run this. 

PS  On a related topic, I also found that the ode operations in mathscript are extremely slow compared to either the native labview code or even the Scilab-node equivalent.  In an offline post to Grant M, I quoted a 40x difference for mathscript code compared to scilab code.  This was actually the marginal difference (ie comparing slopes of execution times to iterations), in order to eliminate the possibility that having to call an external function in mathscript but not scilab was the reason for the slowdown.  I haven't looked at the labview native code, but in general, it looks fast.  So this would be a mathscript issue.