Fast Decompression Lucene Codec #bbuzz
summary
Shows that replacing Java decoding with a SIMD C decoder (C99 vector code from Daniel Lemire) called via HotSpot’s critical native interface halves block decoding latency for Lucene 5.0 P4 blocks (128/188-size) compared with normal JNI, dropping per-block latency into the tens of nanoseconds and decoding ~100 integers in ~70 ns. Benchmarked with JMH on realistic data, total top-10k-term search time falls from 60s to 49s — about an 18% search speedup.
AI-written summary · about
chapters (15)
- 0:00Intro
- 0:55Table of Contents
- 1:50Requirements of a search index
- 2:19The numbers every engineer should know
- 5:354D Codec API
- 10:26What is FOR encoding?
- 11:51Scalar vs. Vectors
- 14:29Vectorization in HotSpot
- 17:46Workaround
- 19:50JDK-7013347 Critical Native
- 24:03Microbenchmark
- 29:21SIMD codec
- 30:15Lucene benchmark
- 33:34Benchmark results
- 35:34Future work
related talks
40mLudicrous Speed: Designing For Performance on the JVM
44mHotspot JVM Auto Vectorization and Vector API
51mJava at Speed: Getting the Most Out of Modern Hardware
35mJava at Speed: Building a Better JVM
21mThe Lucene Scalpel: Tuning Low-Level Segments for Multi-Lingual Concurrency
30mCaching for Speed: Practical Performance Optimization in OpenSearch & Lucene
22mWhat's coming next with Apache Lucene?
44mJava at Speed: Building a Better JVM.