http://qs321.pair.com?node_id=817917


in reply to Partition in to 63 parts
in thread Need a faster way to find matches

Partitioning the problem is a really cool idea, especially since it shows how to easily split up the processing (if only I could). Also I appreciate your code. When I plugged it into my program, it wasn't faster than my starting point. I am guessing it would be faster if my list was larger than 10,000, or if I had a computer with many processors running the algorithm in parallel. At the current size of my list (slightly less than 4,000) the current optimization is the fastest. Just as an FYI, with all the stimulating ideas that were shared, I managed to improve the speed by more than 47 percent.

Replies are listed 'Best First'.
Re^2: Partition in to 63 parts
by gam3 (Curate) on Jan 18, 2010 at 04:31 UTC
    Yes it's only real advantage is that you could stick it in POE and use all your cores.

    If the data is not random you might find some advantage in removing the bit that is set the most first.

    If the input data has some bits set more than 1/63 of the time you can get some advantage. You can see this in that if all of the data had a bit set then this algorithm would remove all the entries from the list on the first pass if it checked that bit first.

    But I assume your data is random.

    -- gam3
    A picture is worth a thousand words, but takes 200K.
      The data isn't random... the numbers come from another algorithm. Finding the pairs is the middle step of a three step algorithm.

      BrowserUK provided a great example of using threads. When I tried your approach, I used too many threads and learned how much overhead threads require. I'll try to merge his partioning approach with my code... I'm finding that after six threads, the performance degrades (on my machine).