LabVIEW
LV threading 8.5 much worse than 8.2??? (or is it VISA or NIDAQmxbase?)
Alright CC. I didn't actually test the variable gain feature, but since the gain array was auto indexed, it should select the correct gain and polarity for each row of the array. At least that was the design of my modification, but I admit I didn't test it with variable gain. I will try to look at it again on Monday but it is looking like a busy week. I must have missed something obvious.
I used the same scaling constants that NI used in their original VI. I assumed that they had the correct value. I guess it is a question for the board designer if 2^12 == 10 V or if it is 2^12-1 == 10V. AFAIK the common practice is the second one since that means that your range is inclusive of 10 V and not one LSB less, so I think you are correct. But, I defer to NI on their calbration values.
The value of the speedup is of course hugely dependent on the size of the array and the CPU. The G5 FPU is really fast if you schedule it so both arithmetic units are running at full bore. The dual FPUs mean that it can do 2 FLOPS/clock tick. Thus if it was fully utilized by an efficient compiler it could do the 32X2500 array in 16 microseconds! That is only using 1 core with no parallelism. But real world problems should keep it only a factor of 10 worse. There is still obviously room for improvement of that algorithm.
Sorry, guys, I don't have DaqMX installed, but I am curious about the following.
How was this VI in the earlier (fast!) version? Why was it changed?
It was that dang matrix transpose. Just move it to the other side of the for loop and it works fine. I had the wrong dimensions first, I find arrays confusing if columns come before rows or when DAQ returns a 2-D array which is samples and which is channels. Since all my gains were the same it works for my case, but thanks for pointing out the error. I am posting (if Lithium will let me) both the fixed VI and an improved test that uses all gains and all bipolar/unipolar combinations and checks for differences.
BTW, today I was working on an Intel Mac so it isn't the compiler making inefficient code for one CPU. I get the same factor of 1000 speed up on that CPU as well.
The oldest version of the VI that I can find installed is from NIDAQmx base V2.1.0. It seems to use the same slow algorithm. I am not sure why the problem suddenly showed up. Maybe the newer version finally used the DMA features and called this VI? Tom W, may be able to shed light on the historical process.
Dohhh. Lithium got me. Let me switch browsers.
I was actually going to propose your "transpose+autoindex" variation to replace the "index column with [i]" version of CC. However it seems they are nearly indistinguishable in performance so it does not really matter. I guess the overhead of the transposition is balanced by the overhead of indexing out colums (where the elements are not adjacent in memory).
If you ever want to slighty simplify the code even more, take the "divisions" out of the case structure since it occurs in all of the cases. One instance is enough 🙂 (I actually prefer CCs solution of indexing into a LUT).
You can also get away with a single unbundle node, just resize it for two outputs. Less clutter.
CC,
I agree with everything except the Rube Goldberg comment!! There is a method to my madness! NEVER EVER compare real numbers without an epsilon. ! I was worried about single bit variations when changing the possible order of computations. This could give variances of 10^-17 or so for double precision. So I started it down that path to compute the percent variation which is the real test. It turned out that the computation was exactly equal, but that is just luck.
I wasn't going to worry about errors in the 1 part in 10^17 and I was testing to see how small my epsilon needed to be to check. It turned out for an epsilon of zero in this case but that was something I didn't want to count on.
Using the array is one way I considered, but does not have the "default" case. I went for bug-for-bug compatibility rather than that speedup. If you use the array then you should check bounds and do the default case if the "gain" is not one of the listed types. Otherwise you change the behavior in error cases.
I can't see any significant difference between the transpose/auto index vs explicit indexing in arrays up to 10,000 X 32. That was a factor of 3400 speedup but the difference between CC and sth was only 1mS or the timing resolution. I really like the idea of selecting the index for auto-indexing for higher dimensional arrays. However moving bytes around memory is what modern CPUs are really really good at doing.
You can also trade a few clock cycles for memory by doing the divide first, letting the LV compiler do it's constant folding magic and then selecting between the two arrays. You double the gain array size but save a bunch of floating divides.
The timing bias was just my making all the wires symmetric. Bad choice in this case!!
Thanks for the pointer on Safari, I see you posted this to the thread. Hopefully they will get this fixed. The NI web pages have never ever passed the W3 validator for HTML. Pitiful adherence to standards.
I think we have beaten this particular VI to death. Now for the other 3000 VIs in the NIDAQmx base package! The good thing is that since it is all LV it is completely transportable and debuggable and not a black box (or Dark Matter as it used to be called) that you can't see what is happening.
