Re: [sisyphus] Re: arch-optimization

[Led <led@ukr-fin.com.ua>]

В сообщении от Вторник 06 Июль 2004 16:05 Yuri N. Sedunov написал(a):
> On Вторник 06 Июль 2004 16:50, Led wrote:
> > В сообщении от Вторник 06 Июль 2004 15:39 Yuri N. Sedunov написал(a):
> > > On Вторник 06 Июль 2004 16:25, Led wrote:
> > >
> > > Отвечайте в список, пожалуйста.
> > >
> > > > В сообщении от Вторник 06 Июль 2004 15:15 вы написали:
> > > > > On Вторник 06 Июль 2004 15:58, Led wrote:
> > > > > <skip>
> > > > >
> > > > > > > Так я и не спрашиваю про i586.
> > > > > > > Интересно, какова у Вас будет скорость кодирования, если просто
> > > > > > > пересобрать пакет c оригинальным спеком под i686.
> > > > > > > То есть не добавляя ваших:
> > > > > > > %define _optlevel 3
> > > > > > > %define optflags %optflags_default -march=pentium4
> > > > > > > -mcpu=pentium4 -mmmx -msse -msse2
> > > > > >
> > > > > > Cудя по fps - такая же получается...
> > > > >
> > > > > Вот, теперь Вы можете переформулировать ваше начальное предложение.
> > > >
> > > > Предложение остаётся таким же: неплохобы иметь для некоторых пакетов
> > > > что-то кроме i586.
> > > >
> > > > > Кстати,  Sisyphus/i686/RPMS/ у нас есть. Что туда положить, кроме
> > > > > xvid?
> > > >
> > > > MPlayer, gcc, libxine, gimp, libogg, libvorbis, libtheora, lame
> > > > (?)... Это навскидку - может в чём и ошибся...
> > >
> > > Возьметесь пересобрать, протестировать?
> >
> > Зачем? Нужны просто спеки для сборки под разные архитектуры (rpm
> > предусматривает нужный вариант набора флажков при указании --target).
> > Ну и хотелось бы поддержку в rpm архитектур pentium3, pentium4,
> > athlonxp... Сколько лет-то уже архитектуре i686?
>
> Давайте исходить из существующего положения вещей. Мы с Вами рассмотрели на
> примере xvid, что никакая правка спека не требуется. Ваша попытка
> соптимизировать сборку для pentium4 не дала сколь-нибудь ощутимого выйгрыша
> в производительности по сравнению с i686.
Моя попытка показала, что оптимизированный c-код на примере xvid на 30% 
быстрее, естетсвенно, что на ассемблерный код эта оптимизация не повлияет. Но 
во всех ли подобных вычислительных софтинах есть ассемблерная оптимизация?

> Очевидно, что найдется еще немало 
> пакетов, пересборка которых под i686, athlon даст достаточный, предельный
> прирост производительности.
Согласен, таких пакетов немного. Но под pentium4 в спеке можно было бы 
включать sse2, pentium3 - sse, athlonxp - sse, 3dnow, 3dnowex

>
> Например, упомянутый Вами gimp
> [aris@siver gimp2-2.0.2]$ ./configure --help|grep "\-mmx\|\-sse\|\-mp"
>   --enable-mmx            enable MMX support (default=auto)
>   --enable-sse            enable SSE support (default=auto)
>   --enable-mp             support multiple processors (default=no)
>
> Как насчет gimp-smp?

Не знаю как в gimp, но в MPlayer, например, аналог default=auto (autodetect) 
срабатывает на этапе компиляции, mplayer c --disable-runtime-cpudetection 
потребляет ресурсов раза в 3 меньше, mencoder тоже экономит значительный 
процент (если я смотрю фильм, а в фоне что-то компилируется/кодируется, то 
выиграш пару часов на 10-часовой процессе - это не так уж и плохо ИМХО). Так 
что указание конкретного --target (а не абстрактного i686) даёт существенную 
прибавку во времени в дальнейшем (опять же - для НЕКОТОРЫХ программ).
Просто мне кажется не всегда целесообразно использовать P4 или AthlonXP как 
высокочастотный Pentium - если я уж купил этот процессор, то хотелось бы 
использовать его по максимуму (со всеми инструкциями) - хотя бы В НЕКОТОРЫХ 
СЛУЧАЯХ (которые, тем не менее, могут занимать значительное время).

Мне почему-то кажется, что тот, кто реально постоянно пользуется таким софтом 
("архитектурнозависимым"), всё равно пересобирают его под своё железо - 
попробовал на себе, оказалось "лучше полдня потерять, зато потом за 5 минут 
долететь"). А та же сборка/пересборка KDE, openoffice? Даже 5%-ая экономия 
времени благодаря оптимизированному под процессор gcc - уже существенно.

Я не собираюсь навязывать своё мнение - для себя я всё решил и делаю как мне 
удобнее/быстрее/выгоднее. Не собираюсь "толкать свою единственно правильную 
политику" - просто высказал мнение:
1) неплохо бы иметь еще несколько "архитектур" в rpm;
2) неплохо бы иметь более гибкие спеки (использующие эти архитектуры при 
указании --target) в сизифе для софта, который от этого реально выигрывает в 
производительности.

Led.