Источник самой большой оптимизации машинного кода

Нет простого и короткого ответа.

1.

Существует множество параметров, таких как размер кэша / конвейера кода, разница между скоростью кеширования и скоростью основной памяти, размер кода с «-Os» против «-O2», «-O3», размер кода с использованием некоторого общего «march = X / mtune = Y "настройки vs" = родной ".

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

Если в кэш помещается больше кода, в кеш помещается больше кода различных выполняющихся параллельно задач, это тоже может быть желательным аспектом ...

Это займет много исследований, чтобы дать исчерпывающий ответ.

2.

Использование разных флагов и параметров компилятора может вызвать различные ошибки и неправильное поведение.

Таким образом, перекомпиляция центральной части, такой как libc, или даже всего дистрибутива сделает ваши отчеты об ошибках непригодными для других, они просто не смогут легко воспроизвести ваши проблемы. Ваша установка превращается в одинокий остров ...

3.

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

4.

И, вероятно, выигрыш в скорости не стоит недель перекомпиляции (если оптимизируется не только libc) и отключения от мейнстрима.

...

Если вам нужно решить проблемы со скоростью, более быстрая система, вероятно, будет эффективным решением.

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

Некоторые программы могут принести больше пользы, чем другие. Особенно сложные математические программы, такие как fold @ home или аналогичные, майнинг криптовалюты, шифрование, кодирование мультимедиа. Это также поможет в декодировании мультимедиа, но самые важные вещи, такие как MMX, AVX и подобные, будут скомпилированы независимо от вашего -march , поэтому, вероятно, вы не заметите разницы при просмотре фильмов. С другой стороны, звук в реальном времени (например, JACK) может принести пользу, поскольку наименьшие задержки влияют на качество звука. Они также менее важны для быстрого обновления в случае обнаружения уязвимости по сравнению с базовыми библиотеками, такими как libc, поскольку вы просто не можете использовать их, пока не обновите.

Если вам интересно, попробуйте дистрибутив на основе исходного кода , где все будет скомпилировано с выбранными вами флагами. Код компилируется очень быстро на современных процессорах, поэтому это не так болезненно, как раньше.Gentoo - самый используемый из них.

Помимо этого, вы можете поиграть с множеством параметров, которые могут повлиять на производительность больше, чем исходный код -march через файловую систему / sys. Например, / sys / block / sd? / Queue / содержит настройки планировщика, которые могут сильно повлиять на общую производительность. Я переключился с CFQ на дедлайн, и это заметно улучшило интерактивную производительность при моей конкретной рабочей нагрузке. Надо сказать, что в CFQ есть целый набор настроек, которые я тоже мог бы настроить по своему вкусу.

Еще одна «сокровищница» - это / proc / sys / . Например, настройте / proc / sys / vm / swappiness , чтобы изменить скорость освобождения памяти при перемещении старых файлов в раздел подкачки. В Red Hat есть отличное руководство по параметрам.

РЕДАКТИРОВАТЬ: добавлена ​​пара примеров программ, которые с большей вероятностью получат выгоду от -march