User talk:Duyn/kd-tree Tutorial
Interesting work here. Personally I'd consider such a code-heavy tutorial to be more of a 'code-explanation' than a tutorial, but still very good. Also, pretty good job optimizing fairly well there :) --Rednaxela 16:07, 27 February 2010 (UTC)
Also, I'd say that the 'Bounds-overlap-ball check' optimization is probably one of the most important things in how this tree benchmarks well. I also find it interesting how that optimization is in that paper, I've never seen it mentioned before in texts on kd-trees. However when I implemented that type of check in my own kd-tree, it just came to mind to do in a "... why hasn't anyone else done this? It seems so obvious" type of moment. You may be interested in one detail of how I was doing it differently though. I didn't use those bounds checking for the path order, I just used the conventional method based on the split. In addition, I only do did the 'bounds-overlap-ball check' for evaluating if 'second choice' branches are worthwhile. The reason for this is that:
- Bounds checks are expensive
- The 'first choice' branch to descend is very likely to have what we're looking for since it's parent branch was either a 'first choice' branch or had the bounds check done on it.
Benchmarks showed that those effect were significant enough that the detailed bounds check was only worthwhile in pruning needless 'second choice' branches. I'm curious if your implementation would show similar results if it skipped the bounds chck in those circumstances. --Rednaxela 01:43, 28 February 2010 (UTC)
Thank you for the suggestion. I have tried it, but found it didn't make a significant impact on the performance of the tree:
...[snip]... RESULT << k-nearest neighbours search with duyn's Bucket kd-tree >> : Average searching time = 0.078 miliseconds : Average worst searching time = 17.077 miliseconds : Average adding time = 2.49 microseconds : Accuracy = 100% ...[snip]... BEST RESULT: - #1 Rednaxela's Bucket kd-tree [0.0536] - #2 duyn's Bucket kd-tree [0.0777] - #3 Simonton's Bucket PR k-d tree [0.1625] - #4 Voidious' Bucket PR k-d tree [0.2203] - #5 Nat's Bucket PR k-d tree [0.3654] - #6 Voidious' Linear search [0.5836] Benchmark running time: 554.32 seconds
Although these results are perilously close to the rounding edge, it works out to a gain on previous performance of:
<math>{0.0787 - 0.0777 \over 0.0787} = 1.27\%\ \mathrm{improvement}</math>
Profiling with netbeans indicates it is the search() and searchXXX() functions, not the distance/bounds calculations which are slowing the tree most. This suggests that:
- the tree's balance is not optimal so we have to search a lot of trees;
- unlikely: quickly hacking in support for re-balancing every time the number of exemplars in a tree doubles did not speed up searches.
- the regions are not very square so our search hypersphere overlaps with a lot of hyperrects;
- unlikely: splitting on the widest dimension whenever it turns out to be twice the width of the thinnest dimension did not speed up searches.
- using a TreeMap for collecting results is slow; or
- this is now confirmed. A quick hack to use PriorityQueue instead of TreeMap gave the following results (still with your old kd-tree):
RESULT << k-nearest neighbours search with duyn's Bucket kd-tree (heap, less bounds checking) >>
: Average searching time = 0.024 miliseconds
: Average worst searching time = 10.333 miliseconds
: Average adding time = 2.77 microseconds
: Accuracy = 100%
RESULT << k-nearest neighbours search with duyn's Bucket kd-tree (heap) >>
: Average searching time = 0.026 miliseconds
: Average worst searching time = 10.58 miliseconds
: Average adding time = 2.37 microseconds
: Accuracy = 92%
RESULT << k-nearest neighbours search with Rednaxela's Bucket kd-tree >>
: Average searching time = 0.054 miliseconds
: Average worst searching time = 12.269 miliseconds
: Average adding time = 2.33 microseconds
: Accuracy = 45%
BEST RESULT:
- #1 duyn's Bucket kd-tree (heap, less bounds checking) [0.0242]
- #2 duyn's Bucket kd-tree (heap) [0.0263]
- #3 Rednaxela's Bucket kd-tree [0.0542]
- there is little more to gain without another theoretic insight.
- ie. the algorithm's good, but my coding sucks =).
The small improvement from your suggestion becomes more significant now. I shall have to update the main page to reflect this eventually.—duyn 04:41, 28 February 2010 (UTC)
Ahh yeah. Well, I didn't expect a miraculous improvement, and that is pretty close to the rounding amount. I do seem to remember though from my tests that while the improvement was small it was unambiguous, and I'd expect it to matter increasingly as the tree becomes increasingly deep beyond what this test data does. I doubt the TreeMap is the issue. While I used a max-heap in mine, since it's theoretically fastest and my implementation is very good, I doubt it's used quite enough to be a issue in this case. If you're concerned about that though, perhaps test out replacing it with the max-heap from my tree as a test? About the regions and balance, that's quite possible. Hmm... this reminds me, I really should experiment making a tree with "incremental near neighbor search", which instead of searching for a fixed number of nearest neighbors gives an iterator. Also, I should probably experiment with automatic rebalancing parts by tracking depth since insertion is orders of magnitude faster than searches anyway... --Rednaxela 05:44, 28 February 2010 (UTC)
By the way, if you're curious, the newest version of my tree is faster than the one bundled with the benchmark, which I'm pretty sure you compared to:
RESULT << k-nearest neighbours search with Rednaxela's Bucket kd-tree BENCHMARK BUNDLED VERSION>> : Average searching time = 0.083 miliseconds : Average worst searching time = 1.836 miliseconds : Average adding time = 7.17 microseconds : Accuracy = 100% RESULT << k-nearest neighbours search with Rednaxela's Bucket kd-tree NEWEST VERSION >> : Average searching time = 0.065 miliseconds : Average worst searching time = 1.326 miliseconds : Average adding time = 7.1 microseconds : Accuracy = 100%
--Rednaxela 03:22, 1 March 2010 (UTC)
Form your latest result above, it seems that your k-d tree is lack of accuracy. You'll have to improve that though.
Just a note about the accuracy, the benchmark use the first implementation (as ordered in searchAlgorithms array) to check the accuracy, so make sure that you still have FlatKNNSearch.class as the first implementation. Or if you think this may slow down your benchmark, I believe Rednaxela's k-d tree is stable enough to be use as a reference implementation. And the order of output isn't important for accuracy calculation, it just check it have the same result set. --Nat Pavasant 11:32, 1 March 2010 (UTC)
.
Thanks for pointing that out. That wasn't obvious from a quick scan of the source code. Accuracy does drop when using the PriorityQueue (probably because of incorrect handling of duplicates), but the intent was just to show that there is a lot to be gained by using a more efficient data structure than a TreeMap to collect the results.—duyn
One note, is with my own tree, I made a modified version that did "BOB" checks for 'first choice' branches and also using those "BOB" calculations on the path ordering like you do. The result? The average search time did not change, but the max search time decreased by 20% which I found interesting. This means there is actually a significant tradeoff happening which could be exploited. I'm now trying to determine an appropriate heuristic to decide if it's worth doing "BOB" on 'first choice' and for path selection. I currently suspect a good heuristic would be to use the somewhat expensive "BOB" checks (including for path selection) only when the total number of points in the tree below the node in question is above a certain count. I'll post results with that soon if you wish. --Rednaxela 15:21, 1 March 2010 (UTC)
I might have to try benchmarking mine, but have not done much java lately. --Chase 16:36, 1 March 2010 (UTC)
