Все о Linux. LinuxRSP.Ru


Cвежие новости Linux и BSD, анонсы статей и книг прямо в почтовый ящик!
Подписаться письмом


 Сегодняшние новости:

25 лет исполнилось ядру Linux

Релиз KDevelop 5.0

Oracle открывает код JDK9 для ARM

Выпущен Timewarrior 1.0.0

Релиз Android 7.0

Percona Memory Engine для MongoDB на базе WiredTiger

PowerShell открыт и доступен для Linux

Форк TrueCrypt: VeraCrypt 1.18

Релиз Snapcraft 2.14

Релиз Go 1.7

Стабильный выпуск рабочего стола Lumina

Вышла первая версия аналога OpenCV - DCV 0.1

Выпуск минималистичной программы для мониторинга jsonmon 3

В MIT разработали новый язык программирования

Первый релиз Qt5Gtk2

Godot 2.1 - новая версия открытого игрового движка

Свободная цифровая станция звукозаписи: Ardour 5.0

Обновление SkypeWeb Plugin for Pidgin

Вышла версия 3.0 Android File Transfer для Linux (и для OS X)

Программный аналог MIDI-контроллера для создания музыки: Launchpadd v1.3

Mozilla спонсирует поддержку Python 3.5 в PyPy

Ef 0.08 - программа для моделирования динамики заряженных частиц

Обновление текстового редактора TEA до версии 42.0.0

Релиз OpenOrienteering Mapper 0.6.4

Вышли Guix и GuixSD 0.11

Релиз Opera 39

Выпуск LibreOffice 5.2

В OpenSSH обнаружены и устранены некоторые уязвимости

Эмулятор FCEUX 2.2.3

Компания Билайн переходит на российскую СУБД с открытым исходным кодом Tarantool

Google

 Новые статьи :

Утилиты для восстановления потерянных данных в Linux

Лучшие файловые менеджеры для Android

20 лучших бесплатных книг о Linux

Как сгенерировать открытый/закрытый SSH-ключ в Linux

Grive - клиент Google Drive для Linux с открытым исходным кодом

Протокол IPv6: варианты подключения

Сервер из образа: DHCP + TFTP + Initrd + OpenVZ

Обзор веб-панелей управления хостингом

Приёмы работы с Vim

Nginx как Reverse Proxy для сайта, использующего SSL

Разработка модулей ядра Linux

Мониторинг нагрузки http-сервера Apache 2

Перевод комментариев к файлу конфигурации Squid

Решение проблем при использовании "1c предприятие" 8.2 в Linux

Advanced Bash-Scripting Guide Искусство программирования на языке сценариев командной оболочки







Rambler's Top100





 
 

Еще раз об Abit6SE
и ее разгоне

Изложенное в предыдущей заметке не давало мне покоя. Уж больно странные получились результаты. И на досуге я решил повторить свои измерения в несколько подкорректированном виде.

Условия

Для этого на диске создаются разделы:

  • primary partirion в 2,5 Гбайт под ext2fs;
  • swap-раздел размером 128 Мбайт;
  • два extended-раздела (под ext2fs) - /usr/local и /home, 1 и 11 Гбайт, соответственно.

Устанавливается Linux Mandrake 7.0/RE, содержащая ядро 2.2.14, glibc 2.1.2, XFree86 3.3.6. SVGA-сервер - из комплекта, хотя есть и сервер NVIDIA, специально предназначенный для видеокарт на чипе TNT (2). В XWindow устанавливается разрешение 1024*768 при 16-битной глубине цвета.

Затем изготаливается несколько тестов. В первую голову это серия глубоко вложенных подкаталогов, содержащих небольшие файлы (HTML, GIF, JPEG, PNG, DjVu); которые посредством скрипта в консольном режиме копируются с места на место. Как уже говорилось, это в первую очередь нагрузка не на диск, а на процессор (включая кэш и системную память).

Далее, изготовляется геологическая карта размером 2560*1586 и экпортируется в некомпрессированный TIFF. Что дает файл размером 11,6 Мбайт. Этот файл в GIMP'е (под WindowMaker'ом)

  • поворачивается на фиксированный (90 градусов) угол;
  • вращается на произвольный (для определенности и единообразия - 52 градуса) угол;
  • подвергается гауссовому размытию с радиусом 10 пикселей.

В чем физический смысл этих, в общем достаточно элементарных, манипуляций? В первую очередь это пересчет пикселей, скорость которого определяется быстродействием процессорной (в широком смысле слова, включая кэш и системную память) подсистемы. При повороте на произвольный угол (и, в меньшей степени, при размытии) на это накладывается еще и быстродействие видеоподсистемы - изрядную долю времени занимает просто перерисовка экрана. Но при одной и той же видеокарте определяющей является процессорная составляющая. А размер файла подобран (методом ползучего эмпиризма) таким образом, чтобы обеспечить достаточную длительность процесса. И при этом свести к минимуму влияние дисковой подсистемы (при данном объеме оперативной памяти индикатор жесткого диска активности не проявляет).

Я не настаиваю на строго количественном характере своих тестов. Но уверен, что качественную оценку чистого быстродействия конкретного железа в реальной работе они дают.

К сожалению, пришлось отказаться от использования в качестве тестовой системы StarOffice (к сожалению - потому что это мог бы быть инструмент межплатформенного сравнения, ведь он существует и под Linux, и под Windows, и под Solaris обоего рода). Дело в том, что измерения посредством его оказались практически невомпроизводимы: скорость загрузки его самого, открытия любого документа или манипулции с последним, как оказалось, могут различаться буквально на порядки - в зависимости от того, обращаетесь ли вы к этому файлу и оперции впервые за сеанс (Linux'а. не XWindow!) или повторно. Вероятно, опять же вследствие кэширования. Для чистоты экспреимента это потребовало бы полной перезагрузки системы после каждого действия. А согласитесь, перезагружать Linux по несколько десятков раз на дню - занятие не из самых веселых и здоровых...

Результаты

Мне не известны результаты тестирования аналогичных (или хотя бы близких) конфигураций под Linux'ом. Поэтому никаких внешних объектов для сравнения у меня нет. Остается прибегнуть к сранению за счет внутренних ресурсов. То есть - к разгону.

Для начала были опробованы установки по умолчанию - FSB 133 Mhz, шина памяти 100 Mhz, внутренняя частота процессора 733 Mhz. Значания производительности (в секундах) при этих параметрах сравнивались с нормальными рабочими установками - то же, плюс шина памяти на 133 Mhz. Результаты оказались весьма неожиданными (таблицы 1 и 2).

Таблица 1. Абсолютная производительность, с
Configuration Copy files Rotation for 90 Free rotation Gaussian Blur
704-128-133 6.97 8.53 28.13 19.72
715-130-133 6.53 8.50 27.07 19.68
733-133-100 7.19 9.78 27.94 19.81
733-133-133 5.69 8.29 24.71 18.37
754-137-100 4.60 8.81 27.32 19.19
754-137-133 Не загрузилось ядро
770-140-100 4.34 9.19 27.63 19.05
770-140-133 Машина не запустилась
800-145-100 6.58 9.28 26.40 18.50
825-150-100 6.59 8.50 26.63 17.97
842-153-100 6.97 9.72 25.81 17.88

Таблица 2. Производительность относительно P-733/133/133, %%
Configuration Copy files Rotation for 90 Free rotation Gaussian Blur
704-128-133 122 103 114 107
715-130-133 115 103 110 107
733-133-100 126 118 113 108
733-133-133 100 100 100 100
754-137-100 81 106 111 104
770-140-100 76 111 112 104
800-145-100 116 112 107 101
825-150-100 116 103 108 98
842-153-100 122 117 104 97

Примечание к табл. 1 и 2: меньшие значения, естественно, соответствуют лучшему результату.

Как можно видеть из таблиц, увеличение чистого быстродействия памяти на 1/3 дает прирост производительности от 8 до 26%. При этом он максимален для теста копирования файлов, где быстродействие подсистемы процессор-кэш-системная память не осложняется влиянием графического режима. Для тестов GIMP различия сглаживаются, как уже говорилось, за счет нивелирующего влияния видеподжсистемы (рис. 1).

Рис. 1. Сравнительное быстродействие при различных установках частоты системной шины и памяти

Идея дальнейшего исследования состояла в плавном изменении частоты системной шины (с минимально возможным шагом, 3-5 Mhz) и соответственно, внутренней частоты процессора при обоих возможных значениях шины памяти. К сожалению, осуществить ее не удалось. Уже при частоте FSB 137 Mhz установка частоты памяти 133 Mhz вызвала сообщение о невозможности загрузить ядро Linux. А при частотах FSB и памяти 140 и 133 Mhz, соответсвенно, система отказалась шрузиться вообще.

Тем не менее, при частоте шины памяти 100 Mhz удалось достигнуть максимально возможной частоты FSB - 153 Mhz. Однако радости это принесло мало.

Так, скорость копирования файлов плавно возрастала до внутренней частоты 770 Mhz (до 25%, см. табл.2). А затем упала на 16% при частоте 800 Mhz и на 22% - при максимально возможной частоте 842 Mhz.

В тестах вращения (как на фиксированный, так и на произвольный угол) ни при какой частоте FSB понижение частоты шины памяти давало снижение быстродействия на 5-10%, не зависимо от частоты FSB. И только гауссианово размытие еле заметно ускорилось при частотах FSB 150-153 Mhz.

Повторяю, я далек от того, чтобы абсолютизировать полученные цифры. Однако, на мой взгляд, тенденцию (графически представленную на рис. 2) они безусловно отражают. А именно: снижение частоты шины памяти (и, соответсвенно, ее абсолютного быстродействия) приводит к ощутимому снижению быстродействия на реальных приложениях Linux. Которое не только не компенсируется увеличением частоты FSB и внутренней частоты процессора, но в ряде случаев даже усугубляется ими.

Рис. 2. Зависимость быстродействия от частоты системной шины и памяти для различных задач

Для пущей проверки этой тнеденции я решил прибегнуть, если так можно выразиться, к ловерклокингу. То есть, сохранив частоту шины памяти 133 Mhz, стал плавно понижать частоту FSB - сначала до 130 Mhz, затем - до 128. К сожалению, при более низких частотах FSB частота памяти автоматически устанавливается на 100 Mhz - проверить вариант с FSB на 100 Mhz и памятью на 133 не удается (по крайней мере, на этой маме).

Результаты подтвердили мои предположения: даже в сочетании 704-128-133 быстродействие системы (хотя и несколько падало относительно варианта 733-133-133) оставалось чуть выше, чем при установках 733-133-100. А иногда оказывалось выше, чем при нештатных повышенных частотах. Опят-таки, в абсолютных значениях разница не велика, но тенденция - налицо.

Выводы

В чем причина этого явления? Рискну высказать предположение.

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

Это особенно выражено для консольных задач, определяемых исключительно взаимоджействием процессор-кэш-память. В графическом режиме закономерность выражена несколько меньше. Так как в этом случае параллельно с частотой FSB растет и частота шины AGP, несколько увеличивая вывод графики (если, разумеется. выдерживает видеокарта).

Хочу подчеркнуть, что цифровые результаты тестов полностью согласуются с субъективными оценками быстродействия при реальной работе. Так, торможение консольных приложений при переходе к предельным частотам FSB (150-153 Mhz) ощущаешь просто физически. Так же как и замедление программ графического режима, едва только переключаешь частоту шины памяти на 100 Mhz. Собственно, именно эти субъективные ощущения и подвигли меня на проведение квазиколичественных оценок...

Каковы практические следствия проведенного исследования? Их несколько. По крайней мере, при работе в Linux - на Windows я свои выводы распространить бы не рискнул.

Во-первых, с точки зрения цена/производительность сочетание относительно дешевого процессора со 100-мегагерцной шиной (речь идет только о продукции Intel) и памяти PC-133 может дать больший эффект, чем более дорогого 133-мегагерцного процессора и памяти PC-100. разумеется, если чипсет допускает асинхронную работу памяти.

Во-вторых, это ставит в заведомо невыгодное положение чипсет i815 - в нем первое сочетание, разумеется. возможно, но уж больно велик числитель дроби из предыдущего абзаца. Тогда как применение новых чипсетов VIA способно снизить этот числитель до предела (разница в цене мам на VIA и i815 - практически двухкратная, сами знаете, в чью пользу).

В третьх, можно поставить под сомнение целесообразность разгона. Не сочтите меня беспринципным ренегатом. Ведь всегда ратовал за разгон, а тут... Так вот, хоть и мысль изреченная банальна, изрекаю:

На современном этапе процессорострительства разгон (если не играть в Quacke, конечно) никакого практического смысла не имеет. Тем более - под Linux, и еще тем болей - если выполняется некая практическая работа. Прирост производительности - сомнителен (а иногда - урост просто несомненен). Последствия же могут быть печальными. Ведь это в Windows при мертвом висе нажал Reset - и после принудительного лечения (ScanDisk'ом, то есть) все более-менее приходит в норму... В Linux же это грозит разрушением файловой системы и прочими приятными развлечениями. Одно утешает - как показал мой (пока ограниченный) опыт, Linux - не дурак, если что не так, он просто не загрузится...

Рассуждая теоретически, можно предположить: максимальный выигрыш от разгона можно получить на старом добром BX-чипсете. На тех его мамах, которые (полу-) штатно поддерживают 133 Mhz на FSB. Ведь здесь пропорционально скорости последней, будет возрастать и быстродействие памяти. Если послденяя сдюжит, конечно...

Правда, предварительные результаты, отраженные в моей предыдущей заметке на эту тему, этого, как будто, не подтверждают: P-733 на i815 дал просто научно-фантастический выигрышь по сравнению с P-533 на разогнанном BX. Однако: ведь речь шла о сравнении процессоров двух разных архитектур (C-Mine и Kaymai, соответственно). Так что, возможно, основной вклад в этот прирост был обусловлен не двустами лишними мегагерцами процессора, а трехкратным ускорением кэша второго уровня? В свете влияния подсистемы памяти на суммарное быстродействие под Linux, такой вывод представляется вполне обоснованным.

В этой связи было бы интересно исследовать T-Bird с его сумасшедшим кэшем первого уровня, большим его суммарным эффективным объемом и быстродействием кэша L2. Теоретически рассуждая, это может быть самая эффективная система для использования под Linux'ом...

В начало
К содержанию
На главную страницу

Связь | О проекте LinuxRSP | Реклама | О Linux
© 1999-2017 LinuxRSP