Все против всех.
64 vs 32, Intel vs AMD, tmpfs vs ext3

Алексей Федорчук

2008-07-20

назад | к началу | вперед

64 vs 32

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

В разное время на обеих этих машинах побывали CDUX, 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
Сводные результаты измерений по всем четырем комбинациям процессор - дистрибутив, сек.)

Примечания:
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-битных систем

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

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

назад | к началу | вперед