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

http://www.linux.org.ru/jump-message.jsp?msgid=2406675&cid=2413401

http://www.linux.org.ru/jump-message.jsp?msgid=2406675&cid=2413411

>$ objdump -d /usr/lib/i686/cmov/libcrypto.so.0.9.8|grep xmm|head 40154

Пожалуйста, назовите пакет которому принадлежит эта библиотека (желательно также указать дистрибутив).

openssl. debian testing и ubuntu 7.10. В генте раньше эта вставка включалась по USE=sse2.

> Конечно, никто не мешает это делать. А вот сделано ли это?

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

> Как эти изыски вляют на написание, сборку и дальнейшую работу приложения?

Как влияют? Естественно, ускоряют критические по произв-ти участки, используя SIMD расширения.

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

Чтобы было.

> А "как изменяется ассемблерный код в зависимости от тех или иных условий" Вам не интересно?

Набаловался уже. Мне система как инструмент нужна, а не как игрушка.

> Теоретизируете и считаете что полностью поняли как работает процессор

Можно сказать, в общих чертах за > 10 лет увлечения ассемблером для x86 и AMD64 (tasm,masm,nasm,gas).

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

В пределах знаний, полученных методом тыка и чтения документации.

> Тот скрипт был приведён в качестве примере, что если пакеты собраны
"Целевая архитектура: i486-linux-gnu " то некоторые оптимизации, и
расширения процессора не будут задействованы

То, что gcc собран под i486-linux-gnu не означает, что он не умеет
собирать код для p4 или prescott. Это должно быть очевидно. И
практика это подтверждает. Этот самый i486-linux-gnu-gcc вполне себе
может собирать код с ипользованием MMX,MMX2,SSE1-SSE3 с
соответствующими -march если использовать векторные расширения gcc,
ну или задать требование преобразовать все FPU инструкции в убогие
скалярные SSE с помощью -mfpmath=sse.

Да, кстати я был неправ насчет -mfpmath=sse. Польза все же есть ~
+10% к производительности на тесте "сферический конь в вакууме"(т.е.
на реальных задачах будет еще меньше). SIMD реально способно дать до
+100% .. +300% к производительности за счет параллельного выполнения
операции над несколькими парами скаляров и этот потенциал можно
раскрыть ассемблерными вставками.

anonymous@unknown:~/devel$ gcc -march=pentium4 test1.c -o test1
anonymous@unknown:~/devel$ ./test1
1000000000 iterations take 19510000 ticks to execute
anonymous@unknown:~/devel$ gcc -march=pentium4 -mfpmath=sse test1.c -o test1
anonymous@unknown:~/devel$ ./test1
1000000000 iterations take 17400000 ticks to execute
anonymous@unknown:~/devel$ cat test1.c
#include <stdio.h>
#include <time.h>

#define COUNT 1000000000

int main() {
double a,b,c,d,e,f,g,h,i,r;
a=b=c=d=e=f=g=h=r=5;
clock_t t1,t2;

t1=clock();

for(i=0;i<COUNT;i++) {
a+=1.0;
b+=1.0;
c+=1.0;
d+=1.0;
e+=1.0;
f+=1.0;
g+=1.0;
h+=1.0;
r=a+b+c+d+f+g+h;
}

t2=clock();

printf("%d iterations take %d ticks to execute\n",COUNT,t2-t1);

return 0;
}

P.S.

Если интересует поиграться с векторными расширениями GCC(если при сборке указана архитектура
которая не поддерживает SIMD используется эмулирующий код, в ином случае gcc автоматически
использует нативные SIMD инструкции), SSE и увидеть на что оно способно можно
посмотреть http://cut.and.paste.org/index.php?id=1843

$ ./sse


4-dimensional vectors(single precision float numbers) addition SSE effectiveness test


4000000000 iterations. Time elapsed = 16
4000000000 iterations using SSE. Time elapsed = 6

>deb http://deb.opera.com/opera/ sid non-fr

deb http://deb.opera.com/opera/ sid non-free

> Я могу пересматривать своё мнение :)

Я не совсем о бубунте говорил, скорее уж о гентушниках. ;) Впрочем это неважно.

> Если удастся добить (_штатными средствами_ :D) фейс Оперы

Кстати, если уж система для экспериментов, то кто мешает перенести сразу все юзерские конфиги из генты и посмотреть как это будет работать? Я, например, с дистрибутива на дистрибутив (дебиан - 5 по счету) приблизительно так и переползал. Лично я по-прежнему считаю, что проблема не в убунте, а в настройках оперы либо в настройках qt.

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

Я выше приводил пример меню OOo без SPR и Abiword с SPR.

>Кстати, если уж система для экспериментов, то кто мешает перенести сразу все юзерские конфиги из генты и посмотреть как это будет работать?

Чудовищно будет, ИМХО :)

>Лично я по-прежнему считаю, что проблема не в убунте, а в настройках оперы либо в настройках qt.

Я с таким на Gentoo первый и последний раз сталкивался года два назад на amd64, на, естественно, opera-32. Что-то там не увязывалось во враппинге. Со временем - починилось. Потом, правда, я с amd64 совсем слез.

...

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

Кстати, в http://deb.opera.com/opera/ я только 9.25 вижу. А мне 9.50 бета нужна, иначе, опять же, жена задолбается синхронизировать тонны своих закладок :)

В Gentoo у меня Опера каждую неделю полуавтоматом обновляется weekly-build'ами. В Убунте так можно?

>openssl. debian testing и ubuntu 7.10.

просто openssl? Я то ждал названия _пакета_: что-то вроде openssl-0.9.8-i586.deb...

>Чтобы было.

Это Вы как специалист с 10 летним стажем заявляете?

>Набаловался уже...

>Можно сказать, в общих чертах за > 10 лет увлечения ассемблером для x86 и AMD64 (tasm,masm,nasm,gas).

>В пределах знаний, полученных методом тыка и чтения документации.

Однако оказалось, что не всё ещё известно ;) И только когда профессиональное самолюбие было задето, Вы, наконец-то, запустили скрипт...

>Этот самый i486-linux-gnu-gcc вполне себе может собирать код с ипользованием MMX,MMX2,SSE1-SSE3 с соответствующими -march если использовать векторные расширения gcc,

Однако, как показывает ситуация по приведённой Вами выше ссылке, он ограничивается только х86 архитектурами. И опять интересный вопрос, почему же был выбран именно i486? Как отличается время сборки для i486 и prescott?

>Польза все же есть ~ +10% к производительности на тесте "сферический конь в вакууме"(т.е. на реальных задачах будет еще меньше).

Я думаю, Вы и так прекрасно понимаете, что 10% это уже очень не плохо. На счёт сферических коней: есть ли SIMD инструкции в liba52.so?

>SIMD реально способно дать до +100% .. +300% к производительности за счет параллельного выполнения операции над несколькими парами скаляров и этот потенциал можно раскрыть ассемблерными вставками.

А выбор алгоритма 1000% и более. От добра, добра не исчут.

>> http://slil.ru/25361698

>Ужоснах. Это где такая кривь-то? :D Подобного эффекта я ещё ни разу не видел :)

В KDE. После шаманства с DPI эффект ушел. Вернее стал слабо выражен, потому что все равно видно сглаживающие красные и зеленые пиксели если приглядеться.

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

У меня такое заметно только сантиметров с пяти от экрана :)

> просто openssl? Я то ждал названия _пакета_: что-то вроде openssl-0.9.8-i586.deb...

openssl_0.9.8g-3_i386.deb openssl_0.9.8e-5ubuntu3.1_i386.deb

> Это Вы как специалист с 10 летним стажем заявляете?

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

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

Да.

> И опять интересный вопрос, почему же был выбран именно i486?

Минимальные системным требования. sarge на x86 поддерживал процессоры i386 и выше. В релизе etch выкинули поддержку i386 - стало i486 и выше.

> Как отличается время сборки для i486 и prescott?

Реально этот gcc собран с "-march=i486 -mtune=pentium4". Интересно, конечно, сравнить на практике, но уж шибко долго возиться.

> Я думаю, Вы и так прекрасно понимаете, что 10% это уже очень не плохо.

10% из возможных 100% или даже 300% это очень малый КПД. Как было показано выше ассемблерная вставка сокращает время операции сложения над 4-мерными векторами с 16 секунд до 6, т.е. на 167%, а здесь какие-то +10% в идеальном случае.

> На счёт сферических коней: есть ли SIMD инструкции в liba52.so?

Нет.

> А выбор алгоритма 1000% и более. От добра, добра не исчут.

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

> Я с таким на Gentoo первый и последний раз сталкивался года два назад на amd64, на, естественно, opera-32.

Сборка оперы с официального сайта deb.opera.com? Лично я с такими спецэффектами не сталкивался ни разу в дебиане 3.1,4,testing ни в убунте 7.04, 7.10.

И, кстати flashplugin-nonfree был починен в соответсвии с новыми md5sums: http://fr.archive.ubuntu.com/ubuntu/pool/multiverse/f/flashplugin-nonfree/fla.... В hardy - пофикшенная версия. К сожалению в репозитарии gutsy так и не обновили. Ну хоть официальное решение есть. Хотя мантейнерам низачот.

> Вообще, в Убунте не нравится то, что со многим нужным мне софтом извращаться приходится ручками.

Например?

> И как в будущем обновляться ещё это всё будет?

Пакеты, с которыми проводились извращения можно за-hold-ить. Самосборные пакеты именуется так, что официальные обновления результаты трудов не перебьют, например: pure-ftpd_1.0.21-custom1.

> Кстати, в http://deb.opera.com/opera/ я только 9.25 вижу.

deb http://deb.opera.com/opera-beta/ lenny non-free

> В Gentoo у меня Опера каждую неделю полуавтоматом обновляется weekly-build'ами. В Убунте так можно?

Подключаешь вышеуказанную официальную репу оперы и будет то же самое. Есть еще официальная репа wine, samba - вобщем тот софт, который стоит держать в самом свежем состоянии, потому что ошибок и неимплементированных функций там еще много. Плюс есть еще gutsy-backports, куда выборочно бэкпортируют свежие программы.

>deb http://deb.opera.com/opera-beta/ lenny non-free

Ага, понятно. До lenny/non-free я не добрался :) (в итоге скачал и поставил .deb вручную - интерфейс стал нативным)

>> Вообще, в Убунте не нравится то, что со многим нужным мне софтом извращаться приходится ручками.

>Например?

Ну, минус Опера из этого списка.

Из нужных на машине жены вещей - осталось только с непатентованным SPR разобраться и ей хватит. Ну а сам - на Gentoo ;)

> Я выше приводил пример меню OOo без SPR и Abiword с SPR.

Только OOo без SPR. http://www.linux.org.ru/jump-message.jsp?msgid=2406675&cid=2414366

А вообще, факт в том, что в дебиане и убунте напильник для того, чтобы включить BCI не нужен, openoffice собран с системным libfreetype и субпиксельный рендеринг включается в пару кликов. Так что все, что достиг a110c после часов задротства с компилятором - это искаробочное состояние freetype и openoffice в ubuntu. Чем меньше нужен бубен - тем качественней дистрибутив, в идеале юзер вообще не должно танцевать с бубном и что-либо компилировать, а "заточка под себя" должна осуществляться на уровне настроек/плагинов/модулей. С подходом gentoo GNU/Linux так бы и остался системой только для продвинутых гиков, которые любят поковыряться с системой и ради пары процентов к производительности готовы убить кучу времени...

>> и с тормозным emerge который рисует /-\- минуты две перед тем как начать собирать.

>Открытие - Gentoo - многозадачная система. И пока "emerge рисует /-\-" - можно пойти на ЛОР, послушать музыку, поредактировать документ в OOo, попрограммировать в Eclipse.... ___<нужное вписать>___.

А можно использовать другой пакетный менеджер - paludis, который работает гораздо быстрее

Дурацкий вопрос, где в Убунте спрятаны эти настройки: http://ubuntuforums.org/showpost.php?p=3430886&postcount=40

...

И ещё - как поставить (опять же, штатно) fglrx? Оказывается, там - vesa. Система -> Администрирование -> Менеджер проприетарных драйверов просто не запускается. Нажимаешь - ничего не происходит. Если выбрать fglrx в разделе "Экраны и графика" там же, то при нажатии на "Тест" экран программы просто закрывается.

В ~/.xsession-errors в конце только:

ERROR: ld.so: object 'libjvm.so' from LD_PRELOAD cannot be preloaded: ignored.
ERROR: ld.so: object 'libawt.so' from LD_PRELOAD cannot be preloaded: ignored.
Предупреждение менеджера окон: неверный параметр WM_TRANSIENT_FOR окна 0x3f указан для 0x3000002 (Welcome to).
Предупреждение менеджера окон: неверный параметр WM_TRANSIENT_FOR окна 0x3f указан для 0x3000496 (Mailer err).

(operapluginwrapper:6715): Gtk-CRITICAL **: gtk_widget_destroy: assertion `GTK_IS_WIDGET (widget)' failed
checking for valid crashreport now
checking for valid crashreport now
opera: Plug-in 6715 is not responding. It will be closed.
opera: Define environment variable OPERA_KEEP_BLOCKED_PLUGIN to keep blocked plug-ins.
on_button_test_config_clicked()
Got pid 7166
(0, 0)
displayconfig-gtk: Fatal IO error 104 (Connection reset by peer) on X server :9.0.
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSchecking for valid crashreport now
checking for valid crashreport now

>А можно использовать другой пакетный менеджер - paludis, который работает гораздо быстрее

Но вот с ним, как раз, нужно много прикладывать руки :)

> На счёт сферических коней: есть ли SIMD инструкции в liba52.so?

Кстати, обнаружилась интересная вещь. Очень многие пакеты, включая кодеки gstreamer, pulseaudio, libswfdec и так далее используют некую liboil:

Описание: Library of Optimized Inner Loops
Liboil is a collection of functions that often benefit from having special
implementations on various architectures or CPUs. Each function in liboil has
several implementations which may perform faster or slower on a given CPU.
Some implementations use alternate algorithms, some use hand-crafted assembly,
and some use special instructions that are only available on certain CPUs, such
as MMX, SSE, or Altivec. The fastest implementation is automatically chosen at
runtime.

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

$ objdump -d /usr/lib/liboil-0.3.so.0.1.0 |grep cpuid
137c0: 0f a2 cpuid
$ objdump -d /usr/lib/liboil-0.3.so.0.1.0 |grep xmm|wc -l
966

Так что вот она, динамическая оптимизация под SIMD там где это нужно,
безо всяких танцев с бубном вокруг cflags и сборок часами, уже здесь
и сейчас - в openssl, mplayer, кодеках gstreamer, pulseaudio, флеше и многом другом!
Тенденции говорят сами за себя: технологичное использование
динамически оптимизированных алгоритмов и модулей ядра вместо
красноглазтия с пересборкой по камень и выкидывания "лишнего из ядра",
которое лежит в модулях и никому не мешает.

> И ещё - как поставить (опять же, штатно) fglrx?

Можно использовать уже собранный модуль, которые есть в linux-restricted-modules искаропки. Драйвер видеокарты можно выбрать в центре управления "экраны и графика". Хотя я, честно говоря, правил xorg.conf ручками. Можно как вариант скачать самый свежий драйвер ati-driver-installer-7-11-x86.x86_64.run(конечно, менее удобно, чем emerge ati-drivers, зато ебилдонезависимо :) ) и либо установить ./ - там GTK-шный инсталлятор next-next-ok :), либо --help. Там есть генерация пакетов "--build-pkg Ubuntu/gutsy". Генерятся пакеты. Cобранные бинарные модули ядра атишники не дали, поэтому придется собирать. Далее dpkg -i *.deb. Далее запускается графическая ncurses морда сборки модулей m-a и в ней выбирается, собирается и ставится пакет fglrx.

Попробуй sudo restricted-manager -d fglrx

Вернее, sudo restricted-manager -e fglrx

Опа внимательно смотрим на образец гентушника.
1. Купи азбуку - одному с деревянной ж..й это помогло стать человеком. И перестань посты в кучку собирать от разных людей.
2. Ну вот теперь я запускаю и вижу всё как надо дальше что?
3. Расскажи какая разница аж интересно. Или у тебя ум за разум заехал? Вот в этих патчах лежит добавочки как видно к freetype. Они включают всё что надо и bci и spr. Собирается по умолчанию мейнтейнером. Я просто ставлю а не занимаюсь не знамо чем.Также и всё остальное нормально собрано. А ты давай мозги напрягай.

>1) Ты слеп как крот. Купи ачки.
>
>2) Тебе написали уже про BCI и SPR. Запусти xmag, если ачков нет.
>
>3) Ты ниасилил разницу между "./configure --with-system-freetype",
>"#define TT_CONFIG_OPTION_BYTECODE_INTERPRETER" и командой patch.

Опа внимательно смотрим на образец гентушника.
1. Купи азбуку - одному с деревянной ж..й это помогло стать человеком и тебе поможет. И перестань посты в кучку собирать от разных людей.
2. Ну вот теперь я запускаю и вижу всё как надо дальше что?
3. Расскажи какая разница аж интересно. Или у тебя ум за разум заехал? Вот в этих патчах лежит добавочки как видно к freetype. Они включают всё что надо и bci и spr. Собирается по умолчанию мейнтейнером. Я просто ставлю а не занимаюсь не знамо чем.Также и всё остальное нормально собрано. А ты давай мозги напрягай.

> в дебиане и убунте напильник для того, чтобы включить BCI не нужен

И где он там включается без пересборки freetype?

>>А можно использовать другой пакетный менеджер - paludis, который работает гораздо быстрее

>Но вот с ним, как раз, нужно много прикладывать руки :)

Отнюдь. Конечно больше приходится use флагов в конфиг файлах писать по пакетно, но за то он работает быстрее, надежнее, его аналог revdep-rebuilda гораздо мощнее, имеет режим --continue-on-failure if-satisfied , проверка зависимостей при удалении

>Отнюдь.

Я на нём около двух месяцев сидел. Исключительно на своём упорстве. В итоге воевать с ним надоело и откатился обратно на emerge :) Я же не раз уже отмечал, что ленив очень. Не люблю много с компом ковыряться, предпочитаю, чтобы он сам работал :D

>Вот в этих патчах лежит добавочки как видно к freetype. Они включают всё что надо и bci и spr. Собирается по умолчанию мейнтейнером.

А я ещё раз повторю вопрос.

1. Где в Ubuntu взять патентованный SPR. То, что я вижу сейчас - это SPR, но весьма паршивый.

2. Как в Gutsy добраться до этих настроек: http://ubuntuforums.org/showpost.php?p=3430886&postcount=40

Ну мы же разобрались в прошлый раз что у меня не бубунту а отечественный дистриб:)) А то что тут ещё какой-то аноним постит по поводу всего рабочего ис_каропки то тут я не копенгаген.

>Ну мы же разобрались в прошлый раз что у меня не бубунту а отечественный дистриб:))

Хорошо, разберусь итак как-нибудь, но нельзя ли посмотреть на твой скрин с примером патентованного spr на "отечественном дистрибутиве"? :)

Ну вот, дошёл уже до компиляции ядра. Пока общее впечатление об Убунте - пока всё строго по прямой - всё прекрасно. Шаг влев / шаг вправо - всё кошмарно... (пытаюсь последние версии fglrx заставить работать)

>openssl_0.9.8g-3_i386.deb openssl_0.9.8e-5ubuntu3.1_i386.deb

А почему он оказался в /usr/lib/i686 ?

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

Если Вы не видите, это не значит что её нет. Соображения бывают очень интересные и неочевидные.

>Минимальные системным требования. sarge на x86 поддерживал процессоры i386 и выше. В релизе etch выкинули поддержку i386 - стало i486 и выше.

Опять же вопрос: так трудно поддерживать пакеты i586, i686... prescott (...core)? Или Вы считаете что оборудование надо брать с запасом, как раз на случай не оптимальных программ?

>10% из возможных 100% или даже 300% это очень малый КПД. Как было показано выше ассемблерная вставка сокращает время операции сложения над 4-мерными векторами с 16 секунд до 6, т.е. на 167%, а здесь какие-то +10% в идеальном случае.

На Ваш взгляд лучше отказаться от 10% прироста сейчас, и долго и упорно дорабатывать программу? Заметьте, во всех проектах не идут дальше ассемблерных вставок в критичных местах, если компилятор предлагает вариант автоматической оптимизации, почему бы не попробовать её в остальных местах? Копейка - рубль бережёт!

>> На счёт сферических коней: есть ли SIMD инструкции в liba52.so?

>Нет.

А у меня есть. Посмотрите исходник. Подумайте. Если здесь тоже прирост около 10%, то это очень хороший повод использовать оптимизатор gcc...

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

Предлагаете везде писать ассемблерные вставки? Вы этим готовы заняться, скажем для 5 архитектур и 20 пакетов?

>ценой большей сложности сопровождения

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

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

Пожалуйста, по конкретней. Что значит: "нет политики stable", "дополнительные проблемы", сколько часов и киловатт энергии. А то ведь опять выясниться что Вы подразумевали одно, а писали другое...

>Так что вот она, динамическая оптимизация под SIMD там где это нужно,
безо всяких танцев с бубном вокруг cflags и сборок часами, уже здесь
и сейчас - в openssl, mplayer, кодеках gstreamer, pulseaudio, флеше и многом другом!

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

$ equery d liboil
[ Searching for packages depending on liboil... ]

media-libs/gst-plugins-base-0.10.15 (>=dev-libs/liboil-0.3.8)
media-libs/gst-plugins-good-0.10.6 (>=dev-libs/liboil-0.3.6)
media-sound/pulseaudio-0.9.8-r6 (>=dev-libs/liboil-0.3.0)
(>=dev-libs/liboil-0.3.6)

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

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

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

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

>Ну мы же разобрались в прошлый раз что у меня не бубунту а отечественный дистриб:))

Может быть Вы просветите что значит --with-system-altlinuxhyph

> Предлагаете везде писать ассемблерные вставки? Вы этим готовы заняться, скажем для 5 архитектур

Не 5. Тратить уйму времени ради оригиналов которые хотят юзать KDE на какой-нибудь Alpha? Даже с PPC заморачиваться уже нет смысла - маки тоже перешли на x86.

Да, напомню, что собираться и работать оно всё равно будет на всех архитектурах на которые вообще портировано, а эти ускоряющие ассемблерные вставки будут применяться только при сборке под x86. Любители PPC если хотят пусть пишут рядом своё.

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

>А не мучает то, что в "тонкой" системе будет куча неиспользуемого дерьма, такого как неисполняемые ветвления, лишние проверки, неиспользуемые параметры командной строки и т.д. которые невозможно отключить опциями конфигурирования и USE-флагами? Не пробовал собирать себе grep и bash, заточенные под себя, без лишнего "дерьма"? Абсурд? Вовсе нет - еще более тонкая настройка системы "под себя" чем позволяют USE-флаги. :) А если честно, то я считаю USE-флаги таким же абсурдом, как кастрирование grep или sed с выкидыванием из них лишних ключей и неунжного функционала.

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

Я же говорил что функционала в ядре не хватает по этому приходится патчить и пересобирать ядро и при этом глупо не оптимизировать его под свои нужды и своё железо!

А что они ещё до сих пор загружают и останавливают всю систему? Их мега универсальные дистры не имеют suspend2?

>Не 5. Тратить уйму времени ради оригиналов которые хотят юзать KDE на какой-нибудь Alpha? Даже с PPC заморачиваться уже нет смысла - маки тоже перешли на x86.

Ну как же, надо написать поддержку: MMX, SSE, SSE2, SSE3, SSE4, 3dnow, 3dnow+ и их комбинаций с x86_64

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

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

> Поддержка BCI в freetype есть.

На скриншоте не видно.

> $ zcat openoffice.org_2.3.0-1ubuntu5.3.diff.gz |grep with-system-freetype|wc -l 13

Твои грепы ничего не доказывают. "Есть в исходниках" не означает "работает". См. директиву #ifdef.

> И перестань посты в кучку собирать от разных людей.

> anonymous (*) (16.01.2008 15:38:58)

Ржунимагу, самонумеруйся, анонимус.

> 1. Где в Ubuntu взять патентованный SPR. То, что я вижу сейчас - это SPR, но весьма паршивый.

У меня на втором ноуте Деб-testing, фонты и там и на Генте виндовые. На Дебе выглядят заметно хуже, чем на Генте. Пилить Деб смысла не вижу, тем ведь типа "искаропки" всё должно работать. Гентовые не мучал, проверил ls /etc/fonts/conf.d/, добавил пару ссылок, удалил пяток ненужных.

Проверял гентушную конфигурацию (читал конфиги freetype), меня она полностью устроила. На других системах (на Слаке, к примеру), я конфигурил всё именно так, как Гента изначально собрана (за исключением ссылок в /etc/fonts/conf.d/, но их мейнтейнеры за меня в принципе настроить для меня не могут).

>Вот вместо того, чтоб трахаться с гентой, сел бы, да перевел. Благо говоришь у тебя уже есть перевод в генте. И жене было бы приятно, и отдача какая-то. Дык нет же, гентушнеги вместо того, чтоб пользу сообществу приносить, только и могут что критиковать.

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

> И где он там включается без пересборки freetype?

http://archive.ubuntu.com/ubuntu/pool/main/f/freetype/freetype_2.3.5-1ubuntu4...

http://ftp.de.debian.org/debian/pool/main/f/freetype/freetype_2.3.5-1.diff.gz

$ zcat freetype_2.3.5-1ubuntu4.diff.gz |grep BYTECODE
+-/* #define TT_CONFIG_OPTION_BYTECODE_INTERPRETER */
++#define TT_CONFIG_OPTION_BYTECODE_INTERPRETER
+ #define TT_CONFIG_OPTION_BYTECODE_INTERPRETER
+ * [ftoption.h]: #define TT_CONFIG_OPTION_BYTECODE_INTERPRETER

>Можно только переключить - нативный / оперовский.

Как? у меня установлена 9.50_beta1 и нативно выглядят только меню

> То, что я вижу сейчас - это SPR, но весьма паршивый.

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

> Где в Ubuntu взять патентованный SPR.

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

Is FreeType 2 Affected by the Patents?

The answer is no for any recent build of FreeType 2, since it comes with an ‘auto-hinting’ module that was specifically designed to completely ignore the TrueType bytecode instructions.

However, the source code for the bytecode interpreter is still available and can be toggled on at compile time, for those that want to use it anyway (because they purchased a license from Apple, or because they are in a country where the patents do not apply, etc.).

http://freetype.sourceforge.net/patents.html

> 2. Как в Gutsy добраться до этих настроек: http://ubuntuforums.org/showpost.php?p=3430886&postcount=40

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

>Отнюдь. Конечно больше приходится use флагов в конфиг файлах писать

я его снес после того как он мне список установленных пакетов рисовал 5 минут. Да и не все возможности emerge в нем есть. В то время как для emerge есть обвязки, которые сводят на нет все преимущества paludis (emwrap.sh и update-live-ebuilds)

> Ну вот, дошёл уже до компиляции ядра. Пока общее впечатление об Убунте - пока всё строго по прямой - всё прекрасно. Шаг влев / шаг
вправо - всё кошмарно... (пытаюсь последние версии fglrx заставить
работать)

Для того, чтобы было все прекрасно надо разобраться с системой, с
module-assistant, make-kpkg. И тогда, поверь, все будет
хорошо(насколько это позволяют недодрайвера ATI):


$ dpkg -l|grep fglrx-kernel
ii fglrx-kernel-2.6.22-14-generic 8.433-1+2.6.22-14.47 ATI binary kernel module for Linux 2.6.22-14-generic
ii fglrx-kernel-source 8.433-1 Kernel module source for the ATI graphics accelerators

Или, к примеру ручная сборка ядра:

$ dpkg -l|grep custom
ii linux-image-2.6.23.11custom 1 Linux kernel binary image for version 2.6.23.11custom

Cижу все равно на дистрибутивном, потому что в нем есть все что надо
и оно работает искаропки, под него заточены и restricted-modules и
ubuntu-modules. За цифрами не гонюсь - ушла тяга с дикому оверклоку с
замыканием контактов в сокетах на платах которые автоматически
определяли FSB и питание по VRM, ушла тяга к гонке версий программ
вместе с виндой и увлечение ковырянием все свободное время системой
тоже. Gentoo и, думаю, LFS - отличные системы чтобы досконально
изучить как работает GNU/Linux и научиться серьезной диагностике и
устранению возникающих косяков. Каждому айтишнику Linux-гуру
рекомендую пройти через это. Но постоянно тратить время на сборки
неправильно. Пользователь не должен что-либо собирать - это работа
разработчиков, мантейнеров дистрибутивов, разработчиков встраиваемых
систем или программно-аппаратных комплексов. Это аксиома. Система
должны быть достаточно умной, чтобы самостоятельно поднимать модули
для установленного железа, загружать прошивки и не делать из
пользователя гика, который ради включения аналога ClearType должен
залезать в далекие дебри исходников. Именно поэтому Ubuntu, взявшая
мощную технологичекую базу из Debian и поставившая во главу угла
Linux на десктопе для людей, хорошо подходит на титул настольной
системы, хотя и есть некоторые косяки(пофиксят. где их нет?) и на
выполнение почетной миссии по устранению бага #1 https://
bugs.launchpad.net/baltix/+bug/1 не на словах, а на деле, хладнокровно без эмоций воплощая "виндекапец"

Microsoft has a majority market share

Ubuntu Confirmed Critical Mark Shuttleworth

И популяризация будет жестким испытанием для GNU/Linux, когда среди
пользователей появится куча не фанатов, а обычных пользователей,
которые не станут закрывать глаза на недостатки открытого софта,
которые не захотят лезть в консоль, не захотят выслушивать объяснений
по поводу отсутствия спецификаций на железо и т.д. Только открытое
столкновение с пользователем без розовых очков в полный контакт может
показать готов ли Linux для массового десктопа или нет, выплывет или
утонет.

> > То, что я вижу сейчас - это SPR, но весьма паршивый.

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

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

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

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

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

Бубунта чё-то молотит, якобы собирая исходники. Процесс от тебя скрыт и ты даже не врубаешься, как именно собирается пакет. Смотрим в книгу -- видим фигу. Вроде патчи есть, вот ты и думаешь, что всё ok. Говённые фонты ты наблюдал с первого твоего дня в Линуксе, вот ты и доволен как слон после купания.

> А почему он оказался в /usr/lib/i686 ?

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

~$ ldconfig -p|grep "ssl.*hwcap" libssl.so.0.9.8 (libc6, hwcap: 0x0008000000008000) => /usr/lib/i686/cmov/libssl.so.0.9.8 libssl.so.0.9.8 (libc6, hwcap: 0x0004000000000000) => /usr/lib/i586/libssl.so.0.9.8 libssl.so.0.9.8 (libc6, hwcap: 0x0002000000000000) => /usr/lib/i486/libssl.so.0.9.8

> Если Вы не видите, это не значит что её нет. Соображения бывают очень интересные и неочевидные.

Соображение может быть такое: выкинуь FPU, выкинуть ненужную совместимость с i387 и выполнять операции с плавающей точкой над двумя скалярами в блоке SSE, вырожденный случай SIMD.

> На Ваш взгляд лучше отказаться от 10% прироста сейчас, и долго и упорно дорабатывать программу? Заметьте, во всех проектах не идут дальше ассемблерных вставок в критичных местах, если компилятор предлагает вариант автоматической оптимизации, почему бы не попробовать её в остальных местах? Копейка - рубль бережёт!

Я считаю, что разгребать гиморрой и тратить часы на сборку ради копеек производительности с учетом того, что во многих местах где есть заметная польза от использования SIMD оно итак используется. перспектив у такого подхода нет, потому что AMD64 вытесняет x86, а на AMD64 уже включен и -mfpmath=sse и автовекторизатор и набор инструкций - не i486, а AMD64. Хотя и мешать уникумам, которые реально видят проценты прироста и вместо установки нормального 64-битного железа на задачи, требующие максимальной производительности, развлекаются мегаоптимизаций под устаревшее x86, не буду.

> Опять же вопрос: так трудно поддерживать пакеты i586, i686... prescott (...core)?

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

> А у меня есть. Посмотрите исходник. Подумайте.

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

> Если здесь тоже прирост около 10%, то это очень хороший повод использовать оптимизатор gcc...

Становиться мантейнером-сборщиком и убивать кучу времени и электроэнергии на сборку только ради созерцания самого факта наличия инструкций SSE - плохой повод. Смешно, например, убить полчаса на сборку ради ускорения на пару секунд при конвертировани аудио. Подумайте. Хотя, если бы бесплатный прирост в пару процентов был бы из коробки отказываться было бы глупо.

> Предлагаете везде писать ассемблерные вставки?

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

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

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