Equinox Desktop Environment, обновление...

Начнём по порядку,

:В отличие от тебя, vm, я знаю причину "торможения" grep в fedore я не говорил что я не знаю причины, я говорил что она тормозит

:Уже не один раз говорилось, что особого эффекта это не даст, за исключением систем с "навороченным" железом повторюсь, но эффект просто впечатляющий - в разы, мой старый атлон 1300 я не считаю навороченным железом

:90% системного времени отъедается целочисленной арифметикой и пересылками подумай, НеДаша, сколько целочисленных регистров у атлона ? чему равен размер указателя ? секёшь ? вся арифметика ускоряется, вместо памяти многие функции могут использовать дополнительные регистры атлона. простой пример - повышение скорости сортировки, наложение масок на файлы, и естественно поиск(это области получающие сильную эффективность)

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

:Читай классику, студент. Так что думай, НеДаша - классик ты наш.

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

В идеале, любая программа не содержащая asm-вставок, должна компилится и уверенно работать с Л_Ю_Б_О_Й комбинацией невзаимоисключающих ключей. На данный момент в GCC включено множество вкусностей в смысле оптимизации - но результат их (совместного да и просто)использования, как правило, плачевный - хорошо если прога откомпилится без Internal bug ... Большой вопрос будет ли она еще и пахать 8)

Я не затрагиваю вопросы генерации кода (к примеру генерации mmx или sse инструкций ) - это другая и тоже болезненная тема.

Всё это добро дает крен то в одну, то в другую сторону (и конец судя по всему - еще ох как не близок)

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

Ды че там греха таить - сам gcc 3.x на первых порах не мог сам себя собрать даже с этим аскетическим набором опций (т.е. сделать make bootstrap).

Еще хочется отметить следующий факт -ffast-math и иже ей подобные, не всегда (зависит от версии gcc и пачей) подразумевает -mfancy-math-387 (аппаратная тригонометрия) - последнее, слава богу, работает достаточно стабильно и хорошо подстегивает соответствующие вычисления. То же касается и -mpush-args при -O2.

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

Зы : юзаю 3.2.3-postCVS (c выходом 3.2.3 его CVS еще продолжался несколько месяцев и туда успели всунуть кой-чего из 3.3 и 3.4 веток)

> В отличие от тебя, vm, я знаю причину "торможения" grep в fedore
> я не говорил что я не знаю причины, я говорил что она тормозит

Ты гонишь. В UTF8 grep и в gentoo тормозит. Это принципиальный минус UTF8. Алгоритмическая проблема, знаешь ли. Если же ты не можешь настроить KOI8-R в fedora, это твои проблемы. Точка.

> повторюсь, но эффект просто впечатляющий - в разы

Гон. Пурга. Лажа. Ложь. Вранье. Обман. Выбери любое из этих слов, но смысл один - _разов_ быть не может. Могут быть проценты - и даже десятки процентов, но только на _очень_ специфических счетных и околосчетных задачах. Синтетические "тесты", специально подогнаные под процессор, могут конечно дать и разы...

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

Не имеет смысла. 80% времени они проводят в ожидании - за исключением разве что gcc. Для gcc скорость работы в плюс-минус 10% некритична - системные администраторы им пользуются редко, разработчики (по сравнению со временем написания кода) тоже. Пользователям он вообще не нужен. Исключение из всех - мастур... То есть опытные сборщики типа тебя.

time { find /usr/share/doc 2>&1 >/dev/null; }
real 0m13.533s
user 0m0.027s
sys 0m0.131s

Разница между real и sys+user - это и есть ожидание, когда процесс ничего не делает. Даже если ядро и find будут работать в десять раз быстрее, пользователь выиграет одну десятую секунды - почти все время съело I/O и другие процессы (которые, на самом деле, спали :-)) Ну и какой смысл в такой оптимизации?

Еще один аргумент на засыпку - на одной из "самосборных" систем программа падает, на второй - не падает. Процессоры на системах разные. Вопрос - где ошибка, в программе, в библиотеках, в ядре, в кодогенераторе компилятора?

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

P.S.: зная вас, горячих гентоводов,добавлю, что повторение той же команды дает результат уже следующего вида real 0m2.440s, user 0m0.026s, sys 0m0.054s. Домашнее задание - получить примерно тот же результат при условии, что порядок количества файлов и каталогов в осматриваемом дереве 14000 (13958, если быть точным). Ну и не забыть сказать процессор и объем памяти :-)

Я не понимаю. Люди, которые говорят, что сборка LFS не дает увеличения скорости в разы! Вы ошибаетесь! Я не понимаю, может вы сами не пробовали это собирать? А, ну да, конечно, у вас же у всех стоят супер навороченные компы, на которых уже не заметен этот прирост. А у меня заметен. Очень даже заметен. Вам же куча людей говорит, что это действительно так. Неужели вы более склонны верить своей теории, чем реальному опыту?

PS Я ничего не говорю про оптимизацию O3,O2,.. Я не знаю, насколько она "быстрее". Я просто хотел сказать, что самому все собирать из исходников - это не бред. Для десктопа, конечно.

PPS Про UTF8. Я сравнивал локаль KOI8-R и UTF8. Так вот, на глаз никакого торможения utf-консоли нет.

2vm

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

я просто тихо какаюсь по полу ;))

hint: не знаю кто такие "сборщики" но о ключах gcc им лучше ничего не знать ;)

это исключительно прерогатива девелоперов - если чего не понял - info gcc до просветления ... хотя думаю это вряд ли поможет пока не напишешь чего нибудь своего с использованием этих самых фич gcc про которые ты видимо просто не имеешь представления

2sS:

bred, gde zhe konstruktivizm ?

svoego uzhe napisano nemalo i kljuchi kompiljazii ja znaju kak ispolzovat

2 Ne Dasha:

priezzhaj, ja tebe pokazhu, chto sistema spezialno vsja rekompilenaja pod atlon rabotaet VRAZI bistree. da chto s toboj sporit, kak baran upersja. Dlja takih kak ti mi i delajem distributivi. Ili ti schitaesh chto I/O operazii ne poddajutsja optimizazii ? Skompiliruij iksi s oprimizazijej, i pojmesh o chem rech. Konechno nikto ne predlagaet takuju sistemu dlja serverov, tak kak do stabilnosti daleko - no na Desktope ochen dazhe horosho - naprimer OpenOffice, mplayer, mozilla --- vse eto letaet.

>bred, gde zhe konstruktivizm ?

>svoego uzhe napisano nemalo i kljuchi kompiljazii ja znaju kak ispolzovat

Кусок Вашего кода который _использует_ -mmmx -msse -msse2 в студию

eh diletant, u menja ATHLON !!!

>eh diletant, u menja ATHLON !!!

;)))

Во блин клоун ;)

hint: ключики я взял исключительно из вашего первоначального поста написали - показывайте код где _это_ используется (можно и без -msse2)

короче тов. студент - идите ка и учите info gcc

ja takogo posta ne delal

vm

>ja takogo posta ne delal

Ага сейчас уже и не писал ;) Причем тем же транслитом ;))

ne moj eto post bil :)

Парень, по книге LFS линукс сможет собрать даже ребенок.

Что касается федоры - ты не делай вид, что ты слепой. Собираешь то, что крутится постоянно, под свой проц и у тебя случается счастье.

P.S. А что значит "шарит в компилировании"? :)

1. Мне вообще параллельно. Не я ставил, а друг - я с ним по телефону общался, т.к. он вообще в этом ничего не понимает.
2. Она и есть на интел.
3. Оказывается, это известная проблема FreeBSD с fujitsu и некоторыми BIOS'ами.
4. Что человеку дали на работе, то и мучает.
5. Винт живой, проверил у себя - suse 7.3 встал как влитой.

P.S. Ему фря нужна.

vm, учу. Ты когда пишешь с машин, где нет русского, используй www.translit.ru

У меня сейчас рабочий комп мягко говоря помоечный - 500 целерон.
Видно, что старт кде после пересборки идет быстрее и программки из его поставки бодрее работают и немного меньше грузят проц. (т.е. после персборки иксов, qt и kde :) Это приятно, но не более того.

Однако наибольший прирост скорости наблюдается не при пересборке, а при переходе на новую версию. 3.1 была быстрее 3.0, 3.2 сейчас быстрее 3.1

Старт программ улучшился при переходе на ядро 2.6.х.

Если программа не оптимизирована под сборку на тот или иной проц (как mplayer, например), то особой выгоды ты не получишь.

> Я ничего не говорю про оптимизацию O3,O2,.. Я не знаю,
> насколько она "быстрее". Я просто хотел сказать, что самому
> все собирать из исходников - это не бред. Для десктопа, конечно.

Ради интереса примерно с полгода назад я собирал и тестировал, сколько процентов прироста в скорости дала оптимизация под P4, в отличие от сборки под обычный i386. Так вот результат очень показателен - примерно 30% прироста к скорости. С учетом того, что шифрование - это как раз очень даже "синтетический" тест (алгоритм был сплощь заточен под u_int32_t, т.е. сугубо регистровые и "одноходовые" операции), результат, мягко говоря, "не впечатлил".

> Про UTF8. Я сравнивал локаль KOI8-R и UTF8.
> Так вот, на глаз никакого торможения utf-консоли нет

Колоссально :-) Предлагаю проверить на приведенном выше примере с regexp'ом, правильно ли grep у тебя работал. Только набор данных метров на десять ему дай, ок? И меряй не на глаз, а по команде time.

> Люди, которые говорят, что сборка LFS не дает
> увеличения скорости в разы!

См.выше.

> Я просто хотел сказать, что самому все собирать из
> исходников - это не бред. Для десктопа, конечно.

Да на здоровье. Только баги сам разгребай :-)

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

> na Desktope ochen dazhe horosho - naprimer OpenOffice,
> mplayer, mozilla --- vse eto letaet.

Да ты знаешь, оно и "так" не тормозит. :-)

2all "опытные сборщики" - пересобирайте что угодно и как угодно, у каждого свои правила.

2no-dash:

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

а вообще тема говно. кто не согласен тот не согласен :)

прикол, ядро 2.4.25 что то резво работает, не ожидал такого - мож кто знает в чём кампот ? мож бенчмарки есть какие нить ?

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

$ cat cpudemo.c
#include <stdlib.h>
int main() {
u_int32_t i,
a1=0,
a2=0xff00ff00,
a3=0xdd11dd11,
a5=0xe0f1cea3,
a6=0x0fc4e7a1;
for (i=0;i<2000000000;i++) {
a1 ^= a2;
a2 ^= a3;
a3 ^= a1;
if (a1 | 1) {
a3 ^= a2 ^ a1 + 1;
} else {
a1 ^= a2 ^ a3 + 2;
}
a5 ^= a3 | a1;
a6 ^= a5 | a2;
}
return 0;
}
$ cat dotest
#!/bin/bash
for arch in i386 athlon i686 pentium3
do
echo Testing $arch
gcc -O2 -mcpu=$arch -march=$arch -o cpudemo.$arch cpudemo.c
time ./cpudemo.$arch
echo
done

Результаты:

Testing i386

real 0m4.842s
user 0m4.329s
sys 0m0.017s

Testing athlon

real 0m5.179s
user 0m4.329s
sys 0m0.022s

Testing i686

real 0m4.491s
user 0m4.314s
sys 0m0.012s

Testing pentium3

real 0m4.465s
user 0m4.312s
sys 0m0.012s

Смотрим на "user" и говорим "сакс", поскольку дельта укладывается в статистическую погрешность. На самом деле, можно привести более приближенный к жизни тест (шифрование блочным шифром с обратной связью), там выигрыш будет заметней, особенно на больших объемах данных - но опять же, уложится в 5-10%. Оно вам надо? Тем более, что в коде GNOME и KDE "через шаг" идет вызов библиотечых функций.

Спокойно-лениво,

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

Вопрос в том что с писанины этой толку, как с козла молока.

Может я, конечно, заблуждаюсь - но что-то мне подсказывает, что мы так и не увидим кодека, к примеру, by VM, или еще чего путного 8)

Скромность украшает, или в школах этому уже не учат ? 8)

> Ради интереса примерно с полгода назад я собирал и тестировал, сколько процентов прироста в скорости дала оптимизация под P4, в отличие от сборки под обычный i386. Так вот результат очень показателен - примерно 30% прироста к скорости. С учетом того, что шифрование - это как раз очень даже "синтетический" тест (алгоритм был сплощь заточен под u_int32_t, т.е. сугубо регистровые и "одноходовые" операции), результат, мягко говоря, "не впечатлил".

А мне и не нужны синтетические тесты. Я имел в виду, что ИМХО пересборка из исходников дает прирост в скорости загрузки программ и скорости работы гуя. Например, firebird-0.7-i686 альтовской сборки у меня ужасно долго грузился и тормозил интерфейс. После пересборки меню почти перестало тормозить и загружаться стало гораздо быстрее. Кстати, собирал я под i686 -O3.

>> Про UTF8. Я сравнивал локаль KOI8-R и UTF8. >> Так вот, на глаз никакого торможения utf-консоли нет

>Колоссально :-) Предлагаю проверить на приведенном выше примере с >regexp'ом, правильно ли grep у тебя работал. Только набор данных >метров на десять ему дай, ок? И меряй не на глаз, а по команде time.

Хех, я же знаю, что utf8 медленнее окажется:). Прсто я хотел сказать, что "на глаз"(а это для меня более важно, чем тесты) скорости не различались. При типичных повседневных задач, а не специально подобранных тестов.

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

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

Я не "опытный сборщик", конечно, но если я вижу, что после моей пересборки у меня работает лучше/быстрее, я буду пересобирать сам.

> А мне и не нужны синтетические тесты. Я имел в виду, что ИМХО
> пересборка из исходников дает прирост в скорости загрузки программ
> и скорости работы гуя

А ты не думал, что оно может просто не задействовать или как раз задействовать какие-нибудь фичи, которые нашла в процессе configure, или просто привязываться к другой версиии библиотеки (которая стоит и собрана у тебя) вместо той, например, что стояла на компе для сборки в Alt'е?

> Хех, я же знаю, что utf8 медленнее окажется:). Прсто я хотел
> сказать, что "на глаз"(а это для меня более важно, чем тесты)
> скорости не различались.

Да, да, конечно - когда мне надо было сделать grep по файлу в 6KB с процентом попадания около 10, я тоже разниц в скорости не замечал - а вот когда потребовалось про'grep'ать 10МБ, вот тогда разница и полезла. Это так, о качестве измерения "на глазок" :-)

jackill (*) (22.02.2004 18:47:14) такая ошибка была мной замечена давно даже на правильных винтах решение такое выбирай установку минимум тока bin как поставиш тогда выбирай постинсталяционая установка и потом доставиш маны и сорцы ядра или че там те надо

во всех остальных случаях даже на пустой диск при копировании файлов выйдеш ета ошибка

еще там оно тупит с резольвом при установки с фтп надо сначала настроить сеть и выбрать фтп иначе оно тупит 2 минуты и может преобразовать днс а может и нет замечено в 47 49 51 52 другие не ставил

*** djelektronik

Синтетический тест говорите ;)

Хош я тебе такой "тест" разгоню в 100 ... нет в 1000 раз ;) ?

Причем именно этот код 1:1 (sic!) просто опциями gcc ;)

> А ты не думал, что оно может просто не задействовать или как раз задействовать какие-нибудь фичи, которые нашла в процессе configure, или просто привязываться к другой версиии библиотеки (которая стоит и собрана у тебя) вместо той, например, что стояла на компе для сборки в Alt'е?

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

> Да, да, конечно - когда мне надо было сделать grep по файлу в 6KB с процентом попадания около 10, я тоже разниц в скорости не замечал - а вот когда потребовалось про'grep'ать 10МБ, вот тогда разница и полезла. Это так, о качестве измерения "на глазок" :-)

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

2sS: говоришь, 1000 раз... Ок, хватит 500. Только со следующими условиями:

1. Если инициализировать aX не константами, а ramdom'ом, то суммарная скорость после пересборки с твоими ключиками должна падать не более, чем на время выполнения random'ов * 2

2. Промежуточные результаты не выбрасывать

3. Время на загрузку бинарника тоже считаем

Если согласен - и добъешься 500 кратной оптимизации - честно признаю, что я позорный ламер :-) Жду ключиков для 500-кратной оптимизации при назначенных условиях.

P.S.: а ты на что надеялся?

2init:

Про UTF8: а ты 40-ка мегобайтный файл grep'ал? А мне иногда приходится :-) Так вот сразу говорю - проблема скорости grep'а федоры НЕ в ключиках gcc, а в приципах организации UTF8

Про библиотеки:
>> А ты не думал, что оно может просто не задействовать или как
>> раз задействовать какие-нибудь фичи, которые нашла в процессе
>> configure, или просто привязываться к другой версиии библиотеки
>> (которая стоит и собрана у тебя) вместо той, например, что
>> стояла на компе для сборки в Alt'е?
>
>Естественно так и было. Но моя-то работает быстрей,
> значит и использовать я буду ее.

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

2no-dashi

Условие простое КОД НЕ МЕНЯТЬ - то есть использовать именно так как было написано ;)

Ну и gcc 3.x ... ну например 3.2.3

>2. Промежуточные результаты не выбрасывать 

;))) 

>Если согласен - и добъешься 500 кратной оптимизации - честно признаю, что я позорный ламер :-)

;))

ss@xantippe:~/$ gcc -O3 -fssa -fssa-ccp -fssa-dce cputest.c -o cpudemo_ssa

ss@xantippe:~/$ gcc -O3 cputest.c -o cpudemo

ss@xantippe:~/$time cpudemo 

real    0m3.062s
user    0m3.050s
sys     0m0.010s

ss@xantippe:~/$time cpudemo_ssa

real    0m0.002s
user    0m0.000s
sys     0m0.010s


;))

Фокус в том что современные оптимизирующие компиляторы стали настолько умными
что порой сами решают какой код должен исполнятся а какой нет. ;))

hint: чтобы цифры, выводимые в тесте имели хоть какой то смысл нужно
- либо собрать приведенный пример с -O0

- либо просто ВСТАВИТЬ printf() этих самых a1..a6 перед return
иначе gcc думает что они вам просто не нужны и .... просто их не вычисляет ;)

Только главное чтоб "опытные сборщики" не узнали бы про эти "волшебные ключики", а то глюков не оберешся ;) 

BTW:

>1. Если инициализировать aX не константами, а ramdom'ом, то суммарная скорость после пересборки с твоими ключиками должна падать не более, чем на время выполнения random'ов * 2 

после замены на 
u_int32_t i, 
 a1=rand(), 
 a2=rand(), 
 a3=rand(), 
 a5=rand(), 
 a6=rand(); 

результат абсолютно такой же ;)

2sS: итак, фактически просто получен измененный алгоритм, который на самом деле не считает ничего из того, что он должен бы посчитать. Вывод - значительного прирост производительности путем сборки "под процессор" добиться нельзя, толкьо изменением алгоритма. Впрочем, мы оюа это прекрасно знали :-)

2no-dashi (*) (24.02.2004 0:39:03)
>Специалистам надо работать, и иметь предсказуемое поведение системы.
Именно !!! Золотые слова %-)
>Найди администратора оракла, и предложи ему поставить "боевой" сервер на свой LFS - много интересного узнаешь и о себе, и о LFS
Скорее небо упадет на землю и Дунай потечет вспять, но Oracle на LFS в продакшн - да ну нах... :-)
P.S. LFS хорош для _домашних_ экспериментов и изучения системы, но на сервера - это садомазохизм :-)

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

Именно ;)

>Вывод - значительного прирост производительности путем сборки "под процессор" добиться нельзя,

Ну это что считать "значительным приростом" данный конкретный кусок кода (если его разумеется поправить) _можно_ разогнать только опциями процентов на несколько - речь идет о том что _этим_ нужно _уметь_ пользоваться. Разумеется модификация алгоритма примерно на порядок эффективней (но требует на 2-3 порядка больше рабочего времени)

Обычно кстати оптимизация идет под задачу+архитектуру+процессор (именно в таком порядке) а не под просто процессор, но разОв в производительности точно не получить

>Ты когда пишешь с машин, где нет русского, используй www.translit.ru

Херня всё это! По-моему стоит взять пример с японцев и сделать транслит вторым видом писменности(ну или как оно там называется), причем на государственном уровне. Вмиг бы куча проблем решилась. А сколько бы бабла сыкономили бы на всяких там кирилизациях-хуялизациях!