Все против всех. Тесты-2008

Алексей Федорчук
20 июля 2008 г

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

Содержание

Введение с поросячьим подтекстом

От автора: слабонервным рекомендуется введение пропустить.

История начинается с того, что у широких масс прогрессивных трудящихся всего мира появилась настоятельная потребность в 64-битных процессорах, каковая немедленно была удовлетворена производителями. Первой на это поле вышла AMD, назвав свою технологию добавления к стандартному набору команд i386 (или, иначе говоря, x86) 64-битных инструкций незамысловато — AMD64.

Правда, Intel уже давно имела собственный 64-битный процессор (IA-64, в девичестве Merced), не способный, однако, выполнять программы, написанные в расчете на i386 (а собственных программ под него почти не писали). И потому распространения за пределами серверного сегмента этот процессор не получил. Однако, дабы не отстать от конкурента, Intel тоже создала свой x86-совместимый 64-битный процессор, прикрутив к нему AMD’ешный набор инструкций, и назвав эту технологию собственным именем — EM64T или x86_64 (для отличия от истинно 64-битного Merced’а, IA-64).

Как уже было сказано, 64-битные настольные процессоры возникли как реакция на потребность пользователей, каковую, по теории профессора Выбегаллы, следует определить как материальную. И, опять же в подтверждение блестящего тезиса Амвросий Амбруазовича, стоило пользователям свою матпотребность в 64-битном компьютере удовлетворить, как у них в соответствии развилась потребность духовная — в 64-битных операционных системах. Ибо что еще с компьютером можно делать, кроме как устанавливать на него разные операционки?

На духпотребность пользователей разработчики софта откликнулись незамедлительно — выпуском 64-битных версий Windows, Net- и OpenBSD (говорят, что процесс портирования NetBSD на архитектуру AMD64 — в силу исторического приоритета будем называть её так, — занял около суток), несколько позднее FreeBSD.

Разумеется, и Linux не остался «на обочине культурного процесса»: каждый уважающий себя дистрибутив этой ОС из числа распространённых счёл своим долгом обзавестись 64-битной версией. А некоторые сделали себе имя на портировании 32-битной системы на 64-битную архитектуру. Лишь немногие дистрибутивы (в первую очередь Slackware и большинство ее клонов) проявили консерватизм и нежелание считаться с духпотребностями пользователей, упрямо сохраняя верность классической 32-разрядности.

Однако так ли они были неправы в своей приверженности старине в эпоху, когда 32-битные процессоры были сметены с прилавков магазинов маркетинговым ураганом? Это и есть первый вопрос, на который призваны ответить мои заметки.

Матпотребности простого настольного юзера не ограничились 64-битными вычислениями — не менее необходима была для него и многопроцессорность, особенно реализованная в виде двух (и более) ядер в едином корпусе. И здесь первопроходцем оказалась компания AMD, выпустив двухяъдерные (и к тому же 64-битные) процессоры AMD64 X2. Компания Intel не замедлила нанести ответный удар, представив собственные «камни» о двух ядрах, Intel Core 2 Duo.

Дальше — больше, в дело вступила четырехствольная артиллерия, сначала от Intel — Core 2 Quad, а затем и от AMD — под скромным именем Phenom, причем последний процессор существует даже в «трехголовом» варианте.

Конечно, многопроцессорные машины существовали очень давно, но использовались они исключительно как сервера и специализированные рабочие станции, не в последнюю очередь — вследствие своей вполне неприличной цены. AMD64 X2 же и многоядерные вариации от Intel’а сделали многопроцессорность доступной (в том числе и финансово) для тех самых юзерских масс, о благе которых столь неустанно пекутся все гиганты IT-индустрии.

Удовлетворение очередной духпотребности не вызвало у осестроителей чрезмерного напряжения сил: практически все операционки из категории «всамделишних» в той или иной мере поддерживают симметричную многопроцессорность (SMP) с незапамятных времен. Немало существует и приложений, способных использовать более чем два процессора. Правда, в основном они относятся к категории так называемых профессиональных, но в последнее время пишут и «полулюбительские» программы, извлекающие выгоду из двух «камней».

Так что вторая линия противостояния вырисовывается четко — между продукцией Intel и AMD.

В противостоянии что 32-битных и 64-битных систем, что двухядерных процессоров от разных производителей сравнительное быстродействие определяется посредством тестов. А поскольку в обоих случаях измеряется быстродействие в первую очередь процессоров (точнее, подсистемы процессор плюс память), резонно было бы максимально снизить влияние привходящих обстоятельств. В данном случае в качестве таковых выступают операции, связанные с чтением с дисков и записью на них. И от этих операций желательно избавиться — тем более, что при современных объемах памяти это совсем несложно: достаточно выполнять чисто процессорные тесты во временной файловой системе в оперативной памяти, которая в Linux носит название tmpfs.

«Но живем ведь, говорю, не на облаке». И в реальной жизни есть очень немного задач, которые можно было бы выполнить, не прибегая к дисковым операциям. Поэтому интересно было бы померить, каким образом последние влияют на результаты процессорных тестов. Таким образом, в сюжете наших заметок появляется третья линия противостояния — между операциями в tmpfs и на реальных block device based файловых системах.

Всем сказанным выше и определяется выбор участников тестирования и его условий.

Участники тестирования

В качестве предметов для издевательства выступало две машины — одна на процессоре AMD64 X2, и вторая — на процессоре Intel Core 2 Duo. Конфигурация первой была подробно описана в прошлогодней заметке о двух умах. Особенности второй составили предмет заметки «Две головы от Intel». Поэтому лишь вкратце напомню их характеристики, существенные для нашей темы.

Итак, цвета AMD защищала машина следующей конфигурации:

  • материнская плата ASUS M2NPV-VM на чипсете GF6150+430 MCP от Nvidia;
  • процессор AMD64 X2 6000+ (сокет AM2), с мегабайтным кэшем L2 на каждое ядро, реальная тактовая частота — 3 Ггц;
  • память DDR2, PC-6400, Samsung Original, две планки по 1 Гбайт каждая, установлены для работы в двухканальном режиме;
  • два винчестера SATA от Samsung, 7400 об./мин., 160 и 120 Мбайт, оба с кэшем 8 Мбайт.

Под флагом Intel в борьбу вступила такая «тачка»:

  • материнская плата ASUS P5E-VM SE, на Intel’овском же чипсете G35, юный мост ICH9;
  • процессор Intel Core 2 Duo E8400 (сокет LGA775), ядро Wolfdale (45 нм), суммарный кэш 6 Мбайт, тактовая частота — 3 ГГц;
  • память DDR2, PC-6400, Corsair XMS2 С5, две планки по 2 Гбайт каждая, установлены для работы в двухканальном режиме;
  • два винчестера SATA от Samsung, 7400 об./мин., первый — 500 Гбайт, 16 Мбайт кэша; второй — 160 Мбайт, кэш 8 Мбайт (тот же самый, что ранее стоял в первой машине).

На машине с процессором AMD были установлены Zenwalk 5.2 current (то есть текущая стабильная версия) — первой системой, и Slamd64 12.1 — второй, обе — на первом, сташестидесятигигабайтном, винчестере. На котором, кроме того, имелся раздел 4 Гбайт, специально предназначенный для тестирования. Он нес на себе файловую систему Ext3fs, смонтированную в режиме ordered с опциями noauto,user. Эта файловая система монтировалась в процессе тестирования (из тестового сценария) в каталог ~/ptest.

Прочее (120 Гбайт) дисковое пространство первого «харда» вместе со вторым винчестером было объединено в программный RAID нулевого уровня, с файловой системой ReiserFS, смонтированной в каталог /home/data. Как будет видно из дальнейшего, RAID-массив в тестировании не участвовал.

На машине с процессором Intel первой системой был установлен Zenwalk 5.2 current, обновленный посредством

$ netpkg upgrade

до состояния snapshot, то есть разрабатываемой версии.

Поскольку винчестер в 160 Гбайт был перенесен с первой машины без изменений, Slamd64 на второй машине также имел место быть, став второй системой на Intel-машине.

Кроме block device based, на обеих машинах в тестировании задействовалась файловая система в оперативной памяти, подмонтируемая при старте такой строкой в файле /etc/fstab:

tmpfs	/tmp	 tmpfs	noatime		0	0

Поскольку на машинах — участницах тестирования, было установлено разное количество оперативной памяти, для уравнения шансов Intel-машина запускалась с параметром ядра mem=2016M. Почему именно столько? Потому что на AMD-машине 32 Мбайт системной памяти было отведено под буфер видеокарты. На Intel-машине под это дело выкроилось аж 256 Мбайт, однако очевидно, что они лежали за пределами доступной для ОС памяти.

Возникает вопрос — насколько правомерно сравнительное тестирование, проведенное для разных дистрибутивов на не вполне идентичном «железе»? Отвечаю: по моему скромному мнению, вполне правомерно. Ибо Zenwalk являет собой достаточно точный клон Slackware, а Slamd64 — просто результат портирования последней на машины с процессорами, поддерживающими 64-битные инструкции.

Впрочем, о близости систем (с учетом различия процессоров) можно судить по выводу команды

$ uname -a

для всех программно-аппаратных комбинаций:

Slamd64 12.1, AMD64x2 6000

Linux alv 2.6.24.5 #1 SMP Sun May 4 16:51:34 BST 2008
     x86_64 x86_64 x86_64 GNU/LinuxZenwalk 5.2, AMD64x2 6000

Linux alv 2.6.24.5 #1 SMP Sun May 4 16:51:34 BST 2008
     x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ AuthenticAMD GNU/LinuxZenwalk 5.2, Intel(R) Core(TM)2 Duo, 3.00GHz

Linux zenwalk 2.6.25.10 #1 SMP PREEMPT Fri Jul 11 20:25:26 CEST 2008
     i686 Intel(R) Core(TM)2 Duo CPU E8400  @ 3.00GHz GenuineIntel GNU/Linux

Что же до не полной идентичности памяти и дисков — различия между ними пренебрежимо малы. Что, собственно, и будет видно из результатов тестирования.

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

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

Тестовый набор включал:

  • разворачивание архива дерева портежей Gentoo — файл portage-20080706.tar.bz2 объемом 31,1 Мбайт, — посредством командыtar xjf portage-20080706.tar.bz2
  • обратное архивирование полученного дерева с компрессией bzip2:tar cjf portage.tar.bz2 path2/portage
  • обратное архивирование того же дерева с компрессией gzip:tar czf portage.tar.gz path2/portage
  • кодирование пяти wav-файлов общим объемом 231 Мбайт в формат flac командойflac -best path2/*.wav
  • кодирование тех же пяти wav-файлов в формат ogg командойoggenc path2/*.wav -q 10

Тестирование выполнялось в «голой» консоли, после старта системы с runlevel 3 — в Slackware и её клонах это загрузка полнофункциональной системы без Иксов.

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

  1. создание каталога /tmp/test и переход в него;
  2. копирование архива и wav-файлов из места их постоянного хранения в /tmp/test;
  3. развертывание и декомпрессия архива tar.bz2;
  4. архивирование и компрессия посредством tar+bzip2;
  5. архивирование и компрессия посредством tar+gzip;
  6. кодирование wav-файлов командой flac;
    для пунктов 3-6 время начала и окончания действия, замеряемое командой date до и после операции, перенаправлялось в результирующий файл командой cat ... >> ...
  7. удаление всех промежуточных продуктов тестирования командой rm -Rf /tmp/test.

Второй этап — определение скорости выполнения тех же операций на реальной файловой системе, — осуществлялся точно также. С тем лишь отличием, что каждый блок действий начинался монтированием тестового раздела в каталог ~/ptest, а завершался — его отмонтированием. Как следует из приведенной выше опции монтирования в файле /etc/fstab, все тесты проводились с правами пользователя.

Каждый блок операций выполнялся три раза, между которыми происходила очистка тестового каталога в tmpfs или размонтирование тестовой файловой системы ext3fs. Собственно, сначала я разогнался и начал делать по пять замеров для каждого блока, но быстро понял, что это бессмысленно ввиду почти полной идентичности результатов, после чего перешел на «трехразовое питание». Чтобы в этом убедиться, достаточно заглянуть в таблицу.

Таблица 1

Тест ## Сек.
untar 1 15
2 14
3 15
4 15
5 14
Среднее 14,5
tar+bzip2 1 52
2 53
3 53
4 52
5 53
Среднее 52,5
tar+gzip 1 9
2 9
3 9
4 9
5 9
Среднее 9,0

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

Далее будут рассмотрены собственно результаты тестирования. Они сгруппированы в соответствии с тремя линиями противостояния.

64 vs 32

Для меня история противостояния 32- и 64-битных систем началась с того момента, как у меня впервые появилась 64-битная машина (это было три года назад, в июле 2005-го).

В разное время на обеих этих машинах побывали CRUX, Archlinux, FreeBSD 5-й и 6-й веток — все они как в 32-битном, так и в 64-битном исполнении. И ни разу я не заметил существенного повышения быстродействия при удвоении разрядности. Исключение составил CRUX 2.1 for AMD64 — визуально это был самый быстрый дистрибутив, который я видел в своей жизни. Хотя и тут 32-битный CRUX от него не сильно отставал, почему, возможно, дальнейшее развитие 64-битного CRUX’а и прекратилось.

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

Следующая попытка сравнения 32 vs 64 была предпринята с появлением в октябре 2006-го второй 64-битной машины, на которой проживали преимущественно Kubuntu разных версий и Zenwalk. Последний тогда (как и поныне) имел только 32-битную реализацию, тогда как Kubuntu была представлена в обоих вариантах. Вот на ней я и попытался провести серию тестов на сравнительное быстродействие.

Результаты тестов показались мне достаточно тривиальными и совпадающими с визуальными впечатлениями: на всех процессорных операциях никакой разницы, выходящей за пределы ошибки эксперимента, между 32-битной и 64-битной версиями не обнаружилось. А вот на тестах с существенной ролью операций дисковых различия выявились — весьма существенные, и причем не в пользу 64-битного «камня». Чего, впрочем, и можно было ожидать, исходя из общих соображений. Опять-таки, доводить это дело до «товарного вида» мне показалось скучным, да и другие дела появились.

Третий же «подход к снаряду» был связан с появлением у меня двухъядерной машины с процессором от Intel. По некоторым причинам, о которых речь пойдет в следующем разделе, мне показалось интересным сравнить производительность «камней» от AMD и Intel, аналогичных по разрядности, количеству ядер и тактовой частоте. Ну а раз уж я взялся за тесты с намерением их довести до публикации, почему бы было заодно не сравнить номинальное быстродействие 32- и 64-битных систем?

В это же время мне попалась на глаза заметка Алексея Михайлова , как раз и посвященная изучению сравнительной производительности 32-битных и 64-битных версий таких дистрибутивов Linux, как Fedora, OpenSUSE и Ubuntu. В ней автор по результатам серии тестов, как то:

  • измерение скорости загрузки системы,
  • кодирование звука WAV в форматы Ogg, MP3 и Flac,
  • развертывание архива tar.bz2 и обратное архивирование
  • компиляция ядра Linux,

приходит к выводу о безусловном превосходстве 64-битных версий всех рассмотренных дистрибутивов по всем позициям. Причем количественно это превосходство составляло:

  • от 1.2% до 26.9% для Fedora,
  • от 0.6% до 45% для OpenSUSE,
  • от 0.6% до 31.7% для Ubuntu 8.04.1.

Причем наибольшая разница выявилась при конвертации wav в ogg (от 27% для Fedora до 31% для Ubuntu, при промежуточных 29№ в OpenSuse).

Тест же на Flac-кодирование показал плохую воспроизводимость: -0,6% для Fedora, 0,6% для Ubuntu, и аж 45% для OpenSuse. Первый результат автор заметки волюнтаристически отбросил как ошибку эксперимента, хотя с не меньшим основанием это можно было бы сделать для результата по OpenSuse — дистрибутива, никогда и ни с какой стороны не славившегося сверхъестественным быстродействием. Не говоря уж о том, что между -0,6 и 0,6% разница просматривается с трудом.

К тому же и условия тестирования, как они описывались в заметке, были, на мой взгляд, не вполне адекватны: тесты и выполнялись в графическом окружении GNOME, тогда как для использовавшихся в них чисто консольных программах резонно было бы исполнение в консольной же среде. И, насколько можно было понять из заметки, каждый тест выполнялся лишь единократно — уверен, что простое повторение теста на flac-кодирование внесло бы ясность в вопрос, что являлось ошибкой эксперимента.

Всё это и подвигло меня на проведение собственной серии тестов на тему 64 vs 32, результаты которых описаны ниже, приведены в таблице 2 и проиллюстрированы диаграммами.

Таблица 2
Сводные результаты измерений по всем четырем комбинациям процессор — дистрибутив, сек.)

Процессор AMD64 X2 6000 Intel core 2 Duo 8400
Дистро Zenwalk Slamd64 Zenwalk Slamd64
FS tmpfs ext3 tmpfs ext3 tmpfs ext3 tmpfs ext3
untar 15,0 27,0 11,5 29,5 10,0 28,5 19,5 24,0
tar+bzip2 52,5 55,0 43,5 46,0 35,0 36,0 27,0 29,0
tar+gzip 9,0 10,0 9,5 9,5 8,0 9,0 7,0 9,0
wav2flac 29,5 30,5 28,5 29,0 26,0 27,0 30,5 29,5
wav2ogg 56,0 56,0 37,5 38,0

Примечания:
1. Для каждого из тестов даны средние по трем измерениям.
2. Тест кодирования wav в ogg на AMD-машине не проводился по организационным причинам (машину пора было отдавать).
3. Меньшие значения соответствуют лучшему результату

Приводимые здесь диаграммы показывают сравнительное быстродействие 32- и 64-битных дистрибутивов на обеих аппаратных платформах для операций в tmpfs.

test-ris2.1
test-ris2.2Из таблицы 2 и особенно из диаграмм можно видеть, что на платформе AMD в трех из четырех проведенных тестов (развертывание архива, архивирование парой утилит tar и bzip2, кодирование wav во flac) 64-битный дистрибутив лидирует, причем в первых двух тестах — весьма уверенно. В архивировании же посредством tar и gzip разница между 32- и 64-битной системами настолько мала, что её можно смело считать лежащей в пределах чувствительности метода.

На платформе Intel картина несколько более сложная. Zenwalk с его 32-мя битами оказывается быстрее на развертывании архива и кодировании wav в flac (в первом случае — весьма ощутимо). При архивировании же посредством tar и bzip2 и кодировании цфм в ogg он уступает (во втором случае значительно) 64-битному Slamd’у. Результаты же архивирования с помощью tar и gzip опять можно считать равными.

Таблица 3
Относительные значения быстродействия 32- и 64-битных систем

AMD Intel
64/32 64/32
untar 0,77 1,95
tar+bzip2 0,83 0,77
tar+gzip 1,06 0,88
wav2flac 0,97 1,17
wav2ogg 0,67

Примечание: в числителе — 64-битная система, в знаменателе — 32-битная

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

AMD vs Intel

Эпоха противостояния Intel и AMD началась очень давно — ещё до того, как я увидел первую персоналку. Сначала AMD была в роли быстроногого Ахиллеса, вечно догоняющего неторопливую черепаху, компенсируя недостаточную производительность своих процессоров их сугубой дешевизной. И длилось это очень немало лет, пока близ рубежа тысячелетий не произошел перелом: первой преодолев планку в один гигагерц тактовой частоты, AMD впервые добилась паритета с Intel. Вынудив последнюю совершить финт ушами, выбросив на рынок процессоры Pentium 4, тактовая частота которых, казалось, могла наращиваться до заоблачных высот, недосягаемых для процессоров AMD с их традиционной архитектурой. Тогда-то впервые и заговорили о том, что мегагерцы и гигагерцы от AMD и от Intel «разные». Потому что Athlon’ы не без успеха конкурировали с «четверками» при тактовых частотах в полтора, а то и в два раза ниже. А с появлением AMD64, а потом еще и их же «двухголовых», скорая смерть архитектуры, лежащей в основе Pentium 4, стала очевидной, так как они не смогли достичь не то что обещанных 10 Ггц, но даже и 4-х.

То, что Pentium 4 был для Intel именно прыжком в сторону, мне казалось еще тогда, в далеком нынче 2001-м или 2002-м годах, когда у меня появилась первая машина на этом процессоре. И уже тогда, несмотря на все уверения аналитиков, что Pentium IV — «это всеръёз и надолго», подобно Ленинскому НЭПу, я был уверен, что произойдет возврат к линии Pentium III.

Что и свершилось с выпуском процессоров с архитектурой Core — прямых наследников Pentium III. Предназначенные сначала для мобильных систем, они быстро переместились в десктопный сегмент, обзавелись 64-битными инструкциями и двумя, а в дальнейшем и четырьмя ядрами. И AMD, уже было почувствовавшей себя царем горы, пришлось несколько потесниться на её вершине.

Даже выпуск AMD’шниками «четырехголового камня», получившего громкое имя Phenom, не спас положения. Во всяком случае, по тестам с любимого Хобота, топ-модели его проигрывают, подчас с разгромным счетом, не только «столькожеголовым» Core 2 Quad, но и далеко не самым старшим «двухголовникам» Core 2 Duo на последнем ядре Wolfdale.

Тесты Хобота выполнялись, разумеется, под управление Windows. И к тому же существенную часть их стандартного тестового набора составляют узкоспециализированные и профессиональные приложения из области 2D-графики и обработки изображений. Поэтому я и решил посмотреть, как ведут себя «равноголовые и равночастотные» процессоры от Intel и от AMD, во-первых, под управлением Linux’а, во-вторых, на обычных пользовательских задачах.

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

На первой диаграмме — сравнения AMD и Intel под 32-битным Zenwalk’ом, — можно видеть превосходство второй платформы, особенно значительное для тестов по «разтариванию» и компрессии с использованием bzip2.

test-ris2.3В количественном выражении это выглядит так (табл. 4):

Таблица 4. AMD vs Intel под 32-битной ОС

Intel/AMD
Zenwalk Slamd64
untar 0,67 1,70
tar+bzip2 0,67 0,62
tar+gzip 0,89 0,74
wav2flac 0,88 1,07

А вот под 64-битной системой всё не столь однозначно: Intel выигрывает на bzip2- и gzip-компрессии (причем для последней это единственный раз, когда разница видна невооруженным глазом) и проигрывает на «растаривании» и flac-кодировании. Причем для первой операции разница весьма значительна.

test-ris2.4К возможному объяснению причин этого мы еще вернемся в заключительной части. А сейчас спустимся с небес на землю, то есть от идеализированной обстановки tmpfs обратимся к суровой реальности.

Tmpfs vs Ext3fs

Пожалуй, системная память — то из компьютерных «железов», которое наиболее явно демонстрирует фантастический количественный прогресс при полном отсутствии прогресса качественного.

Действительно, 20 лет назад 640 Кбайт выглядело весьма внушительно: большинство PC XT стандартно поставлялись с 512 Кбайт. В эпоху PC AT стандартный объем памяти фактически удвоился — нормой стал 1 Мбайт. Однако практически это дало возможность увеличить используемое пространство ОЗУ до 700 Кбайт с очень маленькими копейками за счет включения линии A20, позволявшего загружать резидентные программы в неиспользуемую «дыру» около 900 Кбайт.

В эпоху «трёшек» самыми ходовыми объемами памяти стали 4 Мбайт для 386DX и 2 Мбайт — для 386SX. Причём последний вариант, изобретенный для удобства сборщиков, был совершенно бессмысленным: для DOS 2 Мбайт было много, для входящего в моду Windows 3.0, а потом 3.1 — откровенно мало.

Для «четвёрок» 8 Мбайт памяти стало нормой, унаследованной и первым Pentium’ами (еще на Socket 5). С переходом к Socket 7, примерно совпавшим с пришествием Windows 95, минимальные требования к памяти возросли до 16 Мбайт, а 32 Мбайт считалось достаточным для комфортной работы.

Некоторое время безудержный рост объемов памяти сдерживался относительно высокой её ценой: на момент появления Windows 2000, казавшейся весьма жадной в этом отношении, 512 Мбайт было показателем крутости (в том числе и финансовой).

Но затем произошел обвал цен, и сдерживающий барьер рухнул. Мегабайтный эквивалент 100 условных единиц в последнее время удваивался каждый год, и ныне на указанную сумму можно набрать планок памяти в 4 Гбайт — причём не от дядюшки Ляо из шанхайского опиумного притона, а от последнего производителя. И индикатором крутости теперь будут разве что 8 Гбайт — которые, правда, потребуют уже 64-разрядных операционок.

Качественного же выражения количественный рост памяти за собой не влёк — если оставаться в рамках настольно-пользовательских, а не промышленных задач. Программы под Windows 3.1 на 4 Мбайт памяти работали медленее, чем под DOS на 640 Кбайт, Windows 95 на Pentium II и 32 Мбайт едва могла равняться с Windows 3.1 на 486 машине с 8 Мбайт, и так далее.

В мире же Unix-подобных ОС ситуация с использованием памяти сложилась вообще парадоксальная. Сами по себе они способны исправно функционировать на смешных по нынешним меркам объемах ОЗУ в 8-16 Мбайт. Самые ресурсопожирающие программы консольного режима, такие, как Vim или Emacs, могут в некоторых случаях затребовать аж 32 Мбайт.

До недавнего времени главными потребителями памяти были оконная система X, менеджеры окон и особенно интегрированные среды GNOME и KDE. Однако любой из этих ансамблей более чем комфортно чувствовал себя на 512 Мбайт, которые для пущего спокойствия можно было нарастить до 1 Гбайт.

Возникает резонный вопрос — а куда девать «лишнюю» память, любезно предоставленнную нам производителями? На что уже давно был дан столь же резонный ответ: задействовать её под временную файловую систему в оперативной памяти, типа RAM-дисков или tmpfs (в Linux, во FreeBSD её эквивалентом выступает mfs).

Диски в оперативной памяти (RAM-диски) получили широкое распространение в ряде специфических сфер, например, для LiveCD, позволяя не только повысить быстродействие «живых» дистрибутивов, но и высвободить CD-привод для использования в мирных целях.

Для работы же с данными более подходящей выглядит tmpfs. Которая тоже нашла свою нишу — например, для помещения временных продуктов компиляции в Source Based системах, таких, как Gentoo Linux или FreeBSD. А вот при размещении на неё обычных пользовательских данных встаёт два вопроса:

  • а достаточен ли объем памяти, который можно без вреда для здоровья выделить под tmpfs, для таких задач, как сложная обработка растровых изображений в GIMP’е, и
  • какой выигрыш в производительности мы получим при использовании tmpfs вместо обычной block device based файловой системы?

Ответ на первый вопрос зависит от решаемых задач. При четырех гигабайтах памяти выкроить полгигабайта, а то и гигабайт под tmpfs промежуточные породукты компиляции при сборке ядра или приложений труда не составит. В то же время потребность в памяти при обработке растрового изображения в сотни мегабайт, с учетом «откатов», такова, что на неё никаких планок не напасёшься, тем более, что в «юзерские» (не серверные) материнские платы обычно больше 8 Гбайт не вставить, а 32-битные системы позволяют адресовать и того меньше — «всего» 4 Гбайт.

Ответом на второй вопрос станет рассмотрение побочных результатов тестирования, рассмотренного в предыдущих заметках. А именно — сравнение быстродействия операций в оперативной памяти и на реальной файловой системе. Результаты их можно было видеть в таблице 2, а в графической форме они представлены ниже на диаграммах.

Первая диаграмма показывает, что на платформе AMD под 32-битной ОС операция «растаривания» в tmpfs выполняется почти вдвое быстрее, чем на реальной файловой системе. В прочих тестах преимущество файловой системы в оперативной памяти также имеет место быть, но далеко не столь значительное.

test-ris2.5Под 64-битной ОС на той же платформе «растаривание» в tmpfs выполняется уже почти втрое быстрее, чем на реальной файловой системе, различия же в остальных тестах еще больше сглажживаются: хотя отставание в них ext2fs сохраняется, оно становится едва заметным.

test-ris2.6Переходя к платформе Intel, в 32-битном исполнении мы видим картину, качественно аналогичную предыдущей: трехкратное превосходство tmpfs над ext2fs в операции «растаривания» и небольшое в остальных тестах, кроме ogg-кодирования, где результаты операций в оперативной памяти и в «реале» просто идентичны.

test-ris2.7Наконец, под 64-битами Intel-платформа демонстрирует, напротив, более сглаженную картину: превосходство tmpfs в операции «растаривания» падает до 20 примерно процентов, в остальных тестах оно почти неуловимо, а в тесте на flac-кодирование ext3fs вообще чуть выходит вперед (впрочем, вероятно, в пределах погрешности эксперимента).

test-ris2.8Количественные соотношения быстродействия операций в оперативной памяти и на реальной файловой системе можно видеть в таблице.

Таблица 5

Процессор AMD Intel
Дистро Zenwalk Slamd64 Zenwalk Slamd64
untar 0,56 0,39 0,35 0,81
tar+bzip2 0,95 0,95 0,97 0,93
tar+gzip 0,90 1,00 0,89 0,78
wav2flac 0,97 0,98 0,96 1,03
wav2ogg 1,00 0,99

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

Обсуждение результатов

Какие же выводы можно сделать из всего вышеизложенного? Для начала рассмотрим результаты по каждому из тестов, основываясь на сводной диаграмме.

В тесте на «разтаривание» и декомпрессию обращает на себя внимание стабильное, иногда подавляющее, превосходство операций в tmpfs над таковыми в реальной файловой системе. Что, в принципе, не удивительно: развертывание архива связано с записью огромного числа очень маленьких файлов (вместе с их метаданными), и при выполнении этой процедуры на реальном дисковом «железе» затраты времени оказываются много более значительными, чем когда она осуществляется в оперативной памяти.

Скорее тут можно удивляться, что в единичном случае с 64-битной системой на платформе Intel первенство tmpfs выглядит не таким впечатляющим, как во всех остальных. Исходя из общих соображений, следовало бы ожидать прямо противоположной картины: так как под управлением 64-битного дистрибутива объем записываемых данных больше, чем под 32-мя битами, разница между «реалом» и «виртуалом» должна бы быть больше. Что мы и видим для платформы AMD.

С позиций соотношения производительности платформ ничего определённого сказать нельзя: хотя на tmpfs 32-битная Intel-система и демонстрирует абсолютный минимум, 64-битная система AMD отстаёт от ней лишь немного, а с переходом к «реалу» разница между платформами нивелируется.

Тест на bzip2-компрессию с параметрами по умолчанию создает в основном нагрузку на процессор, и потому с точки зрения производительности платформ кажется наиболее показательным. И здесь мы видим, что таки да, платформа Intel существенно производительнее AMD’шного собрата, как в «виртуале», так и в «реале» (впрочем, здесь разница между ними не очень велика). Столь же выпукло проступает превосходство прогрессивной 64-разрядности над ретроградной 32-разрядностью, причём для обеих платформ.

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

Кодирование звука в формат flac, представляющее собой простую компрессию zip-подобного вида, как и всякие прочие компрессии, считается преимущественно процессоро-емкой операцией, и мы вправе были бы ожидать здесь картины, подобной при bzip2-компрессии. Ан нет, ничего подобного. Если для AMD-машины первенствует 64-битная система, то на Intel — наоборот, 32-битная, показыващая абсолютно лучший в этом тесте результат и в «виртуале», и в реале». При этом разница между «виртуалом» и «реалом» опять же исчезающе мала, а в одном случае (64-битная Intel-платформа) инвертирована в пользу «реала». В целом 64-битная Intel-система практически равна по быстродействию 32-битной системе AMD, а 32 бита от Intel’а опережают 64 бита от AMD.

И, наконец, настоящее кодирование — wav в ogg, к сожалению проведенное только для Intel-платформы, показало отчетливое превосходство 64-битного компьютинга над 32-битным. Равно как и полное безразличие к среде выполнения — «виртуальной» или «реальной».

Осталось кратко сформулировать выводы по трем намеченным линиям противостояния:

  1. В антитезе 32 vs 64 явного лидера выявить не удается, по крайней мере, в настоящее время. В целом можно констатировать превосходство первой в тестах, в той или иной мере связанных с файловыми операциями, тогда как в тестах преимущественно процессорных показывает себя прогрессивность 64-битных вычислений. В перспективе можно ожидать, что превосходство последних будет нарастать: к сожалению, количественных данных привести не могу, но по качественным воспоминаниям два года назад разрыв в быстродействии файловых операций между 32- и 64-разрядными системами был ощутимо больше (разумеется, в пользу первых). Ну а такой сторонний фактор, как рост дисковых кэшей, со временем вообще его снивелирует.
  2. В вековом противостоянии Intel vs AMD на данном отрезке гонки первая явно вырывается вперед. Хотя на повседеневных пользовательских задачах это и не столь сильно проявлено, как в специализированных тестах, к которым прибегают на Хоботе. Что же касается перспективы, то уроки истории учат нас: вслед за провалом (а Phenomen’альные «многоголовники», если учитывать ожидания, следует считать чем-то близким к провалу) AMD постоянно выдвигает новую, рекордную, серию процессоров, на что Intel немедленно наносит ответный удар, и так будет ad finem seculorum (если, конечно, AMD на очередном витке неудач не накроется медным тазом, от чего Господь борони и её, и всех нас).
  3. Наконец, антитеза Tmpfs vs RealFS практически значима оказывается только на задачах с существенным объёмом не просто файловых операций, а операций с маленькими и очень маленькими файлами. Во всех прочих случаях разницей между операциями в «реале» и «виртуале» можно пренебречь, и дальше, в связи со всё тем же совершенствованием дискового «железа», эта разница будет всё больше сглаживаться.

Ну и последний, итоговый, вывод: при обычных пользовательских задачах нет большого резона ни выкидывать свои AMD’шки и бежать занимать очередь за Intel’ами, ни, тем более, стирать 32-битные дистры и ставит на их место 64-битные. Хотя в будущем, вероятно, последняя процедура и обретёт смысл — но к тому времени, я думаю, все дистрибутивы обзаведутся 64-разрядными версиями. Что же до отведения «излишков» памяти под tmpfs — оно не помешает (при той же компиляции, например), но ждать от него чудес в плане роста быстродействия также не следует.

Приложение

Результаты всех измерений быстродействия. Таблица приведена для оценки воспроизводимости средних значений

Процессор AMD64 X2 6000 Intel core 2 Duo 8400
Дистро Zenwalk Slamd64 Zenwalk Slamd64
FS tmpfs ext3 tmpfs ext3 tmpfs ext3 tmpfs ext3
untar
1 15 27 12 30 9 30 20 25
2 14 26 11 30 10 26 19 29
3 15 27 11 29 11 27 19 23
Среднее 15,0 27,0 11,5 29,5 10,0 28,5 19,5 24,0
tar+bzip2
1 52 55 43 46 35 36 27 27
2 53 55 43 44 35 37 28 27
3 53 55 44 46 35 36 27 31
Среднее 52,5 55,0 43,5 46,0 35,0 36,0 27,0 29,0
tar+gzip
1 9 10 11 10 8 9 7 10
2 9 10 12 10 9 9 7 8
3 9 10 8 9 8 9 7 8
Среднее 9,0 10,0 9,5 9,5 8,0 9,0 7,0 9,0
wav2flac
1 30 31 29 29 26 27 31 30
2 29 30 28 30 27 27 30 33
3 29 30 28 29 26 27 30 29
Среднее 29,5 30,5 28,5 29,0 26,0 27,0 30,5 29,5
wav2ogg
1 56 56 38 38
2 56 55 38 37
3 56 56 37 38
Среднее 56,0 56,0 37,5 38,0