Thanks for your kind reply.
For example,I have a 10k size array needs to be processed.I will put it in a For Loop.Every loop time is tiny,but the whole time is significant.
Have you tried "For Loop Iteration Parallelism"?
(Right-click on For Loop and select "Configure Iteration Parallelism..."
Check the Help for requirements (i.e. iterations can't depend on previous iterations)
In theory, you could use a subVI with a higher priority setting. In practice, the thread swap required is likely to cost more than any speed gain you could possibly make.
And if you are that worried about time, then you probably should not be working with Windows, but an RT device where determinism is more important (Windows can make your program idle for "long" periods of time for unknown reasons).
I don't have a CODE needs to be solved,but just an idea wants to figure out.
My superficial think is that if CPU uses highest frequency to a Labview program,the execution time can be shorter.
You've already got some great advice, but be aware that CPU% has nothing to do with "frequency", in fact some CPUs only go to the "highest frequency" if not all cores are used or the thermal envelope is still satisfied (AMD Turbo Core, Intel Turbo Boost, etc.).
Earlier you mentioned a FOR loop, which of course can be parallelized if all iterations can be calculated independently and if most of the heavy lifting is reentrant. It really depends on the problem, so once you decided what you need to calculate, do a google search for parallelization of that specific algorithm. Some parallelize well, others not so much. It all depends on the problem. Once you know what you need to calculate, come back to the forum and ask specific question. We can help.
If this is linear algebra, there is also the LabVIEW Multicore Analysis and Sparse Matrix Toolkit , which has vectorized versions of the plain linear algebra as drop-in replacements. Again, most useful for very large data structures. Make sure to only parallelize on the outermost loop to keep the parallelization overhead to a minimum. A multicore version of a subVI inside a parallel loop inside another parallel loop does not make sense.
There is really no need to "tell" LabVIEW to focus on a certain part of the code, because most likely all other code parts use insignificant amounts in comparison. Yes, it has been mentioned that subVI priorities can be adjusted, but that usually has negative consequences and hurt other parts significantly while not really speeding anything up. I only use "normal" (the default!). For example if you would set a "time critical" priority, the UI thread gets pushed down so much, it will no longer update indicators or react to user interactions in a timely fashion.
And no, LabVIEW RT will not get you any faster unless you can do the computations on an FPGA. RT does not mean "fast", it just means "more deterministic". The windows scheduler is pretty good at giving all CPU to your LabVIEW process unless you also run some other code with heavy CPU demands, so don't!
Some problems can also be pushed to the graphics card if you have a powerful hardware. Have a look at the LabVIEW GPU Analysis Toolkit .
So, in summary, you want to go from data to result as fast as possible, nothing else!!
Parallelization can maybe give you a factor of four improvement (on a quad core CPU), but often there are more efficient algorithms that can solve the same problem orders of magnitude faster using even less CPU. If speed matters, you need to design a reliable benchmark (very difficult!!!) and make at least 5-10 different implementations, then see what's fastest (ignore the %CPU, it is irrelevant!!!). Then come back here and we will have a look and maybe come up with an alternative that is yet another order of magnitude faster. Sometimes minor changes can take better advantage of SSE or allow better in-placeness.
If parallelization works for you specific problem, make sure that the code is future-proof and scales well, independent of CPU. It should work well on a dual core atom or celeron as well as take full advantage of the e.g. the upcoming AMD 3990X (64core, 128 threads!) . 😄 Good luck!
A process which runs for full in one thread on one core will utilize at most 18% of the available CPU resources on a 6 core CPU. And the process will be spread out on all available cores since the OS normally does not lock a program to one core.
The task manager in windows give you some possibilities to control priority and processor affinity. In the fan "Details" (Win 10) or "Processes" (Win 7) you can right click on a process and select "Set priority" to change priority of program, or "Affinity" to select which processor cores the programs is allowed to run on. The settings will be reset at reboot, but programs exists which make it possible to save these settings.
Normally the affinity setting would not be usable for a computer running LabVIEW since i assume that using LabVIEW would be the only task for that computer and administrative tasks does take up little processing power. But it can be used to experiment with number of parallell loops and number of cores.
If you have a optimized LabVIEW program but still not need more power and can't buy a better computer then ask the gamers.
You could overclock your computer. And if you have more cores than LabVIEW can utilize then you may pressure each CPU more if you disable SMP, and maybe disable some of the CPUs in the processor. But no guarantees, i am not sure if my own attempts has been successful.