Gentoo относительно Xubuntu

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

NUMERIC SORT        :+38%
STRING SORT         :-4%
BITFIELD            :-2%
FP EMULATION        :+23%
FOURIER             :+0%
ASSIGNMENT          :+17%
IDEA                :-16%
HUFFMAN             :+2%
NEURAL NET          :+1%
LU DECOMPOSITION    :+18%

Потенциал есть у процессора (учитывая, что ключи оптимизированны для атома). В принципе удаётся ключи подобрать так, что по всем тестам будет приличный рост. Я брал описание ключей на сайте gcc для конкретного компилятора (для атомов сейчас лучше всего оптимизирует код gcc 4.5.3-r2), ускорял nbench раз в 5 и подбирал. На проверку набора уходит около минуты вместе с перекомпиляцией и тестом. Единственно, чтобы это сделать необходимо понимать на что какой ключ влияет. Есть взаимоисключающие, есть усиливающие эффект, есть ключи, определяющие параметры других и пр. Короче нюансов много, но зная их можно с пониманием достаточно быстро осуществить подбор хорошей комбинации.

P.S.

У меня некоторые оптимизированные пакеты работают быстрее бинарных в 2 и более раза. Не все конечно, но профит есть. Тяжелее всего оптимизировать архиваторы - прирост невысок. Но даже тут есть куда стремиться. Так 500 метровый фильм 7z на дебиане сжимается с максимальным сжатием за 12 минут примерно, у меня за 11 (+ всего ~8%). Но для архиваторов это считается круто.

ускорял nbench раз в 5

Вот с этого момента подробнее.

Ну и вообще, ты все руками делал?

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

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

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

Ускорить можно так: делаем каталог с исходниками nbench в домашней папке, далее редактируем ключи и запускаем команду компиляции в несколько потоков с последующим запуском теста. Таким образом не тратится время на установку пакета. Плюс нужно уменьшить время прогонов теста в 5 раз в файле nmglobal.h, отредактировав параметр (ежели не ошибаюсь, пишу по памяти)

#define MINIMUM_SECONDS 5

В данный момент у меня система выдает этот результат nbench (на Intel Atom N270):

BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST                : Iterations/sec.  : Old Index   : New Index
                    :                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :          733.56  :      18.81  :       6.18
STRING SORT         :          129.08  :      57.68  :       8.93
BITFIELD            :      2.5579e+08  :      43.88  :       9.16
FP EMULATION        :          108.32  :      51.98  :      11.99
FOURIER             :          9679.8  :      11.01  :       6.18
ASSIGNMENT          :          19.713  :      75.01  :      19.46
IDEA                :          2104.8  :      32.19  :       9.56
HUFFMAN             :          1069.3  :      29.65  :       9.47
NEURAL NET          :           14.53  :      23.34  :       9.82
LU DECOMPOSITION    :          542.52  :      28.11  :      20.29
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 40.450
FLOATING-POINT INDEX: 19.329
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU                 : Dual GenuineIntel Intel(R) Atom(TM) CPU N270   @ 1.60GHz 800MHz
L2 Cache            : 512 KB
OS                  : Linux 3.0.17-gentoo-r2
C compiler          : i686-pc-linux-gnu-gcc
libc                : 
MEMORY INDEX        : 11.676
INTEGER INDEX       : 9.049
FLOATING-POINT INDEX: 10.720
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.

Компилятор: sys-devel/gcc-4.5.3-r2
Библиотека: sys-libs/glibc-2.15-r3

Процессор не разогнан. Частота стандартная 1,6Ггц.

FOURIER             :           35856  :      40.78  :      22.90

Это при "-march=native -O3 -g0 -s -mmmx -mssse3 -mfpmath=both -ftree-vectorize -ffast-math"

То-есть что-то очень сильно его сажает наших флагов на Core2

Нехило.. Было 12986, стало 35856. Рост производительности в 2.76 раза простой строчкой в make.conf

Добавь ради интереса -fexcess-precision=fast и -funroll-all-loops.. Еще очень сильно влияет -mtune. Если ещё указать -march=native (от какого пляшем) -mtune=native (и до какого танцуем), то диапазон оптимизации сузится конкретно для данного процессора.

В принципе при хорошо подобранных ключах включение -ffast-math не должно сильно увеличивать показания теста.

-O3? разве от него есть профит если не ssd? оно генерит жирный код и винт проседает

-march=native
-march implies -mtune

То есть если просто задать march, то и mtune будет точно таким-же. Выхлоп gcc это подтверждает, он мне сам -march=core2 -mtune=core2 ставит.

-fexcess-precision=fast и -funroll-all-loops

Точность ни на что не повлияла (ffast-math же), а вот анролл догнал Фурье до 36780
Все, понял. У фурье идет адовый профит за счет -mpfmath=both. Жаль, что у меня на домашнем сервере 32 бита всего - было бы еще более интересно сравнивать, если 64.

+100 миллисекунд при загрузке софтины и +комейки с используемой памяти не решают ничего. А вот скорость местами заметно увеличивает.

пруф? хотя бы для каких приложений

алсо, с -mfpmath=both -ftree-vectorize -ffast-math не всякий ебилд соберется

не всякий ебилд соберется

Ну на своем десктопе я из проблемных видел только sqlite. Остальные собираются (благо у сильно проблемных флаги фильтруются)

вы с легкостью можете собрать себе систему без всякого мусора и для ваших задач.

Ну и чем в этом плане ubuntu-minimal/debian-netinst/TinyCore/SliTaz/Alpine хуже генты?

Alpine почти мертв + там uclibc (то есть косяков всплывет - мама не горюй, мои эксперименты с gentoo-uclibc как-то провалились).
SliTaz по сравнению с гентой просто адски нестабилен - гора багов, которые репортить никто не хочет. Мне как разрабу довольно печально.

1-5%

Alpine почти мертв

Да ну не сказал бы. Регулярные апдейты тому подтверждение.

там uclibc (то есть косяков всплывет - мама не горюй, мои эксперименты с gentoo-uclibc как-то провалились)

Это хорошо, что там uclibc. Хорошо, что есть дистр для обкатки uclibc. И да, на существующем в репах софте косяков пока не наблюдал. При сборке стороннего вполне могут всплыть, да.

А имеет ли это смысл? Я имею ввиду компенсирует ли повышенная производительность, затраченное на компиляцию время? Думаю вряд ли.

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

Более чем. Если конечно ты не компилируешь LibreOffice, чтоб один раз документ открыть.

Компенсирует, если не переусердствовать с оптимизацией то система в виде побочного эффекта получит ещё и стабильность. (Gentoo)

Год назад, после ~4 лет на Gentoo, переполз на Ubuntu.

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

PS: на ssd разница в отзывчивости слабо заметна, а если учесть время на компиляцию и прочее задротство - Ubuntu выгоднее.

Результат: появилась девушка

Эту твою девушку зовут Sasha Grey, бро.

Нет, бро, что ты, Sasha просто теплое ламповое отрочество.

40 минут на компиляция, против 1 минуты установки в бинарном дистрибутиве

ты ежедневно будешь переустанавливать тонны нового софта?

Ахххаха, просто кул стори, убун-бро.

Пробежался по опциям, догнал до:

TEST                : Iterations/sec.  : Old Index   : New Index
                    :                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :          1939.2  :      49.73  :      16.33
STRING SORT         :           394.8  :     176.41  :      27.30
BITFIELD            :      6.1446e+08  :     105.40  :      22.02
FP EMULATION        :           197.4  :      94.72  :      21.86
FOURIER             :           36576  :      41.60  :      23.36
ASSIGNMENT          :            50.6  :     192.54  :      49.94
IDEA                :          7211.1  :     110.29  :      32.75
HUFFMAN             :          2734.4  :      75.83  :      24.21
NEURAL NET          :          53.279  :      85.59  :      36.00
LU DECOMPOSITION    :          2179.6  :     112.91  :      81.54
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 105.034
FLOATING-POINT INDEX: 73.801
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU                 : Dual GenuineIntel Pentium(R) Dual-Core  CPU      E5300  @ 2.60GHz 2600MHz
L2 Cache            : 2048 KB
OS                  : Linux 3.8.0-rc2+
C compiler          : gcc version 4.7.2 (Gentoo 4.7.2 p1.3, pie-0.5.5)
libc                : /usr/lib/gcc/i686-pc-linux-gnu/4.7.2/libgcc_s.so.1
MEMORY INDEX        : 31.080
INTEGER INDEX       : 23.066
FLOATING-POINT INDEX: 40.933
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.

В общем, оставил CFLAGS="-march=native -O3 -g0 -s -mmmx -mssse3 -mfpmath=both -ffast-math -fno-tree-pre -funroll-loops -ftree-loop-if-convert-stores"

По идее, надо еще лишние «оптимизации» повырубать, а то кто его знает, может не только у ftree-pre регрессия.

Ну, тут тесты нужно проводить. Субъективно - где-то процентов на 10%-30% будет меньше библиотек, что скажется на времени загрузки каждого конкретного приложения, и на объеме используемой памяти (второе слабо релевантно на современных компах). Что до скорости работы приложений - 5%-15% и то только в некоторых, таких как кодеры/декодеры/упаковщики. В DE, файловых менеджерах и других повседневных приложениях ничего ты не заметишь.

Генту собирают не из соображений производительности.

кот перестал гадить в тапки

Простите, а кот тоже был гентушником?

Бедные, бедные пользователи Atom(TM) CPU. Давайте все вместе пожалеим их.

TEST                : Iterations/sec.  : Old Index   : New Index
                    :                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :          942.48  :      24.17  :       7.94
STRING SORT         :          155.44  :      69.45  :      10.75
BITFIELD            :       4.454e+08  :      76.40  :      15.96
FP EMULATION        :          207.84  :      99.73  :      23.01
FOURIER             :           19510  :      22.19  :      12.46
ASSIGNMENT          :          26.635  :     101.35  :      26.29
IDEA                :          3694.7  :      56.51  :      16.78
HUFFMAN             :          1456.7  :      37.62  :      12.01
NEURAL NET          :          40.287  :      64.72  :      27.22
LU DECOMPOSITION    :            1033  :      53.51  :      38.64
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 59.867
FLOATING-POINT INDEX: 42.513
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU                 : AuthenticAMD Athlon XP (Barton)2600+ 1921MHz
L2 Cache            : 512 KB
OS                  : Linux 3.2.6
C compiler          : gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5.1) 
libc                : libc-2.11.1.so
MEMORY INDEX        : 16.522
INTEGER INDEX       : 13.853
FLOATING-POINT INDEX: 23.579
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38

Давайте все вместе пожалеим их.

Ты эту печку хочешь в ноут пихать?

E-350 достойный или нет?

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

И еще GluckMan прав - преимущестжо генты _не толко_ в оптимизации при компилировании.

-ffast-math - успехов в компиляции фокса :-)

Флаг фильтруется вроде. Потому как у меня он собран.

Ты не поверишь, пихали! http://en.wikipedia.org/wiki/Athlon#Mobile_Athlon_XP

Athlon XP-M
a lower (than desktop) voltage
PowerNow!
s2kctl (или другая приблуда, их несколько было, как вариант, модифицировать BIOS с той же целью)

И все это еще в 2003 году с производительностью в два раза выше, чем «современные» Atom(TM) CPU. В сухом остатке превосходство в энергопотреблении, новых инструкциях да x86-64, польза от которого в случае с атомами сомнительна. Ну и таки да, температура, выше головы и с приблудами не прыгнешь. Я не злорадствую и не призываю всех к некромантии, просто действительно жаль владельцев этого.

Зависит от hardware.

Не соберется sqlite, protobuf из-за ffast-math. Развертывание циклов со стандартными ограничениями не позволит скомпилировать пришпоренный imagemagick. И еще одна библиотека из kde ругается на ffast-math. С остальными полный порядок. Для этих же в генту легко прописываются персональные ключи и всё. Например, в /etc/portage/env/dev-db/sqlite указываются 2 параметра

CFLAGS="ключи_без_ffast-math"
CXXFLAGS="${CFLAGS}"

Выхлоп gcc это подтверждает

Это опровергает результаты тестов скомпилированной nbench. Мой native отличается от atom. Та же ситуация и с march и mtune. Почему так не знаю.

У фурье идет адовый профит за счет -mpfmath=both

Ты абсолютно прав. Если указать sse или mmx, то производительность упадет, но не так резко как если совсем отключить.

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

Уже проверил - на корке прирост выше погрешности дают только эти флаги, все остальные +-1%
Будет время - по очереди поотключаю все по списку, авось что еще регрессию дает.

Это урезанное дальше некуда поделие оказывается может вполне сносно работать.

Работать - более чем. Если 3D игрули не трогать (хотя nvidia должна потянуть) и флеш подкрутить - то все отлично.

Имхо, конечно, но проще новый комп приобрести, чем с гентой ковыряться

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

Одно виртуальное ядро у атома в 2 раза медленнее, чем процессор у старого одноядерного Celeron на почти одинаковой частоте. Перефразируя: 2 ядра атома примерно равны по производительности одноядерному Celeron;) Это так к слову.

Что за проц?

Еще можно заценить на компиляторе gcc-4.5.3-r2, версии выше у меня давали регресии на разных процессорах.

На Asus n10j в принципе можно играть. Дискретная nvidia позволяет рубиться в игры вплоть до первого кризиса. Флеш работает отлично, если включать аппаратку, то вплоть до разрешения HD 1080p. А вот на встроенном интел это уже не прокатывает. Без аппаратки 480p предел для процессора atom n270.

С гентой не нужно ковыряться, всё само в фоне выполнится. А вот менять технику хочется с умом. Мне asus n10j служит с того самого момента, как их на рынок выпустили. Тогда он был самым компактным, имел быструю дискретную видеокарту для своего класса и самым дорогим среди нетбуков. Это для меня и личный органайзер и удобная машинка для работы. На что менять до сих пор не определился. Хочу с сенсорным экраном, с пристегиваемой клавой (чтобы как ноутбук можно было использовать), как обычно быстрый (от Core i5 и выше), с хорошей видеокартой. Вот только с размером пока думаю. Полгода назад подпадал под описание только планшетный asus, но он сильно сливал на видеокарте. Так что менять пока не на что(

А какой тип установки более приемлем, stage1 или 3? В примере с хендбука советуют 3, но ведь это ж фактически базовая система не оптимизированной будет, или я путаю, короче объясните как стоит ставить, stage1, 2 или 3?

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

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

Ясно, спасибо.