Ton Plomp Posted September 30, 2011 Report Share Posted September 30, 2011 I was looking at a function to format a binary string as hex, and tried to get some performance. I was shocked with the following results: What i've concluded is that the Integer to Hex-string function for arrays is not working with U8's but with something else (U32's?). Ton 2 Quote Link to comment
asbo Posted September 30, 2011 Report Share Posted September 30, 2011 What's your OS? I'll run LV2009 and LV2010 on Win7 x64 if you backsave the VI. Quote Link to comment
Saverio Posted September 30, 2011 Report Share Posted September 30, 2011 This may be due to the coercion dot, as reported here: http://forums.ni.com/t5/BreakPoint/Monthly-bugs-August-2008/m-p/758921?view=by_date_ascending#M6325. It appears to still be there, though I don't recall if this was ever determined to be an actual problem. Quote Link to comment
Ravi Beniwal Posted September 30, 2011 Report Share Posted September 30, 2011 This may be due to the coercion dot, as reported here: http://forums.ni.com...scending#M6325. It appears to still be there, though I don't recall if this was ever determined to be an actual problem. In the case of the For Loop, when the string is converted to a U8 array, some memory was claimed, which would cost some time. Including this time, this case completed within 1391ms. Now in the int to string case, we can think of the coercion as claiming another same size memory location with its added time cost. So wouldn't we see more like twice the time it took for the first case instead of about 13 times? Quote Link to comment
Darin Posted September 30, 2011 Report Share Posted September 30, 2011 I seem to remember that Floats are coerced to 64 bit integers, so I am guessing that the default input type is U64 for arrays. It seems silly to not have an explicit [u8] input for the primitive instead of blowing up [u8] to [u64]. I am curious if you could check the performance with different integer array types and find one with a smaller time differential between the two methods. A very useful rule-of-thumb for optimization is that the more code you push into a primitive, the faster it will be. This bug(?) breaks that rule so it is very annoying on many levels. 1 Quote Link to comment
Darin Posted September 30, 2011 Report Share Posted September 30, 2011 Very interesting results from some quick testing. The first time I run the test the Array method is as fast or faster than the for loop. For all subsequent tests the For Loop is much faster (10X). Ctrl-Run then the array wins the first race again. Quote Link to comment
Phillip Brooks Posted September 30, 2011 Report Share Posted September 30, 2011 Very interesting results from some quick testing. The first time I run the test the Array method is as fast or faster than the for loop. For all subsequent tests the For Loop is much faster (10X). Ctrl-Run then the array wins the first race again. This sounds like a development environment issue. Might a compiled version behave differently? (still using LV 8.6 ) Quote Link to comment
Darin Posted September 30, 2011 Report Share Posted September 30, 2011 Rewrote from scratch in LV9 (used native timing instead of OpenG). Array version now beats For Loop consistently by a healthy 20-50% margin. All is right with my world again, other than the annoying red dot. Same in LV10. Slightly puzzled by the initial results matching Ton's, I'll chalk it up to bad luck. I do not know if it matters here or not, but I tend to avoid wiring indicators inside a frame I am trying to benchmark. Quote Link to comment
Ton Plomp Posted October 1, 2011 Author Report Share Posted October 1, 2011 So you mean that the FP-update is the real killer? That would be very strange. Notice that I took a file of 5.5 Megabytes resulting in an array of 5.5 Million Elements, since a single string char is 5 bytes, the total array would be 27.5 Megabytes, with the resulting string being 11 Megabytes. I had the same results in 2010 though. It might be that the size of the input file is important. Ton Quote Link to comment
Popular Post Matt W Posted October 1, 2011 Popular Post Report Share Posted October 1, 2011 If you make sure the indicators are updated after the benchmark (run their wires through all the remaining sequence frames) then array will win, with your current bench mark the winner will depend on which test is run first (I suspect the difference is due to pressure on the memory allocator). Personally I use also use an always copy node to copy any input data before entering it into the first sequence frame to make sure I'm not measuring a data copy (just wiring into the first frame maybe sufficient but I like being sure). That wont matter in this case since you're not modifying the U8 array. A couple side comments. A string to U8 array can be done in place so that it doesn't take any time (a u8 array and string have identical structures in memory so LabVIEW just has to reinterpret the data) You're greatly underestimating the size of the string array. Each string takes 6 bytes 4 for size 2 for data. An array of strings is an array of handles. 4 bytes (array size)+5.5 million * (4 bytes [string handle]+4bytes[string pointer]+6 bytes [the string itself] ) so a total of ~ 73.4 mebibytes. In 64bit the handles and pointers would double in size, I'm unsure if the sizes would double or not. If you avoid the string array (and it's 5.5 million allocations) things go much faster On the first run with 5.5 million elements I get For Loop: 4725 Array: 2758 Mine: 134 On the second run (where LabVIEW can reuse the large arrays allocated in the first run). For Loop: 2262 Array: 2279 Mine: 127 3 Quote Link to comment
Darin Posted October 3, 2011 Report Share Posted October 3, 2011 I like the direction Matt was headed, but I tend to find Case Structures a bit slow in tight loops so I would probably have done something like this instead. Over 4x faster than the built-in primitive (not often we can do that!). I suggest a new set of OpenG VIs to implement Integer Array to Hex String. I would simply use Split Number and the same lookup table for U16 and U32, etc. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.