Почему метод дженерик типа в го существенно медленнее нативного?

Question

[Илья]

Ведь по заявлению разработчиков дженерики собираются в отдельные типы на стадии компиляции, а не в рантайме.
Результат работы бенчмарков выдает либо не оптимизированную реализацию, либо жесткий баг, либо я не правильно понял слова разработчиков.
Демонстрирую на игрушечном примере функции, суть которой проста:

func sumincr(arr []float64, incr float64) (sum float64) {
	for _, x := range arr {
		sum += x + incr
	}
	return sum
}

Код бенчей в песочнице по причинам объёма
https://go.dev/play/p/3wYzYzsIT_8
Результаты: go test -bench=. -count=2

goos: windows
goarch: amd64
pkg: github.com/ogau/evo/bugtesting
cpu: AMD Ryzen 3 PRO 2200G with Radeon Vega Graphics
BenchmarkNativeFunc-4            4113319               298.7 ns/op
BenchmarkNativeFunc-4            3958936               295.3 ns/op
BenchmarkNativeMethod-4          4124042               290.2 ns/op
BenchmarkNativeMethod-4          3952284               295.9 ns/op
BenchmarkGenericFunc-4           2836564               409.9 ns/op
BenchmarkGenericFunc-4           2877542               423.8 ns/op
BenchmarkGenericMethod-4          443005              2628 ns/op
BenchmarkGenericMethod-4          399085              2555 ns/op

Несложно посчитать, что функция полностью использующая механизм обобщения с методом типа расходует в ~8.5 раз больше процессорного времени.
Кстати, что меня при тестах случайно поразило - если поменять порядок проведения бенчмарков, то результаты становятся непредсказуемыми (перепроверено много раз):

goos: windows
goarch: amd64
pkg: github.com/ogau/evo/bugtesting
cpu: AMD Ryzen 3 PRO 2200G with Radeon Vega Graphics
BenchmarkGenericMethod-4          476750              2654 ns/op
BenchmarkGenericMethod-4          427164              2593 ns/op
BenchmarkNativeFunc-4            2104059               571.9 ns/op
BenchmarkNativeFunc-4            2003337               565.6 ns/op
BenchmarkNativeMethod-4          2121109               579.8 ns/op
BenchmarkNativeMethod-4          2095996               575.0 ns/op
BenchmarkGenericFunc-4           2091612               574.3 ns/op
BenchmarkGenericFunc-4           2085957               574.6 ns/op

Вопрос продублирую на StackOverflow, ссылку прикреплю позже.
UPD: https://stackoverflow.com/questions/71649364/why-i...

Comments

[Илья]

там англосаксы в комментах говорят что этот вопрос не относится к программированию и его не нужно было задавать на SO. Это что за прикол, мне нужно напрямую разработчикам писать?

Answer 1

[Илья]

Из обсуждения https://github.com/golang/go/issues/50182 видно что проблема с производительностью generics не новая.
При запуске бенчмарков с флагами получается ожидаемое мной ± равное время выполнения ф-ций:
go test -bench=. -count=2 -gcflags=all=-d=unified

BenchmarkNativeFunc-4            2029149               600.5 ns/op
BenchmarkNativeFunc-4            2018277               591.7 ns/op
BenchmarkNativeMethod-4          1962086               592.0 ns/op
BenchmarkNativeMethod-4          2024234               603.9 ns/op
BenchmarkGenericFunc-4           1985313               573.4 ns/op
BenchmarkGenericFunc-4           2053454               585.1 ns/op
BenchmarkGenericMethod-4         2067790               591.3 ns/op
BenchmarkGenericMethod-4         2054346               612.2 ns/op

что форсирует применение при компиляции stenciling (трафарет по отдельным типам) вместо словарного подхода реализации дженериков (текущая реализация).
Остаётся ждать оптимизаций в обновлениях языка

Answer 2

[Andrey Tsvetkov]

Полагаю, что проблема с реализацией. Нет желания искать в ваших функциях кто прав, кто виноват. давайте так, вы пишите две реализации одного и тоже действия, но одно дженерики, другое по старинке. После напишите бенчмарк к этим двум функциям.

Судя по результатам бенчмарков, результаты с дженериками потребляют сильно больше памяти, причина 100% в этом

Comments

[Илья]

По референсной ф-ции уже можно понять, что основное взаимодействие с памятью - это ридонли доступ к элементам слайса, не более. Пример максимально синтетический и простой. Хотя я уже понял что ответить на подобных вопросниках некому. Нужно стучать в двери разработчикам компиляторов...

[Andrey Tsvetkov]

Да нет же, говорю вам, памяти расходуется больше, а значит тест не честный

[Andrey Tsvetkov]

Хотя стоп, это же не память. Запустите тесты с флагом -benchmem
Подозреваю, что у вас там где-то лишние преобразования к интерфейсу

[Илья]

Andrey Tsvetkov, Я лишний раз проверил и как ожидалось ноль выделений на всех бенчмарках. Приведение интерфейса к типу работает в случае чистого интерфейса, что не равно параметризованному интерфейсу. Так действительно может показаться, но отсюда и мой вопрос. Я надеялся, что все легковесные функции оптимизируются компилятором и будут переведены в inline. Хотя так и есть в assembly, но накладные расходы всё равно велики. Тут внутренняя реализация языка должна объяснить в чём дело. У меня к сожалению таких навыков нет (

[Andrey Tsvetkov]

Действительно. Проблема есть. Запустил бенчмарки с отключением инлайнинга и все результаты +/- одинаковы. Escape analysis утверждает, что функция sumincr_generic_method инлайнится, но по факту это не так. Забавно получается. Надо писать багрепорт разработчикам

[Василий Банников]

Andrey Tsvetkov, что на счёт листинга? Какой там ассемблер генерится?