Go 1.27 における memory allocation の高速化

unagam X: unagam
2026 年 8 月 5 日
golang.tokyo #44

Transcript

1. Go 1.27におけるmemory allocationの高速化 © 2026 ANDPAD All Rights Reserved. Confidential 1
2. Speaker unagam ANDPAD SWE & Science Tokyo(M2) Goとボカロが好き © 2026 ANDPAD All Rights Reserved. Confidential 2
3. Go 1.27 メモリへの割り当てが速くなった！ ヒープへの小さい割り当て(<=80B)が最大30%高速化した プログラム全体でみると約1%高速化した 代わりにバイナリサイズが60KB増えた © 2026 ANDPAD All Rights Reserved. Confidential 3
4. なぜ速くなったのかわからない The compiler now generates calls to size-specialized memory allocation routines, … (訳: コンパイラがサイズ特化のメモリアロケーションルーチンを呼び出し、...) リリースノートより引用：https://go.dev/doc/go1.27#faster-memory-allocation 初見だと全然わからない わかりやすく解説してみよう！ © 2026 ANDPAD All Rights Reserved. Confidential 4
5. 事前知識①: ヒープ メモリ内に値を保存する領域は2種類: スタック&ヒープ スタック ヒープ 寿命 定義された関数内のみ 定義された関数が終了しても残る コスト 小さい 大きい 具体例 © 2026 ANDPAD All Rights Reserved. Confidential 5
6. 事前知識①: ヒープ これ以降全部この話 スタック ヒープ 寿命 定義された関数内のみ 定義された関数が終了しても残る コスト 小さい 大きい 具体例 © 2026 ANDPAD All Rights Reserved. Confidential 6
7. 事前知識②: 値(~32KB)は種類に応じて格納 1. ランタイムでサイズを事前設定(8B, 16B, 24B, 32B,…, 32KB ) 2. 値のサイズを切り上げ(22B→24B, 25B→32B) 3. 値のポインタ有無をチェック(ポインタあり/ポインタなし) 4. 該当のメモリ領域に格納 16B/ポインタあり 16B/ポインタなし 参考: https://internals-for-interns.com/posts/go-memory-allocator/ © 2026 ANDPAD All Rights Reserved. Confidential 7
8. 従来のメモリ格納前の判別作業 メモリ格納時分類が必要になる 値のサイズは？ ポインタは？ 判別作業によるコストが発生していた The Go gopher was designed by Renée French. © 2026 ANDPAD All Rights Reserved. Confidential 8
9. コンパイル時に大体判別可能 8B 16B(ポインタ含む) 8B 32B/ポインタありの区画に格納する © 2026 ANDPAD All Rights Reserved. Confidential 9
10. コンパイル時点で判別しよう! コンパイル時点で格納先決定可能なものは決めてしまう 従来 1. サイズを事前設定する 2. 値のサイズを切り上げる 3. 値のポインタ有無をチェック 4. 該当の区画に格納する © 2026 ANDPAD All Rights Reserved. Confidential 10
11. コンパイル時点で判別しよう! コンパイル時点で格納先決定可能なものは決めてしまう 従来 1. サイズを事前設定 2. 値のサイズを切り上げ 3. 値のポインタ有無をチェック 4. 該当の区画に格納 Go 1.27 小さい値はコンパイラが 2~3を担当する 実行時値を格納だけでOK 判別の作業を省くことで高速化を実現した © 2026 ANDPAD All Rights Reserved. Confidential 11
12. 実際にコンパイルして確かめる サンプルコードのmain.go Userを呼び出してNameを 表示させるだけ サンプルコードなどはこちら https://github.com/UnagamiKanta/go-1-27-faster-malloc © 2026 ANDPAD All Rights Reserved. Confidential 12
13. 従来のコンパイル時の呼び出し 実行するコマンド 従来の実装でビルドしてアセンブリを出力 アセンブリからメモリ割り当てだけを表示する 全ての値共通の割り当て関数が呼ばれる © 2026 ANDPAD All Rights Reserved. Confidential 13
14. Go 1.27のコンパイル時の呼び出し 実行するコマンド Go1.27のメモリ割り当てを有効化する 従来 共通関数を呼び出す Go 1.27 Scan=ポインタを含む SC4 =32Bのサイズを持つ コンパイル時点でサイズ特化関数を呼び出す © 2026 ANDPAD All Rights Reserved. Confidential 14
15. なぜ80B以下だけなのか？ 80Bより大きくても同じ手順だから同様に高速化できそう しかし実際には80Bより大きいと今回の実装から外れる https://cs.opensource.google/go/go/+/refs/tags/g o1.27rc1:src/runtime/_mkmalloc/constants.go;l=30 実際最初は512Bまで同様の実装 runtime: add specialized malloc functions for sizes up to 512 bytes (訳: 最大512Bのサイズ特化メモリ割り当て関数を追加) https://go-review.googlesource.com/c/go/+/665835 なぜ512Bから80Bまで減らされたのか？ © 2026 ANDPAD All Rights Reserved. Confidential 15
16. メリットよりデメリットが大きくなるから 512Bに設定後、サイズ特化関数のベンチが追加された https://go-review.googlesource.com/c/go/+/775980 ベンチが追加されてすぐ、512B→128Bに減らされた https://go-review.googlesource.com/c/go/+/776740 サイズが大きいと効果が非常に小さい CPUキャッシュ圧迫によるアプリ全体への悪影響 ベンチマーク結果をもとにサイズを変更したはず 妥協点として最終的に80Bに調整された © 2026 ANDPAD All Rights Reserved. Confidential 16
17. まとめ • 小さい値のヒープ割り当てが速くなった • 割り当て区画の判別にコストが発生していた • 判別をコンパイラ側で行うようにした • 80Bになったのはメリットとデメリットの妥協点のため © 2026 ANDPAD All Rights Reserved. Confidential 17
18. 宣伝：このベンチマーク結果を見つけよう! GoConで弊社エンジニアがワークショップを開催します! https://gocon.jp/2026/news/session-announcement/ 今回のベンチ結果含め多くのワークを用意しています! © 2026 ANDPAD All Rights Reserved. Confidential 18
19. We are hiring !! Mission 幸せを築く人を、幸せに。 エンジニア採用ページ 住まいをつくる。ビルや施設をつくる。街をつくる。 生活を豊かにする建築・建設業は、幸せづくりと例えられます。 私たちは、その幸せづくりをする人たちをテクノロジーの力で カジュアル面談 後押ししていきたい。心からそう考えてます。 応募フォーム 我々はこれからもお客様の声をサービスに反映して、 建設業界及び建設業従事者様の業務効率化、 DX化を支援してまいります。 開発部公式 X アカウント @andpad_dev Copyright © 2020 Present ANDPAD Inc. This information is confidential and was prepared by ANDPAD Inc. for the use of our client. It is not to be relied on by and 3rd party. 無断転載・無断複製の禁止 Confidential