Библиотека Интернет Индустрии I2R.ru

Статья эта основана на серии экспериментов, производимых с машиной на Pentium 4 в сочетании с различными Linux-системами и их ядрами. Предыдущий опыт показал, что этот процессор сам по себе не обеспечивает, по сравнению с Athlon'ом, прироста производительности, адекватного разнице тактовых частот или хотя бы цены. Однако пример того же Athlon'а вселял надежду, что существенного роста быстродействия можно добиться оптимизацией ядра Linux под конкретный процессор.

Не то что бы мне не хватало производительности Pentium 4/1,9 Ггц по умолчанию — честно говоря, и Athlon'а-то на 1,13 Ггц при должном количестве памяти более чем достаточно почти для любой задачи. Но тут уж — дело чести, подвига и геройства: за всю околокомпьютерную жизнь каждая последующая машина у меня всегда была ощутимо быстрее предыдущей. Можно назвать это азартом — ведь информационные технологии тоже своего рода спорт. Спорт сильных, смелых и, в отличие от горных лыж, уже не обязательно богатых…

Кроме того, очень хотелось проверить справедливость утверждений Intel типа «Технологии будущего — уже сегодня» и «На шаг впереди отраслевых стандартов» (вы таких слоганов наверняка тоже уже насмотрелись), тем более что результаты тестов под Windows (многократно опубликованные в том числе и в Компьюферре) настраивали на весьма скептический лад.

По традиции принято начинать с «железной» стороны дела, то есть характеристик того, что оказалось в наличии. Конфигурация подопытного кролика, описанная в предыдущей статье, была ориентирована на сопоставимость с компьютером на базе Athlon, который имелся в моем распоряжении. Для нынешних же опытов она была несколько изменена, дабы дать возможность «четверке» продемонстрировать себя во всем блеске — буде та окажется на это способной. А именно, к процессору Pentium-4/1.9 Ghz на материнской плате Soltek Sl-SD+ были добавлены память объемом 768 Мбайт (3 модуля по 256 Мбайт, производства Kingston, PC-133) и очень быстрый винчестер Seagate Barracuda ATA-IV, 40 Мбайт, 7200 об./мин в качестве мастера на первом IDE-канале [1]. По команде

hdparm -t /dev/hda

он демонстрирует скорость чтения 40 Мбайт/сек (против 23 Мбайт/сек для ранее использовавшегося Fujitsu). Правда, в качестве видеокарты на это раз выступала ASUS AGP-V3800 Magic (на Riva TNT-2 M64) с 16 Мбайт памяти SDRAM, в оправдание чего могу только повторить слова товарища Сталина: «Других писателей у меня нет». К тому же большая часть приводимых ниже результатов получена на тестах консольного режима, где хватило бы и приснопамятного Trident'а о 512 Кбайт памяти.

Основным мучителем системы выступил Linux Mandarke 8.1 с ядром 2.4.8 и XFree86 версии 4.1.0 (patch level 17). Выбор пал на него по причинам а) высокой функциональности и б) современности. Первая обеспечивает максимальное удовлетворение потребностей среднестатистического русскоязычного пользователя (даже на фоне таких отечественных дистрибутивов, как Altlinux и ASPLinux). Вторая же вселяла надежду на то, что особенности современного железа в ней будут поддерживаться наилучшим образом.

Для дополнительного издевательства был привлечен ASPLinux версии 7.1, данные для которого были получены в ходе сравнения систем на Pentium 4 и Athlon. Хотя количественное их сопоставление несколько условно (ввиду несколько иных аппаратной конфигурации, версии ядра и набора стартовых сервисов), однако далее они фигурируют в таблицах и на диаграммах для качественного сравнения.

Орудия мучений делились на те же две категории — программы консольного режима (копирование и архивирование файловых массивов, конвертирование WAV в MPEG, перекомпиляция ядра) и графический редактор GIMP, запускаемый X Window. Дополнительно использовалась комбинация первых и вторых — тесты GIMP, проводившиеся при двух фоновых задачах, выполнявшихся в отдельных текстовых консолях: все та же компиляция ядра и проигрывание mpeg-файлов программой mpg123.

Тесты были выполнены сначала в Linux Mandrake 8.1 для ядра, устанавливаемого по умолчанию при инсталляции системы. Затем были предприняты меры по оптимизации под процессор Pentium 4, благо в ядрах линии 2.4.x такая опция имеется.

Для конфигурирования ядра использовалось штатное средство из Центра управления KDE (версии 2.2), позволяющее производить выбор опций в графическом режиме. Группировка опций аналогична таковой при использовании make menuconfig. Само по себе конфигурирование в данном случае сводится к выбору процессора Pentium 4 в группе Processor Family. Дополнительно стоит проследить, чтобы были включены опции поддержки чипсетов Intel из серии i8XX (к сожалению, собственно i845 среди них пока не фигурирует) в группе блочных устройств IDE, ATA и ATAPI. Поддержку прочих чипсетов (VIA, например, а также всяческой архаики) не вредно выключить.

После перекомпиляции и переустановки ядра было проведено повторение описанных тестов. Аналогичная процедура была проделана и для ASPLinux, с учетом приведенных выше оговорок.

Теперь, наконец, пора посмотреть, что же получилось в итоге. Начнем, по традиции, с тестов консольного режима (табл. 1, рис. 1 [2]).

Таблица 1. Тесты консольного режима, мин:сек.

Тест	ASPLinux (1)	ASPLinux (2)	Mandrake (1)	Mandrake (2)
Копирование	00:59	01:09	00:31	00:30
Архивация	02:01	02:80	01:38	01:33
Конвертирование Wav в Mpeg	09:33	05:55	08:08	08:30
Компилирование ядра	08:18	09:03	07:05	07:10

Рисунок 1. Диаграмма сравнительной производительности в тестах консольного режима

Результаты консольных тестов противоречивы. При копировании и архивации файлов под управлением Linux Mandrake заметно лишь незначительное превосходство оптимизированного ядра, для ASPLinux же эти операции на оптимизированном ядре выполняется… даже медленнее! Напомню, что для Athlon'а именно на этих процедурах оптимизация ядра давала максимальный прирост производительности.

Зато ASPLinux отыгрывается на конвертации WAV в MPEG — здесь оптимизация ядра дает заметный прирост быстродействия. Для Mandrake же эффект обратный, хотя падение скорости очень незначительно.

Наконец, при тестах на скорость компиляции ядра оптимизированные ядра оказываются менее быстрыми, чем ядра по умолчанию. Тот же эффект наблюдался и для Athlon'а, то есть его можно считать закономерным и объяснить именно тем, что любое ядро собирает «само себя» быстрее [3].

Переходим к GIMP-тестам (таблица 2, рис. 2). Тесты на поворот на 90° и произвольный угол рисуют нам закономерную картину: плавную лесенку снижения времени выполнения операции от ASPLinux неоптимизированного к Mandrake оптимизированному. Качественно похожая картина и при гауссовом размытии, с той лишь разницей, что здесь ASPLinux чуть опередил Mandrake. Преимущество оптимизированных ядер сохраняется в обоих случаях, но для ASPLinux оно более выражено.

Таблица 2. Тесты в GIMP (однозадачный режим), сек.

Тест	ASPLinux (1)	ASPLinux (2)	Mandrake (1)	Mandrake (2)
Поворот на 90°	2.84	2.69	2.57	2.55
Поворот на произвольный угол	11.94	11.84	11.15	10.88
Размытие по Гауссу	8.00	7.57	8.25	7.93

Рисунок 2. Диаграмма сравнительной производительности в GIMP-тестах

Наконец, апофеоз тестирования — работа в многозадачном режиме: не ради ли многозадачности ставим мы Linux или *BSD? Если отвлечься от абсолютных цифр, GIMP-тесты при наличии фоновых задач показывают те же тенденции (табл. 3, рис. 3), хотя для Mandrake здесь более отчетливо проступает превосходство оптимизированного ядра над ядром по умолчанию.

Таблица 3. Тесты в GIMP (многозадачный режим), сек.

Тест	ASPLinux (1)	ASPLinux (2)	Mandrake (1)	Mandrake (2)
Поворот на 90°	26.50	12.08	5.38	3.06
Поворот на произвольный угол	33.75	30.79	26.53	25.03
Размытие по Гауссу	17.18	13.88	26.53	18.69

Рисунок 6. Диаграмма сравнительной производительности в тестах многозадачного режима

Подчеркну, что приведенные данные нельзя рассматривать как сравнительное тестирование дистрибутивов. Более низкие скоростные показатели, получаемые (причем далеко не на всех тестах) для ASPLinux по сравнению с Mandrake, обусловлены, вероятно, более старой версией ядра, меньшим объемом памяти и более медленным винчестером.

В то же время показательно, что выигрыш в быстродействии при оптимизации ядра для ASPLinux в большинстве случаев оказывается больше. Однако практически ни в одном случае такая оптимизация не дает результатов, сравнимых с оптимизацией под Athlon. Это легко объяснимо большим возрастом последней платформы и, как следствие, более проработанной оптимизацией. Вероятно, ни в одной из Linux-систем выигрышные особенности архитектуры Pentium-4 не обыгрываются в должной мере.

Так что приходится согласиться с мнением Intel: Pentium-4 — это технология завтрашнего дня. На наступления коего, вместе с оптимизированным софтом, и остается надеяться…

[1] — В прошлую мою заметку вкралась ошибка: я писал, положившись на буквально понятый текст руководства (for IDE RAID only), что эти разъемы как дополнительные IDE не работают; так вот, по сообщениям моих корреспондентов, это не так.
[обратно к тексту]

[2] — Примечание: здесь и в последующих таблицах цифры (1) и (2) получены для ядер по молчанию и ядер, оптимизированных для процессора Pentium-4, соответственно.
[обратно к тексту]

[3] — Напомню, что в качестве тестовой конфигурации во всех случаях использовалось именно ядро, устанавливаемое каждой системой по умолчанию при инсталляции.
[обратно к тексту]