LabVIEW
string to number conversion
Solved!
mathan wrote:
Altenbach - I need byte array as final output and not a string array.
Look again! There are no string outputs in my solution (not everything that is pink is a string!). For each number, I create an array of U8, and since each can be of different length, I package them into an array of clusters. (If you would autoindex to a 2D array, the short solutions would get padded, something you probably don't want).
If this is not what you want, you need to tell me your definition of "byte array". 😉
Norbert B wrote:
Here is my benchmark-vi. The difference is about 1s faster for the devision where the total time for the devision is about 1.5s....(default number of iterations with Dual Core @ 2GHz) which is quite huge. And i cannot explain the difference and therefore wrote the entry 🙂
Norbert,
This benchmark is completely meaningless.
- You are running both loops at the same time, so your timings are at the mercy of thread assignments, etc. Imagine running this on a single core. 😮
Message Edited by altenbach on 06-11-2008 08:15 AM
OK, here's a good benchmark.
We can do this task in four different ways (be careful, because the division does slightly different rounding, so the solutions are not exactly equivalent).
(1) bit shift by -1
(2) use scale by power of two (hook it up exactly like the bit shift, they should be the same because it uses bit shift internally for integers)
(3) use divide as in your orignal code
(4) use "quotient & remainder" to divide by two, keeping the integer part.
Here are good benchmarks in nanoseconds per division:
(1) 4.23ns
(2) 3.95ns
(3) 11.34ns
(4) 16.44ns
Analysis
As you can see, (1) and (2) are about 3x faster, while 4 is a bit slower. It is interesting that (2) is slightly faster than (1), but it is reproducible. (4) is probably slower because it drags along more baggage, after all, it needs to calculate two outputs, even though only one is used (just guessing).
Norbert B wrote:
This is why i use dualcore as written somewhere above 😉
I admitt that on single core, this approach for benchmarking would be complete nonsense!
Yes, I saw that. Still you don't know which one of the cores is recruited for other stuff such as UI and OS tasks. It is probably not exactly fair. 😉
You can do pretty reliable comparative benchmarks on windows. Run each many times and pick the fastest.
Don't forget to elevate the priority and disable debugging.o
A note to the above benchmark results. Don't forget that each code has a constant loop overhead and if we run the loop and just wire [i] out, we have 2.62ns, which should be subtracted.
The real times (minus loop overhead) are thus:
1.61ns bitshift
1.33ns scale
8.72ns divide
13.82ns Q&R
as you can see, "scale by power of two" can do it with 15% of the effort of the divide solution. 😄
Attached VI reveals quite comparable results, but it seems that my PC is slower than yours, Altenbach......
On the otherhand, i still didn't reboot after the autoupdate
Well, but first, this Vi did create the odd "devision is faster than bit shift" as well... so my PC is really going nuts from time to time....
But it was an interesting thing to look into!
Norbert
On the otherhand, i still didn't reboot after the autoupdate
Well, but first, this Vi did create the odd "devision is faster than bit shift" as well... so my PC is really going nuts from time to time....
But it was an interesting thing to look into!
Norbert
You still have serious flaws in the benchmark. For example the second timing is taken in parallel with the update of the indicator, possibly stealing CPU. also the Q&R should use a I32 diagram constant to avoid coercion.
Using dataflow to delay the indicator update could posibly make a difference, depending how things are scheduled. Sure the indicators are asynchronous, but unless you enforce proper dataflow, you cannot be sure what's happening.
If you disable debugging, the times will be 50%+ faster. You don't want to benchmark debugging overhead.
You can also delete the FOR loop in the lower right corner without any change in functionality. 😉
Message Edited by altenbach on 06-11-2008 09:44 AM
