У меня есть функция, для которой я хотел бы предоставить реализацию сборки для архитектуры amd64.Для обсуждения давайте просто предположим, что это функция Add, но на самом деле она сложнее, чем эта.У меня работает сборочная версия, но мой вопрос касается правильного отображения godoc.У меня такое ощущение, что на данный момент это невозможно, но я хотел обратиться за советом.
Еще несколько деталей:
- Реализация сборки этой функции содержит только несколько инструкций.В частности, простая стоимость вызова функции составляет значительную часть всей стоимости.
- В ней используются специальные инструкции (
BMI2), поэтому ее можно использовать только после проверки способности CPUID.
Реализация структурирована так: .На высоком уровне:
- В общем (не
amd64 случае) функция определяется путем делегирования addGeneric. - В
amd64 случае функцияна самом деле это переменная, изначально установленная на addGeneric, но замененная на addAsm в функции init, если проходит проверка cpuid.
Этот подход работает.Однако вывод godoc является дрянным, потому что в случае amd64 функция на самом деле является переменной.Обратите внимание, что godoc собирает те же теги сборки, что и машина, на которой он работает.Я не уверен, что godoc.org сделает.
Рассмотрены альтернативы:
- Функция
Add делегирует addImpl.Затем мы используем аналогичный трюк, чтобы заменить addImpl в случае amd64.Проблема с этим заключается в том, что (в моих экспериментах) Go не может встроить вызов, и теперь сборка заключена в два вызова функций.Поскольку сборка уже настолько мала, это оказывает заметное влияние на производительность. - В случае
amd64 мы определяем простую функцию Add с проверкой useAsm внутри и вызывающую одну из addGeneric и addAsm в зависимости от результата.Это может иметь еще худшее влияние на производительность.
Так что я думаю, что вопросы:
- Есть ли лучший способ структурировать код для достижения желаемой производительностии правильно ли он указан в документации.
- Если альтернативы нет, есть ли другой способ «обмануть» годока?