OnPair trainer should draw Rust's sample (StdRng + partial_shuffle) for byte-identical dictionaries

未關閉
  • 哪裡不對？
#534 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

還沒有人認領這個 Issue。

評估

難度
4/5
預估耗時
3-5 天
新手友好度
22/100
Issue 類型
缺陷
描述清晰度
描述清楚
活躍度
活躍
技術堆疊
java, rust
領域
data

研究方向

Start in OnPairEncodingEncoder.Encoder.train, which uses SplittableRandom(42) and a full Fisher-Yates shuffle, and compare it with the Rust training_order in encoding/trainer.rs. Port the partial_shuffle tail selection and doubling retry loop on top of SampleRng, and check that SampleRng.nextIntInclusive matches random_range from rand 0.9.5. Done when the 100k-row URL column gives the same dict_bytes_len and encoded size per chunk as the Rust 0.88.0 oracle.

由索引模型根據 Issue 內容生成。

描述

enhancement PARKED

Problem

OnPairEncodingEncoder does not draw the same training sample as the Rust onpair crate, so it trains different dictionaries on identical data. Prime directive: behavioral parity with Rust.

Found by comparing a 100k-row URL column (https://example.com/products/<n>/reviews?page=<m>, 7 chunks of 16,384 rows) written by vortex-java and by Rust 0.88.0 (the release vortex-jni uses), both at cascade 3 with global dict off. Both pick vortex.onpair per chunk.

dict_bytes_len per chunk:

chunk Rust Java
0 8191 8429
1 8525 8368
2 8447 8387
3 8363 8452
4 8379 8473
5 8757 5670
6 1872 1877

Chunks 0-4 end up within 0.04% in total, but Java's chunk 5 is 18% smaller (131,904 B vs 161,507 B): its trainer built a 761-token dictionary and the cascade then dict-encoded the 467 distinct codes. That one chunk is 29.6 KB of the 31.6 KB (3.2%) by which Java's file is smaller. This is training luck, not a systematic advantage, and it could go the other way on other data.

Cause

  • Rust (onpair 0.2.1, training_order in encoding/trainer.rs): StdRng::seed_from_u64(42) (ChaCha12, rand 0.9.5) and order.partial_shuffle(&mut rng, k) with k = min(n, 2 * sample_fraction * n + 1024). Training consumes only the selected tail order[n-k..]; if that tail is shorter than the byte budget, k doubles and the shuffle restarts.
  • Java (OnPairEncodingEncoder.Encoder.train): SplittableRandom(42), a full Fisher-Yates shuffle, and training consumes order from the start.

Proposed fix

  1. Port rand 0.9.5 partial_shuffle on top of SampleRng (already a bit-exact ChaCha12 StdRng and random_range for u32). It uses IncreasingUniform / calculate_bound_u32, which batches several swaps into one random chunk. Check that SampleRng.nextIntInclusive (written against rand 0.10) gives the same values as 0.9.5's random_range.
  2. Reproduce the k computation, the tail consumption and the doubling retry loop in train.
  3. Parity test: the URL column above, Rust as the oracle, comparing dict_bytes_len and encoded size per chunk (expect identical).

Repro

Scratch crate with vortex = "=0.88.0"; data dumped from the Java CascadeDepthGainIntegrationTest patterns (utf8-urls), seed 42. Not committed.

主要語言
Java
星號
3
分支
2
平均合併
9 小時 47 分鐘
30 天內合併 PR
128

環境準備

  • 沒有 Dockerfile 或 Docker Compose 檔案
  • 沒有 Pull Request 範本
  • 閱讀貢獻指南

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

dfa1/vortex-java 的其他 Issue

查看 dfa1/vortex-java 的全部 Issue

相似的 Issue

更多 Java Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。