> Может там конкретно Питон и SQLite хорошо ускоряются.

от пересборки с волшебными ключами? Не смеши мои тапочки. Это только у фантазеров с похороникса, не способных банально чистый тест провести, обязательно надо сравнивать яблоки с ящиками.

там погрешность на уровне точности измерений будет. А если будут хотя бы те стабильные 3% - надо пойти и исправить баг в исходнике.

Чтобы какой-нибудь avx обеспечил ускорение - тебе надо сперва код для него написать. Да, сишный/плюсовый - но именно под avx оптимизатор (выглядит, кстати, дико, и без оптимизатора даст замедление, в разы).

>> уп-с, не работает - патч не приложился/при сборке вылезли ньюансы
> Я когда делаю репозиторий для бинарного дистрибутива, там тоже такое бывает

такого не бывает только у фантазера-гентуфанбоя, с руками-не-из-сфинктера, а у простых смертных сборка, для которой понадобилось не один --with-... поменять, а что-то на самом деле патчить, обычно протекает методом проб и ошибок, и итераций там бывает много (особенно обидно - когда пара из них - из-за ошибок в spec/ debian/rules и мы еще подождем, пока оно пересоберется, теперь прав...мммать, вот тут еще надо было... - при том что готовый бинарник уже вот, лежал)

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

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

Для emerge мне подобный простой обходной путь неизвестен.

Зато вон прекрасная инструкция прямо по второй ссылке из новости - ebuild foo-1.2-r3.ebuild manifest  после смены флажка архитектуры.
Это тебе придется делать _на_каждой_ системе. Удобно, чо.