Improve the execution speed of this VI

[obarriel]

I am running a system that requires that requires processing large amounts of data through this Vi. As it is now, it takes around 0.5s in my computer to execute.

Using the toolkit for multicore analysis I was able to speed it up quite a bit, but I wonder if there is any trick I could use to speed it up even more. Building a DLL would bring any benefit?

Thank you very much in advance.

[GerdW]

Hi obarriel,

how large are typical input data?

Your "ch0" contains 465120 elements: which computation speed do you expect?

Can you provide a VI using "standard" functions instead of those from "SparseMatrix" toolkit? (There are not so many people having that toolkit installed.)

What I see:

• You should not parallelize the inner FOR loop.
• The case structure only needs 3 cases to select from 3 inputs...
• Do you really need an output array of 23 elements?

[obarriel]

Yes, the typical input array contains 465120 elements

The output array will typically have 16 or 23 elements depending on what I plug in the "basis function control"

Later I will upload the vi with the standard functions.

Thank you for your tips!

[Yamaeda]

It probably won't save you many ms, but i see you've tried to use SGL and you have a number or coercion dots converting the arrays back to DBLs. Cleaning that up does something, if not much. 🙂

[altenbach]

It's not clear even the toolkit function even give an advantage here. As has been said, blindly parallelizing everything (e.g. inner loops) is not reasonable.

Can you take a step back and point us to a website that shows the algorithm. Maybe a rewrite from scratch would make more sense.

[altenbach]

---

@altenbach wrote:

Can you take a step back and point us to a website that shows the algorithm. Maybe a rewrite from scratch would make more sense.

---

Are you sure the code is correct? It does not make a lot of sense! For example:

• Your current default data outputs an empty result because the AXB errors out. Do you have better inputs?
• You are multiplying the complex FFT with a quadratic function. Since the FFT has symmetry around the center, it is not obvious what that should even do. Shouldn't that function also have some symmetry?
• You are doing a lot of multiplications with huge arrays of "1". None of these are needed. For example your loop stack could look as follows instead:
•  

[obarriel]

I attach the original vi with a realistic dataset (takes 1.6mb) and using the standard functions instead of using functions from the multicore toolkit

(In my computer using the multicore toolkit improved the whole execution time by a factor of 2.5 or 3).

I will start now implementing your suggestions to see if they provide a speed advantge. Thank you so much. 

The code itself consist of building a large matrix filled with sin and cos (e.g. dimensions 16x465120) and pseudoinvert to multiply it by an incoming signal vector with 465120 elements.

[GerdW]

Hi obarriel,

can you please provide the formulas/algorithm you want to implement?

No substantial changes to your VI, but with Christians suggestion:

It takes ~1.25s on my 8 year old laptop…

(Edit: parallelizing the first FOR loop for sinewave creation to 4 instances reduces by ~25ms.)

[obarriel]

Thank you for your responses.

I include in the attached pdf the equations that are implemented in this vi. This is actually part of a scientific paper that I can also share, but I think only this part is relevant.

With Christian's modification, I had a slight speed improvement. I will paralyze the first loop too to get also this small improvement.

The FFT part I think it is not really very relevant speed-wise, it is used to correct for the high-frequency attenuation introduced by some acquisition hardware. Oddly I get almost the same result symmetrizing my roll-off function, as suggested by Christian, than as it is now.

Upgrading the computer and getting a cpu a larger number of cores would immediately improve the speed, but it is something that I am trying to avoid at the moment as there are some hardware elements in the current computer that need to be kept.