rapidsai/cudf

[FEA] Update IO benchmarks for consistency between formats

Open

#12.739 aberto em 8 de fev. de 2023

Ver no GitHub
 (0 comments) (0 reactions) (0 assignees)C++ (735 forks)batch import
2 - In ProgresscuIOfeature requestgood first issuelibcudf

Métricas do repositório

Stars
 (6.000 stars)
Métricas de merge de PR
 (Mesclagem média 17d 21h) (230 fundiu PRs em 30d)

Description

Is your feature request related to a problem? Please describe.

  • #12678
  • #12675
  • add device buffer data source to CSV reader benchmark (code pointer)
  • migrate CSV writer to nvbench. Currently using gbench.
  • add JSON writer benchmark. This benchmark could be modeled after CSV writer.
  • add JSON reader benchmark with file data source (NESTED_JSON only does parsing and only on device buffers). This benchmark could be modeled after BM_csv_read_io
  • #12700
  • #12674 -> add compression to BM_csv_read_io (?)
  • add benchmark coverage for parquet chunked reader. Perhaps modeled after parquet_read_io_compression
  • for reader benchmarks, verify that the roundtripped table matches the starting table
  • convert compression and io to string axis type. see this discussion in nvbench. the goal is to choose other values from the CLI without having to run all values in automation.
  • rename pmu, efs, trc in ORC writer chunks to peak_memory_usage, encoded_file_size, total_rows, to conform with the other ORC, PQ, CSV, text benchmarks

Additional context The initial set of topics came from a comparison of file read throughput across the supported formats in cuIO. We are also preparing for a comparison of memory footprint across cuIO, especially with Zstd compression/decompression.

Guia do colaborador

Direção de pesquisa
Selecione e conclua a subtarefa restante: renomeie `pmu`, `efs`, `trc` nos chunks do writer ORC para `peak memory usage`, `encoded file size`, `total rows` no benchmark do writer ORC. Familiarize se com o framework nvbench e o código do benchmark do writer ORC.
Pilha de tecnologia
None
Domain
backend
Tipo Issue
Funcionalidade
DifficultyDificuldade de implementação estimada para um novo contribuidor, de 1 para alterações muito pequenas a 5 para trabalho de nível especializado.
4
Tempo estimadoUm intervalo de tempo aproximado para um colaborador experiente investigar, implementar, testar e preparar um pull request.
Mais de 1 semana
Status da atividadeQuão disponível o issue aparece agora: novo, ativo, obsoleto, bloqueado ou aguardando entrada do mantenedor.
Antigo
ClarityCom que clareza o issue explica a mudança esperada, os critérios de aceitação e a próxima etapa.
Claro
Prerequisites
GitC++Benchmarking
Simpatia para novatosUma pontuação de 1 a 100 que estima o quão acessível este issue é para colaboradores iniciantes.
20