07-25-2015 05:12 PM
I have been taught basic examples of Labview data flow like multiple Add, Subtract.. blocks carry out execution at the same time and we can visually see the dataflow in Highlight execution mode.
In this example, I expect count ms to load its value the instant the first frame is run. However, in reality, count ms will only load its value to the right terminal after Search Replace string finishes (takes a long time). This means the time difference is zero !
Note that the integer constant loads the terminal the moment the frame starts, which is correct (unlike count ms)
Solved! Go to Solution.
07-25-2015 05:26 PM
I think the Search & Replace is like a blocking function. I cann't even Stop execution while its running.
07-25-2015 05:30 PM
It does follow dataflow. There is no data depedency among the three paths in the left frame, so any of those can execute first, last, or parallel with the others. Also, most likely the code in the left frame executes in microseconds, making a zero millisecond difference the expected value.
If you want to measure the time a piece of code takes to execute, you must make certain that nothing else executes in parallel. There are other considerations such as constant folding, error handling, debugging code, OS interactions for updating displays, and so on which can affect the timing. For example the zero plus one code never changes so the compiler will reduce that to a constant.
Create another frame to the left and place the Tick Count function in there, alone.
You may also need to place the code you want to time inside a for loop and repeat it thousands of times to get meaningful results. The High Resolution Relative Seconds.vi is useful for intervals shorter than 1 millisecond. It was introduced in a recent version of LV, so if you have an older version, it may not be availabel.
Lynn
07-25-2015 05:32 PM - edited 07-25-2015 05:33 PM
Highlight execution takes away the true parallelness of an application. So they may actually run in parallel when you are not debugging.
However, it looks like you are trying to do a benchmark to see how long your task takes. For this, you actually want the first Count ms to be in a sequence frame BEFORE the code you are trying to benchmark.
07-25-2015 05:47 PM - edited 07-25-2015 05:49 PM
Nope, I only showed Highlight execution to see it myself.
I have attached example code here and you can see what I said was true. Note that this code may hang your machine for 15s.
Count ms only executes after Search & Replace finishes
Cannot Stop execution while Search & Replace is running.
07-25-2015 06:26 PM
Replacing space by space >521000 times seems rather wasteful.
I changed the search expression to \n+ (after looking briefly at the input string). The result differed from the result of your code by one character. I took a guess that there was a double space in there somewhere, and I was right. I put in a second search which found and replaced a double space by a single space. The output strings are equal and the two search code is 150 times faster.
Lynn
07-25-2015 06:33 PM
Hi Lynn, the input string is just a large text file I randomly grabbed from the internet. The nature of what the Replace operation does and on what is not relevant.
My grain of salt is about the dataflow of Count ms, and the blocking behavior of Search & Replace.
07-25-2015 07:24 PM
@zigbee1 wrote:
I have been taught ... blocks carry out execution at the same time and we can visually see the dataflow in Highlight execution mode.
Both incorrect, as already pointed out.
First, highlight execution is not a reliable measure of the order in which things actually execute (and the order is not guaranteed if things have no dataflow dependency).
Second, dataflow does not mean that things happen in parallel. If you want a more strict definition, it can be "a block of code can execute once it has received values on all of its inputs". The fact that it can execute does not guarantee that it will immediately execute. In a theoretical concept of dataflow, that may be the case, but in LV, you have actual implementation and there you have internal mechanisms which decide when a specific piece of code will actually run. As mentioned, to guarantee the order, you need to make sure it ends before the other piece of code starts.
As for the locking of the function, my guess would be that this is because internally it calls a DLL function to implement the regex functionality and that's blocking.
07-25-2015 07:41 PM - edited 07-25-2015 07:51 PM
Both incorrect, as already pointed out.
First, highlight execution is not a reliable measure of the order in which things actually execute (and the order is not guaranteed if things have no dataflow dependency).
Second, dataflow does not mean that things happen in parallel. If you want a more strict definition, it can be "a block of code can execute once it has received values on all of its inputs". The fact that it can execute does not guarantee that it will immediately execute. In a theoretical concept of dataflow, that may be the case, but in LV, you have actual implementation and there you have internal mechanisms which decide when a specific piece of code will actually run. As mentioned, to guarantee the order, you need to make sure it ends before the other piece of code starts.
Does this violate dataflow for you now ? The ADD block did not execute even though it received both values at its two input.
You don't have to enable Highlight like I did, just run it as normal, time 1 indicator will not update until Search & Replace is finished.
07-25-2015 07:56 PM
zigbee1 wrote:
Does this violate dataflow for you now ?
Not even a bit. Again, "can" does not mean "will". It defines the first point in time at which it can happen, nothing more. If you want, you can change the phrasing to "a block of code can execute only after it has received values on all of its inputs". Because the add function and the replace function have no dataflow dependency, there is abosolutely nothing determining their execution order. If you showed that the +1 in the second frame is happening before the +, then I would say you have a bug.
Why does this bother you? It's important to understand that LV does not guarantee parallel execution of anything, nor does it guarantee order of parallel operations. It only guarantees order of operations which have dataflow dependency (and even there, NI sometimes fails to do this correctly under specific circumstances).