Inconsistency between vectorized processing boundary calculation in benchmark and readBatchUsing512Vector calculation method in ParquetReadRouter class?
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 38/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 停滞
- 技術スタック
- java
調査の方向性
ByteBitPackingVectorBenchmarks.java と ParquetReadRouter.readBatchUsing512Vector() の境界計算を比較し、指定されたビット幅と出力サイズに対するベクトル化処理と unpack8Values() 処理に注目してください。各選択肢のベンチマークを実行し、マスク付きおよびマスクなしのベクトルロードを調査して、境界と安全性に関する挙動が正しいかどうかを判断してください。結果によって実装の選択と必要な変更が裏付けられれば完了です。
索引モデルが issue の本文から書いたものです。
説明
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
- 主要言語
- Java
- スター
- 3.1k
- フォーク
- 1.6k
- 平均マージ
- 6日 16時間
- マージ済み PR(30日)
- 36
コントリビューションガイド
このリポジトリのコントリビューションガイドは索引されていません
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
apache/parquet-java のほかの issue
-
Type: bug
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
apache/parquet-java#3792 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
apache/parquet-java#3767 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
apache/parquet-java#3695 · コメント 1 件 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
apache/parquet-java#3667 ·
-
Type: bug
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
apache/parquet-java#3574 · コメント 1 件 ·
apache/parquet-java の issue をすべて見る
似ている issue
-
documentation
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
inu-appcenter/memorIN-backend#288 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
-
frontend maui-pilot pilot-ask question
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
-
area/plugin
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
kestra-io/plugin-kestra#190 ·