BreakPoint
Rube Goldberg Code
(On the bus, cannot test)
Parallelization probably won't help much here, I think.
I would try to use a U16 LUT and autoindex at the left boundary followed by type cast to string.
@altenbach wrote:
I would try to use a U16 LUT and autoindex at the left boundary followed by type cast to string.
Yup, it is about 2x faster than Darin's code. It is also significantly less code (see my signature :D)
(1M string with debugging disabled: mine 5.5ms vs. Darin 11ms)
(not tried parallelization yet)
@altenbach wrote:
(not tried parallelization yet)
As suspected, parallelization does not do much here, even on my 16 core monster. The times are much more variable. While it sometimes is faster, the average is slower with parallelization enabled. I think this is such a fast loop that the split and reassembly overhead cancels out any potential parallelization advantage.
@Darin.K wrote:
That coercion dot is a bit more than annoying. If I remember correctly it blows up the [U8] into a [U64] or [I64]. This is one of those rare moments when a G implementation can outperform a primitive, albeit a botched primitive.
I was under the impression that it is a false coercion dot that only appears if we connect an array of any numeric datatype. You can connect any type numeric scalar and there is no dot. (This has been around since LabVIEW 8.5. See also my post from 2008)
Obviously, things are screwed up. If we hover over the terminal, It says that it expects an array of strings (see picture).
However, if we actually connect an array of strings, it say it expects an array of I32.
Go figure. Still, I think it is a cosmetic problem.
All that said, the code with this primitive followed by "concatenate strings" is about 10x slower than my version with the 16bit LUT. So yes, there are improvements possible 😄
@altenbach wrote:
Yup, it is about 2x faster than Darin's code. It is also significantly less code (see my signature :D)
For completeness, here's a quick benchmark (LV 2012) comparing a few implementations. Modify as needed.
(A similar LV 2010 version can be found here. I don't know how it performs under 2010).
@Darin.K wrote:
As a unitasker this is indeed simpler, but I tend to code in generalities. My code comes from a general VI which will handle arbritrary bases just by changing the LUT and the constant for the stride, not just the special hex case. Hence the 2D LUT. Adapt your code to handle octal, binary, and hexavigesimal see how it goes.
That's a valid point.
Yes, I was surprised how fast it is. I usually don't worry about factors of two unless it is something that takes a long time.
For a more general reuseable (and readable!) code, I would have thought that the string LUT (blue trace) is similarly good, but it loses another factor of two or so... ;). I wonder how it compares with longer strings, such as binary formatted outputs.
Not sure about hexavigesimal and octal (they are not aligned at byte boundaries), but hexadecimal and binary can easily be done the same way and seem to be pretty fast.
Here's a general purpose subVI (LabVIEW 2012) that does it all. 😄
