Результаты тестирования SMP систем / Материнские платы

В этой короткой заметке, мы попытаемся ответить на вопрос о практической пользе SMP-систем. На данный момент не существует общепринятых тестов для SMP-систем, поэтому авторы использовали легко реализуемые ситуации в качестве тестов. В качестве тестовой машины использовалась следующая система: материнская плата Abit BP6 440BX Revision 1.01, два Celeron-366 на частоте 456MHz, Hyundai 128Mb PC-100, видеокарта Asus3400TNT/TV/16M c Detonator 3.66, диск IBM-DJNA-352030 Janus UDMA66, ОС W2k Pro build 2195 version 1.

Начнем с установки. W2k стоял на машине с P3-500 и описаным железом. Мы извлекли старую материнку и на ее место поставили Abit BP6 с двумя Селеронами. Так как на Abit BP6 распаян HighPoint HPT366 UDMA66 контроллер, то к нему мы подключили наш винчестер. В BIOS выставили Boot sequence в "EXT, С, А», а External Means - "UDMA66". Загрузка W2k остановилась на половине, появился BSOD. Надежды на то, что W2k правильно распознает HPT366 и запустит свой драйвер не оправдались, поэтому мы решили подключить винт к IDE порту. На этот раз W2k загрузилась без проблем, при этом ею были найдены два "Mass Storage Device" (по одному на каждый канал), которые и оказались HPT366 Ultra DMA 66 Controller. На обоих контроллерах, впрочем, красовались желтые восклицательные знаки, свидетельствующие о том, что драйвера для них не установлены. Решение этой проблемы было найдено на сайте www.abit.com.tw, в виде новых драйверов. Кстати, нас приятно удивил их размер - всего 40 килобайт. Но, несмотря на столь скромные габариты, они оказались на высоте, и после их установки контроллер заработал нормально. Мы опять поставили винт на UDMA66, и все заработало как надо: W2k загрузилась без каких-либо проблем. Ядро W2k осталось прежним "Standard PC", оно способно использовать только один процессор. Поэтому, теперь пришло время для замены обычного ядра на "MPS Multiprocessor". В NT 4.0 для решения этой проблемы пришлось бы либо переинсталировать всю систему, либо воспользоваться утилиткой "UPTOMP.EXE" из "Resource Kit". В W2k замена ядра упрощена до предела - ядро системы можно поменять в "Device Мanger", так же как и любой другой драйвер. Заняла эта операция около минуты, и прошла без малейших проблем.

Единственной проблемой, которую мы обнаружили на Abit BP6 - это пропажа поддержки APM, теперь выключать компьютер приходится выключателем на корпусе. Рассудив, что здесь может помочь обновление BIOS, мы скачали новую версию прошивки. Записали все необходимое на бутовый флоппик и попробовали загрузится с него. Здесь нас ожидал очередной неприятный сюрприз, несмотря на все наши усилия, машина никак не желала грузиться с дискеты. Оказалось, что комбинация "А, С, EXT" не работает, перепробовав несколько комбинаций мы нашли нужную: "С, А, EXT". BIOS был успешно перепрошит, но APM так и не заработал (возможно, исправление будет в следующих релизах BIOS). Так как нашей целью было проверить, насколько оправдано применение двухпроцессорной машины, а не война с APM, хотя это тоже важно, то мы решили побыстрее перейти к тестам.

К сожалению, наши процессоры отказались работать на шине 100MHz, поэтому все тесты проводились на 83MHz, процессоры при этом работали на 456MHz. Первой задачей, которую мы перед собой поставили, было выянить, какой прирост будет в приложениях специально оптимизированных под SMP. В качестве таковых, нами было выбрано две программы: игра "Quake3 Arena" и пакет "Adobe Photoshop 5.0". Обе эти программы часто встречаются на домашних машинах.

Quake3 Arena (Demo001)

Задачей было протестировать не видеокарту, а выяснить, какой прирост дает применение второго процессора, то тест проводился только в режиме Fastest_640х480, который дает наименьшую нагрузку на видеокарту, и наибольшую на процессор. Оптимизация под SMP включалась/выключалась командой r_smp. r_smp 0: 57.9 fps r_smp 1: 69.6 fps
Прирост 11.7 fps, или 20.2%

Adobe Photoshop 5.0

Для тестов мы использовали 24-х битный BMP размером 13 мегобайт. На этот рисунок накладывались следующие фильтры: Gausian Blur, Unsharp Mask и Facet. Время наложения каждого фильтра замерялось по три раза, после этого брался усредненный результат. Второй процессор включался/выключался командой Set Affinity из Task Manager. 1 CPU 2 CPU Прирост % Gausian Blur 3.7сек 2.45сек 51.02% Unsharp Mask 2.03сек 1.9сек 6.8% Facet 4.35сек 2.58сек 68.6%
Как видно из тестов, реальные приложения специально оптимизированные под SMP способны дать почти 70% прироста.

Однако, выше речь шла о софте, при написании которого специально учитывалась возможность его работы на SMP cистемах, в то время как большинство современных программ не имеют такой оптимизации. Возникает резонный вопрос: есть ли смысл ставить многопроцессорную машину, ведь ее преимущества будут ощутимы только в ограниченном числе приложений? Ответ: да. В любом случае, многопроцессорная машина аппаратно приспособлена для реализации многозадачности (помните правило: один процессор – одна нить?), и при работе нескольких приложений ее преимущество над однопроцессорным собратом должно быть значительным. Какой же должна быть методика тестирования, чтобы доказать это практически? Во-первых, нужно запустить несколько приложений, которые не дают значительного прироста от использования SMP-системы, но сильно загружают процессор. Во-вторых, эти приложения должны обеспечивать возможность подсчета производительности. И, наконец, было бы неплохо, что бы они были достаточно популярными, и любой желающий, мог самостоятельно проверить истинность наших выкладок. Мы выбрали две игры, которые наиболее полно соответствуют всем этим критериям - Quake2 и Unreal. Конечно, никто не будет играть в две игры одновременно, но на их примере, можно выявить тенденцию, которая будет верна практически для любых других процессороемких приложений, от MP3-encoder до DVD-player. Тестирование проводилось следующим образом. В двух окнах – fullscreen off - запускался Quake2 и Unreal, в каждом из них запускался timedemo. Разрешение 320x240, Software rendering (как вы помните, выяснялась производительность процессоров, а не видеокарты). Потом замерялись результаты. После этого, в Task Manager командой Set Affinity оба приложения вешались на один процессор, и снова замерялось timedemo.

Как и в предыдущих тестах, эта методика обеспечивает абсолютно одинаковые условия, которые могут повлиять на результаты: ОС, быстродействие файловой системы, количество памяти, количество запущенных процессов и т.д. Вся разница, которая получается, показывает выигрыш от использования SMP системы.

SMP-ситема
Quake2   45.6          Unreal   32.0

1 CPU Quake2 17.4 Unreal 24.1
Как видно, разница более чем приличная. Результат Quake2 при двухпроцессорной обработке вырастает на 162.06% (Unreal работает), Unreal (Quake2 работает) в свою очередь - на 32.78%. Однако, в процессе тестирования мы заметили, что если при работе обоих игрушек на одном процессоре что-либо начинаешь делать в Quake2, хотя бы просто набирать команду в консоли, то скорость в Unreal сильно падает. Чтобы проверить этот факт, мы остановили в Quake2 режим timedemo и загрузили q2dm1.dm2, после чего просто побегали по карте. В результате всех наших манипуляций Unreal практически остановился - текущий fps с 30 упал до 0.08! Когда мы перестали двигаться в Quake2, но оставили загруженной Q2dm1, fps в Unreal вырос до 0.28. Один кадр рисовался несколько секунд.

Незамедлительно, мы переключили оба приложения на два процессора. Как мы и ожидали, после этого в Quake2 можно было делать все, что душе угодно, на Unreal это никак не влияло. Как было больше 30 fps, так и осталось. Получается, что SMP машина в этом случае оказалась быстрее однопроцессорной в несколько сотен раз. Впечатляет, не правда ли? Конечно, говоря здесь о "скорости", мы подразумеваем не увеличение процессорной мощи, скорее дело в том, КАК система обрабатывает задачи. Вывод, который можно сделать по результатам наших тестов, очевиден. Предлагаем вам сделать его самостоятельно.