архив
Все против всех.
64 vs 32, Intel vs AMD, tmpfs vs ext3
2008-07-20
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 |
А вот теперь пора перейти к обещанному обсуждению результатов.