Inconsistency between vectorized processing boundary calculation in benchmark and readBatchUsing512Vector calculation method in ParquetReadRouter class?
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 38/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- java
- Área
- data-engineering, performance
Línea de trabajo
Compara los cálculos de límites en ByteBitPackingVectorBenchmarks.java y ParquetReadRouter.readBatchUsing512Vector(), centrándote en el procesamiento vectorizado frente al procesamiento con unpack8Values() para los anchos de bits y tamaños de salida indicados. Ejecuta benchmarks de las alternativas e inspecciona las cargas vectoriales enmascaradas y no enmascaradas para determinar si el comportamiento de los límites y la seguridad es correcto; se considera terminado cuando los resultados respaldan la elección de implementación y cualquier cambio necesario.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Hello, I have recently become interested in using vector API Parquet Bit-Packing decode. In the course of researching the code, I found that in the ByteBitPackingVectorBenchmarks.java in the official test benchmarks in the parquet-plugins-benchmarks folder totalByteCountVector = totalBytesCount - inputByteCountPerVector; When this range is exceeded, unpack8Values() is used to decode the data, which ensures that there is enough room for a full vector operation at the end. But in readBatchUsing512Vector() totalByteCountVector = totalBytesCount - BYTES_PER_VECTOR_512;
I am wondering if this affects the throughput performance and logic implementation choices for different bit width decoding methods.
My queries are as follows:
-
In this case, if it is the same amount of data, the number of vectorized decoding will be reduced, won't this affect the optimization effect after combining with Spark?
For example, bitwidth = 3, outputValues = 2048; when ByteBitPackingVectorBenchmarks.java totalByteCountVector = totalBytesCount - inputByteCountPerVector. Here the decoding is done by 63 times unpackValuesUsingVector and 4 times unpack8value. When totalByteCountVector = totalBytesCount - BYTES_PER_VECTOR_512; here the decoding is done by 59 times unpackValuesUsingVector, 20 times unpack8value.
-
I would like to ask here to reserve 64 bytes is to take into account the data out of bounds and other data security considerations?
Is it possible to use totalByteCountVector = totalBytesCount - inputByteCountPerVector; in the readBatchUsing512Vector boundary calculation code? -
Also if readBatchUsing512Vector keeps totalByteCountVector = totalBytesCount - BYTES_PER_VECTOR_512; the vectorization bounds here are enough to cover off the bounds-safe case, Loads a vector from an array of type byte[] starting at an offset and using a mask is necessary?
As I understand it, boundary crossing for vectorized data processing would be mitigated if BYTES_PER_VECTOR_512 is used. The performance loss caused by using masks for boundary data reading safety is greater than static ByteVector fromArray(VectorSpecies species, byte[] a, int offset) which doesn't use masks but directly loads the excess part of the array unused. Would it be possible to consider loading a vector only from an array of type byte[] starting at offset, without using a mask? Although this would add some single decode extra data to the vector loading process? Or is there some other reason why I can't eliminate the mask, I'm just eagerly waiting for an answer.Sorry for my poor English.
Component(s)
Core, Benchmark
- Lenguaje dominante
- Java
- Estrellas
- 3.1k
- Forks
- 1.6k
- Merge medio
- 6 d 16 h
- PR fusionados (30 d)
- 36
Guía de contribución
No hay ninguna guía de contribución indexada para este repositorio
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de apache/parquet-java
-
Type: bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
apache/parquet-java#3792 ·
-
Make PageReader AutoCloseable Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
apache/parquet-java#3767 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
apache/parquet-java#3695 · 1 comentario ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
apache/parquet-java#3667 ·
-
Type: bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
apache/parquet-java#3574 · 1 comentario ·
Todos los issues de apache/parquet-java
Issues similares
-
documentation
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
inu-appcenter/memorIN-backend#288 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
-
frontend maui-pilot pilot-ask question
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
executions.Query — startDate and timeRange filters are sent with inverted comparison operators Abiertoarea/plugin
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
kestra-io/plugin-kestra#190 ·