From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Led To: ALT Linux Sisyphus discussion list Subject: Re: [sisyphus] Re: arch-optimization Date: Tue, 6 Jul 2004 17:39:48 +0300 User-Agent: KMail/1.6.2 References: <200407021806.12557.led@ukr-fin.com.ua> <200407061550.53480.led@ukr-fin.com.ua> <200407061705.29406.aris@altlinux.ru> In-Reply-To: <200407061705.29406.aris@altlinux.ru> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 8bit Message-Id: <200407061739.49593.led@ukr-fin.com.ua> X-BeenThere: sisyphus@altlinux.ru X-Mailman-Version: 2.1.5 Precedence: list Reply-To: led@ukr-fin.com.ua, ALT Linux Sisyphus discussion list List-Id: ALT Linux Sisyphus discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2004 14:39:54 -0000 Archived-At: List-Archive: В сообщении от Вторник 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: > > > > > > > > > > > > > > > > > Так я и не спрашиваю про 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.