Update tutorial

[beauby]

• Remove transitional print import.
• Add C++ code example for one GPU.
• Add python/C++ code examples for several GPUs.

[mdouze]

Have you tested with py2 + py3?

[beauby]

@mdouze Yes, python2.7 and python3.6.

[Enet4]

I hope you don't mind that I throw in a few comments on the C++ examples. Feel free to disregard them if they are not deemed important enough for this context. As code is copied all the time, I would say that providing examples with good practices is a plus.

[Enet4]

Does it make sense to allocate res with new here? It already seems to outlive all indexes in the example, so a plain object with automatic storage duration would suffice:

faiss::gpu::StandardGpuResources res;
faiss::GpuIndexFlatL2 index(&res, d);

[Enet4]

A similar reasoning could be applied here, but alas, it would require another vector to keep the pointers to the resource objects. Other than that, a vector of ngpu GPU resources can be even created inplace without a loop. I can't think of a better way to do this unfortunately. This is what it would look like:

std::vector<faiss::gpu::StandardGpuResources> owned_res{ngpus};
std::vector<faiss::gpu::GpuResources*> res{ngpus};
std::vector<int> devs{ngpus};
for (int i = 0; i < ngpus; i++) {
    res[i] = &owned_res[i];
    devs[i] = i;
}

[Enet4]

When relying on C++11, one can wrap these data allocations around a unique_ptr. Not only it would be automatically freed when falling out of scope, it would protect also prevent leaks in case of exceptions.

#include <memory>

// ...

auto I = std::unique_ptr<long[]>(new long[k * 5]);
auto D = std::unique_ptr<float[]>(new float[k * 5]);

index.search(5, xb, k, D.get(), I.get());

[Enet4]

Was this in a more complicated context, wouldn't want the index to leak. I believe a unique_ptr around the pointer to the GPU index works fine here.

auto index = std::unique_ptr<faiss::Index>(
    faiss::gpu::index_cpu_to_gpu_multiple(
        res,
        devs,
        new faiss::IndexFlat(d)
    ));

[beauby]

@Enet4 Thanks for your comments. Agreed that providing examples with good practices is a plus. I modified the example on one GPU to avoid using new, as it was totally unnecessary.

Regarding the (lack of) use of unique_ptrs, the rationale is to avoid scaring off people who are not familiar with it, and focus on the library usage.

[mdouze]

inconsistent: resources is allocated with new, GpuIndexFlat is allocated on the stack

[mdouze]

This will not be deallocated, so it should be declared separately.

[mdouze]

Remove the sanity check, we will not comment it twice

[mdouze]

could you call the executables 1-Flat, 2-IVFFlat, etc. ?

[wickedfoo]

Use std::unique_ptr at the least if you keep it by pointer, so you don't need the free at the end.