02-14-2012 04:28 PM
Thanks for trying things out. It appears to me that what you claim in theory is not possible in practice. Is that right ?
You claim that "if you want to speed up your parallel code (using disable parallel execution),you want to use timed loops", however neither of us are able to implement this in even a simple example.
If this is the case then LVEA still has a huge problem because putting down parallel loops of any kind severely degrade performance/speed compared to the same code in a single loop. This is a real shame as the beauty of programming in LabVIEW is the ease of which parallel tasks can be coded.
02-14-2012 05:21 PM
>> 5) It would be great to see what performance degradation you get on your faster boards between code in on loop with all the fastest compiler options and then the same code split into two
>> loops with the fastest compiler changes to make it run in parallel. You'll either get only a halving in speed (great!) or a five time reduction (bad news for me).
> I will have to do this
You wrote that you were going to try out this experiment and see if you get much worse perfomance as Vito and I do when splitting one while loop into two parallel while loops.
Have you done this yet ?
02-15-2012 02:08 AM - edited 02-15-2012 02:10 AM
Disable parallel loops gives smaller code. (no need for LV scheduling)
and at that point if you want to use paralelism, you must use timed loops. (like two main tasks)
I don't know what's the cause of the not working code if you use timed loops and all the optimatization.
So, we concluding that for loops are faster then timed loops. I will have to play with timed loops to set the period smaller. (I've set this to 0 ms), but I don't know which period is used. (delay?)
If you disable parallel execution with for loops, only 1 for loop will run at the time. If you replace the 2 for loops with infinite while loops, it will only run one while loop..
I've tested one application on the LPC1788, I have the following timings:
lm3s8962: 90.798 ms and 182.647 ms
lpc1788: 68.788 ms and 140.751 ms
so the lpc1788 is (90.798 / 68.788) = 1.319 and (182.647 / 140.751) = 1.297 times as fast (let's say 1.30)
let in mind that this is the test with the timed loops.
02-15-2012 03:28 AM
It's surprising and disappointing that the LPC1788 didn't perform better. The LPC1788 has twice the CPU clock speed (and therefore MIPS) than the LM3S8962, however it only performed ~1.3x better. And presumably with compiler options that only get ~20% of the CPU performance.
Would it be possible to incude the VIs you used and the compiler settings?
02-15-2012 04:03 AM
I will have to test the lpc1788 with the other tests also (not timed loop)
I have experienced 75% better performance with other apps.
here are the test vi's (LV 2010) in 7zip.
02-15-2012 04:56 AM
Thanks for your VI. I will try it tomorrow when I'm back at work.
Any chance of you running the following two VIs with the compiler options as shown on the LPC1788 board.
They are provided as snippets so hopefully you can just drop them into a blank VI. You will need to replace the display routines with whatever display you hve on the LPC1788.
The times for these runs will tell me everything I need to know about LabVIEW Embedded.
02-15-2012 07:52 PM
Please find attached the zipped Timing Evaluation project.
If you get time to time the two VIs it would be great. When doing the timing, don't take the first run. Instead reset the board and take the next run (all other runs are exactly the same timing, at least for me).
Thanks and Regards,
02-16-2012 02:29 AM
Thanks, I am going to test it.
So you are using LV for ARM 2011?
with standard LM3S8962 target?
I see for the LM3S8962 in LV 2010. that the timings are:
test 1: 113 ms (LV 2011 134 ms)
test 2: 640 ms and 682 ms (LV 2011 718 ms)