09-03-2012 04:35 PM
Now that I have loaded LV 2012 on my Mac I ran this. In LV 2011 the Lock/Unlocks chart averages about twice as much as in LV2012. Running the Profiler slows the results by about 30% on both versions. The three VIs with the largest number of runs are the update.vis. They average a few microseconds and the ratio from LV2011 to LV2012 remains about 2.
It appears that both keep two cores near 100 percent according to Apple's Activity Monitor.
Mac OS X 10.6.8 on iMac running Intel Core i3 at 3.2 GHz. LV2011, SP1 (11.0.1) 32-bit. LV2012, (12.0f1) 32-bit.
Lynn
09-04-2012 01:08 AM
Lynn and David,
Could the difference between 2011 and 2012 be different memory and buffer management?
In the update vi's I'm doing dynamic casting and shoving/replacing a cluster into/in an object.
Which isn't really a too obscure and fishy thing to do?
Another possible difference could the way in which LV handles method overrides?
Running with the profiler in LV2011 gives a performance impact of an order of 2 in magnitude when maxing out loops, which is surprisingly large and possibly limits its usefullnes?
Br,
/Roger
09-14-2012 11:47 PM
This turned into a limbo problem report?
No new updates for some time?
Br,
/Roger
09-15-2012 12:29 PM
I'm curious if this is still being investigated as well. I just moved to 2012 and do a lot of crio work.
09-16-2012 11:15 AM
Hi Roger and Jed,
This is still being investigated. Unfortunately, I don't have any additional information at this time on why this particular benchmark is slower in 2012. Please feel free to check in on this thread or PM me if you would like an update on this particular issue.
David A
09-16-2012 02:17 PM
I still don't understand the use case of this benchmark program.
So it is slower by a factor of two, which, in the grand scheme of things, seems almost irrelevant. (I start worrying when differences by orders of magnitudes show up.) You are basically measuring a single operation, and it got a little slower. Improvements to the compiler always involve compromises between speed, memory use, safety, and many other parameters. This time, the balance got a little bit tipped differently, which possibly exposed advantages elsewhere. Maybe 2011 is artificially fast because some important precautions are skipped that can lead to crashes under a defined set of conditions?
How is the overall speed of your application (not just this tiny benchmark)? Are you really redlining your RT system 100% of the time? Does it really take significantly longer to execute?
Please help me understand the problem. I really don't get it. (Still, I agree it should be investigated.)
09-16-2012 03:42 PM - edited 09-16-2012 03:43 PM
use-case: http://en.wikipedia.org/wiki/Benchmark_(computing)
I have been running this benchmark with variations of it since LV2009 to verify the performance of my implementations and LV. I think it is safe to say that LV2012 is artificially slow, perhaps due to major rework in the compiler.
Well, getting caught in some fancy refactoring without doing comprehensive performance testing is, well...
No matter how good the implementation is in theory, if it does not fly practically, its pointless.
I am not sure I agree that a <50% performance drop is 'irrelevant' for standard LV code, as in my benchmark.
Br,
/Roger
09-16-2012 04:06 PM - edited 09-16-2012 04:06 PM
No, the performance difference is not negligible.
We've found LV 2012 to also be slower than other LV versions on RT. Enough so that we'll probably NOT be moving to 2012 with our project (Even though there are some aspects we'd like to utilise). And yes, we're pushing our RT systems to the limit so every microsecond counts.
Shane.
09-17-2012 04:55 AM - edited 09-17-2012 04:56 AM
Roger,
please check of all VIs you use in your benchmark are using full compiler optimization.
Another point i want to double check:
You disabled debugging for all those VIs?
Norbert
09-17-2012 06:05 AM - edited 09-17-2012 06:06 AM
Not much difference changing the compiler optimization settings and mass compiling between. See images below.
All debugging disabled, too.
Full compiler optimization (10 in LV2012):
Least compiler optimization (0 in LV2012):
Memory Usage (LV2012):
LV2012 Compiler Settings:
Reference (LV2011):
Memory Usage (LV2011):
Br,
/Roger