Re: [devel] Оптимизированные для i686 и выше библиотеки.

[Alexey Tourbin <at@altlinux.ru>]

On Fri, Sep 03, 2010 at 08:24:31PM +0300, Alexander Bokovoy wrote:
> 2010/9/3 Alexey Tourbin <at@altlinux.ru>:
> > Я и говорю, давайте покажем, чего мы добиваемся.  А то понимаешь развели
> > тут тред, оптимизированные для i686 библиотеки.  Можно подумать за это
> > на премию можно выдвинуть.  Пробуешь разобраться, спрашиваешь людей,
> > сколько у вас процентов вышло?  Люди подозрительно молчат, mike спрашивает
> > "тебе жалко что ли"?  thresh хотя бы честно замерил и написал, что там
> > выходит около одного процента в лучше случае (а на атомах - меньше).
> > Мне не жалко, но просто страдать по этому поводу я не собираюсь - нет смысла.
> В MeeGo долго энтузиасты пытались убедить товарищей из Интела, что
> нужно поддерживать что-нибудь, не поддерживающее SSSE3 (ниже
> Core2Duo). Интел, понятное дело, гнет свою палку. Phoronix в мае делал
> сравнение четырех дистрибутивов на нетбуке, для меня единственным
> значимым различием было почти четырехкратное ускорение загрузки
> дистрибутива по сравнению с Fedora 13 (8 секунд против 23), но это

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

> скорее заслуга btrf и меньшего количества сервисов, чем аппаратного
> ускорения. Сравнение делалось на одном и том же нетбуке.
> http://www.phoronix.com/scan.php?page=article&item=meego_10_perf&num=1

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

> Однако тут важным моментом будет наличие грамотно векторизующего
> компилятора. Интеловский компилятор в среднем позволяет отбить 13-15%
> при соблюдении ряда специальных манипуляций с кодом (прагмы и проч.),
> вырастая и в два-три раза при удачных случаях. Но некоторые из этих

Отбить 13% я ещё готов поверить, но в 2-3 раза?
Это чо-то какой-то загон очень большой.

> оптимизаций были добавлены только в GCC 4.5 и все равно они уступают
> интеловскому компилятору. А ручной оптимизации уступает все подряд.
> 
> Это я к тому, что поднимать планку базовой платформы, конечно, можно,
> но я бы лучше сконцентрироваться на нахождении неоптимизированных
> фрагментов кода и их исправлять. А уж потом и вручную оптимизировать
> для конкретной микроархитектуры.
> 
> Сегодня коллега ускорил в три с половиной раза собственный код:
> http://maemo.gitorious.org/meego-image-editor/libquill/commit/aba7db8a8fcb8474d9107dcd9e142f18d07b51bf,
> как можно увидеть, никакими аппаратными оптимизациями там и не пахнет.
> Это при том, что и так чтение thumbnail было в рамках приличия.

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

> Практика показывает, что верить в "у нас тут код вручную оптимизирован
> под SSE" на x86 микроархитектурах становится крайне неблагодарным
> занятием. Микроархитектуры плывут по поддерживаемому функционалу и
> особенности их реализации иногда убивают все прошлые оптимизационные
> заслуги.
> 
> -- 
> / Alexander Bokovoy