4

I have n-sets (distributed on n-ranks) of data which represents the nodes of a mesh and I wanted to know an efficient parallel algorithm to find the intersection of these sets, i.e., the common nodes. An intersection is defined as soon as any 2 sets share a node.

For example;

Input:

Rank 0: Set 1 - [0, 1, 2, 3, 4]

Rank 1: Set 2 - [2, 4, 5, 6]

Rank 2: Set 3 - [0, 5, 6, 7, 8]

Implement Parallel Algorithm --> Result: (after finding intersections)

Rank 0: [0, 2, 4]

Rank 1: [2, 4, 5, 6]

Rank 2: [0, 5, 6]

The algorithm needs to be done on n-ranks with 1 set on each rank.

ROMANIA_engineer
  • 54,432
  • 29
  • 203
  • 199
GK-F3D
  • 73
  • 1
  • 1
  • 8
  • I found an algo to do the 2 set intersection efficiently so I was thinking of creating a tree structure of comparing 2 ranks at a time until I exhaust all the ranks. – GK-F3D Dec 12 '12 at 18:23
  • The 2 set intersection algo looks like this; We can have two index, which both starts at zero. Compare the two first elements of A and B. If A[0] is greater than B[0], we increase index of B by one. If B[0] is greater than A[0], we increase index of A by one. If they are equal, we know an intersection has occurred, so add it to the list and increment index of A and B by one. Once either index reaches the end of A or B, we have found all the intersections of A and B. This needs to be implemented after sorting. – GK-F3D Dec 12 '12 at 18:27
  • 2
    Mathematically, what you want as a result for each rank is the **union of the intersections** of that rank's set with each other rank's set. For parallel implementation, it might be worthwhile considering an equivalent problem: removing each element that is not an element of any other set. P.S. Are the sets alwasys ordered (as in your examples)? – Ted Hopp Dec 12 '12 at 19:02
  • Yes! I think sorting it before doing the intersection operation is helpful. By performing a sort I can eliminate some ranks that might not have any elements in common. Your suggested equivalent problem works too... Let me think about this a little more! – GK-F3D Dec 12 '12 at 19:09

1 Answers1

1

You should be able to this fast O(N), in parallel, with hash tables.

For each set S_i, for each member m_x (all of which can be done in parallel), put the set member into a hash table associated with the set name, e.g., . Anytime you get a hit in the hash table on m_x from set S_j, you now have the corresponding set number S_i, and you know immediately that S_i intersects S_j. You can put m_x in the derived intersection sets.

You need a parallel-safe hash table. That's easy; lock the buckets during updates.

[Another answer suggested sorting the sets. With most sort algorithms, would be O(N ln N) time, not as fast].

Ira Baxter
  • 93,541
  • 22
  • 172
  • 341
  • I thought of this, but wouldn't this be memory intensive? The number of nodes (sum of all entries of all the sets) in the entire domain might be 100's of millions. Would it be better just to assemble all sets on 1 rank and use an optimized serial intersection algo and then communicate this information to all other ranks? – GK-F3D Dec 12 '12 at 23:15
  • You wanted fast. To get fast, you tend to trade time for space. So, how much space? Estimating, a data point might be 16 bytes, a set ID might be 4 bytes, a hashlink might be 8 bytes, so 32 bytes per point * 100 million -> 3200 million bytes. That's 3.2 Gb of RAM, some $50.00 at your local computer dealer. Whats the problem? [Don't you already have to have all these data points in memory anyway?] – Ira Baxter Dec 12 '12 at 23:45
  • .... if you don't want the extra memory for the hash tables, then sorting the sets (pay time for space) would be a fine solution. But, ln 100 million is 22 (base 2), so expect it to be visibly slower. – Ira Baxter Dec 13 '12 at 00:10