Athlon и Linux: созданы друг для друга

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

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

Athlon для Linux

К выбору конфигурации я подошел очень серьезно. Столкнувшись при этом с явлением, казалось бы, прочно забытым с советских времен - дефицитом. Затрагивающим в первую очередь наиболее старшие процессоры и самые "крутые" материнские платы. Однако препятствие это было успешно преодолено, результатом чего явилась следующая платформа:

процессор Athlon T-Bird в конструктиве Socket A (естественно) на 1,13 GHz, с частотой FSB 133 MHz, снабженный кулером Chrome Orb Thermaltake;
системная плата ASUS A7V133 на чипсете VIA KT133A, поддерживающем 133 (266) MHz как на процессорной шине, так и на шине памяти; плата эта неоднократно описывалась в литературе (например: Александр Карабутов. Союз-Аполлон-Атлон. Компьютерра, 5 июня 2001, #21 (398), с. 36-39), поэтому скажу только, что мне достался экземпляр с IDE-RAID (на чипе Promise PDC20265R) и без всяких излишеств типа интегрированного звука;
память PC-133 производства SEC, 1 модуль на 256 Мбайт;
видеокарта Matrox G-450 с 16 Мбайт памяти DDR;
винчестер Quantum lct 20 Гбайт (ATA-100, число же оборотов остается загадкой - говорят, что реально - меньше 4500 об./мин.);
CD-R/RW Panasonic 8x4x32 (IDE);
Zip 100 Мбайт;
некий флоппи-дисковод;
звуковая карта SB AWE128 (в девичестве Ensoniq 1371).

Все это хозяйство было упаковано в корпус ASUS FK-600 (с 250-ваттным блоком питания и дополнительным вентилятором на задней стенке). Винчестер был подключен как Master к первой линии RAID-контроллера (разумеется, соответствующая перемычка для контроллера Promise была установлена в положение ATA-100) штатным 80-жильным шлейфом. Привод Zip и CD-R/RW были помещены на первый встроенный канал IDE (как Master и Slave, соответственно) посредством стандартного 40-жильного шлейфа.

Все перемычки на системной плате были сохранены в положении по умолчанию, то есть управление частотой шин процессора и памяти осуществлялось из BIOS. Каковой (AWARD 6.0 Medallion), нужно заметить, предоставляет возможность настройки массы параметров, прямо влияющих на производительность (в пункте меню Advanced).

Среди них, разумеется, как и на большинстве современных "мам", возможнось изменения частоты шины процессора и памяти - обеих в диапазоне от 90 до 166 Mhz с шагом в 1 Mhz. При этом для 133-мегагерцного Athlon'а изменять их можно только вместе; предполагаю, однако, что для 100-мегагерцного Athlon'а доступна и асинхронная работа.

Есть возможность изменения множителя - от 6 до 12.5. Впрочем, опция эта, по понятным причинам. в большинстве случаев носит чисто декоративный характер.

Забавной показалась мне опция System Performance Setting - с вариантами Optimal и Normal. Я-то, по наивности, всегда думал, что оптимальная работа и есть норма для любого оборудования. Так вот, выставление позиции Optimal делает доступными чередование банков памяти, 4-килобайтный pagging и burst refresh, направленные на достижение максимальной производительности.

Настройки памяти сконцентрированы в пункте Advanced - Chip Configuration. Здесь задается общая ее конфигурация - в соответствие с SPD, как 7-нанносекундной (с таймингами 2-2-2) или 8-нанносекундной (тайминги 3-3-3). Есть и опция User Define, позволяющая вручную выставить CAS, RAS и RAS to CAS. А также включить чередование банков (DIMM Interleave) независимо от общей оптимизации системы.

Все перечисленные пункты стали достаточно обычными в современных системных платах. Однако на A7V133 я обнаружил группу опций настройки памяти, с которыми до сих пор не сталкивался. Это - DRAM Read Latch Delay (от -0.01 до 0.75 ns), Memory Early/Delay Write (от 0.0 до 0.5 ns), Memory Data Drive (Weak или Strong), CAS# Drive (Weak или Strong). исходя из названий, можно предположить, что они предназначены для тонкой настройки чтения/записи. Впрочем, для всех из них имеется и опция Auto.

Прочие пункты меню BIOS достаточно обычны. Чтобы не возвращаться к этому, замечу только, что присутствует функция температурного мониторинга. Так вот, в моей конфигурации она стабильно показывала 42-43 градуса для системной платы и 54-55 градусов - для процессора.

Для моих целей я внес лишь минимальные изменения в настройки по умолчанию. Частоты FSB и шины памяти были выставлены на 133 MHz (автоматические их значения были 100 MHz), включена оптимизация System Performance Setting, тайминги памяти было предписано брать из SPD. Прочие же параметры управления памятью были установлены в положение Auto. Ну и, разумеется, я отключил все, имеющее отношение к энергосбережению.

Linux для Athlon'а

Разобравшись с "железной" частью системы, следовало решить, что же на нее ставить. Из соображений сугубо патриотических рассматривалось два варианта - Linux Mandrake RE Spring 2001 и ASPLinux 7.1 (релиз, двухдисковая версия). Оба эти дистрибутива разработаны нашими соотечественниками и, помимо иных (весьма многочисленных) достоинств, отличаются хорошей поддержкой кириллицы.

Установка Mandrake, что называется, "в лоб" закончилась неудачей: программа установки, правильно определив устройства hda и hdb (Zip-привод и CD-R/RW, соответственно), отказалась опознать винчестер (устройство hdc; напомню, что в Linux IDE-накопители маркируются как hda - первый физический накопитель на первом канале, hdb - второй накопитель, и т.д.).

Впрочем, эта особенность связана с контроллером Promise и документирована в руководстве по Linux Mandrake RE. Как и пути решения этой проблемы. Однако я отложил ее на потом, перейдя к установке ASPLinux. Каковая, будучи многократно описана ранее, и прошла без всяких проблем.

В ходе установки на диске были созданы разделы - корневой (/), объемом 2 Гбайт и /home, размером 15 Гбайт, оба с журналируемой файловой системой reiserfs. Ввиду достаточного количества памяти, от раздела подкачки я отказался.

К комплект ASPLinux входит две версии ядра - 2.2.19 и 2.4.2, с возможностью выбора между ними в процессе загрузки. Кроме того, для сборки ядер имеется ряд предварительно заготовленных конфигурационных файлов на разные случаи жизни. Для ядра 2.4.2, в частности, имеется и вариант оптимизации под Athlon/Duron.

Далее я оставил ядро 2.2.19 без изменений - в качестве эталона для сравнения. А ядро 2.4.2 было перекомпилировано с оптимизацией под Athlon/Duron и, по возможности, с сохранением прочих параметров максимально близкими к конфигурационному файлу по умолчанию. После чего можно было приступать к сравнению.

Условия тестирования

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

копирование в консольном режиме (командой cp -R ~/copyfrom ~/copyto) каталога с большим количеством файлов различного размера, общим объемом 34 Мбайт; вследствие эффективного кэширования в Linux файловых операций, это тест не на быстродействие диска, а на производительность подсистемы процессор/кэш/оперативная память;
манипуляции в GIMP с растровыми изображениями в формате TIF (файл размером 11.6 Мбайт) и PNG (файл размером 7.3 Мбайт); они включали в себя вращение на 90 градусов и на произвольный угол, а также Гауссово размытие (RLE) с радиусом 10 пикселей
традиционный тест быстродействия Linux-систем - перекомпиляция ядра при идентичных параметрах конфигурационного файла.

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

Каждый (кроме перекомпиляции ядра) тест для обоих ядер (2.2.19 с опциями по умолчанию и 2.4.2, оптимизированного для Athlon/Duron) был выполнен по 10 раз с вычислением среднего и стандартного отклонения, для проверки воспроизводимости и минимизации влияния случайных факторов. Результаты чего можно видеть в таблице.

Таблица

Test P-III Athlon-2.2 STD Athlon-2.4 STD Ath2.4/2.2

Copy files, s 5.69 2.67 0.785 0.88 0.067 32.76

TIF 11.6 MB

Rotation 90, s 8.29 4.50 1.10 3.68 0.86 81.78

Rotation arbitrary, s 24.71 10.57 0.18 10.46 0.89 98.95

Gaussian Blur, s 18.37 10.13 0.56 10.76 0.31 106.21

PNG 7.3 MB

Rotation 90, s - 2.78 0.08 2.51 0.07 90.23

Rotation arbitrary, s - 7.71 0.45 7.44 0.14 96.42

Gaussian Blur, s - 9.31 0.72 8.08 0.72 86.89

Kernel Compilation, min - 04:44 - 05:40 - 119.72

В первой колонке таблицы, для сравнения, приведены результаты некоторых тестов для системы с процессором Pentium-III/733 Mhz, на материнской плате ABIT SE6 (детали конфигурации и условия тестирования были описаны ранее).

Сравнение P-III/733 и Athlon/1130 даже в ситуации с неоптимизированным для последнего ядром интересно само по себе. Исходя из соотношения тактовых частот процессоров, максимум, на что можно было бы расчитывать для Athlon'а - это 30-50-процентный прирост производительности. Хотя на реальных задачах и этого ожидать было бы трудно - рост быстродействия давно уже не связан с тактовой частотой линейной зависимостью.

Но в приводимой таблице мы имеем удовольствие наблюдать для Athlon двухкратный (и более) рост скорости выполнения задач как в консольном режиме (копирование файлов), так и в системе X Window (вращение на 90 градусов и на произвольный угол); лишь для гауссова размытия Athlon по быстродействию опережает P-III "всего" на 80% (фиг. 1).

Фиг. 1. Диаграмма сравнительного быстродействия P-III/733 и Athlon/1130 (как с ядром по умолчанию, так и с оптимизированным)

Повторю, что это относится к производительности Athlon с ядром по умолчанию. Если же обратиться к результатам, которые он показывает с ядром, перекомпилированным для Athlon/Duron, результаты еще более впечатляющие. Так, операция копирования файлов при оптимизированном ядре выполняется в три раза быстрее, чем при ядре по умолчанию, и более чем в шесть раз быстрее, чем на системе с процессором Pentium-III/733.

Тесты графического режима не дают столь ясной картины. Так, при манипуляциях с tif-файлом объемом 11.6 Мбайт разница в производительности Athlon с разными ядрами не превышает 20% (вращение на 90%), а в случае гауссова размытия оптимизированное ядро вообще отстало от неоптимизированного (см. фиг. 1). Впрочем, учитывая статистические параметры (см. табл.) быстродействие ядер при вращении на произвольный угол и при гауссовом размытии следует считать идентичным.

Интересно, что при собственно компиляции ядра (с идентичной конфигурацией) ядро 2.2.4 с оптимизацией под Athlon также отстало (и весьма существенно, почти на 20%) от неоптимизированного ядра 2.2.19 (см. табл. и фиг. 1). Правда, для этого теста статистических параметров не дается: каюсь, у меня просто не хватило бы терпения выполнить перекомпиляцию ядра 20 раз подряд. Однако для обоих ядер компиляция выполнялась несколько раз (хотя и не всегда с идентичными параметрами), и с качественно аналогичным результатом. Более того, процесс этот для ядра 2.4.2 оказывался более медленным даже в том случае, когда собиралась более "легкая" конфигурация.

Весьма показательны результаты манипулирования с изображением в формате PNG (фиг. 2). Необходимость обратиться к ним возникла потому, что при манипуляциях с TIF-файлом под ядром 2.4.2 визуально фиксировалось стопорение процесса незадолго до его завершения (о возможных причинах этого я поговорю в заключении). Так вот, при файле меньшего объема оптимизированное под Athlon ядро 2.4.2 продемонстрировало хотя и небольшое (5-15%), но отчетливое (что можно видеть из величин стандартного отклонения в таблице) преимущество над неоптимизированным ядром 2.2.19 (фиг. 2).

Фиг. 2. Сравнительное быстродействие манипуляций над PNG-файлом для ядер 2.2.19 (по умолчанию) и 2.4.2 (оптимизированном для Athlon/Duron)

Признаюсь, результаты первых же измерений оказались для меня неожиданными: я. конечно, надеялся, что Athlon (с поправкой на разницу в тактовых частотах) покажет большее быстродействие, чем Pentium-III, но не настолько же... Почему, собственно, и пришлось прибегнуть к накоплению какой-никакой статистики. Каковая и подтвердила первые единичные измерения. Что, как мне кажется, требует объяснения.

Интерпретация

Очевидно, что разница в производительности (по крайней мере не некоторых задачах под Linux) между Pentium-III и Athlon не может быть обусловлена разницей в их тактовых частотах. Единственное, что приходит в голову - это различие архитектуры.

А главное в данном случае архитектурное различие между Pentium-III и Athlon - в размере и организации кэш-памяти как первого, так и второго уровня. Как известно, Athlon не только много превосходит Pentium-III по объему кэша L1 (128 Кбайт против суммарных 32, по 16 на данные и команды, Кбайт, соответственно). Но и организация кэша у него носит эксклюзивный характер. То есть данные в кэше L1 не дублируются в кэш-памяти второго уровня. В итоге эффективный объем кэширования у Athlon может составить 384 Кбайт.

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

Подтверждение этому можно видеть в сравнении скорости копирования файлов для ядра по умолчанию и ядра, оптимизированного под Athlon/Duron. Не будучи программистом, не возьмусь судить, как конкретно реализована такая оптимизация. Однако резонно было бы ожидать, что именно в оптимизации работы с кэш-памятью большого объема и эксклюзивного характера. Что и обусловило трехкратное преимущество оптимизированного ядра на этой операции.

Не противоречит этому и сравнение результатов манипулирования растровыми изображениями. Если при меньшем объеме файла (да еще и с учетом его формата - PNG) преимущество оптимизированного ядра выступает вполне отчетливо, то с ростом размера (и изменением формата) изображения оно сглаживается вплоть до полного исчезновения. Видимо, где-то здесь лежит предел объема данных, которые могут вместиться в кэш-память заданного размера.

Требует объяснения и тот факт, что при перекомпиляции ядра неоптимизированный его вариант существенно опережает оптимизированный. Единственное, что я могу предположить по этому поводу - то, что ядра линии 2.2 сами по себе несколько быстрее, чем линия 2.4 (это отмечалось многими, в том числе и Линусом Торвальдсом). И именно на этой задаче некоторая замедленность ядра 2.4 (вероятно, за счет поддержки ряда новых функций) не компенсируется даже его оптимизацией под конкретный процессор.

Вместо заключения

Я не рискну подводить какие-либо итоги или, паче того, давать конкретные рекомендации. Мне хотелось бы только обратить внимание на потенциал процессора Athlon как аппаратной платформы для Linux-систем (и, шире, для Unix-подобных систем вообще). Доказательством такого потенциала является прирост производительности его по сравнению с Pentium-III при решении задач, требующих активного обращения к оперативной памяти.

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

Alex Fedorchuk