Автор: Алексей Федорчук
В качестве объекта для бэкапливания и разбэкапливания было избрано всё то же дерево исходников ядра Linux’а всё той же версии. И по той же самой причине — на предмет сравнения, усугублённой банальной ленью искать использовавшиеся ранее архивы портов FreeBSD или портежей Gentoo. Ну а инструментом поначалу выступили tar+bz2.
Тут расписывать словами оказалось вообще нечего — цифирь и картинки скажут всё сами.
Собственно, всё становится мучительно ясно, уже глядя на загрузку процессоров при «растаривании» командой
$ tar xjf linux-2.6.33.1.tar.bz2
и «затаривании» посредством
$ tar cjf linux.tar.bz linux-2.6.33.1
Из иллюстрации к первой
и ко второй
видно, что оба действия, особенно второе, распараллеливаются из рук вон скверно. И потому результаты в первых двух столбцах таблицы
Команда | Core 2 Duo | Phenom II X6, def | Phenom II X6, turbo |
tar xjf, s | 14 | 12 | 13 |
tar cjf, s | 50 | 48 | 49 |
и на диаграммах, иллюстрирующих первую
и вторую команды
нас удивить не могут ничем.
Но возможно, что это тот самый случай, когда заиграет опция раздельного разгона тактовой частоты? Включаем в BIOS соответствующую опцию, смотрим на третью колонку той же таблицы и тянемся к инструменту, именуемому закаткой (губы закатывать): ничего не меняется настолько, что даже лень строить ещё один график.
Но у нас остаётся ход конём по голове: использование tar-архивации вместе с lzma-компрессией. Ведь, согласно данным с Хобота, выньдовый архиватор 7-Zip, основанный на том же самом алгоритме, некоторое распараллеливание обеспечивает. В нашем случае — ничего подобного: и при растаривании в сочетании с lzma-сжатием
и при затаривании с её же помощью
основная нагрузка падает на один и тот же процессор. Причём, вопреки
Правда, при растаривании мы видим совершенно замечательный результат — около 5 секунд на распаковку архива дерева исходников ядра, но сравнить нам его не с чем: в своё время соответствующие измерения на C2D я не сделал, а сейчас уже и не смогу за его отсутствием.
В общем, пока наше ЧСВ греется только о вытяжной вентилятор при компиляции ядра. Что будет дальше — посмотрим. Ибо до самого интересного — запуска многих и многих виртуальных машин — лежат вёрсты и недели.
помнится Calculate linux какраз-таки сменили lzma на 7-zip (он ведь не только для windows есть), потому как последний лучше работает на многопроцессорных системах. Это упоминается в их рассылке (последний пост в http://groups.google.com/group/calculatelinux/browse_thread/thread/d400f1b8f308c1ed)
2 lgb Тут, видимо, дело ещё в том, что традиционный юниксовый метод — сначала затаривание в один архив, потом его компрессия — в принципе распараллеливанию не поддаётся: действительно, чего там распараллеливать при сжатии одного архивного файла?
Это я потом уже смекнул, как тот смекалистый рядовой Петров, рядом с которым упала граната :)
А 7-zip, насколько я помню, компрессирует пофайлово, что выньдовый, что линуксовый. И тут раскидать процессы по ядрам — сам шайтан велел.
Но когда я с ним имел дело — это как только он линуксовый появился — он не сохранял атрибутов принадлежности и доступа. Сейчас это изжито?
Вот бы этого монстра задействовать в проекте распределённых вычислений на платформе BOINC http://ru.wikipedia.org/wiki/BOINC
На мня вот нахлынуло старое увлечение астрономией/космологией и я подключился к проекту Cosmology@home (Иллинойский универ) http://ru.wikipedia.org/wiki/Cosmology@home
Но есть и много других.
В Убунте с этим проблем не возникло, фактически два пакета поставить, сделать настройки (очень протой и понятный интерфейс) и вперёд. Для Федоры наверняка также просто. При том что у меня старенький Pentium Core Duo 2,1Гц + Nvidia GeForce 8400GS (CUDA тоже задействуеться), то обработка заданий идет не плохо (быстрее «средне-статистического» времени). На быстродействие компа влияния практически нет, никак не отражаеться, тут правда может зависеть от того как настройки задать.
Проектов разных много, помоему и по геологии что-то есть, если интересно то присоединяйтесь! :)
А таки распараллеливание не должен делать проц. Этим должен заниматься разработчик софта.
А по поводу отставания… На камешках intel кэша больше (=
А вот с виртуалками можете поэкспериментировать. KVM, конечно же… Тут, когда я сравниваю AMD и Intel, начинаю жалеть о том, что, на момент покупки новых серверов, найти чипы компании из Саннивейла с поддержкой DDR3 не удалось. Иначе, я эти Xeon 5500 ни за что не взял бы.
ЗЫ: странное тестирование. Вы меряете скорость с запущенным гуём? А он не вносит своих флюктуаций в результаты? А у вас одинаковое количество запущенных свистелок гномовских было? Точно не было разницы в окружении? Версии софта те же?
ЗЫ2: Core2 Duo… Мммм, он ведь на DDR2 был? Как бы скорость доступа и адресации у него больше, чем у DDR3, если частота одна и та же.
2 Zerg
Я меряю в своей реальной рабочей среде. Вы же прекрасно понимаете, что на пользовательской машине уже много лет как не играет рояля — сколько там DDR и так далее. На скорость лабания пользователя по клавишам это не влияет, на скорость работы его думателя — тем более.
Стоп, то есть это не тест реальной производительности двух железок на предмет выявления разности в скорости работы, а лишь просто мерилка «для галочки и без смысла»?
Это мерилка того, насколько среднестатистический пользователь вроде меня получает выигрышь от новой железки при своей реальной работе.
Тогда Вам действительно стоит замерить скорость работы с виртуальными машинами. Я считаю, например, это лучшей стороной AMD. А если Вам повезёт, и у вас на мат. плате логика будет поддерживать IOMMU для проброса устройств внутрь виртуалки — то, можно считать, я Вам уже слегка завидую. У меня счастья не случилось…
ЗЫ: ещё разок, я рассматриваю только KVM, ибо нативно…
Да, я тоже только KVM и держу в уме — опыт от общения с VirtualBox’ом последних версий сугубо отрицательный