Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

[インデックス 14802] ファイルの概要

このコミットは、Go言語の型システムにおけるガベージコレクションインポーター（gcimporter）のパフォーマンス改善を目的としています。特に、Linux/ARMアーキテクチャ上でのクロージャ生成が引き起こす性能問題に対処するため、不要なクロージャの生成を削減しています。これにより、go test -shortの実行時間が大幅に短縮されました。

コミット

go/types: less closure creations in gcimporter.

Closures are incredibly expensive on linux/arm due to
repetitive flush of instruction cache.

go test -short on ODROID-X:

Before:
ok      exp/gotype      17.091s
ok      go/types        2.225s

After:
ok      exp/gotype      7.193s
ok      go/types        1.143s

R=dave, minux.ma, rsc
CC=golang-dev, remy
https://golang.org/cl/7062045

GitHub上でのコミットページへのリンク

https://github.com/golang/go/commit/0f545d9ab22034dffa468367d44aceb257e1048e

元コミット内容

go/types: less closure creations in gcimporter.

Closures are incredibly expensive on linux/arm due to
repetitive flush of instruction cache.

go test -short on ODROID-X:

Before:
ok      exp/gotype      17.091s
ok      go/types        2.225s

After:
ok      exp/gotype      7.193s
ok      go/types        1.143s

R=dave, minux.ma, rsc
CC=golang-dev, remy
https://golang.org/cl/7062045

変更の背景

この変更の主な背景は、Go言語のコンパイラおよび型チェッカーの一部であるgcimporterパッケージが、Linux/ARMアーキテクチャ上でパフォーマンス上のボトルネックを抱えていたことです。コミットメッセージによると、この問題は「クロージャの生成がLinux/ARM上で非常に高価である」ことに起因していました。具体的には、クロージャが生成されるたびに命令キャッシュの繰り返しフラッシュが発生し、これが性能低下を招いていました。

go test -shortの実行結果が示すように、変更前はexp/gotypeが17.091秒、go/typesが2.225秒かかっていたのに対し、変更後はそれぞれ7.193秒と1.143秒に短縮されており、特にexp/gotypeでは約58%の高速化が達成されています。これは、組み込みシステムや低消費電力デバイスで広く利用されるARMアーキテクチャにおけるGo言語の実行効率を向上させる上で重要な改善でした。

前提知識の解説

クロージャ (Closures)

クロージャとは、関数がその関数が定義された環境（レキシカルスコープ）を記憶し、その環境内の変数にアクセスできる機能を持つ関数のことです。Go言語では、関数内で別の関数を定義し、その内部関数が外部関数のローカル変数にアクセスする場合にクロージャが生成されます。

例えば、以下のようなGoのコードはクロージャの典型例です。

func adder() func(int) int {
    sum := 0
    return func(x int) int {
        sum += x
        return sum
    }
}

adder関数が返す匿名関数は、adderのスコープにあるsum変数にアクセスし続けることができます。

命令キャッシュ (Instruction Cache)

CPUは、プログラムの実行速度を向上させるために、頻繁にアクセスされる命令を高速なメモリ（キャッシュ）に一時的に保存します。これが命令キャッシュです。CPUが次に実行する命令を探す際、まず命令キャッシュをチェックし、そこに命令があればメインメモリにアクセスするよりもはるかに高速に命令を取得できます。

キャッシュフラッシュ (Cache Flush)

キャッシュフラッシュとは、キャッシュに保存されているデータを無効化し、メインメモリの内容と同期させる操作のことです。命令キャッシュの場合、プログラムが自己書き換えコードを生成したり、動的にコードをロードしたりする際に、キャッシュ内の命令が古くなる可能性があるため、キャッシュをフラッシュして最新の命令を読み込む必要があります。

Linux/ARMにおけるパフォーマンス問題

ARMアーキテクチャ、特に古い世代や特定の組み込みシステム向けのARMプロセッサでは、命令キャッシュのフラッシュ操作が比較的重い処理となることがあります。これは、キャッシュの構造やフラッシュメカニズムの実装に依存します。

Go言語のクロージャは、実行時に動的にコードを生成する場合があります（例えば、クロージャの環境ポインタを設定するためなど）。このような動的なコード生成は、命令キャッシュの整合性を保つためにキャッシュフラッシュを必要とすることがあります。もし、gcimporterが頻繁に小さなクロージャを生成していた場合、そのたびに命令キャッシュのフラッシュが繰り返され、特にフラッシュコストが高いARM環境では、これが顕著なパフォーマンス低下の要因となっていたと考えられます。

このコミットは、このようなARM特有のパフォーマンス特性を考慮し、クロージャの生成を最小限に抑えることで、命令キャッシュフラッシュの回数を減らし、全体的な実行速度を向上させることを目指しています。

技術的詳細

このコミットは、src/pkg/go/types/gcimporter.goファイル内の構文解析ロジックにおいて、不要なクロージャの生成を排除することでパフォーマンスを改善しています。具体的には、parseStructType、parseParameters、parseInterfaceTypeの各関数内で定義されていたローカルなヘルパー関数（parseField、parseParameter、parseMethod）がクロージャとして機能しており、これらが繰り返し呼び出されるたびにオーバーヘッドが発生していました。

変更前は、これらのヘルパー関数がそれぞれ独立したクロージャとして定義され、ループ内で呼び出されていました。クロージャは、その定義されたスコープの変数をキャプチャするため、実行時に追加のメモリ割り当てや、場合によっては命令キャッシュのフラッシュを伴うコード生成が必要になることがあります。特に、ループ内で頻繁に生成・呼び出しが行われると、そのコストが累積して大きなパフォーマンス低下につながります。

このコミットでは、これらのヘルパー関数をクロージャとして定義するのをやめ、そのロジックを直接呼び出し元のループ内にインライン化しています。これにより、クロージャの生成とそれに伴うオーバーヘッドが完全に排除されます。

例えば、parseStructType関数では、parseFieldというクロージャが定義され、構造体のフィールドを解析するためにループ内で呼び出されていました。変更後は、p.parseField()の呼び出しが直接ループ内で行われるようになり、parseFieldクロージャは不要になりました。同様の変更がparseParameters（parseParameterクロージャ）とparseInterfaceType（parseMethodクロージャ）にも適用されています。

この最適化は、コードの可読性をわずかに犠牲にするかもしれませんが、パフォーマンスがクリティカルな部分においては非常に効果的です。特に、gcimporterのようなコンパイラ関連のツールは、大量のコードを処理するため、このような小さな最適化の積み重ねが全体的なビルド時間や解析時間に大きな影響を与えます。

コアとなるコードの変更箇所

変更はsrc/pkg/go/types/gcimporter.goファイルに集中しています。

  1. parseStructType関数:

    • parseField := func() { ... } のクロージャ定義が削除されました。
    • クロージャの呼び出し箇所 parseField() が fields = append(fields, p.parseField()) に直接置き換えられました。
    • ループの条件が if p.tok != '}' から for p.tok != '}' に変更され、ループ内のロジックが簡素化されました。

  2. parseParameters関数:

    • parseParameter := func() { ... } のクロージャ定義が削除されました。
    • クロージャの呼び出し箇所 parseParameter() が par, variadic := p.parseParameter() と list = append(list, par) に直接置き換えられました。
    • ループの構造が変更され、より直接的な解析ロジックになりました。

  3. parseInterfaceType関数:

    • parseMethod := func() { ... } のクロージャ定義が削除されました。
    • クロージャの呼び出し箇所 parseMethod() が name := p.parseName()、typ := p.parseSignature()、methods = append(methods, &Method{name, typ}) に直接置き換えられました。
    • ループの構造が変更され、より直接的な解析ロジックになりました。

これらの変更により、合計で15行が追加され、30行が削除されています。

コアとなるコードの解説

変更前 (src/pkg/go/types/gcimporter.go の一部)

// parseStructType 関数内
func (p *gcParser) parseStructType() Type {
	var fields []*Field

	parseField := func() { // ここでクロージャが生成される
		fields = append(fields, p.parseField())
	}

	p.expectKeyword("struct")
	p.expect('{')
	if p.tok != '}' {
		parseField() // クロージャの呼び出し
		for p.tok == ';' {
			p.next()
			parseField() // クロージャの呼び出し
		}
	}
	p.expect('}')

	// ...
}

// parseParameters 関数内
func (p *gcParser) parseParameters() (list []*Var, isVariadic bool) {
	parseParameter := func() { // ここでクロージャが生成される
		par, variadic := p.parseParameter()
		list = append(list, par)
		if variadic {
			if isVariadic {
				p.error("can only use ... with final parameter")
			}
			isVariadic = true
		}
	}

	p.expect('(')
	if p.tok != ')' {
		parseParameter() // クロージャの呼び出し
		for p.tok == ',' {
			p.next()
			parseParameter() // クロージャの呼び出し
		}
	}
	p.expect(')')

	return
}

// parseInterfaceType 関数内
func (p *gcParser) parseInterfaceType() Type {
	var methods []*Method

	parseMethod := func() { // ここでクロージャが生成される
		name := p.parseName()
		typ := p.parseSignature()
		methods = append(methods, &Method{name, typ})
	}

	p.expectKeyword("interface")
	p.expect('{')
	if p.tok != '}' {
		parseMethod() // クロージャの呼び出し
		for p.tok == ';' {
			p.next()
			parseMethod() // クロージャの呼び出し
		}
	}
	p.expect('}')

	// ...
}

変更前は、parseField、parseParameter、parseMethodという匿名関数がそれぞれクロージャとして定義されていました。これらのクロージャは、外部スコープの変数（例: fields, list, methods）をキャプチャしていました。ループ内でこれらのクロージャが繰り返し呼び出されるたびに、クロージャの生成と実行に伴うオーバーヘッドが発生していました。特にARMのようなアーキテクチャでは、このオーバーヘッドが命令キャッシュのフラッシュを引き起こし、パフォーマンスに悪影響を与えていました。

変更後 (src/pkg/go/types/gcimporter.go の一部)

// parseStructType 関数内
func (p *gcParser) parseStructType() Type {
	var fields []*Field

	p.expectKeyword("struct")
	p.expect('{')
	for p.tok != '}' { // ループ構造の変更
		if len(fields) > 0 {
			p.expect(';')
		}
		fields = append(fields, p.parseField()) // クロージャを介さず直接呼び出し
	}
	p.expect('}')

	// ...
}

// parseParameters 関数内
func (p *gcParser) parseParameters() (list []*Var, isVariadic bool) {
	p.expect('(')
	for p.tok != ')' { // ループ構造の変更
		if len(list) > 0 {
			p.expect(',')
		}
		par, variadic := p.parseParameter() // クロージャを介さず直接呼び出し
		list = append(list, par)
		if variadic {
			if isVariadic {
				p.error("can only use ... with final parameter")
			}
			isVariadic = true
		}
	}
	p.expect(')')

	return
}

// parseInterfaceType 関数内
func (p *gcParser) parseInterfaceType() Type {
	var methods []*Method

	p.expectKeyword("interface")
	p.expect('{')
	for p.tok != '}' { // ループ構造の変更
		if len(methods) > 0 {
			p.expect(';')
		}
		name := p.parseName() // クロージャを介さず直接呼び出し
		typ := p.parseSignature() // クロージャを介さず直接呼び出し
		methods = append(methods, &Method{name, typ})
	}
	p.expect('}')

	// ...
}

変更後では、parseField、parseParameter、parseMethodといったクロージャの定義が完全に削除されました。代わりに、それらのクロージャが実行していたロジック（例: p.parseField()の呼び出しや、name、typの取得とmethodsへの追加）が、直接ループ内にインライン化されています。

これにより、クロージャの生成とそれに伴うメモリ割り当てや命令キャッシュフラッシュのオーバーヘッドがなくなりました。結果として、特にARM環境でのgcimporterのパフォーマンスが大幅に向上しました。コードの構造も、クロージャを介するよりも直接的で分かりやすくなっています。

関連リンク

参考にした情報源リンク

  • Go言語のクロージャに関する公式ドキュメントやチュートリアル
  • CPUキャッシュ、特に命令キャッシュとキャッシュフラッシュに関する一般的なコンピュータアーキテクチャの資料
  • ARMアーキテクチャにおけるパフォーマンス最適化に関する情報（特に命令キャッシュの扱いについて）
  • ODROID-Xに関する情報（コミットメッセージに記載されているベンチマーク環境）

[インデックス 14802] ファイルの概要

このコミットは、Go言語の型システムにおけるガベージコレクションインポーター（gcimporter）のパフォーマンス改善を目的としています。特に、Linux/ARMアーキテクチャ上でのクロージャ生成が引き起こす性能問題に対処するため、不要なクロージャの生成を削減しています。これにより、go test -shortの実行時間が大幅に短縮されました。

コミット

go/types: less closure creations in gcimporter.

Closures are incredibly expensive on linux/arm due to
repetitive flush of instruction cache.

go test -short on ODROID-X:

Before:
ok      exp/gotype      17.091s
ok      go/types        2.225s

After:
ok      exp/gotype      7.193s
ok      go/types        1.143s

R=dave, minux.ma, rsc
CC=golang-dev, remy
https://golang.org/cl/7062045

GitHub上でのコミットページへのリンク

https://github.com/golang/go/commit/0f545d9ab22034dffa468367d44aceb257e1048e

元コミット内容

go/types: less closure creations in gcimporter.

Closures are incredibly expensive on linux/arm due to
repetitive flush of instruction cache.

go test -short on ODROID-X:

Before:
ok      exp/gotype      17.091s
ok      go/types      2.225s

After:
ok      exp/gotype      7.193s
ok      go/types      1.143s

R=dave, minux.ma, rsc
CC=golang-dev, remy
https://golang.org/cl/7062045

変更の背景

この変更の主な背景は、Go言語のコンパイラおよび型チェッカーの一部であるgcimporterパッケージが、Linux/ARMアーキテクチャ上でパフォーマンス上のボトルネックを抱えていたことです。コミットメッセージによると、この問題は「クロージャの生成がLinux/ARM上で非常に高価である」ことに起因していました。具体的には、クロージャが生成されるたびに命令キャッシュの繰り返しフラッシュが発生し、これが性能低下を招いていました。

go test -shortの実行結果が示すように、変更前はexp/gotypeが17.091秒、go/typesが2.225秒かかっていたのに対し、変更後はそれぞれ7.193秒と1.143秒に短縮されており、特にexp/gotypeでは約58%の高速化が達成されています。これは、組み込みシステムや低消費電力デバイスで広く利用されるARMアーキテクチャにおけるGo言語の実行効率を向上させる上で重要な改善でした。

前提知識の解説

クロージャ (Closures)

クロージャとは、関数がその関数が定義された環境（レキシカルスコープ）を記憶し、その環境内の変数にアクセスできる機能を持つ関数のことです。Go言語では、関数内で別の関数を定義し、その内部関数が外部関数のローカル変数にアクセスする場合にクロージャが生成されます。

例えば、以下のようなGoのコードはクロージャの典型例です。

func adder() func(int) int {
    sum := 0
    return func(x int) int {
        sum += x
        return sum
    }
}

adder関数が返す匿名関数は、adderのスコープにあるsum変数にアクセスし続けることができます。

命令キャッシュ (Instruction Cache)

CPUは、プログラムの実行速度を向上させるために、頻繁にアクセスされる命令を高速なメモリ（キャッシュ）に一時的に保存します。これが命令キャッシュです。CPUが次に実行する命令を探す際、まず命令キャッシュをチェックし、そこに命令があればメインメモリにアクセスするよりもはるかに高速に命令を取得できます。

キャッシュフラッシュ (Cache Flush)

キャッシュフラッシュとは、キャッシュに保存されているデータを無効化し、メインメモリの内容と同期させる操作のことです。命令キャッシュの場合、プログラムが自己書き換えコードを生成したり、動的にコードをロードしたりする際に、キャッシュ内の命令が古くなる可能性があるため、キャッシュをフラッシュして最新の命令を読み込む必要があります。

Linux/ARMにおけるパフォーマンス問題

ARMアーキテクチャ、特に古い世代や特定の組み込みシステム向けのARMプロセッサでは、命令キャッシュのフラッシュ操作が比較的重い処理となることがあります。これは、キャッシュの構造やフラッシュメカニズムの実装に依存します。

Go言語のクロージャは、実行時に動的にコードを生成する場合があります（例えば、クロージャの環境ポインタを設定するためなど）。このような動的なコード生成は、命令キャッシュの整合性を保つためにキャッシュフラッシュを必要とすることがあります。もし、gcimporterが頻繁に小さなクロージャを生成していた場合、そのたびに命令キャッシュのフラッシュが繰り返され、特にフラッシュコストが高いARM環境では、これが顕著なパフォーマンス低下の要因となっていたと考えられます。

このコミットは、このようなARM特有のパフォーマンス特性を考慮し、クロージャの生成を最小限に抑えることで、命令キャッシュフラッシュの回数を減らし、全体的な実行速度を向上させることを目指しています。

技術的詳細

このコミットは、src/pkg/go/types/gcimporter.goファイル内の構文解析ロジックにおいて、不要なクロージャの生成を排除することでパフォーマンスを改善しています。具体的には、parseStructType、parseParameters、parseInterfaceTypeの各関数内で定義されていたローカルなヘルパー関数（parseField、parseParameter、parseMethod）がクロージャとして機能しており、これらが繰り返し呼び出されるたびにオーバーヘッドが発生していました。

変更前は、これらのヘルパー関数がそれぞれ独立したクロージャとして定義され、ループ内で呼び出されていました。クロージャは、その定義されたスコープの変数をキャプチャするため、実行時に追加のメモリ割り当てや、場合によっては命令キャッシュのフラッシュを伴うコード生成が必要になることがあります。特に、ループ内で頻繁に生成・呼び出しが行われると、そのコストが累積して大きなパフォーマンス低下につながります。

このコミットでは、これらのヘルパー関数をクロージャとして定義するのをやめ、そのロジックを直接呼び出し元のループ内にインライン化しています。これにより、クロージャの生成とそれに伴うオーバーヘッドが完全に排除されます。

例えば、parseStructType関数では、parseFieldというクロージャが定義され、構造体のフィールドを解析するためにループ内で呼び出されていました。変更後は、p.parseField()の呼び出しが直接ループ内で行われるようになり、parseFieldクロージャは不要になりました。同様の変更がparseParameters（parseParameterクロージャ）とparseInterfaceType（parseMethodクロージャ）にも適用されています。

この最適化は、コードの可読性をわずかに犠牲にするかもしれませんが、パフォーマンスがクリティカルな部分においては非常に効果的です。特に、gcimporterのようなコンパイラ関連のツールは、大量のコードを処理するため、このような小さな最適化の積み重ねが全体的なビルド時間や解析時間に大きな影響を与えます。

コアとなるコードの変更箇所

変更はsrc/pkg/go/types/gcimporter.goファイルに集中しています。

  1. parseStructType関数:

    • parseField := func() { ... } のクロージャ定義が削除されました。
    • クロージャの呼び出し箇所 parseField() が fields = append(fields, p.parseField()) に直接置き換えられました。
    • ループの条件が if p.tok != '}' から for p.tok != '}' に変更され、ループ内のロジックが簡素化されました。

  2. parseParameters関数:

    • parseParameter := func() { ... } のクロージャ定義が削除されました。
    • クロージャの呼び出し箇所 parseParameter() が par, variadic := p.parseParameter() と list = append(list, par) に直接置き換えられました。
    • ループの構造が変更され、より直接的な解析ロジックになりました。

  3. parseInterfaceType関数:

    • parseMethod := func() { ... } のクロージャ定義が削除されました。
    • クロージャの呼び出し箇所 parseMethod() が name := p.parseName()、typ := p.parseSignature()、methods = append(methods, &Method{name, typ}) に直接置き換えられました。
    • ループの構造が変更され、より直接的な解析ロジックになりました。

これらの変更により、合計で15行が追加され、30行が削除されています。

コアとなるコードの解説

変更前 (src/pkg/go/types/gcimporter.go の一部)

// parseStructType 関数内
func (p *gcParser) parseStructType() Type {
	var fields []*Field

	parseField := func() { // ここでクロージャが生成される
		fields = append(fields, p.parseField())
	}

	p.expectKeyword("struct")
	p.expect('{')
	if p.tok != '}' {
		parseField() // クロージャの呼び出し
		for p.tok == ';' {
			p.next()
			parseField() // クロージャの呼び出し
		}
	}
	p.expect('}')

	// ...
}

// parseParameters 関数内
func (p *gcParser) parseParameters() (list []*Var, isVariadic bool) {
	parseParameter := func() { // ここでクロージャが生成される
		par, variadic := p.parseParameter()
		list = append(list, par)
		if variadic {
			if isVariadic {
				p.error("can only use ... with final parameter")
			}
			isVariadic = true
		}
	}

	p.expect('(')
	if p.tok != ')' {
		parseParameter() // クロージャの呼び出し
		for p.tok == ',' {
			p.next()
			parseParameter() // クロージャの呼び出し
		}
	}
	p.expect(')')

	return
}

// parseInterfaceType 関数内
func (p *gcParser) parseInterfaceType() Type {
	var methods []*Method

	parseMethod := func() { // ここでクロージャが生成される
		name := p.parseName()
		typ := p.parseSignature()
		methods = append(methods, &Method{name, typ})
	}

	p.expectKeyword("interface")
	p.expect('{')
	if p.tok != '}' {
		parseMethod() // クロージャの呼び出し
		for p.tok == ';' {
			p.next()
			parseMethod() // クロージャの呼び出し
		}
	}
	p.expect('}')

	// ...
}

変更前は、parseField、parseParameter、parseMethodという匿名関数がそれぞれクロージャとして定義されていました。これらのクロージャは、外部スコープの変数（例: fields, list, methods）をキャプチャしていました。ループ内でこれらのクロージャが繰り返し呼び出されるたびに、クロージャの生成と実行に伴うオーバーヘッドが発生していました。特にARMのようなアーキテクチャでは、このオーバーヘッドが命令キャッシュのフラッシュを引き起こし、パフォーマンスに悪影響を与えていました。

変更後 (src/pkg/go/types/gcimporter.go の一部)

// parseStructType 関数内
func (p *gcParser) parseStructType() Type {
	var fields []*Field

	p.expectKeyword("struct")
	p.expect('{')
	for p.tok != '}' { // ループ構造の変更
		if len(fields) > 0 {
			p.expect(';')
		}
		fields = append(fields, p.parseField()) // クロージャを介さず直接呼び出し
	}
	p.expect('}')

	// ...
}

// parseParameters 関数内
func (p *gcParser) parseParameters() (list []*Var, isVariadic bool) {
	p.expect('(')
	for p.tok != ')' { // ループ構造の変更
		if len(list) > 0 {
			p.expect(',')
		}
		par, variadic := p.parseParameter() // クロージャを介さず直接呼び出し
		list = append(list, par)
		if variadic {
			if isVariadic {
				p.error("can only use ... with final parameter")
			}
			isVariadic = true
		}
	}
	p.expect(')')

	return
}

// parseInterfaceType 関数内
func (p *gcParser) parseInterfaceType() Type {
	var methods []*Method

	p.expectKeyword("interface")
	p.expect('{')
	for p.tok != '}' { // ループ構造の変更
		if len(methods) > 0 {
			p.expect(';')
		}
		name := p.parseName() // クロージャを介さず直接呼び出し
		typ := p.parseSignature() // クロージャを介さず直接呼び出し
		methods = append(methods, &Method{name, typ})
	}
	p.expect('}')

	// ...
}

変更後では、parseField、parseParameter、parseMethodといったクロージャの定義が完全に削除されました。代わりに、それらのクロージャが実行していたロジック（例: p.parseField()の呼び出しや、name、typの取得とmethodsへの追加）が、直接ループ内にインライン化されています。

これにより、クロージャの生成とそれに伴うメモリ割り当てや命令キャッシュフラッシュのオーバーヘッドがなくなりました。結果として、特にARM環境でのgcimporterのパフォーマンスが大幅に向上しました。コードの構造も、クロージャを介するよりも直接的で分かりやすくなっています。

関連リンク

参考にした情報源リンク

  • Go言語のクロージャに関する公式ドキュメントやチュートリアル
  • CPUキャッシュ、特に命令キャッシュとキャッシュフラッシュに関する一般的なコンピュータアーキテクチャの資料
  • ARMアーキテクチャにおけるパフォーマンス最適化に関する情報（特に命令キャッシュの扱いについて）
  • ODROID-Xに関する情報（コミットメッセージに記載されているベンチマーク環境）
  • Go closures on ARM processors primarily impact performance due to their implementation details rather than directly causing frequent instruction cache flushes. While instruction cache flushing is a critical consideration for dynamically generated code on ARM, it's not a direct or common consequence of using Go closures in typical application development.
  • Instruction cache flushing is primarily necessary when code is dynamically generated or modified at runtime (self-modifying code), such as in Just-In-Time (JIT) compilers. When new instructions are written to memory (which goes through the D-cache), the I-cache must be explicitly invalidated to ensure the CPU fetches the updated instructions.
  • The performance characteristics of Go closures on ARM are more closely related to the overhead of heap allocations and compiler optimization limitations rather than the direct cost of instruction cache flushes.

[インデックス 14802] ファイルの概要

このコミットは、Go言語の型システムにおけるガベージコレクションインポーター（gcimporter）のパフォーマンス改善を目的としています。特に、Linux/ARMアーキテクチャ上でのクロージャ生成が引き起こす性能問題に対処するため、不要なクロージャの生成を削減しています。これにより、go test -shortの実行時間が大幅に短縮されました。

コミット

go/types: less closure creations in gcimporter.

Closures are incredibly expensive on linux/arm due to
repetitive flush of instruction cache.

go test -short on ODROID-X:

Before:
ok      exp/gotype      17.091s
ok      go/types        2.225s

After:
ok      exp/gotype      7.193s
ok      go/types        1.143s

R=dave, minux.ma, rsc
CC=golang-dev, remy
https://golang.org/cl/7062045

GitHub上でのコミットページへのリンク

https://github.com/golang/go/commit/0f545d9ab22034dffa468367d44aceb257e1048e

元コミット内容

go/types: less closure creations in gcimporter.

Closures are incredibly expensive on linux/arm due to
repetitive flush of instruction cache.

go test -short on ODROID-X:

Before:
ok      exp/gotype      17.091s
ok      go/types        2.225s

After:
ok      exp/gotype      7.193s
ok      go/types        1.143s

R=dave, minux.ma, rsc
CC=golang-dev, remy
https://golang.org/cl/7062045

変更の背景

この変更の主な背景は、Go言語のコンパイラおよび型チェッカーの一部であるgcimporterパッケージが、Linux/ARMアーキテクチャ上でパフォーマンス上のボトルネックを抱えていたことです。コミットメッセージによると、この問題は「クロージャの生成がLinux/ARM上で非常に高価である」ことに起因していました。具体的には、クロージャが生成されるたびに命令キャッシュの繰り返しフラッシュが発生し、これが性能低下を招いていました。

go test -shortの実行結果が示すように、変更前はexp/gotypeが17.091秒、go/typesが2.225秒かかっていたのに対し、変更後はそれぞれ7.193秒と1.143秒に短縮されており、特にexp/gotypeでは約58%の高速化が達成されています。これは、組み込みシステムや低消費電力デバイスで広く利用されるARMアーキテクチャにおけるGo言語の実行効率を向上させる上で重要な改善でした。

前提知識の解説

クロージャ (Closures)

クロージャとは、関数がその関数が定義された環境（レキシカルスコープ）を記憶し、その環境内の変数にアクセスできる機能を持つ関数のことです。Go言語では、関数内で別の関数を定義し、その内部関数が外部関数のローカル変数にアクセスする場合にクロージャが生成されます。

例えば、以下のようなGoのコードはクロージャの典型例です。

func adder() func(int) int {
    sum := 0
    return func(x int) int {
        sum += x
        return sum
    }
}

adder関数が返す匿名関数は、adderのスコープにあるsum変数にアクセスし続けることができます。

命令キャッシュ (Instruction Cache)

CPUは、プログラムの実行速度を向上させるために、頻繁にアクセスされる命令を高速なメモリ（キャッシュ）に一時的に保存します。これが命令キャッシュです。CPUが次に実行する命令を探す際、まず命令キャッシュをチェックし、そこに命令があればメインメモリにアクセスするよりもはるかに高速に命令を取得できます。

キャッシュフラッシュ (Cache Flush)

キャッシュフラッシュとは、キャッシュに保存されているデータを無効化し、メインメモリの内容と同期させる操作のことです。命令キャッシュの場合、プログラムが自己書き換えコードを生成したり、動的にコードをロードしたりする際に、キャッシュ内の命令が古くなる可能性があるため、キャッシュをフラッシュして最新の命令を読み込む必要があります。

Linux/ARMにおけるパフォーマンス問題

ARMアーキテクチャ、特に古い世代や特定の組み込みシステム向けのARMプロセッサでは、命令キャッシュのフラッシュ操作が比較的重い処理となることがあります。これは、キャッシュの構造やフラッシュメカニズムの実装に依存します。

Go言語のクロージャは、その実装詳細により、パフォーマンスに影響を与える可能性があります。クロージャが周囲のスコープから変数をキャプチャする場合、これらの変数を参照するためにヒープ上に「クロージャオブジェクト」が作成されます。このヒープ割り当ては、メモリ使用量とガベージコレクションのオーバーヘッドを発生させ、通常の関数呼び出しと比較してパフォーマンスに影響を与える可能性があります。

コミットメッセージでは「repetitive flush of instruction cache」が問題として挙げられていますが、一般的なGo言語のクロージャの使用が直接的に頻繁な命令キャッシュフラッシュを引き起こすわけではありません。命令キャッシュフラッシュは主に、JITコンパイラのように実行時にコードが動的に生成または変更される（自己書き換えコード）場合に必要となります。Goはコンパイル言語であり、ユーザーが書いたコードは実行前に機械語に変換されます。Goのクロージャはコンパイラとランタイムによって処理され、その実行は、命令キャッシュの頻繁なフラッシュを必要とするような動的なコード生成を本質的に伴いません。

しかし、Goランタイム自体が内部的に動的なコード生成（例えば、リフレクションや特定の内部メカニズムのため）を行う可能性はあります。もしgcimporterが、クロージャの生成に関連して、このような命令キャッシュのフラッシュを誘発するような内部的な動的コード生成を頻繁に行っていた場合、それがARM環境でのパフォーマンス低下の要因となっていたと考えられます。このコミットは、このようなARM特有のパフォーマンス特性を考慮し、クロージャの生成を最小限に抑えることで、命令キャッシュフラッシュの回数を減らし、全体的な実行速度を向上させることを目指しています。

技術的詳細

このコミットは、src/pkg/go/types/gcimporter.goファイル内の構文解析ロジックにおいて、不要なクロージャの生成を排除することでパフォーマンスを改善しています。具体的には、parseStructType、parseParameters、parseInterfaceTypeの各関数内で定義されていたローカルなヘルパー関数（parseField、parseParameter、parseMethod）がクロージャとして機能しており、これらが繰り返し呼び出されるたびにオーバーヘッドが発生していました。

変更前は、これらのヘルパー関数がそれぞれ独立したクロージャとして定義され、ループ内で呼び出されていました。クロージャは、その定義されたスコープの変数をキャプチャするため、実行時に追加のメモリ割り当てや、場合によっては命令キャッシュのフラッシュを伴うコード生成が必要になることがあります。特に、ループ内で頻繁に生成・呼び出しが行われると、そのコストが累積して大きなパフォーマンス低下につながります。

このコミットでは、これらのヘルパー関数をクロージャとして定義するのをやめ、そのロジックを直接呼び出し元のループ内にインライン化しています。これにより、クロージャの生成とそれに伴うオーバーヘッドが完全に排除されます。

例えば、parseStructType関数では、parseFieldというクロージャが定義され、構造体のフィールドを解析するためにループ内で呼び出されていました。変更後は、p.parseField()の呼び出しが直接ループ内で行われるようになり、parseFieldクロージャは不要になりました。同様の変更がparseParameters（parseParameterクロージャ）とparseInterfaceType（parseMethodクロージャ）にも適用されています。

この最適化は、コードの可読性をわずかに犠牲にするかもしれませんが、パフォーマンスがクリティカルな部分においては非常に効果的です。特に、gcimporterのようなコンパイラ関連のツールは、大量のコードを処理するため、このような小さな最適化の積み重ねが全体的なビルド時間や解析時間に大きな影響を与えます。

コアとなるコードの変更箇所

変更はsrc/pkg/go/types/gcimporter.goファイルに集中しています。

  1. parseStructType関数:

    • parseField := func() { ... } のクロージャ定義が削除されました。
    • クロージャの呼び出し箇所 parseField() が fields = append(fields, p.parseField()) に直接置き換えられました。
    • ループの条件が if p.tok != '}' から for p.tok != '}' に変更され、ループ内のロジックが簡素化されました。

  2. parseParameters関数:

    • parseParameter := func() { ... } のクロージャ定義が削除されました。
    • クロージャの呼び出し箇所 parseParameter() が par, variadic := p.parseParameter() と list = append(list, par) に直接置き換えられました。
    • ループの構造が変更され、より直接的な解析ロジックになりました。

  3. parseInterfaceType関数:

    • parseMethod := func() { ... } のクロージャ定義が削除されました。
    • クロージャの呼び出し箇所 parseMethod() が name := p.parseName()、typ := p.parseSignature()、methods = append(methods, &Method{name, typ}) に直接置き換えられました。
    • ループの構造が変更され、より直接的な解析ロジックになりました。

これらの変更により、合計で15行が追加され、30行が削除されています。

コアとなるコードの解説

変更前 (src/pkg/go/types/gcimporter.go の一部)

// parseStructType 関数内
func (p *gcParser) parseStructType() Type {
	var fields []*Field

	parseField := func() { // ここでクロージャが生成される
		fields = append(fields, p.parseField())
	}

	p.expectKeyword("struct")
	p.expect('{')
	if p.tok != '}' {
		parseField() // クロージャの呼び出し
		for p.tok == ';' {
			p.next()
			parseField() // クロージャの呼び出し
		}
	}
	p.expect('}')

	// ...
}

// parseParameters 関数内
func (p *gcParser) parseParameters() (list []*Var, isVariadic bool) {
	parseParameter := func() { // ここでクロージャが生成される
		par, variadic := p.parseParameter()
		list = append(list, par)
		if variadic {
			if isVariadic {
				p.error("can only use ... with final parameter")
			}
			isVariadic = true
		}
	}

	p.expect('(')
	if p.tok != ')' {
		parseParameter() // クロージャの呼び出し
		for p.tok == ',' {
			p.next()
			parseParameter() // クロージャの呼び出し
		}
	}
	p.expect(')')

	return
}

// parseInterfaceType 関数内
func (p *gcParser) parseInterfaceType() Type {
	var methods []*Method

	parseMethod := func() { // ここでクロージャが生成される
		name := p.parseName()
		typ := p.parseSignature()
		methods = append(methods, &Method{name, typ})
	}

	p.expectKeyword("interface")
	p.expect('{')
	if p.tok != '}' {
		parseMethod() // クロージャの呼び出し
		for p.tok == ';' {
			p.next()
			parseMethod() // クロージャの呼び出し
		}
		// ...
	}
	p.expect('}')

	// ...
}

変更前は、parseField、parseParameter、parseMethodという匿名関数がそれぞれクロージャとして定義されていました。これらのクロージャは、外部スコープの変数（例: fields, list, methods）をキャプチャしていました。ループ内でこれらのクロージャが繰り返し呼び出されるたびに、クロージャの生成と実行に伴うオーバーヘッドが発生していました。特にARMのようなアーキテクチャでは、このオーバーヘッドが命令キャッシュのフラッシュを引き起こし、パフォーマンスに悪影響を与えていました。

変更後 (src/pkg/go/types/gcimporter.go の一部)

// parseStructType 関数内
func (p *gcParser) parseStructType() Type {
	var fields []*Field

	p.expectKeyword("struct")
	p.expect('{')
	for p.tok != '}' { // ループ構造の変更
		if len(fields) > 0 {
			p.expect(';')
		}
		fields = append(fields, p.parseField()) // クロージャを介さず直接呼び出し
	}
	p.expect('}')

	// ...
}

// parseParameters 関数内
func (p *gcParser) parseParameters() (list []*Var, isVariadic bool) {
	p.expect('(')
	for p.tok != ')' { // ループ構造の変更
		if len(list) > 0 {
			p.expect(',')
		}
		par, variadic := p.parseParameter() // クロージャを介さず直接呼び出し
		list = append(list, par)
		if variadic {
			if isVariadic {
				p.error("can only use ... with final parameter")
			}
			isVariadic = true
		}
	}
	p.expect(')')

	return
}

// parseInterfaceType 関数内
func (p *gcParser) parseInterfaceType() Type {
	var methods []*Method

	p.expectKeyword("interface")
	p.expect('{')
	for p.tok != '}' { // ループ構造の変更
		if len(methods) > 0 {
			p.expect(';')
		}
		name := p.parseName() // クロージャを介さず直接呼び出し
		typ := p.parseSignature() // クロージャを介さず直接呼び出し
		methods = append(methods, &Method{name, typ})
	}
	p.expect('}')

	// ...
}

変更後では、parseField、parseParameter、parseMethodといったクロージャの定義が完全に削除されました。代わりに、それらのクロージャが実行していたロジック（例: p.parseField()の呼び出しや、name、typの取得とmethodsへの追加）が、直接ループ内にインライン化されています。

これにより、クロージャの生成とそれに伴うメモリ割り当てや命令キャッシュフラッシュのオーバーヘッドがなくなりました。結果として、特にARM環境でのgcimporterのパフォーマンスが大幅に向上しました。コードの構造も、クロージャを介するよりも直接的で分かりやすくなっています。

関連リンク

参考にした情報源リンク

  • Go言語のクロージャに関する公式ドキュメントやチュートリアル
  • CPUキャッシュ、特に命令キャッシュとキャッシュフラッシュに関する一般的なコンピュータアーキテクチャの資料
  • ARMアーキテクチャにおけるパフォーマンス最適化に関する情報（特に命令キャッシュの扱いについて）
  • ODROID-Xに関する情報（コミットメッセージに記載されているベンチマーク環境）
  • Go closures on ARM processors primarily impact performance due to their implementation details rather than directly causing frequent instruction cache flushes. While instruction cache flushing is a critical consideration for dynamically generated code on ARM, it's not a direct or common consequence of using Go closures in typical application development.
  • Instruction cache flushing is primarily necessary when code is dynamically generated or modified at runtime (self-modifying code), such as in Just-In-Time (JIT) compilers. When new instructions are written to memory (which goes through the D-cache), the I-cache must be explicitly invalidated to ensure the CPU fetches the updated instructions.
  • The performance characteristics of Go closures on ARM are more closely related to the overhead of heap allocations and compiler optimization limitations rather than the direct cost of instruction cache flushes.