Re^2: Partition in to 63 parts

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

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.

Comment on Re^2: Partition in to 63 parts

Replies are listed 'Best First'.
Re^3: Partition in to 63 parts by remzak (Acolyte) on Jan 18, 2010 at 21:36 UTC
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).	[reply]

Replies are listed 'Best First'.

Re^3: Partition in to 63 parts
by remzak (Acolyte) on Jan 18, 2010 at 21:36 UTC

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).

[reply]

In Section Seekers of Perl Wisdom