Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Inconsistency between vectorized processing boundary calculation in benchmark and readBatchUsing512Vector calculation method in ParquetReadRouter class?

Ouverte
#3,073 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
38/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
À l'abandon
Stack technique
java

Piste de recherche

Comparez les calculs des limites dans ByteBitPackingVectorBenchmarks.java et ParquetReadRouter.readBatchUsing512Vector(), en vous concentrant sur le traitement vectorisé par rapport au traitement avec unpack8Values() pour les largeurs de bits et les tailles de sortie indiquées. Évaluez les alternatives avec des benchmarks et inspectez les chargements vectoriels masqués et non masqués afin de déterminer si le comportement concernant les limites et la sécurité est correct ; le travail est terminé lorsque les résultats étayent le choix d’implémentation et toute modification nécessaire.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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:

  1. 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.
    totalVectorCount

  2. 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?

  3. 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?
    load Vector Using Mask or not
    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

Langage dominant
Java
Étoiles
3.1k
Forks
1.6k
Merge moyen
6 j 16 h
PR mergées (30 j)
36

Guide de contribution

Aucun guide de contribution indexé pour ce dépôt

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de apache/parquet-java

Toutes les issues de apache/parquet-java

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.