【golang】構造体のフィールド宣言順序は パフォーマンスにどう影響するか？

Transcript

1. 構造体のフィールド宣言順序は パフォーマンスにどう影響するか？ 梅木和弥 Go Connect #16
2. 前提: Go はフィールドを自動で並び替えません Rust コンパイラがフィールドを自動で並び替える Go 宣言順序はがそのままメモリレイアウトに反映される
3. 64 bit アーキテクチャのアライメント規則 型 bool / int8 / byte int16 int32 / float23 int64 / float64 / pointer string slice サイズ 1B 2B 4B 8B 16 B 24 B アライメント 1 2 4 8 8 8
4. 検証の目的 「フィールド宣言順序の違い」が パフォーマンスにどの程度の影響を与えるのか...。
5. 検証方法 静的サイズ検証 それぞれのサンプルの実際のメモリレイアウトを出力。 BenchmarkAlloc 100万件のスライスを make する速度を計測。(アロケーション性能) BenchmarkTraverse 100万件を全走査して集計する速度を計測。(キャッシュライン効率) Company Name
6. 検証方法 サンプルA アライメントに配慮しないフィールド順序 type SampleA struct { a bool // 1 B + 7 B padding b int64 // 8 B c bool // 1 B + 3 B padding d int32 // 4 B } サンプルB サイズ降順に配置 type SampleB struct { b int64 // 8 B d int32 // 4 B a bool // 1 B c bool // 1 B + 2 B padding } Company Name
7. 仮説 Metric SampleA SampleB Diff サイズ 24 B 16 B -33 % Allocs/op 同等 同等 ns/op 高い 低い 改善見込みあり？
8. 計測してきました。 Company Name
9. 結果 ~ 静的サイズ検証 宣言順序を変更しただけで 24 B → 16 B SampleA a b 8B d 16B SampleB b c 24 B d ac 16 B 8B 33.3 % のサイズ削減（パディングとして無駄になっていた8Bを回収） Company Name
10. 結果 ~ ベンチマーク結果 Metric SampleA SampleB Diff Sizeof 24 B 16 B -33.3% Alloc B/op (1M) 25,165,841 16,777,232 -33.3% Alloc ns/op (1M) -353,284 -258,446 -26.8% Traverse ns/op (1M) -724,043 -638,430 -11.8% Allocs/op 1 1 0% Company Name
11. 結論 構造体サイズが減る: -33% 大量生成時の処理速度が向上する: -27% スライス走査も高速化: -12% Company Name
12. ご清聴ありがとうございました。 @umekikazuya
13. 結果 ~ ベンチマーク結果 サイズ差 -33% フィールド間パディングが計 8B 削減された ( unsafe.Sizeof で確認) アロケーションコスト -26.8% 総バイト数が 33% 減った分に比例して make の所要時間も短縮 走査スループット -11.8% 1キャッシュライン(64B)に載る要素数が2.67個→4個に増え、キャッシュ率が低下 Allocs/op は同等 make([]T, N) は型サイズに関係なく1回の alloc。構造体サイズは回数ではなくバイト量にのみ影響。 Company Name