Блогосайт Alv’а. О Unix'ах, былом и грядущем

Сделал себе новый полу-сайт, полу-блог:
http://alv.me/
Это всё-таки поприличней выглядит.
Постепенно перетащу туда весь контент отсюда и с http://alv-aka-fedorchuk.blogspot.com/

Наброски к книге. 2. Настраиваем HAL

Кроме описанного ранее, есть и более радикальный метод настройки монтирования сменных носителей от лица пользователя -- использование механизма HAL (Hardware Abstraction Level). Правда, работает он только в Иксах, насколько мне известно, точно -- в интегрированных средах KDE, GNOME и Xfce, за менеджеры окон не скажу по незнанию; хотя, судя по тому, что порт hal идёт в качестве зависимости X-сервера, вероятно, и в некоторых из них этот механизм также поддерживается.

Итак, для начала необходимо установить соответствующий порт -- /usr/ports/sysutils/hal. Правда, как только что было сказано, при установке Иксов и какой-либо из интегрированных сред он уже будет инсталлирован как зависимость, причём вместе с графическим фронт-эндом к нему (в случае с GNOME и Xfce это будет порт /usr/ports/sysutils/gnome-mount).

Теперь -- собственно настройка. Она проста как грабли: отправляемся в каталог /usr/local/etc/PolicyKit и обнаруживаем там файл PolicyKit.conf. По умолчанию содержимое его следующее:

<config version="0.1">
   <match user="root">
   <return result="yes"/>
   </match>
   <define_admin_auth group="wheel"/>
</config>

Что предваряется следующей фразой:

<!-- See the manual page PolicyKit.conf(5) for file format -->

Руководствуясь man (5) PolicyKit.conf, между

    <define_admin_auth group="wheel"/>

и

</config>

дописываем следующие строки:

    <match action="org.freedesktop.hal.storage.mount-removable">
             <return result="yes"/>
   </match>
   <match action="org.freedesktop.hal.storage.mount-fixed">
              <return result="yes"/>
   </match>

разрешающие членам группы wheel монтирование сменных и внутренних носителей, соответственно.

И после реинициализации системы (например, посредством временного перехода в однопользовательский режим или полного рестарта) получаем возможность автоматического монтирования сменных устройств сразу вслед за их помещением в привод или подсоединением к USB-порту.

Наброски к книге. 1. Монтирование сменных устройств

Начинающих пользователей FreeBSD, имеющих опыт работы в современных дистрибутивах Linux'а, часто раздражает необходимость получать права администратора для монтирования сменных накопителей (компакт-диски, флэшки, носители цифровых камер). И по умолчанию это действительно так, и попытки решить эту задачу простым редактированием файла /etc/fstab по образу и подобию Linux'ового успеха иметь не будут -- опция user, обеспечивающая эту функцию в последней ОС, командой mount из FreeBSD не поддерживается.

И тем не менее необходимость административных прав для монтирования сменных устройств во FreeBSD -- кажущаяся. Вот только для реализации права юзера на монтирование потребуются несколько иные действия.

Для начала, получив привилегии root'а, устанавливаем права доступа к файлам сменных устройств в файле /etc/devfs.conf, отвечающем за поведение файловой системы devfs:

perm    /dev/cd0     0666
perm    /dev/xpt0    0666
perm    /dev/pass0   0666
perm    /dev/da0  0666
perm    /dev/da0s1   0666

Заодно тут же снимаем символ комментария со строки

#link    acd0    cdrom

Благодаря этому при создании devfs (а она, как известно, пересоздаётся при каждом рестарте машины) будет устанавливаться символическая ссылка для файла /dev/cdrom (такое имя привода компакт-диска желают видеть некоторые программы, например, mplayer) на файл реального устройства acd0.

Затем в файле /ect/sysctl.conf разрешаем монтирование VFS от имени обычного пользователя:

vfs.usermount=1

Теперь возвращаем себе права обычного пользователя и от его имени создаём в домашнем каталоге точки монтирования для сменных устройств:

% mkdir ~/cdrom ~/usb

Проверяем правильность настроек командами:

% /sbin/mount -t vfat /dev/da0s1 ~/usb
% /sbin/mount -t cd9660 -o ro /dev/da0s1 ~/cdrom

Если монтирование проходит нормально, то вносим в файл /etc/fstab соответствующие строки:

/dev/acd0 /home/username/cdrom cd9660 ro,noauto 0 0
/dev/da0s1 /home/username/usb vfat rw,noauto 0 0

Однако возможно, что после всех предпринятых шагов флэшка или компакт откужутся монтироваться от лица пользователя, выдав предупреждение, что

Operation not permitted

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

Первое решение -- это (от лица суперпользователя) присвоить командам /sbin/mount и /sbin/umount так называемый бит суидности:

# chmod a+s /sbin/mount /sbin/umount

Не очень изящно, но, говорят, работает.

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

#!/bin/sh
mount /cdrom;  umount /cdrom
mount /mnt; umount /mnt

который поместить в каталог /usr/local/etc/rc.d/ под именем, например, mount_umount.sh. Наличие компакта в приводе или флэшки, подсоединённой к USB-порту, не обязательно.

Мне с такой ситуацией сталкиваться не пришлось, поэтому не опробовал ни первый, ни второй способы. Но, по сведениям, работают оба.

Хроника блога. 5

Не прошло и шести лет с того времени, как я начал писать первую книжку про FreeBSD, как настал психологический момент для сочинения второй.
Рабочее название: FreeBSD. Героиня моего романа
Пока сподобился сочинить только оглавление - оно же примерный план будущей книги.
Сразу должен оговорить - это будет не второе изнание книги "FreeBSD: установка, настройка, использование", пусть даже расширенное и дополненное.
Нет, операционки меняются, и мы меняемся вместе с ними. Возможно, даже больше, чем операционки.
И в результате из этого начинания получится совершенно другая книга. Какая - я и сам еще точно не знаю...

FreeBSD: Героиня моего романа

Содержание

• Почему FreeBSD?
  Вместо вступления
• FreeBSD как она есть
  Интрига завязывается
  
• Берклиада
  История одной системы
• Подготовка к выходу
  Что надо иметь, знать и уметь
• Всё имеет свое начало...
  Инсталляция: возможны варианты
• ... И всё начинается с загрузки
  Загрузка и инициализация системы
• На чём стоит FreeBSD
  Диски, разделы, тома, файловые системы
• Файловая иерархия
  Логика файловой системы
• Мир на трёх кашалотах мается
  Файлы, процессы и пользователи
• Темная сторона Луны
  Консоль и терминалы
• Kernelland & Userland
  Ядро и мир FreeBSD
• Вступление в Userland
  Командные оболочки
• Обзор Userland'а
  Системные и пользовательские утилиты
• Ворота в мир FOSS
  Порты и пакеты
• Лики интерфейса
  Xorg, WM и DE
• Главный инструмент Free'шника
  Текстовые редакторы
• Мир без границ
  Интернет и коммуникации
• Конторские будни
  Офисные пакеты и приложения
• В часы досуга
  Графика и мультимедиа
• Что дальше?
  Вместо заключения

Хроника блога. 4

Только-только я подумал, что наконец собрал все свои старые сочинения, как тут, в процессе сочинения нового материала по сравнению быстродействия файловых систем (будет в ближайшее время на Citkit'е), обнаружил несколько заметок о тестировании железа под Linux, файловых систем Linux и FreeBSD, а также серию заметок об оптимизации.

Последняя наиболее занятна. Она написана ещё во времена присноблаженного Линуксшопа, в 2003 году. Вывод из неё - что оптимизация под "железо" и т.д. если и существует, то увидеть её результаты невооружённым глазом весьма затруднительно.

Прошло пять лет. С тех пор, если ситуация и изменилась, то только в худшую (для "оптимизаторов") сторону...

Тестирование Linux'ов. Осень 2003 Тур 4. lame на Athlon'е

2003 г

Результаты lame-тестов на моей машине так заинтриговали меня, что немедленно по размещении итогов предыдущего тура к месту дислокации машины на Athlon-XP/1800+, конфигурация которого была описана в статье о первом туре. И повторил - к сожалению, до того, как ознакомился с соображениями Георгия Шаповалова в нашем форуме, описанными в предыдущей статье. Картина получилась довольно показательная.

Итак, на этой машине имелся Red Hat 9, уцелевший после 1-го тура, содержащий в себе ядро 2.4.20 и gcc 3.2.2. На этом хозяйстве был последовательно собран lame с теми же настройками, что и на моей: уровни оптимизации -O0, -O1, -O2 без всяких дополнительных флагов, сборка lame по умолчанию - напомню, она выполняется с флагами

CFLAGS="-O3 -fomit-frame-pointer \
 -ffast-math -funroll-loops \
 -Wall -pipe"

сборка с флагами

CFLAGS="-O3 -march=i686"

и две сборки конкретно под Athlon-XP. В первой задействовался стандартный сопроцессор:

CFLAGS="-O3 -march=athlon-xp \
 -fomit-frame-pointer \
 -funroll-loops -pipe \
 -mfpmath=387"

Во второй - флаги для мультимедиа-инструкций:

CFLAGS="-O3 -march=athlon-xp \
 -fomit-frame-pointer
 -funroll-loops -pipe \
 -mfpmath=sse -mmmx -msse -m3dnow"

В связи с замечанием Георгия скажу пару слов о том, откуда взялся флаг -funroll-loops. Происхождение его - чисто эмпирическое, в цикле статей о тестировании процессоров на iXBT (недавно узнал, что в народе его, оказывается, ласково называют Хоботом - спасибо @lexb за информацию) было отмечено, что снятие его приводит к провалу производительности (в том числе на AMD64), а поскольку проверять это мне было лень, решил, что джентльменам верят на слово. Впрочем, как показано в конце предыдущей статьи ко 2-й интермедии, рояля это не играет...

Как и ранее, после каждой сборки lame трижды выполнялось конвертирование WAV -> MPEG все того же 750-мегабайтного файла (исключение - для сборки при -O0, причину вы легко поймете, взглянув на таблицу). Как и в первый раз, результаты по lame продемонстрировали просто потрясающую воспроизводимость - в каждой серии отличий более чем на секунду не отмечалось - что в CPU time, что в Real time. Зато здесь я впервые заметил разницу между CPU time и Real time: первое было меньше стабильно на 2-3 секунды. Поскольку результаты по CPU time показали суммарно лучшую воспроизводимость, в таблице и на диаграммах использованы именно они (напомню, что в первом lame-тесте оба показателя были просто идентичны).

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

Таблица. Сравнение средних
-O0	00:13:55
-O1	00:05:07
-O2	00:05:01
Default -O3	00:04:57
-O3 -march=i686	00:04:28
-O3 -march=athlon-xp/387	00:04:28
-O3 -march=athlon-xp/sse	00:04:32

Имеющий глаза все увидит сам, но не откажу себе в удовольствии кратко описать картину:

• резкое повышение быстродействия при применении хоть какой-то оптимизации - разница между -O0 и -O1 - более чем в два с половиной раза;
• едва, но все же заметный, рост производительности от -O1 до -O3 чистого;
• ощутимый прирост скорости при переходе к -O3 -march=i686, составивший почти полминуты;
• абсолютно совпадающий с ним результат для -O3 -march=athlon-xp с задействованием 387;

и, опять же, чуть видимое, но все же - видимое, падение при переходе к сочетанию -march=athlon-xp с наборами sse-типа.

То есть качественно картина практически аналогична полученной для Pentium-4, за исключением отдельных деталей. Так, быстрый сопроцессор Athlon'а помешал, видимо, флагу -funroll-loops отъесть у него производительности. Большие абсолютные значения времени кодирования (все же реально здесь было на один гигагерц меньше, чем на моем агрегате) выявили чуть заметные отличия при уровнях оптимизации -O1, -O2 и -O3. И инструкции sse-типа повредили Athlon'у не так сильно, как "четверке" :-)). Однако все остальное вполне укладывается в наметившуюся ранее тенденцию. Что позволяет сделать уже более определенные выводы.

Помните, как Атос во время завтрака при возвращении в Париж (после истории с подвесками) спросил своих товарищей, что они едят? И когда в ответ те начали расписывать изыски французской кулинарии, возразил: "Господа, вы едите конину. Может быть, даже с седлом".

Так вот, господа, сидящие за крутейшими "четверками" и Athlon'ами и воображащие себя пожирателями трюфелей и омаров (не обижайтесь, это я и про себя). Вы работаете за PentiumPro. Может быть, даже без инструкций mmx/sse... И отсюда - первый вывод: единственные флаги оптимизации, в общем случае окупающие усилия пальцев по их вводу и амортизацию клавиатуры - это

CFLAGS="-O3 -march=i686"

А все остальное, включая mmmx/msse/msse2, способно в лучшем случае не очень ухудшить быстродействие.

Отдельно - о флагах из области mmx/sse. Теоретически они должны бы дать прирост быстродействия. Однако для этого, как резонно заметил Георгий, собираемая с ними программа должна знать о существовании таких инструкций. А похоже, что большинство программ (даже таких, как lame, которой они могли бы принести пользу - чему примером виндовые аналоги) об этом и не подозревают.

И - к слову сказать, правильно делают. Мне всегда казалось, что подмена универсальных инструкций специализированными если и даст сиюминутную выгоду, в долгосрочной перспективе не оправдана: а как завтра Intel выдумает новый набор, mega-sse#? Тогда как старый добрый сопроцессор - он и в Африке сопроцессор...

Второй вывод: пример lame убеждает, что есть программы, не оптимизируемые под процессор (или процессоры, под которые некоторые программы оптимизировать бессмысленно?). Однако мы знаем примеры и противного: ведь те 30 процентов для gcc, полученные таким образом Джастин Piszcz (фамилию транскрибировать не рискну:-))- это реальность (ну пусть не 30, но 10-15% - тоже хороший результат).

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

Тестирование Linux'ов. Осень 2003. Тур 3. Парадоксы оптимизации

2003 г

Парадоксальные результаты первого тура тестирования побудили меня обратиться к изучению вопроса о том, а насколько же оптимизация реально влияет на производительность? Результаты исследования оказались столь поразительными, что я не могу не поделиться ими на этих страницах. Однако начну по порядку.

Исследования проводились на моей домашней машине - напомню, это P4/2,53 с 533-мегагерцной шиной, мама на i845PE, памяти - 1 Гбайт (2x512, DDR333), "несущий" винт - Seagate Barracuda IV о 40 Гбайт, прочие компоненты несущественны. Дистрибутив - в девичестве Archlinux 0.5, подвергнутый мною многочисленным операциям по смене пола, наращиванию одними членами и усекновению - других. В итоге чего в нем образовались: ядро 2.4.22 и gcc 3.3.1. Последний был сконфигурирован (вывод команды gcc -v) так:

Configured with: ../gcc-3.3.1/configure --prefix=/usr --enable-shared --enable-languages=c,c++ --enable-threads=posix --with-slibdir=/lib --enable-_cxa_atexit --enable-clocale=gnu
Thread model: posix

А собран командой

$ make bootstrap

со следующими флагами:

CFLAGS="-O3 -march=pentium4 \
 -fomit-frame-pointer
 -funroll-loops -pipe \
 -mfpmath=sse -mmmx -msse2 -fPIC"
CXXFLAGS="$CFLAGS"
BOOTSTRAPCFLAGS="$CFLAGS"

внесенными в профильный файл (/root/.zshrc).

Тратить особо много времени мне не хотелось - некоторым образом и другие дела есть (однако, забегая вперед, замечу, что в итоге я провозился с этими тестами намного дольше, чем рассчитывал). Поэтому я решил выбрать одну, но представительную, задачу. А именно: кодирование WAV -> MPEG программой lame (текущая на тот момент версия 3.92). То есть один из тех классических тестов, на которых всегда демонстрировалось превосходство Pentium 4 над всеми остальными x86-совместимыми архитектурами (на другие тесты, типа преобразования MPEG -> DivX и тому подобное, я потенции в себе не находил).

В качестве объекта для истязания я выбрал wav-файл размером около 750 Мбайт, представляющий собой оцифровку записи концерта Юрия Визбора в альплагере Цей, выполненную с магнитофонной ленты Владимиром Поповым (за что ему - искренняя благодарность). Это я к тому, что никаких проприетарных дисков я не граббил:-)

Итак, для начала я собрал lame в конфигурации по умолчанию. А нужно заметить, что эта самая умолчальная конфигурация предусматривает следующие флаги (их можно подсмотреть в файле ~/lame-xx/configure.in):

-O3 -fomit-frame-pointer -ffast-math -funroll-loops -Wall -pipe

То есть с высоким уровнем оптимизации (хотя, естественно, и без указания конкретного процессора). После этого я перекодировал свой wav-файл просто:

$ lame visbor.wav

Учитывая далеко не студийное качество записи исходного материала, с битрейтами и прочим я решил не возиться. Впрочем, по умолчанию в lame предполагаются достаточно высокие параметры - mpeg layer 1, 44,1 kHz, 128 kbps, qual=2. Результаты трех измерений (по выводу команды lame Real time, которое у меня и здесь, и во всех последующих случаях совпало с выводом CPU time) оказались, как можно видеть из таблицы 1, практически идентичными - 2 минуты 59 секунд в среднем.

Таблица 1

Сборка Gcc 3.3.1
	1	2	3	Avg
Default -O3	00:03:00	00:02:59	00:02:59	00:02:59
-march=p4 with other	00:03:26	00:03:26	00:03:27	00:03:26
-march=i686	00:02:55	00:02:55	00:02:55	00:02:55
-march=p4 only	00:02:56	00:02:56	00:02:57	00:02:56
Сборка Gcc 3.3.2
-march=p4 with other	00:03:29	00:03:26	00:03:26	00:03:27
-O2	00:02:59	00:03:00	00:03:00	00:03:00
-O1	00:03:01	00:03:01	00:03:01	00:03:01
-O0	00:06:19	00:06:19	00:06:19	00:06:19

Пересобираю lame со своими обычными флагами (приведенными выше), которые включают специфичные для "четверки" инструкции и, довольно потирая руки, запускаю конвертацию по новой. Ожидая демонстрации мощи P-4, даже не отправляюсь курить. Тем больше было мое изумление, когда вижу результат - 3 минуты 26 секунд, то есть почти на полминуты худший. Второй и третий прогоны теста картины не меняют (см. табл. 1)...

Н-да, сказал я себе, и пересобрал lame с теми флагами, которые используются при сборке Arch Linux вообще:

CFLAGS="-O3 -march=i686"

Здесь душа моя порадовалась - результаты оказались хоть и чуть-чуть, но получше умолчальных - 2 минуты 55 секунд, причем с идеальной воспроизводимостью (см. табл. 1).

Тут же появляется мысль пересобрать lame, выкинув P4-специфичные флаги и оставив только

CFLAGS="-O3 -march=pentium4"

Результат отличился от предыдущего нечувствительно (однако все-таки в худшую сторону) - 2 минуты 56 секунд :-)...

Однако - подумал я, и решил сменить компилятор на ультрамодерновый gcc 3.3.2, тем более что все равно собирался это делать. Конфигурирую его и собираю точно тем же образом, что и предыдущий:

$ CFLAGS="-O3 -march=pentium4 \
 -fomit-frame-pointer \
 -funroll-loops -pipe \
 -mfpmath=sse -mmmx -msse2 -fPIC"

Configured with: ../gcc-3.3.2/configure --prefix=/usr --enable-shared --enable-languages=c,c++ --enable-threads=posix --with-slibdir=/lib --enable-_cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 3.3.2

$ make bootstrap

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

Решено - сделано, последовательно пересобираю lame только с флагами

CFLAGS="-O2"

затем

CFLAGS="-O1"

и, наконец,

CFLAGS="-O0"

то есть без всякой оптимизации. Сказалось, но весьма странным образом. Результаты для уровней -O2 и -O1 составили, соответственно, 3 минуты ровно и 3 минуты одна секунда. И только при -O0 я наконец смог удовлетворенно сказать то, что сказали русские мужики после того, как засунули в японскую бензопилу шестигранный лом (из уважения к, возможно, читающим это дамам повторять не буду): результат 6 минут 19 секунд продемонстрировал, что все-таки уровни оптимизации в gcc придуманы были не зря. Что блестяще :-) демонстрирует сводная таблица средних значений (табл. 2) и построенная по ней диаграмма (рисунок).

Таблица 2

Табл. 2. Сравнение средних
-O0	00:06:19
-O1	00:03:01
-O2	00:03:00
-O3	00:02:59
-O3 -march=i686	00:02:55
-O3 -march=p4 only	00:02:56
-O3 -march=p4 etc.	00:03:26

Конечно, все сказанное относится к одной отдельно взятой (и довольно специфической) программе, выполнявшейся на единичном (и также довольно специфическом) процессоре. Тем не менее, некоторые предварительные выводы сделать можно.

А именно - наилучший результат с точки зрения быстродействия достигается при использовании сочетания флагов -O3 и -march=i686 (не случайно CRUX и Archlinux, которые собираются именно так, субъективно казались мне самыми быстрыми дистрибутивами из всего виденного). Впрочем, эффект от этого на практике можно почувствовать только при тотальном о-грабблении пары ящиков сидюков (да и то при условии их конвейерной подачи в привод). Различия же между уровнями оптимизации от -O1 до -O3 можно считать несущественными (рис. 1). Лишь полное отсутствие оптимизации (-O0) ухудшает производительность в значительной мере (более чем в два раза). И - крайности смыкаются - тот же эффект, хотя и не столь выраженный, дает "оптимальная оптимизация" под Pentium 4 (что также имеет органолептическое подтверждение - заоптимизированные до посинения под "четверку" дистрибутивы типа Sorcerer сотоварищи на практике оказываются изрядно задумчивыми).

Рис. 1.

Конечно, интересно было бы посмотреть, имеет ли место такой эффект при экстремальной оптимизации под Athlon. С одной стороны, мои наблюдения более чем двухлетней давности показывают, что еще тогда gcc оптимизировал под него лучше, чем под P4. С другой же - возможно, что в описанном и кроется причина провального результата Gentoo на mkisofs, полученного в первом туре мегатестирования.

И еще один, косвенный (но приятный), вывод: кодирование посредством lame обеспечивает практически идеальную воспроизводимость результатов. И, следовательно, эта программа должна стать непременным членом любого набора пользовательских тестов под Linux.

После сочинения всего сказанного выше я познакомился с мнением Георгия Шаповалова. Он высказал несколько резонных соображений касаемо флагов оптимизации, которые мне, естественно, захотелось проверить (на той же конфигурации).

Для начала, руководствуясь советами Георгия "-march=где-то_рядом и -O2", я пересобрал lame с флагами

CFLAGS="-O2 -march=i686"

получив при этом, однако, чуть-чуть худшие результаты, чем при -O3 -march=i686 (2:57 и 2:55, соответственно).

Потом я вспомнил, что резонные люди советовали не собирать пакеты для Pentium 4 с использованием флага -march=pentium4, а ограничиваться для этого флагом -march=pentium3. Что ж, за нами не заржавеет, собираю lame c

CFLAGS="-O3 -march=pentium3 \
 -fomit-frame-pointer \
 -funroll-loops -pipe \
 -mfpmath=sse -mmmx -msse"

Результат измерений - 2:56. Далее, избавляюсь от вредоносного флага -funroll-loops:

CFLAGS="-O3 -march=pentium3 \
 -fomit-frame-pointer \
 -pipe -mfpmath=sse -mmmx -msse"

Результат неизменно превосходен - 2 минуты 56 секунд :-)

Вспоминаю историю о насморке: как известно, без врачебного вмешательства он длится целую неделю, а при лечении квалифицированным врачом - проходит всего за семь дней. И дальнейшие эксперименты прекращаю. Не забыв, однако, составить новую сводную таблицу средних значений (табл. 2) и соответствующий ей график (для пущей сопоставимости с lame-тестом на Athlon'е, который был выполнен позже).

Таблица 3

Таблица. Результаты lame-теста для P4
-O0	00:06:19
-O1	00:03:01
-O2	00:03:00
-O3	00:02:59
-O2 -march=i686	00:02:57
-O3 -march=i686	00:02:55
-O3 -march=p4 only	00:02:56
-O3 -march=p4 sse funrall	00:03:26
-O3 -march=p3 sse funrall	00:02:56
-O3 -march=p3 sse w/o funrall	00:02:56

Рисунок 2

Увы - картина все та же (рис. 2): резкое падение быстродействия при -O0, ощутимое - при -march=pentium4 со всеми sse-прибамбасами, прочие же случаи - практически равны...

Тестирование Linux'ов. Осень 2003. Тур 2. Про prelink

2003 г

Разговоры про prelink и его фантастическую способность к ускорению запуска Linux-приложений ведутся давно. Достаточно вспомнить ставший знаменитым тест Хосе Суареса. В итоге и у меня появилось желание посмотреть, что же это такое. А в рамках начавшегося мегатестирования - и померять, как этот самый prelink влияет на реальную работу.

Издевательству подвергался дистрибутив Archlinux (последняя стабильная версия, 0.5), который сам по себе заслуживает внимания (и оное надеюсь уделить ему в ближайшие дни). Насколько мне известно, собирается дистрибутив с флагами -O2 -march=i686, то есть без особых изысков. Тем не менее, субъективно он производит впечатление весьма быстрого.

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

Для начала скачиваю prelink с места его постоянного проживания - ftp://people.redhat.com/jakub/prelink, - и распаковываю архив. Затем внимательно читаю ./configure --help и запускаю собственно конфигурирование:

$ ./configure --prefix=/usr

в ответ на что от меня требуют библиотеку libelf. Она также имеется среди пакетов Arch, однако чистоты эксперимента для собираю и ее. Скачиваю его последнюю (0.8.2) версию с http://www.stud.uni-hannover.de/~michael/software/, разворачиваю тарбалл и собираю обычным образом -

$ ./configure --prefix=/usr ;
$ make ;
$ make install

После чего повторяю процедуру конфигурирования prelink, по благополучном ее завершении запускаю make - и получаю сообщение об ошибке. Причем, что самое обидное и парадоксальное - на стадии сборки компонентов для архитектуры PPC, нужной мне, как зайцу стоп-сигнал. Я довольно долго ломал голову, как побороть эту напасть - снятием ли флагов оптимизации, или искоренением из make-файлов упоминаний о не-PC'шных архитектурах. И в конце концов в глубине кроны дерева портежей Gentoo обнаружил специально предназначенный к тому патч. Он залегает в отростке portage/sys-devel/prelink/files и носит имя prelink-20030505-glibc231.patch (к сожалению, более простого способа его получения в не-Gentoo-дистрибутивах я не обнаружил - разве что самому написать:-)). Несовпадение номеров версий патча и собственно prelink смущать тут не должно - все описанное проверено на собственной шкуре и работает.

Итак, налагаю патч:

$ patch -Np1 -i /path/prelink-20030505-glibc231.patch

после чего сборка prelink проходит безболезненно.

В результате я получаю исполняемый файл /usr/sbin/prelink и соответствующую ему man-страницу. По изучении которой нужно выполнить некоторые конфигурационные мероприятия. А именно - скопировать из каталога doc в дереве исходников prelink файл prelink.conf:

$ cp ~/prelink-src/doc/prelink.conf /etc

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

-l /bin
-l /usr/bin
-l /sbin
-l /usr/sbin
-l /usr/local/bin
-l /usr/X11R6/bin
-l /opt/qt/bin
-l /opt/kde/bin
-l /usr/libexec
-l /lib
-l /usr/lib
-l /usr/local/lib
-l /usr/X11R6/lib
-l /usr/X11R6/LessTif
-l /opt/qt/lib
-l /opt/kde/lib

Теперь можно, наконец, запустить процесс предварительного связывания. Делается это так:

$ prelink -avfmR

Смысл опций команды следующий: -a предписывает применить прелинкинг ко всем исполняемым файлам; -v - выводит подробную информацию о ходе процесса; -f - директива применять прелинкинг повторно, даже если эта процедура уже была выполнена; -m и -R - опции, страхующие от ошибок нехватки памяти и переполнения буфера (подробности, как обычно, - на man prelink).

Особо подчеркну необходимость опции -v. Я бы даже советовал отправить вывод команды (вернее, ее сообщений об ошибках) в файл:

$ prelink -avfmR 2> prelink.log

Без этого трудно узнать, какие программы подверглись прелинкингу, а какие - нет. Ибо те, что были собраны с опцией non-PIC (или, напротив, без опции --with=pic), предварительно связанными быть не могут. У меня в этот черный список попало некоторое количество KDE-приложений, что, возможно, и отразилось на результатах тестирования, приводимых ниже.

Выход из этого положения - простой, но занудный: пересобрать все, что попало в prelink.log. И тут уж, разумеется, впредь не забывать, что любая программа, в выводе ./configure --help которой отмечается доступность опции --with-pic, должна конфигурироваться именно с ее участием. Для гарантии чего флаг -fPIC можно добавить в список значений переменной CFLAGS. А после этого - повторить процедуру прелинкинга, для чего, собственно, и требуется упоминаемая выше опция -f - без нее программы повторно прелинкованы не будут.

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

• Pentium4/2,53 (шина 533 Mhz, без Hyper Treading'а);
• "Мама" Albatron PX845PE ProII;
• память - 2x512MB, DDR PC333;
• видео - от того же Albatron'а, GeForce 4 440MX;
• HDD - Seagate Barracuda IV, 3 шт. - 40 Гбайт на 1 мастере, 80 Гбайт на 1 слейве, 80 Гбайт на 1 мастере;
• CD-R/RW Teac - скоростей не помню, смотреть лень, да и рояля не играет;
• всякое прочее типа клавы, мыши и прочего, к делу не относящегося.

Раскладка дисковых разделов:

• корневой (500 Мбайт) - на 1-м мастере;
• /boot (50 Мбайт) на нем же;
• /var и /usr (1 и 10 Гбайт, соответственно) там же, оба logical (все прочие - primary);
• два swap-раздела по 1 Гбайт - на 1-м слейве и втором мастере;
• /home - 160 Гбайт без двух на soft-RAID из 1-го слейва и 2-го мастера.

Система, как уже было сказано, - Archlinux 0.5, с ядром, поднятым до 2.4.22, gcc 3.0, glibc 2.3.2, binutils 2.14 с www.gnu.org, XFree86 4.3.0, KDE 3.1.4, установленные из пакетов. Графический режим - 1280x1024, 16 bit, стандартный X-сервер, без драйверов nvidia. Больше, пожалуй, добавить нечего.

Измерялась скорость запуска самого KDE и следующих KDE-приложений: konqueror'а как браузера и его же как файлового менеджера (с моими профилями), текстового редактора kate, почтовика kmail и KWord из комплекта KOffice.

Методика: сначала, после перезагрузки системы, запускалось KDE с измерением времени. Затем в сеансе KDE замерялось время запуска перечисленных приложений в указанном порядке. После этого - выход из сеанса и перезагрузка, после чего процедура повторялась второй раз. Результаты приведены в таблице.

Таблица

Тест	W/o prelink			With prelink			With/Without
Программа	1st	2nd	Avg	1st	2nd	Avg	Avg
KDE	17,94	18,16	18,05	19,13	19,19	19,16	1,06
Konqueror-Web	2,16	1,78	1,97	1,25	1,57	1,41	0,72
Konqueror-FM	2,12	1,78	1,95	1,87	1,84	1,86	0,95
Kate	1,91	1,85	1,88	1,69	1,62	1,66	0,88
Kmail	2,03	2,06	2,05	1,69	1,91	1,80	0,88
KWord	1,91	1,72	1,82	1,47	1,38	1,42	0,79

Можно видеть, что хотя прелинкованное KDE запускается чуть медленнее, чем до prelink, каждое отдельно взятое KDE-приложение стартует несколько (на 5-28%) быстрее - вывод о том, стоит ли игра свеч, предлагается сделать самостоятельно. Однако можно точно констатировать, что представленные измерения далеко не дотягивают до результатов Хосе - возможно, именно вследствие того, что не все компоненты Qt и KDE подверглись прелинкингу.

Тестирование Linux'ов. Осень 2003. Тур 1. Gentoo против Red Hat

2003 г

Учера, у США... нет, не бойтесь, не увбили там Мартына ЛУтера КингА. И даже товарища Кирова там не увбили. И вообще, убивали там не кого, а только чего - конкретно, собственное время. И убивали его в целях сугубо благородных - то есть, можно сказать, приносили в жертву, - в жертву ответу на извечный вопрос: кто на свете всех быстрее, всех стабильней и милее.

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

Генеральной идеей первого тура было: сравнить "умолчальное" быстродействие коренных представителей двух струй современного майнстрейма в Линукс-дистрибутивостроении: Red Hat как представителя пакетной линии, и Gentoo - от сборной Source Based. В дальнейшем предполагалось привлечь к ответу ещё одну пару - Mandrake от монстроизируемых максималистов и CRUX (или его клон Archlinux) - от течения здоровых минималистов.

Решено было нАчать с Gentoo - поскольку процесс его установки обещал быть более длительным. Здесь уместно сказать, на чем тестирование осуществлялось. По это дело была выделена такая машина:

• материнская плата MSI 6561 на чипсете SiS 745 под сокет A;
• в сокете находился Athlon XP 1800+ (этот индекс в пересчёте на простые мегагерцы примерно соответствует 1500 Mhz);
• 768 Мбайт памяти - два модуля в 512 и 256 Мбайт, соответственно (вытаскивать оные, для уточнения родословной, по правде говоря, было лень);
• видеокарта на GeForce2 MX о 32 Мбайт памяти, генетика её точно установлена не была;
• винчестер IBM/Hitachi на 80 Мбайт, 7200 обормотов в минуту в виде мастера на первом IDE-канале;
• сетевая карта от Intel (точное название не записал - да и вряд ли это принципиально);
• прочие компоненты (типа CD - слейва на втором канале, мыши, клавы, встроенного звука, к теме нынешнего занятия прямого отношения не имеющие.

Диск был разбит в соответствие с рекомендациями разработчиков - эмулируя процесс установки малоопытным юзером, держащимся документации, яко воинского устава (хотя, положа руку на сердце, кто рискнёт сказать, будто-бы, будучи малоопытным юзером, в документацию вообще заглядывал?). Так что на винте были учреждены: корневой раздел (/ - /dev/hda3) на 80 Гбайт, загрузочный (/boot - /dev/hda1) - на 84 Мбайт, и раздел подкачки (swap - /dev/hda2). Файловые системы - ext3fs как для /, так и для /boot (не говорите мне, что в последнем случае это бессмысленно - так уж исторически склалось).

Уже на первой стадии тестирования подстерегали тяготы и лишения. Так. упорно не желала настраиваться сеть. Были шероховатости и при настройке Иксов - впрочем, в конце концов, преодолённые. Однако времени на это ушло больше, чем планировалось в соответствие с генеральной линией партии...

Тем не менее, и из этих непредвиденных осложнений можно было сделать первый вывод о тестировании. А именно - из пакетов нужно ставить пакетные же дистрибутивы, тогда как Source Based самим Господом заповедовано собирать из исходников...

В программу тестирования вошли:

• традиционный тест линуксоидов сборка ядра (конкретно - канонической vanilla с kernel.org, версии 2.4.21, штатно входящей как в Gentoo, так и в Red Hat (тогдашних версий - напомню, дело происходило в октябре 2003 г.); конфигурация ядра - по умолчанию, после ответа на несколько вопросов, оказавшихся обязательными;
• архивирование и компрессия содержимого первого официального инсталляционного диска Gentoo 1.4, предварительно, разумеется, скопированного на винчестер;
• создание iso-образа из того же материалу, то есть из каталога с файлами первого установочного Gentoo-диска.

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

$ date > kernel# ; \
make dep && \
make clean bzImage modules modules_install && \
date >> kernel#

Архивирование и компрессия:

$ date > tar# ; \
tar cjpvf cd1.tar.bz2 cd && \
date >> tar#

Создание образа:

date > iso# ; \
mkisofs -R -J -o cd#.iso cd && \
date >> iso#

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

Далее (на те же самые разделы, с пересозданием тех же файловых систем) был установлен Red Hat 9 (с 3-дискового set'а, по возможности в минимальной комплектации), после чего отданы те же команды, что и ранее для Gentoo. А вот результаты - результаты оказались столь неожиданными, что я не буду о них распространяться, а просто приведу таблицу и график.

	Gentoo				Red Hat
Тест, час:мuн:cek	Дубль 1	Дyбль 2	Дyбль 3	Среднее	Дубль 1	Дyбль 2	Дyбль 3	Среднее
Ядро	00:07:30	00:07:29	00:07:32	00:07:30	00:06:25	00:06:20	00:06:27	00:06:24
Tar.bz2	00:12:41	00:12:18	00:12:18	00:12:26	00:11:16	00:11:18	00:11:16	00:11:17
Mkiso	00:03:00	00:02:59	00:03:00	00:03:00	00:00:18	00:00:18	00:00:18	00:00:18

Пара слов о методике. Таблица была составлена в OpenOffice.org 1.1.0. Значения в ней получены как разность вывода команды date после и до исполнения соответствующей команды, среднее также подсчитано автоматически (при формате ячеек, заданных как time). Так что наблюдаемые эффекты нельзя списать на мои ошибки в арифметике. График также построен в OpenOffice и экспортирован в GIF.

В принципе, цифры и диаграмма говорят сам за себя. Для тех же, кто не верит своим глазам, дам краткий комментарий. Red Hat, не смотря на свое пакетное происхождение и отсутствие какой-либо оптимизации под наличный процессор (напомню - Athlon XP) демонстрирует небольшое, но уверенное преимущество перед пакетным же Gentoo в тестах на сборку ядра и архивирование/компрессию. Которое становится просто подавляющим в тесте на создание iso-образа...

Объяснений этому факту у меня нет. Единственное, что приходит в голову - кривизна конкретной версии (или конкретной сборки) mkisofs в Gentoo.