Daniel Robbins хочет вернуться в Gentoo Foundation

> Вы это можете аргументировать?

Могу аргументировать собственным опытом активного использования Gentoo x86 в течение 4-х лет со 2000+ пакетов и нередкими обновлениями. Регулярными проблемами с несобирающимимися пакетами, импорто-экспортом базы ldap при каждом обновлении, ручном переключении gcc на третью версию, ручным выносом и установкой krb5-mit вместо heimdal для того, чтобы собрать пакет который с другим керберосом собиратьсян е хочет, а одновременно heimdal и krb5 не встают, после размаскировки ~x86 пакета и его зависимостей после обновления вруг появляются новые пакеты, которые нужно вручную расзмаскировывать, старые библиотеки которые сносит emerge, ломая пакеты и заставляя постоянно прогонять revdep-rebuild, пакеты перестающие собираться другой версией gcc, проблемы пойманные с неоттесированными -O3, с -fstack-protector, с -ftree-vectorize, с USE+hardened. Больше степеней свободы: CFLAGS, USE-флагов, опций конфигурирования ядра которые имеют тенденцию меняться, версий инструментов сборки, тем больше раскиданных граблей, на которые предстоит встать. Когда сборкой занимаются мантейнеры, которые на сборке пакетов собаку, то все эти беды обходят юзера стороной.

> Пожалуйста, по конкретней. Что значит: "нет политики stable"

Политика stable означает, что если поставил систему и все работает, то ни один апдейт систему не сломает, потому что новые версии с изменениями функционала в обновления стабильной ветви не попадают, устраняются только критически баги и проблемы безопасности без изменения версии(обновления безопасности, которых в генте нет, проблемы решаются переходом на неузвимую версию, в которой могли поменять параметры конфига, выкинуть deprecated, что-нибудь сломать, изменить пути к бинарникам после чего улетели скриипты). Вмешательство админа на стабильной системе требуется только тогда, когда происходит переход на новую версию STABLE, например с sarge на etch. За это и любят Debian Stable. Любая серьезная система(RHEL,Solaris,SLES) обновляется по тому же принципу.

> "дополнительные проблемы"

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

> сколько часов и киловатт энергии.

Посчитайте сами. Мощность системника * число часов компиляции. Обновление 2000+ пакетов в своей генту, которой я пользовался занимало на P4 3GHz+512RAM порой до суток-полторы если не считать пинков чтобы сменить нужный для qemu компилятор, размаскировать новые появившиеся зависимости, решить появившиеся блокирующие зависимости или наоборот заблокировать несобирающийся пакет или взять его из ~x86. Если увлекался бы сборкой openoffice было бы еще больше. Под нагрузкой получаем 250-300Вт. Итого за 3-4 часа - 1кВт*ч. Одно обновление - 6..10 кВт*4 Итого 10-15 рублей за одно обновление, гудение компьютера ночами и депрессия из-за того, что опять при обновлении какие-то проблемы. Достаточно аргументированно? :)

>Отнюдь.

>... В итоге воевать с ним надоело

Так в чем же ты воевал то ? Я ни пойму никак...

> Опять теоретизируете:

> Вот так вот... Я надеюсь не надо объяснять зачем нужен liba52?

Хорошо, не будем теоретизировать. Сколько процентов прироста
производительности от использования SSE-инструкций и как это
проявляется на практике? Ваша очередь приводить аргументы в пользу
разумности твикания CFLAGS. gcc кстати не славился уровнем
оптимизации, в отличиеи от, например, icc.

> Вы в своих разработках конечно же уже используете такие вещи?

Я сейчас не занимаюсь разработкой.

> P.S. рекомендую ещё узнать какой этап компиляции blas-atlas занимает больше всего времени...

Зачем? У нас, все как у белых людей:

$ apt-cache search ^atlas
atlas3-3dnow - Automatically Tuned Linear Algebra Software,3dnow shared
atlas3-3dnow-dev - Automatically Tuned Linear Algebra Software,3dnow static
atlas3-base - Automatically Tuned Linear Algebra Software,generic shared
atlas3-base-dev - Automatically Tuned Linear Algebra Software,generic static
atlas3-doc - Automatically Tuned Linear Algebra Software,documentation
atlas3-headers - Automatically Tuned Linear Algebra Software,C header files
atlas3-sse - Automatically Tuned Linear Algebra Software,SSE1 shared
atlas3-sse-dev - Automatically Tuned Linear Algebra Software,SSE1 static
atlas3-sse2 - Automatically Tuned Linear Algebra Software,SSE2 shared
atlas3-sse2-dev - Automatically Tuned Linear Algebra Software,SSE2 static
atlas3-test - Automatically Tuned Linear Algebra Software,test programs

+

$ ldconfig -p|grep "atlas.*hwcap"
liblapack_atlas.so.3 (libc6, hwcap: 0x0000000004000000) => /usr/lib/sse2/liblapack_atlas.so.3
liblapack_atlas.so.3 (libc6, hwcap: 0x0000000002000000) => /usr/lib/sse/liblapack_atlas.so.3
libatlas.so.3 (libc6, hwcap: 0x0000000004000000) => /usr/lib/sse2/libatlas.so.3
libatlas.so.3 (libc6, hwcap: 0x0000000002000000) => /usr/lib/sse/libatlas.so.3

Вобщем, мифы про мегаоптимизированную генту, которая разрывает убогенькие бинарные дистрибутивы собираемые с -march=i486 -mtune=i686 в клочья, разбит. :)

s/6..10 кВт*4/6..10 кВт*ч * 1.4 руб/кВтч/

> Гентушники, да спрсите у жтих Убунтовцев наконец не о приростах скорости при перекомпиляции, а об более приземленых вещах: скорости копирования файлов, времени загрузки и т.д.

На десктопе: 42.5 МБайт/с с винта в /dev/null, 30 - с винта на винт, 9.2 МБ/с по 100MBit сети через NFS. Время загрузки - секунд 30(upstart искарпки, который в гентах надо прикручивать).

> Я же говорил что функционала в ядре не хватает

Допустим на какой-нибудь мегаспециализированной задаче может и не хватить. А на типовых задачах - десктоп, LAMP сервера, squid, radius, MTA, файлопомойки?

> по этому приходится патчить и пересобирать ядро

Модули ядра уже отменили? В бинарном дистрибутиве нельзя протвикать и собрать ядро?

> при этом глупо не оптимизировать его под свои нужды и своё железо!

Еще ни разу не видел цифр насколько сильно "оптимизация под свои нужды" на что-то влияет. Гентушники этим похоже не интересуются, просто по-ламерски не вникая в суть верят, что "оптимизируя все под свое железо" получают мегаоптимизацию, MMX и SSE2 в ядре, мегаускоренные модули.

> Глаза разуй или сходи на экскурсию к любому виндузисту.

Шрифты на винде говно и зеленые буквы видны из-за cleartype. :)

> Не трудно, вот ты говно и продемонстрировал, statically linked старую фритайп либу. А наличие патчей для фритайпа пытаешься выдать за работу BCI и SPR.

Тебя мордой ткнули, что openoffice в дебе и убунте использует системную libfreetype: http://www.linux.org.ru/jump-message.jsp?msgid=2406675&cid=2413281 http://www.linux.org.ru/jump-message.jsp?msgid=2406675&cid=2416827 тебя ткнули в то, что openoffice собирается без проблем(хотя собирать его итак ненужно), которые ты постоянно ловишь со своей libshit в генте и переносишь свой неудачный опыт на другие системы. И в пачтеный freetype с BCI тебя мордой ткнули. А то, что я демонстрировал было с невключенным субпиксельным рендерингом. Так что обосрался - теперь обсыхай. Не дорос пока до систем, которым не нужны безумно красные глаза и напильник, максимум - маникюрная пилка. Подрастешь, глаза потускнеют - может быть пройдешь фейс-контроль. =)

> Запостил порнуху, а теперь выкручиваешь. Патенты-не патенты. Буквы кривые, корявые и лохматые.

Потом что SPR не включал.

> Хуже только зелёные буквы другого бубунтолога выглядят.

Это и есть хваленый субпиксельный рендеринг. И в винде буквы зеленые, только этом мнее выражено.

> Бубунта чё-то молотит, якобы собирая исходники. Процесс от тебя скрыт и ты даже не врубаешься, как именно собирается пакет

apt-get source и смотри, если такой задрот, что хочешь во всем разобраться. Ты уже разобрался как работает каждая процедура опенфоиса, за что отвечает каждая переменная, каждая микросхема и каждый резистор с кондером в твоем компьютере, мониторе и мобиле? Или все такой же ламер, который только и смог что осилить комиксы по прохождению stage1-stage3 и юзе-флаги? :)

Интересно подскажи как без пересборки freetype включит spr в OO?

>Модули ядра уже отменили? В бинарном дистрибутиве нельзя протвикать и собрать ядро?

Гы...(с) А в Убунте тогда не будет проблем с oldconfig или обновлять ядро некошерно?

>На Дебе выглядят заметно хуже, чем на Генте. [...] Гентовые не мучал

Самое забавное, что меня и гентушный дефолтовый SPR не удовлетворяет :) Только патентованный.

>Чем он паршивый?

Корявые и неровные косые линии и дуги. Иногда вылезающая "цветность". Отвратительная отрисовка на цветных фонах.

>Вообще-то включенный интерпретатор байт-кода BCI - патентованный

Ещё раз - интерпретатор байткода не занимается SPR. Какой BCI - в cairo, например? :) Или я торможу круто? Почему речь всё время идёт о freetype, когда для патентованного SPR патчатся cairo и libXft?

>gnome-control-center / Внешний вид / Шрифты / Субпиксельное сглаживание (для ЖК мониторов). Неужели это так трудно?

Не трудно. Но там таких настроек нет. Только дефолтовые настройки Гнома 2.20. Там нет настроек "Text rendering".

>> Хуже только зелёные буквы другого бубунтолога выглядят.

> Это и есть хваленый субпиксельный рендеринг.

Это _кривой_ _непатентованный_ SPR :)

> И в винде буквы зеленые, только этом мнее выражено.

В винде, кстати, фиговый SPR. Даже в Висте, хотя там чуть лучше, чем в XP.

Слушай посмотри как у меня нормально выглядит или нет: http://img144.imageshack.us/img144/7656/screen4uu6.png ? А то смотрю мне нравится, а ничего такого не делал.

>Слушай посмотри как у меня нормально выглядит или нет

У тебя ЭЛТ? Тогда, наверное, нормально. Субпиксельного сглаживания на скрине вообще нет :) У меня оно смотрится со ступеньками на косых линиях и некоторой "вспушенностью".

> http://img144.imageshack.us/img144/7656/screen4uu6.png ?

Буквы "пушистые" всё равно. Поставь fixed-misc и выключи сглаживание. Вот такое оно должно в идеале быть, только с другим начертанием разумеется.

>Да потому, что openssl несет оптимизированные бинарники для i486, i586 и i686 с sse2, которые автоматически загружаются линковщиком в зависимости от hwcaps

А почему нельзя распихать всё это по отдельным пакетам, и ставить только то что нужно?

>Соображение может быть такое:

Фантазии можете оставить при себе. Если не знаете, то не надо тут что-то вымучивать...

>Я считаю, что разгребать гиморрой

Свои медицинские проблемы тоже оставьте при себе.

>Хотя и мешать уникумам, которые реально видят проценты прироста и вместо установки нормального 64-битного железа на задачи, требующие максимальной производительности, развлекаются мегаоптимизаций под устаревшее x86, не буду.

Вы никогда не пытались посмотреть HDTV?

>Какие _практические_ преимущества это дает и как это себя проявляет?

Вы не в курсе чем занимается liba52? Знаете, не хочу чтобы у меня звук от картинки отставал ;) А если бы Вы посмотрели в исходник, то увидели, что пример который я приводил, вобщем то не такой уж сферический конь в вакууме...

>Смешно, например, убить полчаса на сборку ради ускорения на пару секунд при конвертировани аудио.

У меня данная библиотека собирается за 8.222 с без использования ccache. Так что свои смешные проблемы сюда приплетать не надо.

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

И почему это до сих пор не сделано? И я опять рекомендую посмотреть на blas-atlas...

>Сначала найдите MMX и SSE где-то кроме x86 и AMD64.

А, Вы считаете что достаточно только SSE? А SSE2 SSE3 SSE4 Вы считаете ненужными?

>Могу аргументировать собственным опытом активного использования Gentoo x86 в течение 4-х лет со 2000+ пакетов и нередкими обновлениями.

Т.е. ниже Ваше личное субъективное мнение, а не аргументы.

>Политика stable означает, что если поставил систему и все работает, то ни один апдейт систему не сломает, потому что новые версии с изменениями функционала в обновления стабильной ветви не попадают, устраняются только критически баги и проблемы безопасности без изменения версии(обновления безопасности, которых в генте нет, проблемы решаются переходом на неузвимую версию, в которой могли поменять параметры конфига, выкинуть deprecated, что-нибудь сломать, изменить пути к бинарникам после чего улетели скриипты).

Это называется arch + glsa-check ;) Ещё очень интересно узнать, stable никогда не обновляется, или иногда приходиться ставить новые версии ПО?

>За это и любят Debian Stable. Любая серьезная система(RHEL,Solaris,SLES) обновляется по тому же принципу.

Что, Вы ставите production сервера на автоматическое обновление?

>Малая часть проблем, с которыми удалось столкнуться в генту и которых не может быть в принципе в бинарном дистрибутиве перечислена выше.

Т.е. это просто для красного словца.

>Мощность системника * число часов компиляции. Обновление 2000+ пакетов в своей генту, которой я пользовался занимало на P4 3GHz+512RAM порой до суток-полторы если не считать пинков чтобы сменить нужный для qemu компилятор, размаскировать новые появившиеся зависимости, решить появившиеся блокирующие зависимости или наоборот заблокировать несобирающийся пакет или взять его из ~x86. Если увлекался бы сборкой openoffice было бы еще больше. Под нагрузкой получаем 250-300Вт. Итого за 3-4 часа - 1кВт*ч. Одно обновление - 6..10 кВт*4 Итого 10-15 рублей за одно обновление, гудение компьютера ночами и депрессия из-за того, что опять при обновлении какие-то проблемы. Достаточно аргументированно? :)

Господин анонимный теоретик! Спешу Вам сообщить, что по Вашим рассчётам я должен тратить 1200-2400 кВт*ч в месяц, с почти ежедневными обновлениями emerge -uDN --with-bdeps y world (Athlon64 3200+ 1512RAM 1313 пакетов на данный момент). А теперь посмотрим на показания счётчика: от 250 кВт*ч летом до 450 кВт*ч зимой. Это учитывая что я живу в частном доме, а это 10 энергосберегающих ламп, холодильник, два проточных водонагревателя, насос системы отопления и т.д. Гудение по ночам - только когда выходит новый ООо и kde, остальное - без отрыва от работы, и никаких депрессий. Так что, аргументов не достаточно.

>Спешу Вам сообщить, что по Вашим рассчётам я должен тратить 1200-2400 кВт*ч в месяц

Гы :) У меня три компа, один из которых совсем не выключается, а два выключаются только на ночь, т.е. реально в сутки они нарабатывают где-то около 55..57 "компьютеро-часов" (плюс холодильник, пылесос, микроволновка, кухонный комбайн, 11 лампочек, из которых энергосберегающих - шесть, фен у жены, электрочайник и т.д. и т.п.) нажигают в месяц около 600кВт*ч :)

>Хорошо, не будем теоретизировать.

Это было сказано на счёт liboil. Её используют очень мало.

>Сколько процентов прироста производительности от использования SSE-инструкций и как это проявляется на практике?

Процент сказать не могу, это тяжело оценить. На практике заметно как более плавное и без отставания звука воспроизведение фильмов.

>Ваша очередь приводить аргументы в пользу разумности твикания CFLAGS.

Объём ассемблерного кода увеличивается незначительно (на 10-100 строк, я это проверил), в то время как специальный тест показал, что при этом возможно ускорение до 10%

>gcc кстати не славился уровнем оптимизации, в отличиеи от, например, icc.

Ну так вперёд! Замените gcc на icc!

>Я сейчас не занимаюсь разработкой.

А когда занимались (ведь целых 10 лет !) почему не использовали?

>Зачем? У нас, все как у белых людей:

Ну тогда хотя бы почитайте README и INSTALL...

>Хорошо, не будем теоретизировать.

Это было сказано на счёт liboil. Её используют очень мало.

>Сколько процентов прироста производительности от использования SSE-инструкций и как это проявляется на практике?

Процент сказать не могу, это тяжело оценить. На практике заметно как более плавное и без отставания звука воспроизведение фильмов.

>Ваша очередь приводить аргументы в пользу разумности твикания CFLAGS.

Объём ассемблерного кода увеличивается незначительно (на 10-100 строк, я это проверил), в то время как специальный тест показал, что при этом возможно ускорение до 10%

>gcc кстати не славился уровнем оптимизации, в отличиеи от, например, icc.

Ну так вперёд! Замените gcc на icc!

>Я сейчас не занимаюсь разработкой.

А когда занимались (ведь целых 10 лет !) почему не использовали?

>Зачем? У нас, все как у белых людей:

Ну тогда, хотя бы почитайте README и INSTALL...

> А почему нельзя распихать всё это по отдельным пакетам, и ставить только то что нужно?

Спросите у разработчиков. А вообще проще положиться на умную автоматику, которая прозрачно определить CPU features и воспользуется оптимизированной сборкой без вмешательства человеческого фактора.

> Фантазии можете оставить при себе. Если не знаете, то не надо тут что-то вымучивать...

> Свои медицинские проблемы тоже оставьте при себе.

Вы свои выдумки про существенное преимущество сборки всей системы под конкретный CPU в сравнении с точечными оптимизациями kernel,libc под i686+библиотеки под SIMD там где это дает эффект в бинарных пакетах; трудности с хранением на винчестере с сотнями гигабайт пары мегабайт сборок openssl для 486 и 586; а также медицинские трудности с красными глазами, которые требуют оптимизировать всю систему подряд, включая пинг, трейсерт и apache под SSE тоже оставьте при себе. Ни одного реального преимущества(кодирование видео, декодирование звука и т.д), ради которых стоит затевать подобные генте игры в мантейнеров приведено пока не было.

> Вы никогда не пытались посмотреть HDTV?

Смотрел. В "300 спартанцев" звук иногда прерывается.

> Вы не в курсе чем занимается liba52? Знаете, не хочу чтобы у меня звук от картинки отставал ;)

Декодирование звука это не самая ресурсоемкая задача в HDTV имхо.

> Вы не в курсе чем занимается liba52? Знаете, не хочу чтобы у меня звук от картинки отставал ;) А если бы Вы посмотрели в исходник, то увидели, что пример который я приводил, вобщем то не такой уж сферический конь в вакууме...

liba52 как раз не сферический конь в вакууме в отличие от сферических исходников в вакууме. Ну и как, неужели без оптимизации звук отстает и заикается, а после оптимизации с -mfpmath=sse сразу перестает? Это ведь несложно проверить. Вот и скажиет есть ли эффект от оптимизации или его нет.

> У меня данная библиотека собирается за 8.222 с без использования ccache. Так что свои смешные проблемы сюда приплетать не надо.

А включить мозги и подумать, что речь была не о сборке ОДНОЙ библиотеки из множества? А часы сборки ядра, libc, qt, кедов и openoffice(тут оказалось есть ценители не уважающие openoffice-bin) куда делись? У меня 2474 пакетов. Можете примерно прикинуть сколько месяцев займет сборка всего этого и пересборка при обновлениях.

> И почему это до сих пор не сделано? И я опять рекомендую посмотреть на blas-atlas...

Много где сделано. В частности для вышеупомянутой atlas с оптимизированными пакетами, заточенные с использованием вставок под SSE, SSE2 и 3dnow.

> А, Вы считаете что достаточно только SSE? А SSE2 SSE3 SSE4 Вы считаете ненужными?

gcc не умеет оптимизировать под MMX,MMX2,SS2,SSE3,SSE4 и т.д. хотя команды знает. -mfpmath=sse оптимизирует только плавабщую точку и только под SSE. Поэтому чтобы воспользоваться всеми преимуществами SIMD там где они _могут_ раскрыться(операции с векторами) надо писать ассембленые вставки или, чтобы упростить задачу и не городить велик, пользоваться библиотеками типа libiol, в которых собраны оптимизированные аглгоритмы, которые динамически используют возможности установленного процессора.

> Т.е. ниже Ваше личное субъективное мнение, а не аргументы.

Не путайте большой практический опыт с субъективным мнением.

> Это называется arch + glsa-check ;)

Вы так и не понял что такое обновления безопасности в stable. Они НЕ ДОЛЖНЫ ПРИВОДИТЬ К ИЗМЕНЕНИЮ ФУНКЦИОНАЛА программы. А glsa-check когда как может либо наложить патч на имеющуюся версию, либо вхерачить новую версию программы, которая устраняет проблему, зато вполне может что-нибудь сломать из-за того, что новая версия это не только хотфикс.

> Ещё очень интересно узнать, stable никогда не обновляется

Версии в stable не обновляются до выхода следующей версии stable.

> или иногда приходиться ставить новые версии ПО?

_Иногда_ _может_ понадобиться. Тогда мы _сознательно_, сознавая все возможные последствия, пожертвуем стабильностью ради нового функционала _конкретного_ пакета(ов) и поставим нужные пакеты из бэкпортов.

> Что, Вы ставите production сервера на автоматическое обновление?

Вы опять ничего не поняли. Все серьезные вендоры придерживаются такой же как в stable осторожной политики обновлений, чтобы не создать хотфиксом проблемы с настроенными и оттестированными серверами. А гентушные мантейнеры и гентушники пока не доросли до осознания важности такой политики обновлений на важных серверах и этих пионеров также не заботит отсутствие такой ерунды как LSB совместимость, которая отсутствует в генте как класс.

> Т.е. это просто для красного словца.

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

> Господин анонимный теоретик!

Уважаемый аналитик, мои рассчеты приведены для собственного ПК на базе P4, который славится своей прожорливостью и базируется на огнедышащем Prescott C-степпинг, для системы с двумя тысячами пакетов. Блок питания на 350Вт. До ~250-300Вт оно все и потребляет под нагрузкой. Если для вас будет открытием, что начальные условия и график обновлений могут отличаться, то это ваши личные проблемы.

> А теперь посмотрим на показания счётчика: от 250 кВт*ч летом до 450 кВт*ч зимой.

Озвучьте правильную цифру сколько потребляет электроэнергии ваш компьютер, занимаясь бестолковыми сборками.

> Гы :) У меня три компа, один из которых совсем не выключается, а два выключаются только на ночь, т.е. реально в сутки они нарабатывают где-то около 55..57 "компьютеро-часов" (плюс холодильник, пылесос, микроволновка, кухонный комбайн, 11 лампочек, из которых энергосберегающих - шесть, фен у жены, электрочайник и т.д. и т.п.) нажигают в месяц около 600кВт*ч :)

Гы-Гы. А у меня один компьютер который никогда не выключается домашний сервер с Debian(cel 300, ~60Вт*ч) и один - персоналка с огнедышащим под нагрузкой p4 prescott и Ubuntu, которая отключается. Лампочки, микровонлновка, электрочайник, два телевизора, стиральная машина и т.д. и т.п. За прошлый месяц когда еще был живой нормальным ЭЛТ монитор, накрутилось 154кВт*ч. Во времена гентууу было до 378КВт*ч. :)

> Это было сказано на счёт liboil. Её используют очень мало.

$ apt-rdepends -d -r liboil0.3|wc -l Чтение списков пакетов... Готово Построение дерева зависимостей Reading state information... Готово 310

> Процент сказать не могу, это тяжело оценить.

Почему тяжело? Например, распаковка или запаковка архива или кодирование звука стало работать на одних и тех же данных после оптимизации на столько-то секунд.

> На практике заметно как более плавное и без отставания звука воспроизведение фильмов.

А без оптимизации звук не оставал? Очень субъективно. Не исключено самовнушение.

> в то время как специальный тест показал, что при этом возможно ускорение до 10%

Бенчмарк сферического коня в вакууме показал, что ускорение на операциях с _плавающей_ на _конкретном_ процессоре точкой возможно до 12.5%. Меня же интересует как это проявляется на реальных приложениях в объективных величинах - быстрее на столько-то секунд, больше на столько-то fps. Сферические кони в вакууме представляют чисто академический интерес. А на практике рассчетные библиотеки типа atlas, как было показано, грамотно прооптимизированы под SEE/SSE2/3dnow, openssl использует динамическую оптимизацию под тип процессора и набор команд SSE2, mplayer тоже:

$ objdump -d /usr/bin/mplayer|egrep "mm[[:digit:]]"|wc -l 165053

gstreamer и многие другие пакеты используют динамически оптимизирующийся liboil...

> Ну так вперёд! Замените gcc на icc!

Попробуйте сами. Только потом не жалуйтесь, что многие программы не собираются или падают. http://gentoo-wiki.com/HOWTO_ICC_and_Portage#Packages_that_don.27t_work_with_ICC Мне такие приключения ни к чему.

> А когда занимались (ведь целых 10 лет !) почему не использовали?

Какая разница?

> Ну тогда хотя бы почитайте README и INSTALL...

Почитал. Что должен был там интересного и по теме дискуссии обнаружить?

s/60Вт*ч/60Вт/

>Допустим на какой-нибудь мегаспециализированной задаче может и не хватить. А на типовых задачах - десктоп, LAMP сервера, squid, radius, MTA, файлопомойки?

На десктопе хочу suspend2 для серверов хочу selinux & grsecurity & PAX, а ещё сильно хочется SSI кластер и для десктопов и для серверов...

>Модули ядра уже отменили? В бинарном дистрибутиве нельзя протвикать и собрать ядро?

Если нужного функционала в ядро не включили и модули не собрали то прийдетса компилить самому. И меня радует что вы впервые здесь согласились с необходимостью иногда пересобирать ядро!

>Еще ни разу не видел цифр насколько сильно "оптимизация под свои нужды" на что-то влияет. Гентушники этим похоже не интересуются, просто по-ламерски не вникая в суть верят, что "оптимизируя все под свое железо" получают мегаоптимизацию, MMX и SSE2 в ядре, мегаускоренные модули.

Ну соберите заточенное под свои нужды и архитектуру ядро 2.6.23.12 или какое там последнее и сами почувствуете разницу в скорости работы. Можете и для остальных здесь результаты тестов выложить.

> Если нужного функционала в ядро не включили и модули не собрали то прийдетса компилить самому. И меня радует что вы впервые здесь согласились с необходимостью иногда пересобирать ядро!

А что, кто-то спорил? ;))) Тока ключевое слово здесь _иногда_, так ведь? И кто сказал, что под дебианом/федорой это сделать низзя?

>А что, кто-то спорил? ;))) Тока ключевое слово здесь _иногда_, так ведь?

Когда нужного функционала дистростроитили в штатном ядре не дают то будешь пересобирать _ВСЕГДА_.

>И кто сказал, что под дебианом/федорой это сделать низзя?

Прочитай что они писали... мне показалось что им религия какая то запрещает компилятором пользоваться, может грех это у них считается;)

>А вообще проще положиться на умную автоматику, которая прозрачно определить CPU features и воспользуется оптимизированной сборкой без вмешательства человеческого фактора.

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

>Вы свои выдумки про существенное преимущество сборки всей системы под конкретный CPU в сравнении с точечными оптимизациями kernel,libc под i686+библиотеки под SIMD там где это дает эффект в бинарных пакетах; трудности с хранением на винчестере с сотнями гигабайт пары мегабайт сборок openssl для 486 и 586; а также медицинские трудности с красными глазами, которые требуют оптимизировать всю систему подряд, включая пинг, трейсерт и apache под SSE тоже оставьте при себе. Ни одного реального преимущества(кодирование видео, декодирование звука и т.д), ради которых стоит затевать подобные генте игры в мантейнеров приведено пока не было.

Только что мы прослушали пятиминутку ненависти в исполнении Анонимного Теоретика!

>Смотрел. В "300 спартанцев" звук иногда прерывается.

Т.е. не помешало бы чуть-чуть оптимизации?

>Декодирование звука это не самая ресурсоемкая задача в HDTV имхо.

Не зря говорят: копейка - рубль бережёт.

>Ну и как, неужели без оптимизации звук отстает и заикается, а после оптимизации с -mfpmath=sse сразу перестает? Это ведь несложно проверить.

Проверить это мне довольно тяжело. Мне придётся ставить рядышком две 32битных системы, чего я себе позволить не могу, как по времени, так и по ресурсам.

>Вот и скажиет есть ли эффект от оптимизации или его нет.

Я lib52 отдельно собрал, и посмотрел на вывод ассемблера некоторых частей. Каждая функция увеличилась на 10-100 команд (по сравнению с mfpmath=387), SSE инструкции (естественно скалярные) используются довольно часто, в общем в тех функциях всё в основном сводиться к циклам с умножением и сложением чисел, ассемблерный код похож на код того примера.

>А включить мозги и подумать, что речь была не о сборке ОДНОЙ библиотеки из множества?

А Вам надо "2000+"? Мне не трудно потратить 5-10 минут на сборку нужных библиотек.

>часы сборки ядра, libc, qt, кедов и openoffice(тут оказалось есть ценители не уважающие openoffice-bin) куда делись?

Неужели на компьютере, который практически не тормозит ТВЧ (я надеюсь 1080р) сборка libc, qt и кедов занимает часы?

>Можете примерно прикинуть сколько месяцев займет сборка всего этого и пересборка при обновлениях.

Не надо прикидывать, я Вам так скажу, у меня это заняло: glibc - 1час 44мин; qt3 - 23мин; qt4 - 1час 16мин; kdebase, kdepim, kdelibs - приблизительно по 1 часу, остальные части - каждая около 20-30 минут; openoffice - 8,5 часов.

Это максимальные длительности сборки. Если какая-то часть находилась в кэше ccache, то время соответственно меньше. Так же хочу заметить, что ТВЧ (1080p) у меня выглядит как слайд-шоу.

>У меня 2474 пакетов. Можете примерно прикинуть сколько месяцев займет сборка всего этого и пересборка при обновлениях.

Нет, не могу. Но могу сказать для своих 1313 пакетов: 2дня 20часов. Теперь осталось только придумать повод чтобы их все сразу компилить, а то ведь с электроэнергий то просчитались-с ;)

>Много где сделано.

Давайте число: сколько алгоритмов, "которые получат заметную пользу от SIMD можно вынести в один пакет и бороться с максимальной оптимизацией там", и сколько уже вынесено.

>В частности для вышеупомянутой atlas с оптимизированными пакетами, заточенные с использованием вставок под SSE, SSE2 и 3dnow.

Вы посмотрите всё-таки что там они делают на этапе компиляции...

>gcc не умеет оптимизировать под MMX,MMX2,SS2,SSE3,SSE4 и т.д. хотя команды знает. -mfpmath=sse оптимизирует только плавабщую точку и только под SSE. Поэтому чтобы воспользоваться всеми преимуществами SIMD там где они _могут_ раскрыться(операции с векторами) надо писать ассембленые вставки или, чтобы упростить задачу и не городить велик,

Вы выше прочитать http://www.linux.org.ru/jump-message.jsp?msgid=2406675&cid=2419536 не можете? А, это наверное совсем другой анонимус был ;)

>пользоваться библиотеками типа libiol, в которых собраны оптимизированные аглгоритмы, которые динамически используют возможности установленного процессора.

Я интересно дождусь списка этих библиотек?

>Не путайте большой практический опыт с субъективным мнением.

Может быть Вы назовёте отличия, и мы сравним?

>Вы так и не понял что такое обновления безопасности в stable. Они НЕ ДОЛЖНЫ ПРИВОДИТЬ К ИЗМЕНЕНИЮ ФУНКЦИОНАЛА программы. А glsa-check когда как может либо наложить патч на имеющуюся версию, либо вхерачить новую версию программы, которая устраняет проблему, зато вполне может что-нибудь сломать из-за того, что новая версия это не только хотфикс.

А Вы не слышали о -r ебилдах? Если хотите, можете их писать и для устаревших пакетов.

>Версии в stable не обновляются до выхода следующей версии stable.

Боюсь, что в этом случае Вы правы: это противоречит идеологии gentoo.

>_Иногда_ _может_ понадобиться. Тогда мы _сознательно_, сознавая все возможные последствия, пожертвуем стабильностью ради нового функционала _конкретного_ пакета(ов) и поставим нужные пакеты из бэкпортов.

И где _Вы_ придерживаетесь такой политики?

>Все серьезные вендоры придерживаются такой же как в stable осторожной политики обновлений, чтобы не создать хотфиксом проблемы с настроенными и оттестированными серверами.

И не было случаев, когда этот хотфикс приводил к пролемам? Неверю!

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

Вы не доросли до осознания иделогоии gentoo.

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

Вытер желчь с монитора...

>Уважаемый аналитик, мои рассчеты приведены для собственного ПК на базе P4, который славится своей прожорливостью и базируется на огнедышащем Prescott C-степпинг, для системы с двумя тысячами пакетов.

Пожалуйста, назовите показания счётчика за последние три месяца.

>Блок питания на 350Вт. До ~250-300Вт оно все и потребляет под нагрузкой.

Аналогично. Плюс монитор (LCD) и колонки 5.1 (около 100Вт). Только вот энергосберегающие технологии активированы, поэтому от 200 Вт.

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

Я Вас прошу не сферический рассчёт для вакуума, а примерный рассчёт. Или Вы, пока пользовались gentoo, постоянно пересобирали 2474 пакета? Ну тогда не удивительно, что Вы истратили около 2МВт*ч энергии...

>Озвучьте правильную цифру сколько потребляет электроэнергии ваш компьютер, занимаясь бестолковыми сборками.

Тестера нет под рукой. А среднемесяное я привёл точно. Хотите посмотреть emerge.log и сканы квитанций?

>компьютер который никогда не выключается домашний сервер с Debian(cel 300, ~60Вт*ч)

Что-то не сходиться. Или получается что потребляемая мощность этого компьютера 0,083Вт, или расход в месяц только на него 64кВт, почему тогда на всё остальное так мало энергии?

>Лампочки, микровонлновка, электрочайник, два телевизора, стиральная машина и т.д. и т.п. За прошлый месяц когда еще был живой нормальным ЭЛТ монитор, накрутилось 154кВт*ч.

Кажется становиться понятно: холодильника нет, стиральная машина включается раз в месяц и т.д. Не понятно только, зачем одинокому холостяку почти постоянно занятому на работе два телевизора?

>$ apt-rdepends -d -r liboil0.3|wc -l Чтение списков пакетов... Готово Построение дерева зависимостей Reading state information... Готово 310

Может быть расшифруете, что это были за строчки. Так, ради интереса...

>Например, распаковка или запаковка архива или кодирование звука стало работать на одних и тех же данных после оптимизации на столько-то секунд.

Ещё раз для непонятливых: для этого мне придётся ставить две 32битных системы, для чего у меня нет ни времени, ни компьютерных ресурсов.

>А без оптимизации звук не оставал? Очень субъективно. Не исключено самовнушение.

Давайте тестовый стенд - проведу объективное исследование.

>Бенчмарк сферического коня в вакууме показал, что ускорение на операциях с _плавающей_ на _конкретном_ процессоре точкой возможно до 12.5%.

А мы что, про десять процессоров говорим?

>Меня же интересует как это проявляется на реальных приложениях в объективных величинах - быстрее на столько-то секунд, больше на столько-то fps.

Меня тоже. Где тестовый стенд?

>рассчетные библиотеки типа atlas, как было показано, грамотно прооптимизированы под SEE/SSE2/3dnow, openssl использует динамическую оптимизацию под тип процессора и набор команд SSE2

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

>gstreamer и многие другие пакеты используют динамически оптимизирующийся liboil...

Кроме gstreamer и pulseaudio что-то не видать...

>Попробуйте сами.

Причём тут я? Вы уже не первый раз упоминаете icc, а теперь говорите "Мне такие приключения ни к чему." Т.е. опять ради красного словца что-то ляпнули, а мне монитор от желчи вытирать?

>Какая разница?

Вы очень много чего предлагаете сделать другим. Я вот хочу узнать, почему же Вы этого не делали? Может быть там какие-то камни подводные? Я начну так делать, а из-за этих камней вовремя сделать не смогу...

>Почитал. Что должен был там интересного и по теме дискуссии обнаружить?

Специальный раздел: "2.2 Turn off CPU throttling when installing ATLAS"

И далее:

"An ATLAS install is performed in 5 steps, only the first two of which are mandatory. This install process is very similar to other free software installs, particularly gnu, though the fact that ATLAS does an extremely complex empirical tuning step can make the build step particularly long running."

А также параграфы 3.2 (особенно 3.2.3 IMPORTANT NOTE), 3.4, 6 (особенно 6.1).

Вы думаете достаточно будет 2 вариантов библиотек для увеличия скорости?

>Только что мы прослушали пятиминутку ненависти в исполнении Анонимного Теоретика!

ну факты приведи-то, ё-моё, шелл-логи там какие-нибудь, или тот же $time <...>, не надо быть голословным.

>ну факты приведи-то, ё-моё, шелл-логи там какие-нибудь, или тот же $time <...>, не надо быть голословным.

Вы это всерьёз? Попробуйте на досуге сравнить "преимущество сборки всей системы под конкретный CPU " с " точечными оптимизациями kernel,libc под i686+библиотеки под SIMD там где это дает эффект в бинарных пакетах". Перед этим не забудь-те объяснить мне, что всё это значит.

> Когда нужного функционала дистростроитили в штатном ядре не дают то будешь пересобирать _ВСЕГДА_.

Когда один пакет - всегда, то в рамках дистрибутива в целом это получается - _иногда_ ;)

> Прочитай что они писали... мне показалось что им религия какая то запрещает компилятором пользоваться, может грех это у них считается;)

Это эмоции. Тут столько неадекватных мнений высказалось по поводу OOO и остального, что неудивительно, если даже самые нормальные зарекуться писать make в ближайшие полгода... ;)

>> Смотрел. В "300 спартанцев" звук иногда прерывается.

> Т.е. не помешало бы чуть-чуть оптимизации?

200 спартанцев не тормозило бы? Дык перекомпиляцией их количество не уменьшить, это история, она на USE-флаги не ведется... ;)

> На десктопе хочу suspend2

swsusp из коробки и он работает. Если тебе важен не результат, а процесс ковыряния - выбери другую ОС.

> для серверов хочу selinux & grsecurity & PAX

SELinux в ядре Deian(debian лучше для сервера, ubuntu - для десктопа) из коробки, нужно только настроить. Grsec всю жизнь включал в себя PAX. Пакет называется kernel-patch-grsecurity2. Хотя, учитывая ASLR, защиту от переполнений кучи, вкомпиленные проверки стека и бит NX PAX нафиг не нужен, а RSBAC учитывая selinux тем более.

> Если нужного функционала в ядро не включили и модули не собрали то прийдетса компилить самому.

Драйвера и фирмварь для массы железок, не включенных в ванильное ядро собраны и включены в убунте в отдельный пакет ubuntu-modules + restricted-modules. Что серьезно снижает вероятность собирать что-то из модулей. Хотя тем, кому нужен grsec, хотя он с успехом заменяется selinux+средства защиты от переполнений встроенные в ядро и libc и аппаратно неисполнимые стек и куча(NX) придется собрать свое ядро. Сборка ядра парой параноиков не означают, что и все остальные тоже должны бросить все и сломя голову сменить дистрибутив на тот, где постоянно нужно компилировать _все_.

>> В бинарном дистрибутиве нельзя протвикать и собрать ядро?

> И меня радует что вы впервые здесь согласились с необходимостью иногда пересобирать ядро!

С возможность, а не с необходимостью. Не отрицаю вероятность, что это понадобится где-то в очень-очень-очень редком очень-очень-очень специализированном случае из-за серьезного _недостатка_ ядра или программы(отсутствует нужный функционал), который можно устранить только путем наложения патчей. Такой недостаток должен быть устранен разработчиками. И если разработчики нерасторопны, то в этом конкретном очень-очень-редким случаем мы можем заняться устранением проблемы самостоятельно, воспользовавшись преимуществом opensource. Но это не означает, что преимущество опенсорс - это компилирование все что движется.

> Ну соберите заточенное под свои нужды и архитектуру ядро 2.6.23.12 или какое там последнее и сами почувствуете разницу в скорости работы.

Собрал. Не почувствовал.

ii linux-image-2.6.23.11custom 1 Linux kernel binary image for version 2.6.23.11custom

Самовнушение? Время убитое на сборку ядра и пересборку модулей не включенных в ядро того не стоило.

> Можете и для остальных здесь результаты тестов выложить.

Каких тестов. Вы считаете, что это будет быстрее - ну так и докажите, а не переводите все на "поставь, ощути, выложи результаты".

> Когда нужного функционала дистростроитили в штатном ядре не дают то будешь пересобирать _ВСЕГДА_.

Смотретьв сторону модуля ядра. Версия ядра в пределах версии деба и убунты не изменяется, следовательно можно собрать один раз и как бы не обновлял ядро самосборный модуль пересобирать не придется. У меня на sarge стоял ipt_TARPIT, пересобирать псоле каждого обновления ядра не приходилось. В худшем случае, когда модулем добавить функционал нельзя, а требуются более глубокие изменения, то ситуация сводится к сборке ядра вручную как.. в генту. При этом в генту пересобирать ядро вручную это не исключение, а правило, версия изменяется - следовательно надо пересобирать все модули.

> Прочитай что они писали... мне показалось что им религия какая то запрещает компилятором пользоваться, может грех это у них считается;)

Посмотри на виндузятников. Это и есть пример пользователя обыкновенного. Linux перестал быть системой для программистов, следовательно о массовом задротстве с компилятором на дескопах и серверах забудьте.

> Вот я тоже предлагал положиться в некоторых моментах на автоматику, а Вы не хотите...

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

> Только что мы прослушали пятиминутку ненависти в исполнении Анонимного Теоретика!

Не хамите ("медицинские трудности", "догадки можете оставить при себе") и с вами будут по-человечески.

> Т.е. не помешало бы чуть-чуть оптимизации?

Не помешало бы, если бы я смотрел HDTV, а не запустил его чисто ради эксперимента "потянет-не потянет". Но опять трахаться с гентой я не собираюсь - эффективнее сменить железо на более мощное с аппаратным HD и решить проблему навсегда, чем постоянно возюкаться с компьютером.

> Не зря говорят: копейка - рубль бережёт.

Если ударяться в философствование, то "Время - деньги", следовательно, тратить время и электроэнергию на генту - терять деньги. При оптимизации никто не ударяется в красноглазие, оптимизируя каждый такт - оптимизируют лишь критические участки(лишь те такты, что накручивают в циклах серьезные задержки). В даном случае критический участок - декодирование видео, а никак не аудио.

> Проверить это мне довольно тяжело.

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

> Мне придётся ставить рядышком две 32битных системы, чего я себе позволить не могу, как по времени, так и по ресурсам.

Для того, чтобы проверить дает ли хоть какой-то прирост lib52 достаточно собрать ее без оптимизации, а потом с оптимизацией. Вот с объективным тестом сложнее.

> А Вам надо "2000+"?

Да.

> Мне не трудно потратить 5-10 минут на сборку нужных библиотек.

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

> Неужели на компьютере, который практически не тормозит ТВЧ (я надеюсь 1080р) сборка libc, qt и кедов занимает часы?

720p. P4 2.8Ghz. Сборка libc и qt занимает часы.

> Теперь осталось только придумать повод чтобы их все сразу компилить,

Достаточно регулярно обновляться в обычном режиме, чтобы пересобрать всё.

> а то ведь с электроэнергий то просчитались-с ;)

Для своих начальных данных не просчитались.

> Давайте число: сколько алгоритмов,

Вы сами себе представляете всю асбурдность требований посчитать число алгоримтов? Любые алгоритмы связанные векторами, матрицами, с параллельной обработкой.

> .. "которые получат заметную пользу от SIMD можно вынести в один пакет и бороться с максимальной оптимизацией там", и сколько уже вынесено.

Предлагаете прошерстить установленные 2.5 тыс пакетов или весь репозитарий с десятками тысяч пакетов, чтобы получить такие сведения? Неглубоко копнув оказалось 310 пакетов использующих только libaio, про мплеер, atlas, openssl и пр. написано выше.

> Вы посмотрите всё-таки что там они делают на этапе компиляции...

Может хватит загадывать загадки и отсылать искать нечто в Readme.txt и Install.txt, то смотреть компиляцию? Я четко вижу ассемблерные вставки, например atlas3-3.6.0/tune/blas/gemm/CASES/ATL_smm14x1x84_sse. И четко вижу оптимизированные пакеты, с библиотеками, которые автоматически выбираются загрузчиком при линковке в зависимости от hwcap.

> Вы выше прочитать http://www.linux.org.ru/jump-message.jsp?msgid=2406675&cid=2419536 не можете? А, это наверное совсем другой анонимус был ;)

Другой. Заморачиваться с поддержкой "MMX, SSE, SSE2, SSE3, SSE4, 3dnow, 3dnow+ и их комбинаций с x86_64" никто не будет. Выберут, к примеру SSE или SSE2(между SSEx разница невелика, как и между набором команд i486 и i686). SSE заменяет 3dnow! MMX-ом стали пользоваться редко, видимо потому, что целочисленная арифметика итак достаточно шустрая и процессор довольно неплохо оптимизирует поток команд, оптимально загружая параллельные блоки АЛУ. А те жалкие проценты прироста, который выдавливает gcc с -mfpmath=sse(КПД 3-10%) на плавающей точке по сравнению с тем, что можно получить от SSE вручную(прирост произ-ти в 2-4 раза, что было подтверждено примером выше - 6 секунд вместо 16), и которые уже выдавлены по умолчанию на x86-64 это несерьезно.

> Я интересно дождусь списка этих библиотек?

Все 310 пакетов показать из вывода apt-rdepends -d -r liboil0.3?

>Посмотри на виндузятников. Это и есть пример пользователя обыкновенного. Linux перестал быть системой для программистов, следовательно о массовом задротстве с компилятором на дескопах и серверах забудьте.

Так бы сразу и признались -- компиляция зло, потому что в любимой Винде компилировать по-большому счёту и нечего -- БГ подумал обо всём за нас. Вы думаете, что кругом, куда прийдут масовые виндузятники все остальные должны лечь под них?

А зачем вообще брать виндузятников за пример?

>720p. P4 2.8Ghz. Сборка libc и qt занимает часы.

У тебя что-то в консерватории не то. P4 3.0ГГц, без тормозов 720p, но:

$ sudo qlop -gH qt

qt: Thu Jan 17 08:54:21 2008: 31 minutes, 42 seconds

$ sudo qlop -gH glibc

glibc: Sun Dec 16 06:15:05 2007: 22 minutes, 16 seconds

> потому что в любимой Винде компилировать по-большому счёту и нечего

А зачем это делать даже в линуксе? Все дураки наверное, что предпочитают пакетные менеджеры и бинарные пакеты. Да, я знаю в чём преимущество открытых исходников, но что ж мы не видим десятков форков у каждой программы? Все предпочитают чтобы "за них думали" мейнтейнеры дистрибутивов.

> БГ подумал обо всём за нас

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

>Драйвера и фирмварь для массы железок, не включенных в ванильное ядро собраны и включены в убунте в отдельный пакет ubuntu-modules + restricted-modules. Что серьезно снижает вероятность собирать что-то из модулей.

А там есть рабочие драйвера для Dlink DWL-G122?

>Автоматика должна выполнять всю грязную работу. emerge, сборка ядра и решение проблем в этапе сборки это не автоматизация.

Надо чтоб оно сразу из мозга? Нет. emerge и т.п. это и есть автоматизация. Сравните, например, с LFS.

>Не хамите ("медицинские трудности", "догадки можете оставить при себе") и с вами будут по-человечески.

А, т.е. корректное замечание на выставление на показ проблем с прямой кишкой теперь называется хамством? Не знал, не знал...

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

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

>> А Вам надо "2000+"?

>Да.

В отличие от Вас, я 2500 пакетов обновлял постепенно, в течении полугода, раз в день, или раз в два дня выполняя emerge -uDN --with-bdeps y world; revdep-rebuild. Что Вам мешает поступать подобным образом мне не понятно.

>затем стало раздражать убийство времени на всю эту чушь.

Опять у Вас какие-то проблемы. Всё, успокойтесь. Вам больше ничего не надо ковырять, оптимизировать, решать...

>720p. P4 2.8Ghz. Сборка libc и qt занимает часы.

Как-то это не сходиться. У Вас процессор работает на частоте почти на гигагерц большей чем мой, а libc и qt собираются часы! Как такое может быть?

>Достаточно регулярно обновляться в обычном режиме, чтобы пересобрать всё.

У меня на это ушло пол-года. Т.е. те самые мегаватт*часы получаются в сумме за пол-года (сразу хочу заметить, что даже здесь Вы серьёзно ошиблись, весь дом за эти пол-года израсходовал только 2000кВт*ч ).

>Для своих начальных данных не просчитались.

Сферических и конеобразных ;) Потому как толкового расчёта от Вас я так и не увидел.

>Надо чтоб оно сразу из мозга? Нет. emerge и т.п. это и есть автоматизация. Сравните, например, с LFS.

Или с pkgtool из Slackware.

>В отличие от Вас, я 2500 пакетов обновлял постепенно, в течении полугода, раз в день, или раз в два дня выполняя emerge -uDN --with-bdeps y world; revdep-rebuild. Что Вам мешает поступать подобным образом мне не понятно.

Видимо, это такая болезнь -- репозитариозависимость: желание всегда иметь всё самое новое ПО сейчас (даже если ты им и не думаешь пользоватся), не учитывая, что могут быть и проблемы про переходе на новые версии. (Например, у KMyFirewall недавно изменился формат файлов).

>Все дураки наверное, что предпочитают пакетные менеджеры и бинарные пакеты.

Не надо быть таким самокритичным. ;)

>Я предпочитаю чтобы при поломке машины за меня "думали" в автосервисе.

Ваше право. А к чему тогда называть задротами тех, кто может, в случае необходимости починить машину сам. Или для вас работники автосервиса -- задроты? (Это же Ваши слова "Linux перестал быть системой для программистов, следовательно о массовом задротстве с компилятором на дескопах и серверах забудьте."? Тогда все програмисты -- задроты? (Потому как это предложение можно понять так "Линукс раньше был системой для програмистов, которые занимались задротством на десктопах и серверах"). Или я неправ?

P.S.Вы в этом не усматриваете какого-то ммм... унижения или оскорбления? Сходите к психологу, чтоли...

> А к чему тогда называть задротами тех, кто может, в случае необходимости починить машину сам.

Задрот тот кто в выходной день ковыряется в моторе и орёт на всех кто пользуется услугами автосервиса что они ламеры поганые.

>Вы сами себе представляете всю асбурдность требований посчитать число алгоримтов?

И что же в нём такого абсурдного? Вы же сами уже назвали некоторое число таких алгоритмов. Теперь только надо узанть это все, или ещё есть.

>Любые алгоритмы связанные векторами, матрицами, с параллельной обработкой.

Оказывается что не любые. Иначе liba52 использовал бы fftw вместо своих костылей.

>Предлагаете прошерстить установленные 2.5 тыс пакетов или весь репозитарий с десятками тысяч пакетов, чтобы получить такие сведения?

Нет. Мне нужны алгоритмы "которые получат заметную пользу от SIMD можно вынести в _один пакет_ и бороться с максимальной оптимизацией там" которые уже вынесены. Пока Вы пирвели только один пример - liboil. Я могу Вам подкинуть ещё - fftw.

>Неглубоко копнув оказалось 310 пакетов использующих только libaio, про мплеер, atlas, openssl и пр. написано выше.

А если посмотреть сколько пакетов использует glibc... Вы видимо не поняли вопроса. Интересует не libaio, а liboil. Кто её использует непосредственно? atlas и openssl используют свои собственные библиотеки.

>Я четко вижу ассемблерные вставки, например atlas3-3.6.0/tune/blas/gemm/CASES/ATL_smm14x1x84_sse.

Может быть Вы чётко видите оптимизацию под размер кэша и другие оптимизации? Вы видимо считаете что оптимизации для набора инструкций SSE вполне достаточно? Это не совсем так.

>И четко вижу оптимизированные пакеты, с библиотеками, которые автоматически выбираются загрузчиком при линковке в зависимости от hwcap.

И для какого процессора? Для среднестатистического? Во время компиляции atlas выводит довольно подробную информацию по тестам и бенчмаркам.

>Выберут, к примеру SSE или SSE2

Т.е. из своего P4 2,8 Вы можете смело выкидывать некоторые блоки, ведь они не используются. А зачем тогда надо было покупать именно такой процессор? Надо было ограничиться только SSE или SSE2, а чтобы побыстрее работал - взять двух процессорную матплату.

В общем тут мне становиться понятно почему Вы не увидели причин по которым в набор инструкций SIMD включены скалярные инструкции.

>MMX-ом стали пользоваться редко, видимо потому, что целочисленная арифметика итак достаточно шустрая и процессор довольно неплохо оптимизирует поток команд, оптимально загружая параллельные блоки АЛУ

Вы опять так убеждённо об этом заявляете, как будто тестовый стенд у Вас в соседней комнате находится!

>и которые уже выдавлены по умолчанию на x86-64 это несерьезно.

ручную оптимизацию не сравнить с автоматической.

>Все 310 пакетов показать из вывода apt-rdepends -d -r liboil0.3?

Можно и так. Без переносов строк это займёт мало места. Только давайте без рекурсивных зависимостей, и только то, что прямо использует liboil.

>Задрот тот кто в выходной день ковыряется в моторе и орёт на всех кто пользуется услугами автосервиса что они ламеры поганые.

А как называть тех, кто тыкает пальцем в любящего поковыряться с мотором и называет его красноглазым, даже когда тот вообще никого не трогает? :)