generates a multi-凯发k8网页登录

on windows and linux, you must use a compiler that supports the open multiprocessing (openmp) application interface. see .

if you have a macos with an xcode version 12.0 or later, using the dspunfold function is not supported.

if the input matlab function has runtime errors, the errors are not caught when you run the multi-threaded mex file. before you use the dspunfold function, call codegen on the matlab function and make sure that the mex file is generated successfully.

if the generated code uses a large amount of memory to store the local variables, around 4 mb on windows platform, the generated multi-threaded mex file can have unexpected behavior. this limit varies with each platform. as a workaround, reduce the size of the input signals or restructure the matlab function to use less local memory.

dspunfold does not support:

if multiple frames of the analyzer input are identical, the analyzer might throw false positive pass results. it is recommended that you provide at least two different frames for each input of the analyzer.

if the algorithm in the entry-point matlab function chooses its state length based on the input values, the analyzer might provide different pass results for different input values. for an example, see the fir_mean function in .

if the input to the entry-point matlab function does affect the output immediately, the analyzer might throw false positive pass results. for an example, see the input_output function in .

if the output results of the multi-threaded mex file and single-threaded mex file match statistically but do not match numerically, the analyzer does not pass. consider the filternoise function that follows, which filters a random noise signal with an fir filter. the function calls randn from within itself to generate random noise. hence, the output results of the filternoise function match statistically but not match numerically.

function output = filternoise(x)
persistent firfilter
if isempty(firfilter)
    firfilter = dsp.firfilter('numerator',fir1(12,0.4));
end
output = firfilter(x randn(1000,1));
end

dspunfold filternoise -args {randn(1000,1)} -s auto 

analyzing input matlab function filternoise
creating single-threaded mex file filternoise_st.mexw64
searching for minimal state length (this might take a while)
checking stateless ... insufficient
checking 1 ... insufficient
checking infinite ... sufficient
checking 2 ... insufficient
minimal state length is inf
creating multi-threaded mex file filternoise_mt.mexw64
warning: the multi-threading was disabled due to performance considerations. 
this happens when the state length is greater than or
equal to (threads-1)*repetition frames (3 frames in this case). 
> in coder.internal.warning (line 8)
  in unfoldingengine/buildparallelsolution (line 25)
  in unfoldingengine/generate (line 207)
  in dspunfold (line 234) 
creating analyzer file filternoise_analyzer

the algorithm does not need an infinite state. the state length of the fir filter, hence the algorithm is 12.

call dspunfold with state length set to 12.

dspunfold filternoise -args {randn(1000,1)} -s 12 -f true

analyzing input matlab function filternoise
creating single-threaded mex file filternoise_st.mexw64
creating multi-threaded mex file filternoise_mt.mexw64
creating analyzer file filternoise_analyzer

run the analyzer function.

filternoise_analyzer(randn(1000*4,1))

analyzing multi-threaded mex file filternoise_mt.mexw64  ... 
latency = 8 frames
speedup = 0.5x
warning: the output results of the multi-threaded mex file filternoise_mt.mexw64 do not 
match the output results of the single-threaded mex file filternoise_st.mexw64. check that 
you provided the correct state length value to the dspunfold function when you generated the 
multi-threaded mex file filternoise_mt.mexw64. for best practices and possible solutions to 
this problem, see the 'tips' section in the dspunfold function reference page. 
> in coder.internal.warning (line 8)
  in filternoise_analyzer 
ans = 
    latency: 8
    speedup: 0.4970
       pass: 0

the analyzer looks for a numerical match and fails the verification, even though the generated multi-threaded mex file is valid.

if the entry-point matlab function contains code with low complexity, matlab overhead or multi-threaded mex overhead overshadow any performance gains. in such cases, do not use dspunfold.

if the number of operations in the input matlab function is small compared to the size of the input or output data, the multi-threaded mex file does not provide any speedup gain. sometimes, it can result in a speedup loss, even if the repetition value is increased. in such cases, do not use dspunfold.

do not display plots, scopes, or execute other user interface operations from within the multi-threaded mex file. the generated mex file can have unexpected behavior.

do not use coder.extrinsic inside the input matlab function. the generated mex file can have unexpected behavior.

do not use a random number inside the matlab function. the outputs of the single-threaded mex file and the multi-threaded mex file might not match. also, the outputs of the consecutive executions of the multi-threaded mex file might not match. the analyzer might not pass the numerical match verification.

it is recommended that you generate the random number outside the entry-point matlab function and pass it as an argument to the function.

do not use global or persistent variables anywhere other than in the entry-point matlab function. for example, avoid using persistent variables in subfunctions. the generated mex file can produce inaccurate results. in general, global variables are not recommended.

do not access i/o resources from within the multi-threaded mex file. the generated mex file can have unexpected behavior. these resources include file writers and readers, udp sockets, and audio players and recorders.

do not use functions with interactive inputs (for example, the keyboard) inside the multi-threaded mex file. the generated mex file can have unexpected behavior.

to generate a valid multi-threaded mex file with the required speedup and latency, follow the .

before using dspunfold, call codegen on the entry-point matlab function and make sure that the function generates a mex file successfully.

after generating the multi-threaded mex file using dspunfold, run the analyzer function. make sure that the analyzer function passes. the exception to this rule is when the algorithm produces results that match statistically, but not numerically. in this exception, the analyzer function does not pass, even though the dspunfold function generates a valid multi-threaded mex file. see 'analyzer limitations' for an example.

for help on using the mex file and analyzer, at the matlab command prompt, enter help and help .

if you choose a state length that is greater than or equal to the value of the exact state length, the analyzer passes. if the analyzer fails, increase the state length, regenerate the mex file, and verify again.

if the state length is greater than 0, the inputs marked as frames (through -f option) must all have the same dimensions.

when generating the mex file and running the analyzer, use inputs that invoke the same state length.

if the algorithm in the entry-point matlab function chooses a code path based on the input values, use inputs that choose the code path with the longest state length.

provide random inputs to -args.

choose inputs that have an immediate effect on the output. see .

make sure the outputs of the multi-threaded mex file and the single-threaded mex file do not contain nan or an inf. the analyzer cannot do numeric checks and returns pass as false. the automatic state length detection tool detects infinite state length and displays a warning

provide multiple frames with different values for each input of the analyzer. to improve the analyzer effectiveness, append successive frames along the first dimension.

provide inputs to the analyzer that lead to efficient code coverage.

to improve the speedup of the multi-threaded mex file, specify the exact state length in samples. you can specify the state length in samples by setting at least one entry of frameinputs to true. the use of samples reduces the overhead and increases the speedup.

to increase the speedup at the cost of larger latency, you can:

for each input that can be divided into samples without altering the algorithm behavior, set frame status to true using the -f option. the input is then considered in samples, which can increase the speedup of the generated multi-threaded mex file.