08-28-2012 01:55 PM
I have used 7.1 but not below that. Ok if we start this discussion it will keep going may be later on Breakpoint. Now I am curious to see your comments on the Benchmarking
08-28-2012 02:18 PM
I am glad i did not promise anything!
The only thing I can offer is to
1) try putting a "0 ms wait" in the while loops where you are doing the increments to help out with cooperative multi-tasking. It help with the process scheduling.
2) Make sure you have turned off debugging etc in both versions.
3) I believe there was a change implemented with the type cast that may be part of the explanation if your results still look bad for 2012. I can not be sure since I was told a bug I uncovered that allowed breaking some the LVOOP contracts would be fixed but I did not here back so I admit I am speculating.
In the meantime i will falg NI to look at this closer and either explain or log this a performance bug.
Sorry but that is all I can do.
Ben
08-28-2012 02:32 PM
Thanks, Ben
It's also my suspicion that the culprit could be the type cast, method override or queue operations that somewhere along the line got a performance hit for LV2012?
Or perhaps it could be an overly aggressive memory size optimization in the runtime, which gives an execution speed penalty?
Maybe LV 2012 is too C/C++ 'delete/free' trigger happy? 🙂
Well... I'll keep scratching my ignorant head over this one...
Let's see what NI's got to say about this.
Br,
/Roger
08-28-2012 02:35 PM
When I notified NI I told them;
"We either have a bug or a leson to learn."
Ben
08-28-2012 03:21 PM
08-28-2012 03:58 PM
Darin.K wrote:
Just to rule out the obvious, have you mass compiled and saved the VIs in LV12? Opening a VI in a new version puts all subVI FP in memory which can slow things down, much like benchmarking with SubVIs open will.
I got the imprdion this runs on a RT platform in which case that should be covered when compiled and downloaded... of course I may be wrong about either of those points.
Ben
08-28-2012 04:32 PM
08-29-2012 12:02 AM - edited 08-29-2012 12:03 AM
The performance drop is most noticeable on more computationally constrained RT targets, such as the sbRIO 9606.
On my "real" c/sbRIO customer projects/programs where I previously was utilizing about 30-40% of CPU, now flatlines at 100%.
Br,
/Roger
08-29-2012 07:00 AM
@User002 wrote:
The performance drop is most noticeable on more computationally constrained RT targets, such as the sbRIO 9606.
On my "real" c/sbRIO customer projects/programs where I previously was utilizing about 30-40% of CPU, now flatlines at 100%.
Br,
/Roger
Please try putting "0 ms wait"s in those loops.
Please.
The "0 ms wait" only marks the end of the loop so the task scheduler can do it job without preempting etc.
Ben
08-29-2012 07:12 AM
Did that yesterday.
The performance went down even further (some 20%), since we are forcing the scheduler to run between each iteration I presume?
Br,
/Roger
@Ben wrote:
@User002 wrote:
The performance drop is most noticeable on more computationally constrained RT targets, such as the sbRIO 9606.
On my "real" c/sbRIO customer projects/programs where I previously was utilizing about 30-40% of CPU, now flatlines at 100%.
Br,
/Roger
Please try putting "0 ms wait"s in those loops.
Please.
The "0 ms wait" only marks the end of the loop so the task scheduler can do it job without preempting etc.
Ben