Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parallel processing - improved #969

Merged
merged 3 commits into from
Apr 1, 2022
Merged

Conversation

dxdc
Copy link
Contributor

@dxdc dxdc commented Apr 1, 2022

Summary

This is an improvement to #959.

Bug fix for faiss

Simplified/optimized use of omp parallel

  • Eliminates the OOM faults from the existing version, and is generally a lot simpler. It seems to be very slightly faster as well.

Unordered maps

  • Switch to unordered maps. Since we are running this in parallel, we can achieve faster lookups, and there is no advantage to use ordered maps since we are sorting the final output anyway.

Optimized for loops

  • Rather than iterating through the entire loop twice, and checking whether or not it's a degenerate pair within the inner loop, this optimization allows for just a single run through to produce all of the unique pairs.
    for (unsigned int i = 0; i < filenames.size() - 1; i++) {
      for (unsigned int j = i + 1; j < filenames.size(); j++) {
        // comparison here
      }
    }
  • The iteration through the TMK arrays was modified to accommodate a more facile parallelization. Essentially, we build a list of filenames like this first. This also allows us to prefill the adjacencyMatrix diagonal and avoid an unneeded extra computation.
  std::vector<std::string> filenames;
  filenames.reserve(metadataToFeatures.size());

  for (const auto &s : metadataToFeatures) {
    // prefill adjacencyMatrix diagonal
    adjacencyMatrix[s.first].insert(s.first);
    filenames.push_back(s.first);
  }

Documentation

  • Updated README to add notes about how to build the parallel versions

Test Plan

Copy link
Contributor

@Dcallies Dcallies left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, this is definitely an argument for more unit testing in the longer term. I'm worried about our team's continued knowledge gap and the ability to verify the outputs.

Comment on lines +85 to +87
- The tests will not run after `make` without more changes, but they can be run manually
- Avoid BOM or CRLF line endings (e.g., if `haystack.txt` files are supplied)
- Use of absolute file paths may need more work in some cases. Try relative paths, or copying executables (like `ffmpeg.exe`) to your local directory.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you create issues for these?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure. I combined them into a single Windows-based issue: #971

@Dcallies Dcallies merged commit b10ea7c into facebook:main Apr 1, 2022
@dxdc
Copy link
Contributor Author

dxdc commented Apr 2, 2022

Hmm, this is definitely an argument for more unit testing in the longer term. I'm worried about our team's continued knowledge gap and the ability to verify the outputs.

Yeah. I have been manually verifying the outputs myself against the standard set of TMK files.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants