Алексей Федорчук
20 июля 2008 г
В этих заметках будут описаны три линии противостояния программно-аппаратных комбинаций, казалось бы, совершенно независимые друг от друга, но по сути своей тесно взаимосвязанные.
Содержание
- Введение с поросячьим подтекстом
- Участники тестирования
- Условия тестирования
- 64 vs 32
- AMD vs Intel
- Tmpfs vs Ext3fs
- Обсуждение результатов
- Приложение
Введение с поросячьим подтекстом
От автора: слабонервным рекомендуется введение пропустить.
История начинается с того, что у широких масс прогрессивных трудящихся всего мира появилась настоятельная потребность в 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, включавшие:
- создание каталога /tmp/test и переход в него;
- копирование архива и wav-файлов из места их постоянного хранения в /tmp/test;
- развертывание и декомпрессия архива tar.bz2;
- архивирование и компрессия посредством tar+bzip2;
- архивирование и компрессия посредством tar+gzip;
- кодирование wav-файлов командой flac;
для пунктов 3-6 время начала и окончания действия, замеряемое командой date до и после операции, перенаправлялось в результирующий файл командойcat ... >> ... - удаление всех промежуточных продуктов тестирования командой 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.
Из таблицы 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.
В количественном выражении это выглядит так (табл. 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-кодировании. Причем для первой операции разница весьма значительна.
К возможному объяснению причин этого мы еще вернемся в заключительной части. А сейчас спустимся с небес на землю, то есть от идеализированной обстановки 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 выполняется почти вдвое быстрее, чем на реальной файловой системе. В прочих тестах преимущество файловой системы в оперативной памяти также имеет место быть, но далеко не столь значительное.
Под 64-битной ОС на той же платформе «растаривание» в tmpfs выполняется уже почти втрое быстрее, чем на реальной файловой системе, различия же в остальных тестах еще больше сглажживаются: хотя отставание в них ext2fs сохраняется, оно становится едва заметным.
Переходя к платформе Intel, в 32-битном исполнении мы видим картину, качественно аналогичную предыдущей: трехкратное превосходство tmpfs над ext2fs в операции «растаривания» и небольшое в остальных тестах, кроме ogg-кодирования, где результаты операций в оперативной памяти и в «реале» просто идентичны.
Наконец, под 64-битами Intel-платформа демонстрирует, напротив, более сглаженную картину: превосходство tmpfs в операции «растаривания» падает до 20 примерно процентов, в остальных тестах оно почти неуловимо, а в тесте на flac-кодирование ext3fs вообще чуть выходит вперед (впрочем, вероятно, в пределах погрешности эксперимента).
Количественные соотношения быстродействия операций в оперативной памяти и на реальной файловой системе можно видеть в таблице.
Таблица 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-битным. Равно как и полное безразличие к среде выполнения — «виртуальной» или «реальной».
Осталось кратко сформулировать выводы по трем намеченным линиям противостояния:
- В антитезе 32 vs 64 явного лидера выявить не удается, по крайней мере, в настоящее время. В целом можно констатировать превосходство первой в тестах, в той или иной мере связанных с файловыми операциями, тогда как в тестах преимущественно процессорных показывает себя прогрессивность 64-битных вычислений. В перспективе можно ожидать, что превосходство последних будет нарастать: к сожалению, количественных данных привести не могу, но по качественным воспоминаниям два года назад разрыв в быстродействии файловых операций между 32- и 64-разрядными системами был ощутимо больше (разумеется, в пользу первых). Ну а такой сторонний фактор, как рост дисковых кэшей, со временем вообще его снивелирует.
- В вековом противостоянии Intel vs AMD на данном отрезке гонки первая явно вырывается вперед. Хотя на повседеневных пользовательских задачах это и не столь сильно проявлено, как в специализированных тестах, к которым прибегают на Хоботе. Что же касается перспективы, то уроки истории учат нас: вслед за провалом (а Phenomen’альные «многоголовники», если учитывать ожидания, следует считать чем-то близким к провалу) AMD постоянно выдвигает новую, рекордную, серию процессоров, на что Intel немедленно наносит ответный удар, и так будет ad finem seculorum (если, конечно, AMD на очередном витке неудач не накроется медным тазом, от чего Господь борони и её, и всех нас).
- Наконец, антитеза 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 |