Inconsistency between vectorized processing boundary calculation in benchmark and readBatchUsing512Vector calculation method in ParquetReadRouter class?
Maintainer antworten meist innerhalb von 2 Tagen
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 38/100
- Issue-Typ
- Bug
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Veraltet
- Tech-Stack
- java
- Bereich
- data-engineering, performance
Rechercherichtung
Vergleiche die Grenzberechnungen in ByteBitPackingVectorBenchmarks.java und ParquetReadRouter.readBatchUsing512Vector() und konzentriere dich dabei auf die vektorisierte Verarbeitung gegenüber der Verarbeitung mit unpack8Values() für die angegebenen Bitbreiten und Ausgabegrößen. Benchmarke die Alternativen und untersuche die maskierten und unmaskierten Vektor-Ladevorgänge, um festzustellen, ob das Grenz- und Sicherheitsverhalten korrekt ist; abgeschlossen ist die Aufgabe, wenn die Implementierungsentscheidung und jede erforderliche Änderung durch Ergebnisse gestützt werden.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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
- Vorherrschende Sprache
- Java
- Sterne
- 3.1k
- Forks
- 1.6k
- Ø Merge
- 4 T. 9 Std.
- Gemergte PRs (30 T.)
- 32
Entwicklungsumgebung
Die Einrichtungsdateien dieses Projekts haben wir noch nicht geprüft. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus apache/parquet-java
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 74/100
apache/parquet-java#3829 ·
Maintainer antworten meist innerhalb von 2 Tagen
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 88/100
apache/parquet-java#3820 ·
Maintainer antworten meist innerhalb von 2 Tagen
-
Type: bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
apache/parquet-java#3792 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 2 Tagen
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
apache/parquet-java#3767 ·
Maintainer antworten meist innerhalb von 2 Tagen
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
apache/parquet-java#3695 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 2 Tagen
Alle Issues in apache/parquet-java
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
Maintainer antworten meist innerhalb von 1 Tag
-
Content
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
RunestoneInteractive/rs#1559 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 2 Tagen
-
documentation
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 86/100
inu-appcenter/memorIN-backend#298 ·
Maintainer antworten meist innerhalb von 1 Tag
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 85/100
opendataloader-project/opendataloader-pdf#757 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
redhat-developer/intellij-quarkus#1626 ·