MathScript Performance

[gregyorke]

 
Hello:

I  am currently evaluating Mathscript. I  am testing the speed in the attached example.

I  estimate about 1 second to run the code.  There  is a YouTube example which appears to be the same ?  Is  this typical performance ?

My  application requires at least 1000 times faster than this.

 Do  you have any suggestions on achieving this performance ?

Someone  mentioned  LV Code. Any links to this ?

Regards,

Greg  Yorke

[johnsold]

Greg,

I do not have Mathscript.

I do not understand the terminology used to define y2 = B + C * exp(-t/tau) .* t; in particular the .* part.

Other than that it looks like something that could probably run in milliseconds in native LV code.

Lynn

[natasftw]

If your application requires a 1ms period, why are you developing for Windows instead of a more deterministic OS?

But, yes.  You can get faster speed using native LV code.

[johnsold]

The calculation of y1 takes about 3 microseconds in native LV code (average of 10000 iterations). The drawing of the plot takes 28 milliseconds. 

[Edit] Sorry, I misread the timing. The calculations also take ~23 ms. 

Unless your users have unusual eyes and brains and unless you computer has an unusual monitor and video driver, it does not make sense to update the plots on the screen more than a few times per second.

Lynn

[Bob_Schor]

Well, I coded this up on my 5-year-old Dell laptop in Windows 7 x64, LabVIEW 2015.  I timed (using the Precision Timer) generating both curves and displaying them in an XY graph.  Took about 106 microseconds, i.e. about 10KHz.  So why, oh why, would anybody want to do this calculation in a MathScript within LabVIEW (as opposed to throwing away MathScript and just using pure LabVIEW)?  Does a speedup of 10,000 seem like a good deal?  Does that make worth spending a few hours learning (extremely simple) LabVIEW coding procedures a good idea?

Bob Schor

[Bob_Schor]

Hmm.  Not sure why my code runs so much faster then Johnsold's code (except we are probably doing different things).  I did it again on my PC at work -- a desktop machine, about 2-3 years old, possibly an I7 processor.  I did a loop of 1000 repetitions (including outputting the graph), and the loop took 27 microseconds.  I'm attaching the code as a Snippet -- I think I interpreted the MathScript correctly ...

Bob Schor

[gregyorke]

Bob,

Thanks for your interest. My original question was in regard to the performance of Mathscript. I was using the y1, y2 as an example for testing performance.

My actual application is not the y1, y2 example. However there is no LabVIEW objects that can be used for my application so I am testing at Mathscript first (as recommended by a NI sales person).

My application is written in VB6 (about 100 lines of code - with 10-20 non-linear equations (trig, exp functions) with 2 predictor-corrector solution steps for each loop.

Each calculation loop executes about 100 - 200 (trig, exp type) equations.

For 10000 calculation loops the VB code runs in about 800 ms.  I need this performance.

Do you have any recommendations for this scenario ?

Regards,

Greg Yorke 

[johnsold]

Bob and Greg,

I have been asleep at the switch. I did not take into account the number of times the core code executed. I was using the Profiler, which is only moderately accurate as a timer.

I modified Bob's code to include mine as a subVI so they could be compared under similar circumstances. The biggest difference between my VI and Bob's is that I used Ramp.vi to generate the time array and then used array calculations.

Also I changed tmax and p to controls because using constants may allow the compiler to do constant folding which can make a big difference in speeds. I moved the indicators outside the sequence structure. This also forces the compiler to generate an output.

With those changes my code runs in about 28 us per iteration while Bob's takes about 33 us.  The outputs for y2 are slightly different due to the use of different values for  C.

##############

Optimizing code for speed takes some care and skill. You want to avoid repeating any calculation unnecessarily, meaning move things outside loops where feasible. You want to be especially careful not to change the size of arrays during calculations. Do not wire anything to indicators inside the loops. Display is orders of magnitude slower than most calculations. Avoid coercion dots. Some are harmless but in many cases they indicate a data conversion. The tmax divided by p calculation in Bob's code is an example showing a conversion dot. In this case it probably does not cost any extra time. That is also a calculation which never changes and belongs outside the loop.  The negation and divide by tau may also be moved outside the loop. Working in complex variables helps for some kinds of problems.  Lookup tables for things which can be precalculated can be much faster than doing the calculations.

If you can post the equations (not the VB code) and your attempt to implement them in LV, someone can probably help optimize the speed.

Lynn

[Bob_Schor]

Yes -- do it all in LabVIEW, which is fast, even without being optimized for speed.  Alternatively, do it all in VB.

If you provide documentation of what you want to do, it is possible that one or more of us will take this on as a "challenge".  To avoid frustrating any intrepid souls who would be so motivated, try to provide enough input that we can be confident we are doing the right computation.  If there is test material that we could use as input, that would also be helpful.

Bob (Glutton for Punishment) Schor

[gregyorke]

Bob,

I am reluctant to disclose the VB code at this time. That may change. I am surprised of the poor performance with MathScript. (Reminds me of using the Excel Calc Engine.) 

I am also sure that the NI person that looked at this application originally was correct in that there were no LV objects available for this part of my application.

(Two other parts can use LV objects.) So I am looking at changing the equations (pre-computing). 

Yes, do it all in VB is option 1 that I considered. That is the basis of my test results.

The Honeywell DCS Experion CAB VB.net platform/environment is actually ideal. However the application needs to run at 100 hz to process a noisy signal.

Typically the DCS will only run at 1 hz.  So I need a different approach.  I am currently working on an NI and a non-NI solution approach.

Thanks again.

Greg