Почему бенчмарки гоняют на маках везде? я сервера не на

маках держу, а разница на epyc-е каком-нибудь может быть в другую сторону

там есть бенчмарки на Ryzen 5 3600 и i7 3930k если у вас есть возможность запустить на условном Epyc или Xeon то с радостью приму 🙂

я на ржавом себе когда парсер выбирал - гонял тесты на целевом железе на aws в 4-5 долларов уложился :)

в любом случае с удовольствием приму результаты на другом железе) но в целом глобальной разницы быть не должно

у меня были прям кардинально разные, но это специфично для моего случая, возможно

тут в целом идёт оптимизация на instruction-level parallelism, сокращение branch misprediction до минимума и удаление всего возможного жира включая минимизацию вызова функций

закинул пр с результатами бенча на 2 х E5-2667 v2

спасибо! как и предполагалось, соотношения практически не отличаются. я конечно не могу убедиться что бенчмарк был проведён корректно (потенциальные источники шумов были исключены до максимуму, throttling'а не было, и т.д.)

маки априори так себе платформа для бенчмарков

ну, пока сервера на армах не распространены - да я об этом и написал

дело не столько в арме

А кто то запускает софт на bare metal и результаты тестов на условном aws им ничего не дадут

А можно не брать и на одном железе сравнить библиотеки, чтобы увидеть разницу )

но мы-то про разное железо

osx очень много иногда документированной магии имеет внутри - например на М1 тот же шедулер имеет свою логику раскидывания задач по ядрам, на которую невозможно повлиять и которая может вызывать много приколов если вдруг у тебя нагрузка стала странной. То есть есть задачи когда 4 потока казалось бы идеально распаралеливающегося кода (где каждый тред не зависит от работы соседа) могут оказаться быстрее чем 8 (на М1, точнее быстрее чем 5, 6, 7 и скорее всего 8). И логика этого всего меняется от версии ОС (в 12-ой макоси поведение было чуть другим чем в 13-ой)

а зачем, если мы получим де-факто лишь разные циферки, соотношение останется примерно прежним

тем более

ну окей, это верно лишь в рамках го. В рамках нормальных языков с нормальными оптимизаторами и -march=native флагом, могут всплыть новые детали, связанные со специфичными инструкциями, недоступными ранее

это все о том, что бенчмарки проводить сложно и можно случайно получить мусор в качестве результата, если ты случайно сделал что-то не то. Другой пример - в osx есть системный blas, который на самом деле интерфейс к Accelerate Framework’у везде, где это возможно. И если цель побенчмаркать только процессор - можно на этом погореть и получить странные результаты. Притом на всем коде, что линкуется с blas’ом.

Надо еще помнить, что native не определяет ничего, он использует захардкоженные авторами компилятора списки поддерживаемого, размеры кэшей и прочего. Если там ошибка - тоже будет плохо. Или если компилятор ничего не знает о процессоре.

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

Ну корнер кейс или нет, а Zen 4 появился только в gcc 13.1, который вышел в апреле. А вот процессор вышел в сентябре прошлого года. И все это время тюнить надо было вручную хотя бы по набору инструкций. А так еще нужно правильно расставлять цену каких-то инструкций.