Description
提案の核心 (The Core Proposal)
先にも提案しましたが値がnullかどうかのフラグは型のフィールドをシリアライズするときに書き込むがそのフラグをパックする
Nullable(参照型および Nullable)のフラグ管理を、現在の 1バイト/フィールド 方式から、1ビット/フィールド(ビットパッキング)方式へ切り替えるオプション、または最適化の導入
背景と課題 (Background & Motivation)
現状: int? が 100 個あるクラスをシリアライズすると、100 バイトのヘッダーが発生する。
課題: * 容量: 小さなデータが大量にある場合、ヘッダーがバイナリの大部分を占め、キャッシュ効率を落としている。
CPU: 1つずつ Null チェックとヘッダー読み込みを行うため、分岐予測の負担が大きく、SIMD 等による一括コピーパスを阻害している。
具体的な改善案 (Proposed Implementation)
Grouping Flags: 64個までの Nullable フィールドを 1つの ulong フラグにまとめ、オブジェクトの先頭付近に配置する。
Data Locality: フラグが立っている(実体がある)データのみを連続した領域に配置する。
Fast-Path Logic: フラグが「全ビットON」の場合、Unsafe.CopyBlock で一括コピーを行うコードを Source Generator で生成する。
Sparse Scanning: AIによるとBitOperations.TrailingZeroCountを用いて0の場所を読み飛ばす、が出来るらしいですが自分には理解できませんでした。
期待される効果 (Expected Impact)
バイナリサイズ: 参照型/Nullable が多いクラスでclass(98%),byte?(89%)のサイズに。
スループット: SIMD/一括コピーの適用により、デシリアライズ速度が向上する可能性がある
5.挙動の指定の仕方
Source Generator の複雑化: デフォルトの挙動を変えるのではなく、[MemoryPackable(GenerateBitPackedHeader = true)] のようなオプトイン形式を提案する。
Reactions are currently unavailable
You can’t perform that action at this time.
先にも提案しましたが値がnullかどうかのフラグは型のフィールドをシリアライズするときに書き込むがそのフラグをパックする
Nullable(参照型および Nullable)のフラグ管理を、現在の 1バイト/フィールド 方式から、1ビット/フィールド(ビットパッキング)方式へ切り替えるオプション、または最適化の導入
現状: int? が 100 個あるクラスをシリアライズすると、100 バイトのヘッダーが発生する。
課題: * 容量: 小さなデータが大量にある場合、ヘッダーがバイナリの大部分を占め、キャッシュ効率を落としている。
CPU: 1つずつ Null チェックとヘッダー読み込みを行うため、分岐予測の負担が大きく、SIMD 等による一括コピーパスを阻害している。
Grouping Flags: 64個までの Nullable フィールドを 1つの ulong フラグにまとめ、オブジェクトの先頭付近に配置する。
Data Locality: フラグが立っている(実体がある)データのみを連続した領域に配置する。
Fast-Path Logic: フラグが「全ビットON」の場合、Unsafe.CopyBlock で一括コピーを行うコードを Source Generator で生成する。
Sparse Scanning: AIによるとBitOperations.TrailingZeroCountを用いて0の場所を読み飛ばす、が出来るらしいですが自分には理解できませんでした。
バイナリサイズ: 参照型/Nullable が多いクラスでclass(98%),byte?(89%)のサイズに。
スループット: SIMD/一括コピーの適用により、デシリアライズ速度が向上する可能性がある
5.挙動の指定の仕方
Source Generator の複雑化: デフォルトの挙動を変えるのではなく、[MemoryPackable(GenerateBitPackedHeader = true)] のようなオプトイン形式を提案する。