LabVIEW
fastest way to do a bitwise comparison of 2 large files
optimizing other people's code can be really funny 🙂
What about this:
Message Edited by GerdW on 02-15-2007 09:45 AM
@tst wrote:Well, you should have known better than trying to have an optimization contest with Altenbach. It's normally a recipe for losing (and for learning
), and being the sole user of other obscure LV features (I hope Stephen doesn't read this) does not mean you can handle these minute details as well.
What's the fun of anything if you don't challenge those who are superior to you... You can't master every aspect of LabVIEW with just three years of experience, can you
Now I've to continue my project with those other obscure LV features.Tomi
@GerdW wrote:
What about this:
Very nice Gerd! 🙂
I guess it would need a diagram comment to remind the casual observer what this piece of obscure code does. 🙂 Mine is a bit more dumbed down and explicit.
Creating the lookup table is peanuts compared to the overall calculation and I suggested an ever faster option above: "calculate the lookup table once, then turn it into a diagram constant and delete the code.. 😉
Depending on the version, LabVIEW might actually fold both solutions into a constant at compile time anyway, so we won't see a speed difference no matter what. 😮
Still, I love your solution. 🙂
I agree with Tomi that the rest of the code could probably still be improved. Looping on U32 is one idea, but a U32 lookup table would be too large. We probably need to make sure that the lookup table fits into cache very comfortably. Maybe loop on U32, split each element inside the loop into two U16 and use an U16 lookup in parallel for each iteration. Might be faster, might be slower. No guarantees. 😉 Also probably needs a little bit of code to handle file sizes that are not divisible by four.
tbd wrote:... and if Dennis needs an even faster routine (about 30%), this is simple but a tad cumbersome.
Are you sure? How do you measure the speed? In my casual testing your code is about 5x slower than mine ...
To be fair, you need to subtract the times differently. Your tester measures (1) the time of your VI and (2) the total time of your AND mine VI in succession.
You need to subtract differently to get both times indepdendently, see image. The image also shows a typical result (~5x faster) 🙂
Message Edited by altenbach on 02-16-2007 12:55 AM
altenbach wrote:
To be fair...
To be fair, you should read my post, specifically "Damn...Interesting elapsed time calculation".
Saw the problem, but left it attached for your enjoyment!
Can't duplicate your results and wonder if you used any tricks to give your VI an advantage(?) Your lookup table is now a diagram constant. I bumped the sample-set up to 2,000,000, and tried swapping which VI runs first (it's advantageous to run second.)
After a minor mod, our routines are a dead-heat when there are mostly mis-matches, yours is faster if there are no mis-matches.
The mod is to replace "Default" (case) in Diff1.vi with the list of values.
Not to "beat a dead horse" or anything.
Message Edited by tbd on 02-24-2007 11:27 PM
