You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Depending on the number and sizes of the compression blocks, performing compression/decompression on the CPU can be faster than on the GPU. This is more emphasized for the compression side. Libcudf should have this as a run-time option. Ideally, the implementation would dynamically select how the operation is performed based on the parameters and the system.
The implementation should transparently dispatch between kernel and host operations to avoid having all readers/writers depend on this feature. For optimal performance, the host path should use a thread pool.
Libcudf already has the host side GZIP and Snappy compression/decompression. The main compression format that we cannot currently process on the host is ZSTD, and we would need to somehow add this dependency.
The text was updated successfully, but these errors were encountered:
Depending on the number and sizes of the compression blocks, performing compression/decompression on the CPU can be faster than on the GPU. This is more emphasized for the compression side. Libcudf should have this as a run-time option. Ideally, the implementation would dynamically select how the operation is performed based on the parameters and the system.
The implementation should transparently dispatch between kernel and host operations to avoid having all readers/writers depend on this feature. For optimal performance, the host path should use a thread pool.
Libcudf already has the host side GZIP and Snappy compression/decompression. The main compression format that we cannot currently process on the host is ZSTD, and we would need to somehow add this dependency.
The text was updated successfully, but these errors were encountered: