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

Ага. И с glibc та же фигня... Сами разработчики говорят, что лучше не надо :)

>Согласись, что 5% прироста на k6-2 (300?) и 5% прироста на P4/2.8 -- >это две большие разницы.

Спорить глупо. k6-2 450->500 :)

>В первом случае прирост вовсе не мудрено не заметить.

Возникает вопрос. Почему я заметил _сильное_ отличие при переходе от мандрейк на слаку? Это не для флейма. Я просто реально не понимаю почему так...

>При всем уважении к твоему железу.

А че железо то уважать? Работать дает, музыку играет, фильмы кажет, ну х?й с ней.

>Ага. И с glibc та же фигня... Сами разработчики говорят, что лучше не надо :)

Да, с glibc я прогнал, оказывается. ;) Он тоже на O2 прямо в ebuild'е залочен. Упустил... Значит влияние O3 на производительность приложений выше, чем я полагал, раз glibc тут не при чем.

>Возникает вопрос. Почему я заметил _сильное_ отличие при переходе от мандрейк на слаку? Это не для флейма. Я просто реально не понимаю почему так...

Я не могу ответить на твой вопрос. Слака была моим первым дистрибутивом (Slackware96 3.1) и уважаема мной до сих пор, но я должен сам попробовать то, что пробовал ты, чтобы сказать что-то определенное.

2Demetrio: Ты слаку из последних не пробовал? Реально она летает по сравнению с мандрейком?

>А че железо то уважать?

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

2 dave

/* Другими словами, в самом языке C есть пара вещей, которые мешают проведению оптимизации. */

Прикольно! Надо отучаться от гадкой привычки использования указателей в Си. :-J Оптимизация-то страдает!

Если хочешь отучаться - то никто тебе в этом помешать, конечно, не сможет.

P.S. Ты какое логикой пользуешься? Где её можно купить?

В принципе , я полностью перешёл на Эксперементальную Gentoo`у Всю , инфу , которую скидывают на Gentoo` форуме использую , Т.е. всё , что с masked * -* ;) Да бывают , траблы конечно , но это в основном из-за того , что portage pre13 еле-еле продвигают с gcc 3.5 & 3.4 ;)Приходится юзать тогда i686-pc-linux-gnu-3.3.3 + portage - r9 . На глаз видно ну процента 3-5 % прироста,может комп очень слабый , по сравнению со старой gentoo`й . А ещё собрал glibc-2.3.4-20040619 - отсальные снапшоты не собираются :( Обидно Всё равно советую попробовать reiser4 + reier4progs , ну хотя бы на /usr/portage -

А , кто-нибудь попробовал gcc - 3.5 из снапшотов собрать ? Какие флаги юзаете ? Я слышал , что собираются пока проги только под OO

> Даже обычная команда ls выполнялась быстрее в каталогах с большим количеством файлов

Объясняю на пальцах: скорость работы ls зависит на 95% от текущего состояния кэша.

>Объясняю на пальцах: скорость работы ls зависит на 95% от текущего состояния кэша.

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

> Прикольно! Надо отучаться от гадкой привычки использования указателей в Си. :-J Оптимизация-то страдает!

Забавно, конечно :)

Правда стоит заметить, что при использовании архитектуры PDP-11 [и различных ее продолжений, таких как VAX] многие операции с указателями естественными образом "ложатся" на ассемблерный код. Там есть очень мощная косвенная адресация. Возможно, для такой архитектуры оптимизация работы с указателями не особо-то и нужна. Но вот, x86...

>Значит влияние O3 на производительность приложений выше, чем я полагал, >раз glibc тут не при чем.

Особенно на ls :) Без обид. :)

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

Да проехали уже.

Я просто знаю всего одну прогу, которую _стоит_ пересобирать из исходников -- mplayer. Но там дело осбое #ifdef ... А все остальное от лукавого. ИМХО

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

Адресуется прочесть всем "оптимизаторам".

Тест: пишем две небольшие программки с тупым, но активно
использующим процессор алгоритмом примитивной сортировки
(как известно, сортировку можно назвать типичным тестом на
скорость базовых инструкций mov/jmp/cmp).

Тестовые программы собираются с флагами оптимизации -O2 и -O3 с
указанием -march/-mcpu=i386, i686, pentium3 и pentium4. Также
указывался флаг -fregmove.

Примеров два, один целочисленный (сортировка массива в 65536
элементов типа int), второй для плавающей точки (32768 элементов
типа double).

Исходник cpu_demo1.c:

#include <stdio.h>
#include <stdlib.h>

void do_sort(int * lst, int cnt) {
    int i,j,k;
    for (i=0;i<cnt-1;i++) {
        for (j=i+1;j<cnt;j++) {
            if (lst[i]>lst[j]) {
                k=lst[i];
                lst[i]=lst[j];
                lst[j]=k;
            }
        }
    }
}

#define maxlen  65536

int main() {
    int i;
    int * lst = (int*) malloc( sizeof(int) * maxlen );
    for (i=0;i<maxlen;i++) {
        lst[i] = maxlen-1-i;
    }
    do_sort(lst,maxlen);
    free(lst);
    return 0;
}

Файл cpu_demo2.c:

#include <stdio.h>
#include <stdlib.h>

void do_sort(double * lst, int cnt) {
    int i,j,k;
    for (i=0;i<cnt-1;i++) {
        for (j=i+1;j<cnt;j++) {
            if (lst[i]>lst[j]) {
                k=lst[i];
                lst[i]=lst[j];
                lst[j]=k;
            }
        }
    }
}

#define maxlen 32768

int main() {
    int i;
    double * lst = (double*) malloc( sizeof(double) * maxlen );
    for (i=0;i<maxlen;i++) {
        lst[i] = maxlen-1-i;
    }
    do_sort(lst,maxlen);
    free(lst);
    return 0;
}

Результаты прогонов на Celeron 2GHz (архитектура P4):

Для целочисленной арифметики:

cpu_demo1.i386.o2 8.95
cpu_demo1.i386.o3 9.09
cpu_demo1.i686.o2 9.02
cpu_demo1.i686.o3 9.12
cpu_demo1.pentium3.o2 8.95
cpu_demo1.pentium3.o3 9.10
cpu_demo1.pentium4.o2 8.91
cpu_demo1.pentium4.o3 9.06

Для арифметики с плавающей точкой:

cpu_demo2.i386.o2 11.06
cpu_demo2.i386.o3 10.68
cpu_demo2.i686.o2 9.91
cpu_demo2.i686.o3 10.41
cpu_demo2.pentium3.o2 9.94
cpu_demo2.pentium3.o3 10.44
cpu_demo2.pentium4.o2 5.23
cpu_demo2.pentium4.o3 5.14

Теперь результаты без -fregmove:

cpu_demo1.i386.o2 9.27
cpu_demo1.i386.o3 9.12
cpu_demo1.i686.o2 9.35
cpu_demo1.i686.o3 9.20
cpu_demo1.pentium3.o2 9.48
cpu_demo1.pentium3.o3 9.23
cpu_demo1.pentium4.o2 9.55
cpu_demo1.pentium4.o3 9.19

cpu_demo2.i386.o2 10.97
cpu_demo2.i386.o3 10.51
cpu_demo2.i686.o2 9.91
cpu_demo2.i686.o3 10.48
cpu_demo2.pentium3.o2 9.84
cpu_demo2.pentium3.o3 10.48
cpu_demo2.pentium4.o2 5.50
cpu_demo2.pentium4.o3 5.26

Вывод - та часть системы, где не используется арифметика с
плавающей точкой, значимо быстрее от пересборки НЕ СТАНЕТ.
Расчетные же задачи действительно ускоряются практически в
2 раза, что означает, что "пересборка системы" под свой
процессор для web/mail/file сервероа бессмысленна, и все
заявления про "оптимизацию" и "мой быстрый дженту, а ваша
федора сасет" не более чем пионерия чистой воды.

Поэтому, уважаемые гентисты и прочие, НЕ НАДО ГНАТЬ, ЧТО
"ПОСЛИ ПИРИСБОРКИ МОЙ СИРВАК СТАЛ ТАКИМ БЫСТРЫМ ШТО ИВО
ТИПЕРЬ ДАЖЕ КРЭЙ НИДАГОНИТ!"

У вас мог ускориться MPlayer/lame, ускориться расчет таблиц в
оффисных программах, уменьшиться и без того малое потребение
ресурсов процессора в XMMS, но значимого прироста производительности
базовой системы не будет.

Ну и еще, чтобы вы не дергались по поводу "а вот если не одна
задача крутится, то все по другому выглядит!", я проделал еще
один прогон, запустив по 4 экземпляра программ-тестеров (по два
экземпляра каждого теста) одновременно:

cpu_demo1.i386.o2      9.27  8.69
cpu_demo1.i386.o3      9.38  9.00
cpu_demo1.i686.o2      9.34  8.76
cpu_demo1.i686.o3      9.31  8.98
cpu_demo1.pentium3.o2  9.48  8.75
cpu_demo1.pentium3.o3  9.28  9.02
cpu_demo1.pentium4.o2  9.48  8.65
cpu_demo1.pentium4.o3  9.13  8.65

cpu_demo2.i386.o2     10.84 10.87
cpu_demo2.i386.o3     10.52 11.07
cpu_demo2.i686.o2      9.75  9.79
cpu_demo2.i686.o3     10.37 10.39
cpu_demo2.pentium3.o2  9.80  9.84
cpu_demo2.pentium3.o3 10.40 10.42
cpu_demo2.pentium4.o2  5.34  5.76
cpu_demo2.pentium4.o3  5.26  5.18

Все, вопросы об оптимизации не-числодробилок,
надеюсь, больше ставиться на обсуждение не будут?

Прогнал ваши тесты на Athlon 1133MHz. Не заметил практически никакой разницы ни между опциями -O2, -O3, -O9, -Os, ни между i386, i586, i686, athlon. Ощутил разницу только вообще убрав -Ox, время выполнения возросло значительно, при этом первый пример с целочисленными вычислениями стал выполняться заметно дольше, нежели с вычислениями с плавающей запятой. При использовании оптимизации наоборот второй пример выполняется дольше первого.

С/у, Ден.

Тоже, вот, решил в свободное время протестировать свой старенький целерончик архитектуры P3 (по одному испытанию на тест):

------------

cpu_demo1.i386 56.847

cpu_demo1.i386.o2 18.586

cpu_demo1.i386.o3 16.539

cpu_demo1.i686 51.667

cpu_demo1.i686.o2 15.727

cpu_demo1.i686.o3 16.873

cpu_demo1.pentium3 48.925

cpu_demo1.pentium3.o2 14.363

cpu_demo1.pentium3.o3 16.950

------------

cpu_demo2.i386 41.938

cpu_demo2.i386.o2 33.455

cpu_demo2.i386.o3 32.754

cpu_demo2.i686 37.428

cpu_demo2.i686.o2 33.105

cpu_demo2.i686.o3 24.423

cpu_demo2.pentium3 35.085

cpu_demo2.pentium3.o2 30.010

cpu_demo2.pentium3.o3 26.485

------------

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

Так вот я об этом и говорил всегда - пересборка базовой системы (glibc/ядро/демоны/апач и т.д.) в принципе не способна дать такого прироста производительности, чтобы стоило с ней связываться. Еще рекомендую присмотреться к результатам - на целочисленной задаче -O3 является ТОРМОЗЯЩИМ флагом. В ядре, кстати, 99.9% операций проводятся с типами u_intXX_YY, т.е. использовать -O3 при сборке ядра не только смело, но и... Скажем так: неразумно. glibc, кстати, тоже оперирует u_intXX типами. Практически все демоны также работают преимущественно в целых числах, т.е. любители -O3 - это ССЗБ.

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

P.S.: возражений гентистов мы похоже уже не увидим - цифры по результатам тестов не врут, и с ними не поспоришь - это секунды, а не условные единицы стоимости владения, где можно подтянуть за уши все, что угодно :-)

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

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

А я заменил кулер с зачудившим вентилятором. Скорость загрузки мозиллы (на глаз) возросла неимоверно, раза в три.

... ещё один дистрибутив.

> А этот "алгоритм", кстати, совершенно не "пузырек", а гнусная инсинуация на тему простой выборки :-)

Нет, речь идет, все-таки, об одном из вариантов метода "пузырька". В качестве примера приведу ява-апплет из Java SDK: $JAVA_HOME/demo/applets/SortDemo/BubbleSortAlgorithm.java

> Так вот я об этом и говорил всегда - пересборка базовой системы (glibc/ядро/демоны/апач и т.д.) в принципе не способна дать такого прироста производительности, чтобы стоило с ней связываться.

Полностью согласен.

Между прочим, недавно у меня на машине стоял Gentoo 2004.0 в качестве эксперимента. Тогда меня меньше всего интересовала оптимизация и всякого рода перекомпиляция. Большая часть системы, вообще, была взята из уже готовых гентушных бинарников, например, KDE.

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

> В качестве примера приведу ява-апплет из Java SDK: $JAVA_HOME/demo/applets/SortDemo/BubbleSortAlgorithm.java

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

2no-dashi  (*) (16.07.2004 10:08:10)

void do_sort(double * lst, int cnt) {
    int i,j,k;
    for (i=0;i<cnt-1;i++) {
        for (j=i+1;j<cnt;j++) {
            if (lst[i]>lst[j]) {
                k=lst[i];
                lst[i]=lst[j];
                lst[j]=k;
            }
        }
    }
}

Прошу извинения, но, ради чистоты теста, почему k не double ?

void do_sort(double * lst, int cnt) {
    int i,j,k;
                lst[j]=k;

Re: i386 vs i586

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

Блин. Придется снова запускать тест - много чего могло теряться на преобразовании :-)

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