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

Условия

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

• 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'ом...