query performance tuning

[n0thing233]

Summary

Hi. I would like to get some understanding on the search performance, I've noticed doc here :
https://github.com/facebookresearch/faiss/wiki/Threads-and-asynchronous-calls
and I realized the faiss internal threading is done by OpenMP.
I have two questions here:
question 1:
when I call index.search() on a batch queries (a numpy matrix), the OpenMP will do pthread_create() on the fly or it will search for an available thread in existing thread-pool? creating short-lived thread on each search call seems a big overhead?
I was trying to use strace to print all kernel calls, but didn't find any "pthread_create" under the search process and its subprocesses. maybe is it in another process?
I do see some clone() linux function called, does that mean new subprocesses are created to do the search?

Question 2:
I need to clarify on the sentence "However it is very inefficient to call batches of queries from multiple threads, this will spawn more threads than CPU cores."
How can I make sure that the number of threads created <= CPU cores?

For example, Assuming I have 2 threads calling index.search(),and I set OMP_NUM_THREADS=4, does that mean 8 is the max number of threads OPENMP will create to do the search?

Running on:

• CPU

Interface:

• Python

[mdouze]

1. this is dependent on the openmp implementation, but in general openmp operates a thread pool
2. yes about 2 x 4 threads. NB that for externally created threads, openmp creates independent thread pools.

[n0thing233]

@mdouze
thanks on the quick reply! I have a follow up question:
with the following python code:
index = faiss.read_index(filename, faiss.IO_FLAG_MMAP)
is the index object above python thread safe? Can multiple python threads use the same index object?
the reason I'm asking the question is that, for our use case, the index itself is huge (25GB).It has to be read in a memory-mapped way. (even reading it in a memory- map way will take 1G memory) and shared by multiple threads of my web server to perform the search.
What I'm concerned is that race condition or the unexpected behavior will happen if multiple threads refer to the same index object for search purpose.