hariec ~ % uname -a
Linux gentoo 2.6.39.1-zen+ #2 ZEN SMP PREEMPT Wed Jun 22 16:38:42 MSD 2011 x86_64 AMD Athlon(tm) 7450 Dual-Core Processor AuthenticAMD GNU/Linux
Ты видел как я ядро собираю в статье.
1500 для эксперимента. Ты прав есть дискомфорт, вернусь на 1000.
При параметре CONFIG_HZ больше 1000 производительность компьютера сильно проваливается. И это действительно заметно невооруженным глазом. Компьютер “ватным” становится.
Для тестирования взят пакет nbench. Он тестирует производительность одного из двух ядер процессора Atom N270. Хочу сразу предупредить параметры действительно экстремальные, есть вероятность, что какой-нибудь из пакетов соберется неправильно. Видимых ошибок не будет, но система может получится очень нестабильной. Повторять убедительно не рекомендую - только на свой риск и страх.
nbench скомпилирован со стандартными параметрами:
CFLAGS="-O2 -march=i686 -pipe"
CXXFLAGS="${CFLAGS}"
*стандартное ядро Calculate Linux 2.6.38.8
Результат тестирования:
nbench скомпилирован с параметрами:
CFLAGS="-O3 -march=native -mtune=native -fomit-frame-pointer -pipe -mmmx -msse -msse2 -msse3 -mssse3 -g0 -Wno-all"
CXXFLAGS="${CFLAGS}"
Результат тестирования:
Сравнение:
Ну и напоследок для развлечения скомпилировал nbench с максимальной оптимизацией выполнения математических операций, нарушающей принятые стандарты []{.непредсказуемыми .абсолютно .быть .могут .результаты .полученные .- .рискованно .очень .и .очень .-ffast-math .параметр .применять}:
CFLAGS="-O3 -march=native -mtune=native -fomit-frame-pointer -pipe -mmmx -msse -msse2 -msse3 -mssse3 -ffast-math -g0 -Wno-all"
CXXFLAGS="${CFLAGS}"
Результат тестирования:
В таблицу для сравнения даже вносить результаты не стал. Параметр слишком рискованный.
P.S.
Все описанное здесь действо было скомпилировано с помощью gcc-4.4.5. Тестировалось nbench-2.2.3-r1.
Пробую проверить жизнеспособность параметров:
CFLAGS="-O3 -march=native -mtune=native -fomit-frame-pointer -pipe -mmmx -msse -msse2 -msse3 -mssse3 -g0 -Wno-all"
CXXFLAGS="${CFLAGS}"
Запустил сборку gcc. Первый раз скомпилирует с этими параметрами стандартный gcc и сформирует установочный пакет, второй раз повторит эту операцию оптимизированный уже таким образом компилятор gcc. На выходе будут получены два установочных архива gcc.
Какие файлы лучше сравнить внутри архивов на расхождения?
P.S.
Сравнил эти:
$ ~/test-gcc 1-ая компиляция/usr/bin $ md5sum -b *
3e5b128b54141ce92c584991855d11a0 *c**-4.4.5
30eb116f281b47be9327114867769f1d *cpp-4.4.5
3e5b128b54141ce92c584991855d11a0 *g**-4.4.5
41e35d7a44421c6f392263eaa0164a07 *gcc-4.4.5
9907e9537e69988fa7dfdc29e0a5b1da *gfortran-4.4.5
3e5b128b54141ce92c584991855d11a0 *i686-pc-linux-gnu-c**-4.4.5
30eb116f281b47be9327114867769f1d *i686-pc-linux-gnu-cpp-4.4.5
3e5b128b54141ce92c584991855d11a0 *i686-pc-linux-gnu-g**-4.4.5
41e35d7a44421c6f392263eaa0164a07 *i686-pc-linux-gnu-gcc-4.4.5
9907e9537e69988fa7dfdc29e0a5b1da *i686-pc-linux-gnu-gfortran-4.4.5
$ ~/test-gcc 2-ая компиляция/usr/bin $ md5sum -b *
3e5b128b54141ce92c584991855d11a0 *c**-4.4.5
30eb116f281b47be9327114867769f1d *cpp-4.4.5
3e5b128b54141ce92c584991855d11a0 *g**-4.4.5
41e35d7a44421c6f392263eaa0164a07 *gcc-4.4.5
9907e9537e69988fa7dfdc29e0a5b1da *gfortran-4.4.5
3e5b128b54141ce92c584991855d11a0 *i686-pc-linux-gnu-c**-4.4.5
30eb116f281b47be9327114867769f1d *i686-pc-linux-gnu-cpp-4.4.5
3e5b128b54141ce92c584991855d11a0 *i686-pc-linux-gnu-g**-4.4.5
41e35d7a44421c6f392263eaa0164a07 *i686-pc-linux-gnu-gcc-4.4.5
9907e9537e69988fa7dfdc29e0a5b1da *i686-pc-linux-gnu-gfortran-4.4.5
Контрольные суммы совпали. С большой вероятностью можно сказать, что файлы одинаковы
Почему не перейдешь на 4.5.2. Довольно стабилен. Таких конечно жестких опций не давал, но вся система собрана с -О3. За тесты Спасибо, очень интересно.
Не знаю. Наверно уже привык доверять разработчикам Calculate. Одно знаю точно переходить на 4.6 и выше смысла нет. Программы прилично медленнее начинают работать с арифметикой. “-O3 -march=native -pipe” у меня такие параметры Калька держала тоже очень неплохо. Могу с уверенностью сказать, что с ними можно компилировать без проблем на Atom N270.
Самое странное, что заметил есть разница в выводе консолей, а результат один в один… Файлы прикладываю архивом.
P.S.
Пришлось переписать пост - вместо одного архива изначально два одинаковых получилось. А как удалить лишний прикрепленный файл, не переписав пост, не знаю. Различия оказались обусловлены работой ccache. И gcc не обратил никакого внимания на опции оптимизации в make.conf. Компилировался с параметрами -O2 -march=native. Возможно придется повторить сборку (emerge -bN gcc).
вывод_в_консоль_при_компиляции_gcc_1_и_2_раз.tar.gz (448 KB)
А ни кто и не говорил за 4.6. Разработчикам Calculate я тоже доверяю, вот только сомневаюсь что они вообще заморачивались на счет компилятора. Используют стабильное из дерева. 
Нашел почему не переходят на gcc-4.5.2
“On x86 targets, code containing floating-point calculations may run significantly slower when compiled with GCC 4.5 in strict C99 conformance mode than they did with earlier GCC versions. This is due to stricter standard conformance of the compiler and can be avoided by using the option -fexcess-precision=fast”
Почти дословно:
_На x86 машинах, код, содержащий вычислений с плавающей точкой может работать значительно медленнее, так как компиляция на GCC 4.5 происходит в более строгом соответствии со спецификацией C99, чем это было с предыдущими версиями GCC. Это связано со строгим стандартом соответствия компилятора, но его можно избежать, используя опцию -fexcess-precision=fast
_
Ссылка - текст взят с релиза 4.5.2
P.S.
Полет на системе с экспериментальными параметрами пока нормальный;) Производительность очень радует.