Go Wiki: AssemblyPolicy

このドキュメントでは、Go の暗号パッケージにアセンブリコードを追加する時期と方法について説明します。

一般的なルールは次のとおりです。

• アセンブリではなく、ポータブルな Go を優先します。アセンブリのコードは、N 個のパッケージではなく、(N 個のパッケージ * M 個のアーキテクチャ) を維持することを意味します。
• アセンブリの使用を最小限に抑えます。55% の速度向上に 2 倍のアセンブリを使用するよりも、50% の速度向上に少量のアセンブリを使用することを望みます。コミットメッセージでアセンブリ/Go の境界をどこに設定したかの決定を説明し、ベンチマークで裏付けます。
• スタンドアロンの Go プログラム、または avo のような go get 可能なプログラムのいずれかを使用して、自明でない量のアセンブリを生成するには、より高レベルのプログラムを使用します。その他の再現可能なプロセス (形式的に検証されたコードジェネレーターなど) の出力も考慮されます。実装戦略については、事前に課題トラッカーで議論してください。
• Go で記述された高レベルロジックから呼び出される、小さく、テスト可能なユニット (25 ～ 75 行) を使用します。Go で記述されたロジックから呼び出される小さく、テスト可能な関数が遅すぎる場合は、Go と互換性のあるラッパーを持つ小さく、テスト可能なアセンブリユニットを使用し、Go テストが個々のユニットをテストできるようにします。
• すべてのアセンブリ関数には、アセンブリと並行してテストされる参照 Go 実装が必要です。TargetSpecific に従って構造とテストのプラクティスを行います。
• プラットフォームが根本的に異なる機能 (高レベルの暗号化命令など) を持たない限り、アセンブリユニットと参照 Go 実装のインターフェースはアーキテクチャ間で同じでなければなりません。
• Go セキュリティチームが明示的に特定の implemention の所有を約束しない限り、外部の貢献者がその維持を約束する必要があります。変更が必要な場合 (たとえば、より広範なリファクタリングの一部として) で、メンテナーが利用できない場合、アセンブリは削除されます。
• コードは CI でテストする必要があります。つまり、命令をサポートするビルダーが必要であり、複数の (またはフォールバック) パスがある場合は、それらを個別にテストする必要があります。(ヒント: CPU 機能の検出を無効にするには GODEBUG=cpu.X=off を使用します。)
• コンパイラの改善に伴い再評価できるように、実装がアセンブリを必要とする理由 (特定のパフォーマンス上の利点、命令へのアクセスなど) を Go コードに文書化します。

現在標準ライブラリにあるすべてのアセンブリがこのポリシーに準拠しているわけではありません。既存のアセンブリの変更は、その実装が準拠するように更新されるまで推奨されません。新しいアセンブリは準拠している必要があります。