06-18-2009 09:45 AM
altenbach wrote:
smercurio_fc wrote:In fairness, the text indicates that it was done for speed.
Doing a meaningful benchmark on this is very (very!) difficult, because we need to make sure to avoid constant folding.
Anyway, the code shown in the book is surprisingly efficient compared to some other ideas,
but a plain string operation is still about twice as fast (code at the bottom).
It may be now, but can you say the same thing for earlier versions of LabVIEW? As I pointed out in my response, we have no way of knowing for which version of LabVIEW that was written for. It may very well be that the author is correct for a specific version of LabVIEW, or the author may have had to guess and guessed incorrectly, or did the analysis incorrectly. I'm just not jumping to the Rube Goldberg "label" especially given the explanation in the text.
06-18-2009 09:48 AM
smercurio_fc wrote:
Jeff Bohrer wrote:Me thinks Smercurio_FC doth protesteth too much. you edited the book didn't you?
Huh?
All I'm trying to point out is that you can't jump to a conclusion regarding that code, especially given the explanation that was in the book (and shown in the screenshot). Memory management and allocations have changed dramatically over the years, so what was true once may no longer be true. So what may seem like a Rube Goldberg and something completely unnecessary today may have been a necessary evil way back in the "stone age".
Sorry if I gave offence. I was responding out of astonishment that you knew the referance material well enough that you could quote the privisos and footnotes in the front matter of the book! And really, someone on the forum probably edited the text- why not you?
06-18-2009 11:05 AM
06-18-2009 11:22 AM - edited 06-18-2009 11:25 AM
smercurio_fc wrote:
It may be now, but can you say the same thing for earlier versions of LabVIEW?
I am sure that benchmarking this beast was also not very easy in earlier LabVIEW version and without the buffer allocation display, it's like flying blind. I am sure the auther had to rely on some NI internal information. Maybe this example even originated from NI and made the usergroup circuit as a fringe example. It is puzzling that is still is fast despite all these three buffer allocations, and this is difficult to explain and I am not claiming to understand.
My benchmarking posts above were a purely academic exercise to see if the same can be said even today. Apparently, the compiler has evolved and these function no longer operate "in place" as the book claimed, and this could be part of the reason why it is no longer the best operation.
In any case, the book is stale and should be updated.
Doing a simple 4-byte operation like this does not really deserve much performance scrutiny, because it is simply not worth it. Compared to anything else, it will happen in a nanoblink of an eye. There is no excuse to do a screenful of wire gymnastics, just to squeeze out another nanosecond. It is somewhat Rube Goldberg'ish. 😉
I have not read the book, but such performance optimizations should be limited to repeated operations on large datasets, i.e. in cases where it actually makes a difference. The focus of a chapter on performance optimization should be to teach how to benchmark performance in general and what section of code to single out for performance optimization. Identify the real bottlenecks!
One thing I learned early on is that we cannot rely on gut instinct. The only way to tell is to wire up alternative versions, look at the buffer allocations for hints, and race them while making sure that we are actually measuring the correct thing and not some folded code section. (Then we post the solution in the forum and somebody else will come up with something that is yet another order of magnitude faster. :D)
06-18-2009 11:37 AM
The easiest thing is to actually READ the text in the book. It explicitly says the trick came from Rob Dye and identifies him as a member of LV R&D (he still is, last I heard).
Altenbach knows Rob, so I'm sure he trusts him on something like this, but as you mentioned, this probably doesn't take into account improvements in recent versions and would probably not be a meaningful optimization anyway.
06-18-2009 01:08 PM - edited 06-18-2009 01:12 PM
tst wrote:Altenbach knows Rob, ...
I know a few Robs at NI (and elsewhere!) but I am not very good with names and words in general (That's why I am not a text programmer :D), so I am not 100% sure that I know or met this particular Rob. A diagram picture would probably jog my memory. 😄
Still, If Rob Dye is reading this, feel free to chip in. 🙂
06-18-2009 01:24 PM
If memory serves, he was in the original development team, so he's probably in the LV 1 about picture. 😄
He was in the session we had with Jeff K. at NIWeek '07, if you can remember back that far. Personally, I'm fairly senile myself, particularly when it comes to names and faces of people I know, so I can sympathize. If you click the images link in the link you provided, there's a picture of a guy in glasses in the second row (from a Facebook profile). I believe that's him (makes sense from the people listed as friends).
06-18-2009 01:29 PM - edited 06-18-2009 01:32 PM
Searching for "Rob Dye LabVIEW" finds this picture, where he's also with glasses (It's actually from the same book) 😄
06-18-2009 01:33 PM
06-18-2009 02:06 PM - edited 06-18-2009 02:07 PM
I remember this book now. I used it during my Labview puppy training back in 1996 I think. So it is old. Back in my days the cover was violet so I did not recognized it. Here is some more pictures showing mister Rob from the book and now. So if Rob read this feel free to comment ;). We wont bite you. It is far more important thing going on in this world. LIke that Obama brutal kills a fly, and receive critic from PETA. So much for Mr. nice gay :smileyvery-happy: