Speeding up execution

[saboo]

I am working on a MIMO channel emulator. The system has a large number of blocks which have to finish execution within the coherence time of the channel, which is a fraction of a milli second. However due to the complexity of some of the operations, I have had to use Matlab scripts to execute them. Now the entire cblock takes around half a second to run, which is far from my goal. Is the invocation of Matlab slowing down the operation? How do I speed up the execution to finish within the coherence time?

Thanks

[johnsold]

So you want to speed up your program by a factor of ~1000 but you do not tell us anything about what kinds of calculations you are doing, how much data is involved, or what the program architecture is.

What have you tried? What does the Profiler say about which parts are the bottlenecks? Can you post some code?

Lynn

[saboo]

oopsey, sorry should have done that. It mostly involves a lot of probabilistic computations, some intense arithmetic calculations and a lot of array operations. Plus there are loops which run, but only for a max of 20 times. There is also a small modulation module and 3 Matlab scripts.

I don't have a solution in mind yet. So haven't tried anything so far. I have attached the vi. 

[johnsold]

There are quite a few things you can do to speed up your program.  A factor of 3 to 5 is probably acheivable.  Who knows how much more?

1. You have some duplicated code and a lot of unnecessary code.

2. You do a lot of things the hard and slow way.

3. I do not have Matlab so I cannot test the speed of the scripts.  Since they call Matlab to run the scripts, I suspect the process is slower, even if Matlab can do the calculation faster.

4. Wires running behind other objects and right to left make a LV program hard to read.

5. At least one part probably does not work.  The code executes but may not produce the result you expect.

OK. Specifics.

1. You have constants 6 and 20 several places in the code.  If your system ever changes you will need to find and change all of them.  It is usually better to have one of each and wire them to all the places used.  No speed penalty but a lot of work troubleshooting if something needs to be changed.

2a. Using the Continuous Random.vi to generate 1 sample, as an array, then indexing the sample out takes about 3 times longer than using the Random Number (the Dice) from the Numeric palette.  It also produces uniformly distributed random numbers between 0 and 1. There are 8 or 9 of these constructions in your program.  Add about 200 ns each time one is called.

2b. Express VIs are almost always slower than using LV primitve functions.  The Angle Spread calculation (multiply, add, power of 10) is 260 ns slower on my computer. The Random Delays (ln(x)) is about 250 ns slower.

2c. Expression nodes are slower than using LV primitve functions.  The simple i+1 in a for loop takes 4.3 ns compared to 1.6 ns for the +1 primitive in the Numeric palette. Calculating the subpath offsets in a Formula Node takes 1 us compared to 280 ns with a case structure. Since it never changes, it should be calculated once, outside the loop. Then the time does not matter but you save a microsecond on every iteration.

5. The AoD sorting: step 6 involves equality comparison of floating point values.  This will often produce a false value for inputs which may be very close due to the finite representation of numbers in binary. Using the >0 test or In Range and Coerce?, depending on exactly what you are trying to do is probably a better method.

Lynn

[saboo]

Thanks for going over my code.I have a few points to make with regard to:

2a: I have not just uniform random number generation but gaussian at a couple of places as well. And I did check out the dice function. But I'm not sure how accurately I can generate numbers in a bigger range using that function (if at all).

2c: The subpath offsets are calculated only once for each of the 20 paths.I'm not sure what you mean by doing it outside the loop. But thanks for the case-structure tip.

5: The two floating point values are of the same precision and are derived from the same source with no arithmetic manipulation: one is the absolute value of the other. I have also checked their working on the front panel and they work correctly.

The code is in its primitive stages so you are right about wires running from one end to the other and duplication of constants.

I'll try the changes and see what the performance is like. But I do have another quick question:

Is the difference between 'iteration duration' indicator on the output node in a timed structure and 'Elapsed Time VI'  just that the former gives only the time to execute the code within the structure, while the latter specifies the time spent before transferring to the next iteration?

Thanks.

[johnsold]

2a. For Gaussian distributions you will need to use the VI.  Since you are intersted in performance, the dice will be faster where uniform distributions are OK.  To get other ranges just multiply by the span and add any required offset.  For the 0 to 360 (if I recall correctly) just multiply the 0-1 output of the dice by 360.

2c. Your for loop which calcuated the offsets was inside the main while loop so the identical calculation was repeated on every iteration.  By moving it outside the while loop, you are passing a constant array to the loop.

5. Under those conditions it probably works.  My point was that this is generally not a good practice.  Search for a recent discussion of -0.  It appears that there are two representations of 0 for floating point numbers.

I cannot help with the last question because timed loops are not available on my platform.

Lynn

[saboo]

2a: I did try out that method. But wouldn't the precision of the uniform number generator affect the range of possible values that we can ultimately generate? There are bound to be some values that cannot be generated by just multiplication and addition by constants, right? That's why I was worried about its accuracy.

[RavensFan]

No.  The precision is going to be the same whether you are dealing with a double precision floating point number between 0 and 1 or 0 and 360.  Pretty much the same.

[saboo]

I didn't mean the precision would get affected. I meant the actual numbers themselves.

If , just as an example with 2 decimal digits of precision, the dice generated 0, 0.01, 0.02 ,... 1, then multiplication by 360 would give 0, 3.6, 7.2, ..., 32.4, 360. The precision is the same but the range is discontinuous and no offset would help obtain all values. 

[RavensFan]

No.

The random number generator puts out a floating point number between 0 and 1.  The precision of that is down to whatever a double floating point would give.  It isn't has coarse as .01 like you thing.   Multiply by 360, you get that same small precision.  You can round that to whatever precision you need whether it is integer level, or something much smaller.

What precision/interval do you need between your different numbers?