CITKIT.ru - свободные мысли о свободном софте
Деловая газета CitCity.ru Библиотека CITForum.ru Форумы Курилка
Каталог софта Движение Open Source Дискуссионный клуб Дистрибутивы Окружение Приложения Заметки Разное
19.09.2019

Последние комментарии

ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)
24 December, 22:53
Kubuntu Feisty (15)
24 December, 18:42
Один на один с Windows XP (3758)
24 December, 11:46

Каталог софта

Статьи

Дискуссионный клуб
Linux в школе
Open Source и деньги
Open Source и жизнь
Windows vs Linux
Копирайт
Кто такие анонимусы
Лицензии
Нетбуки
Нужен ли русский Linux?
Пользователи
Дистрибутивы
Идеология
Выбор дистрибутива
Archlinux & CRUX
Debian
Fedora
Gentoo
LFS
LiveCD
Mandriva
OpenSolaris
Slackware
Zenwalk
Другие линуксы
BSD
MINIX
Движение Open Source
История
Классика жанра
Окружение
shell
Библиотеки UI
Графические среды
Шрифты
Приложения
Безопасность
Управление пакетами
Разное
Linuxformat. Колонки Алексея Федорчука
Заметки
Блогометки
Файловые системы
Заметки о ядре

Заметки

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

CITKIT.ru

Страницы: 1 :: 2 :: 3 :: ... :: 6 :: следующая

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

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

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

История начинается с того, что у широких масс прогрессивных трудящихся всего мира появилась настоятельная потребность в 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/Linux

Zenwalk 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/Linux

Zenwalk 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

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

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

Для тестирования мной были применены программы и данные, используемые уже несколько лет, начиная с первых моих экспериментов в этой области (см. http://posix.ru/system/, раздел Тесты). Правда, с некоторыми коррективами, не меняющими качественной картины, но не дающей возможности прямого количественного сравнения с ранее проыеденными измерениями.

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

  • разворачивание архива дерева портежей 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

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

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

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

после чего обсудим результаты.



Страницы: 1 :: 2 :: 3 :: ... :: 6 :: следующая

Комментарии

Страницы комментариев: предыдущая :: 1 :: 2 :: 3 :: 4 :: 5 :: 6 :: следующая

аноним, Wed Sep 17 14:51:24 2008:
По поводу разорения DEC и DEC Alpha AXP 21x64 в качестве причины этого: никогда так не смеялся. Я в своё время работал сервис-инженером именно на самой DEC и занимался серверами на Alpha AXP. И те "факты" что указал Юра - это бред сивой кобылы. Уже при появлении Alpha был создан компилятор DEC FX32 позволявший использовать приложения для Win32 i386 на ALPHA. Он обеспечивал производительность в режиме эмуляции i486 равную 98% от полной за счёт подгрузки PAL-кодов - микропрограммной реализации "не родной" системы команд. Далее, список приложений для Alpha на ноябрь 1994 года описанное в документе "Alpha AXP Applications Catalog" это 529 страниц не считая приложений A - D. Формат книги A4. Так что, приложения тут Юра не при чём. Я понимаю, Wiki великий источник, но у меня на столе лежит документ отпечатанный в 1994 году. Слухи против документов?:)

Далее, по поводу покупки нас COMPAQ - я не буду утверждать точно, но наше руководство в начале 1995 года объявило приказ из штаб квартиры корпорации - "В связи с объединением корпораций DEC и COMPAQ произвести сокращение численности сотрудников сервис-центров. Оставить на работе только тех специалистов которые проработали в корпорации не менее 10 лет при условии свободного владения английским, французским и немецким языками. Свободным владение считать умение объясняться, читать, переводить (на уровне синхронного перевода). Причина увольнения сотрудников - слияние корпораций с целью расширения бизнеса." - это выписка из приказа об увольнении который нам тогда зачитали.

Далее, по поводу ОЗУ - ЕСС память (с коррекцией ошибок) работает на 10% - 15% медленнее чем обычная память на равной частоте и при равных временных диаграммах.

Далее, по поводу процессоров - а Вы найдёте для серверного процессора задачи, системную плату, блок питания форм-фактора WTX? эти платы требуют специальных блоков питания, с бытовым ширпотребом они просто не запускаются.
RAVEN, Mon Aug 11 12:42:55 2008:
где распаковщики?
аноним, Tue Aug 5 23:57:03 2008:
М. б. здесь есть понимающие в железе.

ECC по звашему мнению заметно замедляет память или нет?
аноним, Sun Aug 3 14:58:24 2008:
аноним, четверг, 31 июля 2008 г. 12:14:37:
Задумался об идее поставить в домашний комп 2 Зеона.
А что думают форумчане по поводу такой идеи?

Ксеноны были бы по круче. Еще лучше - биксеноны.
аноним, Sun Aug 3 01:39:18 2008:
Алексей Федорчук неточно указал на обьем доступной памяти в 32бит .Ограничение в 4 гига для 32 бит - это не аппаратные ограничения х86 забыл наверно про про PSE 36 и РАЕ .Теоретическое ограничения РАЕ 64 гб (В NUMA системах до 128 гб ) .
аноним, Thu Jul 31 12:14:37 2008:
Задумался об идее поставить в домашний комп 2 Зеона.
А что думают форумчане по поводу такой идеи?
аноним, Wed Jul 30 16:11:25 2008:
Вот сейчас в раздумии, что взять: двуядерник 2х 3.1 ГГц или четырёхядерник 4х 2.8 ГГц.

А что пипл думает - есть ли заметное преимущество от четырёх ядер??

Эх, жалко нет мамок с двумя сокетами 775.
Доброжелатель, Tue Jul 29 17:43:34 2008:
_

2 Юра, вторник, 29 июля 2008 г. 12:00:53:

// Первым 64-битным процессорами были DEC Alpha. Кстати, в том числе из-за его 64хбитности DEC и разорился. А в AMD не стали изобретать ничего нового, а наняли специалистов из бывшего DEC, которые и создавали AMD64.
-----

А вот и нет, DEC Alpha не были первыми (http://en.wikipedia.org/wiki/64-bit#64-bit_processor_timeline).

По поводу нанятых AMD специалистов DEC, то это внутренние дела AMD, о которых мы можем судить всё-таки из прессы, а не из первых рук (или Вы работаете в AMD?). Помимо прочего, эти отношения включали лицензирование у DEC шины EV6 для архитектуры K7 (то есть раньше, чем был создан К8). О таком сотрудничестве известно. Известно, что работать в AMD пошёл Дирк Мейер (http://en.wikipedia.org/wiki/Dirk_Meyer), но это было до того, как Compaq купила DEC. А что AMD наняла ряд специалистов из DEC — поделитесь, пожалуйста, источником.

О причинах разорения DEC у Вас тоже интересная версия. Почитайте, впрочем, вот здесь: http://www.alasir.com/articles/alpha_history/index_rus.html


// Хотелось бы, чтобы софт под Linux был более оптимизированным под новые процессоры и 64хбитную архитектуру, но такое, увы, пока невозможно как раз из-за таких версусов.


Интересные, однако, заявления про «более оптимизированный» линукс. Послушайте, а Вы попробовали поработать с каким-то из дистрибутивов для 64-битных архитектур (это не только х68-64, между прочим)? Кстати, можно попробовать и не линукс, а, например, NetBSD.

_
Юра, Tue Jul 29 12:00:53 2008:
Первым 64-битным процессорами были DEC Alpha. Кстати, в том числе из-за его 64хбитности DEC и разорился. А в AMD не стали изобретать ничего нового, а наняли специалистов из бывшего DEC, которые и создавали AMD64.
Хотелось бы, чтобы софт под Linux был более оптимизированным под новые процессоры и 64хбитную архитектуру, но такое, увы, пока невозможно как раз из-за таких версусов.
Lindemidux, Sun Jul 27 03:05:06 2008:
2 Vitaliy, воскресенье, 27 июля 2008 г. 00:50:00:

А я попугаеметрию не ругаю, но только в попугаи упираться нельзя никак. Просто еще один тест.

Страницы комментариев: предыдущая :: 1 :: 2 :: 3 :: 4 :: 5 :: 6 :: следующая

Комментарии заморожены.

Новости:

Все новости на CitCity.ru

Компании месяца

 
Последние комментарии
Почему школам следует использовать только свободные программы (101)
20 Декабрь, 14:51
ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)

24 Декабрь, 22:53
Linux в школе: мифы про школу и информатику (334)
24 Декабрь, 22:43
Kubuntu Feisty (15)
24 Декабрь, 18:42
Software is like sex: it's better when it's free.
©Linus Torvalds