Remove the cuFile (GDS) backend

[madsbk]

I am wondering if it is time to remove the cuFile backend such that the LIBCUDF_CUFILE_POLICY options become: KVIKIO (the current default) and OFF.

This will remove a lot of code and make it easier to simplify and add new IO features, I think.

cc. @GregoryKimball, @vuule

[bdice]

@madsbk Can you help explain the potential impact on performance? How does KVIKIO performance compare to GDS or ALWAYS? I don't have a very good grasp on how these behave in terms of performance, but am in favor of simplification.

[vuule]

I'm a bit hesitant to remove this. If nothing else, having an option that uses GDS but does not use kvikIO has been useful for debugging.

[madsbk]

@madsbk Can you help explain the potential impact on performance? How does KVIKIO performance compare to GDS or ALWAYS? I don't have a very good grasp on how these behave in terms of performance, but am in favor of simplification.

When cuFile is available, the performance of KVIKIO and GDS is the same. They both use the same thread pool implementation, thread pool size, and chunk size.

When cuFile isn’t available, GDS delegates to libcudf's own IO implementation whereas KVIKIO uses its own IO implementation. All benchmarks I have seen, KVIKIO performs on par or better than libcudf’s own IO implementation hence why KVIKIO is the default backend.

ALWAYS forces the use of cuFile and will fail if not available. It is the same as setting KVIKIO_COMPAT_MODE=off (disabling KvikIO’s compatibility mode).

I'm a bit hesitant to remove this. If nothing else, having an option that uses GDS but does not use KvikIO has been useful for debugging.

I agree, GDS as a debug point might be useful but I am not sure it is worth it the extra code and complexity. KVIKIO has been the default backend since 23.02 and we still have OFF (libcudf’s own IO implementation) to test against.