Łukasz Posted August 29, 2023 Report Share Posted August 29, 2023 (edited) Your task is whipping up a piece of code that can unravel a string stuffed with uint64 data, all dressed up in that fancy communication protocol jacket. But hold your horses, partner! The catch is to make it faster than my own fancy footwork. Giddy up and get coding! Example of slow solution: Much faster solution: Y'all can lay your eyes on the testin' stuff right down yonder in that there attachment. And guess what? There's a little description of that frame thingamajig to tickle your fancy. So put on your explorin' hat and give it a gander! decode-frame.vi Edited August 29, 2023 by Łukasz 1 Quote Link to comment
Popular Post cordm Posted August 30, 2023 Popular Post Report Share Posted August 30, 2023 Is the frame size 16 bytes? In the first you use 14, in the second 16. This is slightly faster: The biggest hurdle is converting the endianness, I do not think you can get much faster with conversion. I tried to be clever using BLAS dcopy for copying out the relevant part, but the conversion kills the performance gain. decode-frame-cm.vi 3 Quote Link to comment
Łukasz Posted August 30, 2023 Author Report Share Posted August 30, 2023 oh true, the frame is 16 bytes long. So your solution is the fastest now. Quote Link to comment
Popular Post LogMAN Posted August 30, 2023 Popular Post Report Share Posted August 30, 2023 2 hours ago, cordm said: I tried to be clever using BLAS dcopy for copying out the relevant part, but the conversion kills the performance gain. It is actually much faster on my machine. Here are a few results: @Łukasz Fast solution: ~30 µs @cordm Case 1 (really slow): ~403 µs Case 2 (good performance and readability): ~54 µs -- output is wrong, see below. Case 3 (): ~235 µs Case 4 (original solution): ~30 µs Case 5 (LV200000_BLASLAPACK.dll): ~14 µs Case 6 (LVBLAS.dll:BLASCopyVectorH): ~16 µs -- Windows 11, LabVIEW 2020 SP1 (32-bit) 2 hours ago, cordm said: This is slightly faster: This code actually truncates the last value because the length of the source array becomes odd. Here are two possible fixes. The second one is slightly faster for me. 1) Append the final element: ~60 µs. (slightly slower than before) 2) Rotate the string before conversion: ~42 µs. 3 Quote Link to comment
Łukasz Posted September 4, 2023 Author Report Share Posted September 4, 2023 I tried all the solutions using LabVIEW 64-bit on Ubuntu. I fixed case 2, and cases 5 and 6 produced very similar results. I'm a bit worried about using BLAS VIs because they might cause problems during the building process. @cordm and @LogMAN I truly want to express my gratitude for your help. 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.