SPEC CPU 2000: определение производительности в новом тысячелетии

Мощность компьютеров и работающих на них приложений, непрерывно повышается. Любой покупатель стремится приобрести самую современную и мощную систему, какую только может себе позволить. Но как определить, является ли она таковой? Пусть даже используемое вами приложение вообще не выполняет операций ввода/вывода - производительность будет определяться не только одним процессором: на нее влияют кэш-память, основная память и компиляторы; кроме того, разные программы предъявляют различные требования к производительности. Как получить достоверную информацию о ее уровне?

Standard Performance Evaluation Corporation (SPEC) - это некоммерческий консорциум, в который входят производители оборудования и программного обеспечения, университеты, пользователи и консультанты. Миссия SPEC состоит в разработке заслуживающих доверия с технической точки зрения, объективных тестов компонентного и системного уровня для различных операционных систем и сред, в том числе тестов вычислительного характера, тестов оценки работы системы в качестве Web-серверов и тестов графических подсистем. Члены консорциума выбирают комплекты тестов, базирующиеся на реальных приложениях, чтобы и проектировщики систем, и покупатели компьютеров могли принимать решения исходя из результатов, полученных на реалистичных рабочих нагрузках. По условиям лицензионного соглашения члены консорциума обязуются выполнять тесты и сообщать о результатах в соответствии со специальными спецификациями.

30 июня 2000 года SPEC изъял из обращения комплект тестов CPU95. На смену ему пришел CPU2000 - новый комплект процессорных тестов, в который вошли 19 приложений, ранее не участвовавших ни в одном из тестовых пакетов SPEC. Непрерывно развивая свои тесты, SPEC старается идти в ногу с прогрессом, темпы которого приобретают в наши дни все большую быстроту. Как же SPEC разрабатывает тестовые пакеты и в чем именно состоят их функции? Получить понятие о процессе разработки мы сможем, прожив один из рабочих дней вместе со SPEC.

«Тест-марафон» SPEC

Холодное февральское утро 1999 года, четверг, 6:00. Сотрудник Compaq собирается отключить сигнализацию в штаб-квартире SPEC в Манассасе, Вирджиния, чтобы начать рабочий день. Но он обнаруживает, что сигнализация уже отключена, так как два сотрудника IBM остались в офисе со вчерашнего дня. Идет привычный ритуал SPEC длиной в неделю: один из подкомитетов проводит «тест-марафон» и работа круглые сутки. Служащий Compaq проходит в торцевую комнату, где стоит 30-градусная жара, создаваемая установленными там рабочими станциями Sun, Siemens, Intel, SGI, Compaq и IBM. Он открывает окно для притока холодного воздуха, и открывает окна приложений на рабочих станциях чтобы просмотреть результаты работы «комплекта 60», который со временем получит название SPEC CPU2000. (SPEC выпустит его 10 месяцев спустя, после выхода «комплекта 98»).

Основная цель работы на данном этапе - обеспечение переносимости кандидатов в тесты. Пока остальные члены подкомитета прибывают на сегодняшнее собрание, служащий Compaq обновляет электронную таблицу Porter Progress. На четвертый день тест-марафона таблица содержит результаты для

• 34 кандидатов в тесты;
• 18 платформ от семи производителей оборудования (11 - 32-разрядные и 7 - 64-разрядные);
• 11 версий Unix (три из них - разновидности Linux) и две версии Windows NT.

SPEC тестирует множество различных систем, хотя на данном тест-марафоне представлены лишь два основных семейства ОС - Unix и NT. SPEC не имеет возможности сделать участие для какой-либо платформы обязательным и полагается на силы добровольцев.

К сожалению, лишь 19 из 34 кандидатов в тесты успешно функционируют на всех платформах. Обеспечение переносимости - непростая задача, поскольку приложения комплектов SPEC - не абстрактные вычислительные циклы, а программы, решающие реальные задачи. Трудности переносимости можно грубо классифицировать по языкам программирования, на которых написан исходный текст.

Fortran. Приложения на Fortran-77 переносить проще всего, потому что язык содержит относительно мало машиннозависимых функций, а соответствующему стандарту ANSI уже более 20 лет. Тем не менее трудности есть. К примеру, одно из приложений состоит из 47134 строк кода и 123 файлов исходных текстов, и дает неверные результаты, будучи скомпилированным одним из компиляторов SPEC со включенной оптимизацией. Отладка затруднена. Позже выяснится, что виноват компилятор, приложение будет «реабилитировано», и тест 200.sixtrack войдет в комплект CPU2000.

Несколько приложений на F77 занимают для работы 200 Мбайт оперативной памяти. Один из участников подкомитета жалуется, что при статическом размещении исполняемые файлы занимают слишком много места на диске; при динамическом же на другой платформе не хватает стека операционной системы. В конце концов SPEC остановится на динамическом выделении, но разрешит использовать статическое в случае необходимости.

Приложения на Fortran-90 переносить гораздо труднее, потому что реализаций F90 намного меньше, и они гораздо менее совершенны по сравнению с F77. Автор одного из приложений старается использовать максимальное количество возможностей Fortran-90, предусмотренных стандартом. В феврале 1999 года это приложение успешно выполнялось лишь на трех платформах. Позже оно заработает на всех тестировавшихся компиляторах F90, а автор 187.facerec получит повод гордиться тем, что обнаружил ошибки во многих из них. Но и сама facerec тоже будет скорректирована (см. врезку «Работа по сравнению»).

Си и С++. Приложения на языке Си переносить сложнее, чем программы на любом из диалектов Fortran. Проблемы довольно распространенные: сколько байт занимает переменная типа long? Сколько байт занимает указатель? Реализована ли на данной платформе функция calloc? Каков порядок следования байт - прямой, обратный? Приложения подходят к этим проблемам по-разному, а SPEC предъявляет свои собственные требования. Например, SPEC предпочитает стандарты ANSI, но в некоторых программах до сих пор имеются функции из стандарта Си от Кернигана и Ритчи. В конце концов те из них, которые вызывают проблемы, будет решено удалить, а остальные оставят нетронутыми. В некоторых программах используется процесс настройки (configure), но SPEC предпочитает сводить к минимуму различия в исходных текстах и избегать дополнительных усилий по конфигурированию, предпочитая другие методы обеспечения переносимости, например введение дополнительных директив #ifdef.

Наиболее сложны в переносе приложения на С++. Стандарт на это язык появился относительно недавно, динамические функции (библиотеки классов) различаются и трудны в сравнении, поэтому SPEC приняла лишь два приложения на С++. Одно из них уже исключено из комплекта: оно функционировало с GNU g++, но на ANSI C++ его перенести не удалось. Другое - 252.eon - оказалось гораздо более переносимым, заработало со всеми 17 компиляторами С++, протестированными в феврале 1999 года, и позднее (в декабре 1999 года) вошла в состав CPU2000.

Как видно из таблицы 1, в описываемую неделю февраля 1999 года тест-марафон позволил решить более чем половину всех проблем. Цель тест-марафона - собрать вместе как можно большее число платформ, тестов и руководителей проектов, заставив тех совместно разрешать технические проблемы: на тест-марафонах не редкость, когда сразу несколько сотрудников различных компаний сидят за одним дисплеем, помогая друг другу.

Руководители проектов и ответственный за инструменты

Руководитель проекта курирует разработку тестов-кандидатов и отвечает за разрешение проблем, связанных с переносимостью. Один из руководителей проектов взял на себя сразу 10 тестов, но позже подкомитет облегчил ему нагрузку.

Другому досталось всего три теста, но в каждом из них были свои сложности. Первый из тестов представлял собой систему моделирования, которую никак не удавалось заставить выдавать одинаковые результаты на разных платформах, и от которой позднее пришлось отказаться. Второй - 186.crafty - требовал для своего выполнения 64-битный целочисленный тип, не предусмотренный стандартом С89, но так или иначе реализуемый средствами всех тестировавшихся компиляторов. Третий тест выдает непонятные ошибки степени достоверности, и сотрудникам приходится проводить тщательные взаимные проверки результатов. Приложение создает точечную карту, состоящую из областей разного цвета. Для отдельных граничных пикселов выбор цвета зависит от малейшей разницы в результатах выполнения операций с плавающей запятой, и различные платформы принимают разные решения, хотя результат для глаза почти не заметен. После обсуждения члены подкомитета выносят решение, что для данного приложения различия значения не имеют.

Один из членов подкомитета отвечает за инструментарий - он пишет инструментальные средства, контролирующие компиляцию, исполнение тестов и оценку степени их достоверности. Ответственный за инструменты предлагает новый параметр - skiptol, допустимое число различающихся результатов. Функция реализована в описываемую неделю февраля, и приложение 177.mesa вошла в состав CPU2000 уже со skiptol, допускающим шесть различий на разных платформах при общем количестве выводимых чисел 3,9 млн.

Выбор тестов

Перенос требует чисто технической работы с довольно простым критерием завершенности: работает ли тест? Выбор теста, напротив, определяется многими, зачастую конфликтующими критериями, не всегда простыми. Тесты CPU2000 (табл. 2) были выбраны из большого списка кандидатов, предложенных членами консорциума и независимыми пользователями в рамках конкурса, объявленного на Web-узле SPEC. В конечном счете тесты выбираются голосованием, в ходе которого степень влияния различных критериев может оцениваться разными участниками по-разному. Зачастую кандидат в тесты может получить голос «за», если он

• имеет много пользователей;
• использует значительное количество аппаратных ресурсов;
• решает интересную техническую задачу;
• выдает результаты, опубликованные известными изданиями;
• расширяет ассортимент задач, решаемых тестами комплекта.

Тест-кандидат может получить голос «против», если он:

• не переносится в разумные сроки;
• выполняет слишком много операций ввода-вывода, и потому не может быть отнесен к вычислительным задачам;
• уже входил в состав комплекта SPEC CPU ранее, а его рабочая нагрузка осталась без существенных изменений;
• является скорее фрагментом кода, чем завершенным приложением;
• повторяет задачи, решаемые другими тестами-кандидатами;
• выполняет разную работу на различных платформах.

Объективные критерии

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

Данную проблему решили следующим образом. Все участники одновременно предоставили какое-то количество объективных данных, которые подкомитет хранил в секрете. Схема прекрасно работает: SPEC получает объективные данные по операциям ввода/вывода, операциям с кэш-памятью и основной памятью, составу операций с плавающей запятой, ветвлении, профилях и покрытию кода.

Три субъективных критерия

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

Второе субъективное соображение - прозрачность. Прозрачный тест достигает стабильности достаточно быстро, чтобы у участников хватило времени его проанализировать. Он может иметь сложный исходный текст, но не должен производить впечатление намеренно запутанного. Тест имеет рабочую нагрузку, которую можно описать как обычным английским языком, так и в технической терминологии, принятой в области, для которой написано приложение. Для включения теста в комплект имеются веские аргументы.

Последний субъективный критерий - уровень заинтересованности производителя. Есть ли у участника подкомитета, являющегося сотрудником некой компании-производителя, соблазн проголосовать из соображений конкурентной борьбы? Да, такой соблазн есть, но существуют два фактора, существенно снижающие его влияние.

• Как правило, участники не имеют сведений об уровне производительности кандидата в тесты, показанном на оборудовании конкурирующей фирмы. Даже при наличии неограниченного бюджета и времени было бы невозможным приобрести еще не выпущенные конкурентом аппаратное обеспечение и компиляторы следующего поколения. Определить степень конкурентоспособности теста до выхода комплекта нельзя; поэтому лучше голосовать, исходя из технических характеристик приложения.
• Уговоры типа «вам следует проголосовать за 999.favorite, потому что это поможет моей компании» в подкомитете недопустимы. Подобные действия, совершаемые в открытую, могут привести к результатам, обратным ожидаемым: малейшие попытки способны посеять сомнения в прозрачности теста.

Конечно, члены SPEC, являющиеся сотрудниками компаний, учитывают интересы своих работодателей. К примеру, служащий компании, выпускающей Unix-системы с прямым порядком следования байт, следит за тем, чтобы игровое поле не оказалось с наклоном в пользу NT-систем, у которых порядок следования байт в слове обратный. Доводы в пользу выравнивания игрового поля приветствуются и быстро находят поддержку. Однако попытки наклонить его попросту не срабатывают.

Результаты

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

На рис. 1 приведены показатели производительности выполнения операций с целыми и вещественными числами для четырех систем разной конфигурации, оснащенных процессорами Alpha 21164 и 21264. Производительность определяется относительно эталонной машины, 300-мегагерцевой Sun Ultra5_10, индекс производительности которой составляет 100.

Посмотрим сначала на результаты трех систем с процессором 21164. Как можно видеть, производительность зависит не только от числа мегагерц.

• Производительность в 26 тестах на системах с 21164 находится в пределах от 92,3 до 331.
• Результаты 500-мегагерцевых систем на 21164 (AlphaStation 500/500 и Personal Workstation 500 au) различаются более чем на 5% в 17 из 26 тестов.
• 533-мегагерцевый AlphaServer 4100 5/533, имеющий по сравнению с остальными преимущество в 7% по тактовой частоте, обходит их более чем на 10% в трех тестах, менее чем на 3% в трех тестах, и проигрывает 500-мегагерцевой системе три раза.

Чтобы разобраться в этих результатах, необходимо отметить различия между системами, особенно между их иерархиями памяти (см. табл. 3). Обратите внимание, что каждая из систем на 21164 по какой-то из характеристик превосходит остальные:

• AlphaStation 500/500 имеет самый большой объем кэш-памяти уровня 3;
• Personal Workstation 500au отличается наименьшим временем ожидания кэш- и основной памяти, особенно если измерять его в тактах процессора;
• AlphaServer 4100 5/533 отличается наибольшей пропускной способностью памяти.

Эффекты кэширования. AlphaServer 4100 5/533 выигрывает в большинстве тестов, причем с наибольшим отрывом на 179.art. Из табл. 2 видно, что физически 179.art почти умещается в 4 Мбайт кэш-памяти, но не умещается - в 2 Мбайт. Уровень непопаданий (табл. 4) подтверждает это. Система выигрывает потому, что программа 179.art целиком умещается в ее кэш-памяти, которая работает быстрее, чем у 500/500.

Тест, демонстрирующий особенно интересные эффекты кэширования - 181.mcf. На нем 500/500 показывает лучший результат, чем у 4100/533. Согласно профилю DCPI (системы профилирования Compaq Continuous Profiling Infrastructure, ранее известной как Digital Continuous Profiling Infrastructure) [2], 4100 5/533 тратит довольно много времени на выполнение кода, подобного следующему, в котором инструкция вычитания требует в среднем 177 тактов (cycles per issue, CPI).

ldq a1,64(s1)
...[две инструкции пропущены]...
ldq a2,88(t6)
ldq v0,32(a1)
...[одна инструкция пропущена]...
subq a2,v0,v0

Данный участок кода загружает в регистры а1 и а2 значения из памяти; в регистр v0 значение, содержащееся в ячейке памяти, адрес которой на 32 байта больше адреса, хранящегося в а1; вычитает значение v0 из а2 и сохраняет результат в v0.

Задержки определялись для зависимых загрузок («pointer chasing» - операции с многоуровневой косвенной адресацией) при шаге 128 - чем меньше задержка, тем лучше. Пропускная способность в млн. байт в секунду определялась при помощи триады Маккалпина [1] - чем пропускная способность выше, тем лучше.

Таким образом, операция вычитания происходит по завершении трех загрузок, выполняемых в шести инструкциях, непосредственно предшествующих вычитанию. Чтобы выяснить точное распределение процессорного времени, понадобилось бы низкоуровневое моделирование системы; однако и без него можно правдоподобно объяснить, почему на выполнение данного кода требуется 117 тактов. Инструкция вычитания обычно ждет зависимой загрузки v0, обнаруживая ее в кэш-памяти третьего уровня в 15% времени (33 такта), и в основной памяти - в 85% времени (132 такта). Для инструкции вычитания число непопаданий в кэш, по DCPI, составляет 253 млн. Для сравнения, в случае с 500/500 CPI составляет 95 (что намного меньше по сравнению с временем задержки основной памяти - 117 тактов), а количество непопаданий в кэш третьего уровня - лишь 161 млн. Наличие 8 Мбайт кэш-памяти существенно повышает производительность 181.mcf.

Основная память. Эффекты кэширования играют важную роль, но многие научные приложения обрабатывают большие массивы данных, и потому их производительность зависит от пропускной способности основной памяти. AlphaServer 4100 5/533 по этому показателю является лучшим среди всех трех систем на 21164, так что своим выигрышам он, по-видимому, обязан данному преимуществу. Как видно из таблицы 4, три из пяти входящих в комплект SPECfp2000 приложений (171.swim, 189.lucas, 173.applu), характеризующихся максимальным числом непопаданий в кэш, не особенно улучшают свои результаты при увеличении объема кэш-памяти с 2 до 4 Мбайт. Таким образом, разница результатов 4100 5/533 по сравнению с 500au возникает, очевидно, за счет различий в пропускной способности памяти, а не эффектов кэширования. Не очень ясно, почему результаты swim так мало улучшаются с увеличением объема кэш-памяти, но можно правдоподобно объяснить, почему так резко улучшаются результаты lucas: процессор 211164 одновременно может принять лишь два ожидающих обработки запроса на загрузку из памяти. Следовательно, преимущество 4100 5/533 в пропускной способности наиболее выраженно проявляется в том случае, когда команды загрузки равномерно распределены по всему коду, а не сбиты в кучи. Когда такие команды рассеяны, увеличивается вероятность совместного выполнения вычислительных операций и операций обмена с памятью; если же те сбиты в кучи, после третьей загрузки процессор приостановит их обработку, и уровень перекрытия операций понизится.

Lucas - приложение, разработанное задолго до представления в SPEC. Как показывает DCPI, основная масса (около 2,6 млрд.) непопаданий в кэш приходится на подпрограмму fft_square, но ни для одной из индивидуальных инструкций число непопаданий не превышает 86 млн. Если извлечь виртуальные адреса 40 инструкций с наибольшим числом непопаданий (на которые в сумме приходится 84% всех непопаданий fft_square), среднее расстояние между ними составит 823 байт или 205 инструкций. Другими словами, операции с памятью в 189.lucas довольно равномерно распределены по коду.

Итак, мы рассмотрели три системы с тактовой частотой около 500 МГц, использующих один и тот же процессор, но обладающих разными иерархиями памяти, и отметили различия в производительности выполнения на этих системах тестов CPU2000. Получен вывод, что уровень производительности определяется не одной только тактовой частотой.

Производительность процессора

Теперь сменим процессор, но останемся на уровне 500 МГц. На рис. 1 также сравнивается производительность трех систем на 500-мегагерцевом 21164 с AlphaServer DS20 6/500 на базе нового процессора, Alpha 21264. Как видно из табл. 3, эта система обладает совершенно иной иерархией памяти. Задержка кэш-памяти у него в 1,8 раз ниже, задержка основной памяти - в 1,3 раза ниже, а пропускная способность - в 4,5 раза выше - это стало возможно благодаря новой системе памяти и процессора, который принимает одновременно до восьми ожидающих обработки запросов на загрузку из памяти и до восьми ожидающих обработки запросов на запись в память.

Хотя тактовая частота осталась на прежнем уровне, производительность радикально изменилась. Наибольшая разница была показана в тестах 252.eon (выполняется в 1,89 раз быстрее по сравнению с 4100 5/533), 186.crafty (в 1,94 раза) и 176.gcc (в 2,03 раза). Eon и crafty занимают мало места в памяти; так что по-видимому, преимущество при их выполнении было достигнуто за счет более малой задержки кэш-памяти и за счет самого процессора, который поддерживает неупорядоченную выдачу инструкций (в отличие от 21164, который допускает лишь упорядоченную выдачу).

Почему максимальное улучшение результатов среди целочисленных тестов показывает компилятор gcc, и почему версия gcc из CPU2000 демонстрирует гораздо лучший результат, чем gcc из комплекта CPU95 (в первом используется версия 2.03, во втором - 1.61) [3]? Говоря упрощенно, причина в рабочей нагрузке. В CPU95 gсс выполняет оптимизацию по минимуму, выполняясь на DS20 в течение 79 с, за которые компилируется 56 программ, не используя при этом более 47 Мбайт виртуальной памяти. Версия из CPU2000 компилирует намного большие по объему программы, затем интенсивно выполняет инкаплуляцию, а затем проводит обширную оптимизацию. Компилятор gcc работает на DS20 в течение 327 с, компилирует лишь пять программ и использует 156 Мбайт виртуальной памяти. Высокая пропускная способность DS20 очень влияет на производительность выполнения теста gcc из CPU2000 в то время, как тот перебирает кортежи в поисках наилучшего метода оптимизации.

В тестах оценки производительности выполнения операций вещественной арифметики от приложений 171.swim, 189.lucas и 173.applu (табл. 4), очевидно, следует ожидать повышения производительности за счет улучшенной пропускной способности памяти. Для двух из трех тестов на системах с 21164 данное предположение, как видно, подтверждается. Система же на базе 21264, пропускная способность памяти которой по сравнению с остальными в 4,5 раза выше, показывает лучшие результаты на всех трех тестах - производительность повысилась в 4,9, 2,2 и 2,8 раз, соответственно.

Несмотря на свой высокий уровень непопаданий в кэш, 183.equake улучшает результат лишь в 1,7 раз. Согласно описанию приложения в документации CPU2000, этот тест использует «неструктурированную петлю, которая локально вычисляет длину волны при помощи метода конечных элементов». По данным DCPI, наибольшее число непопаданий в кэш приходится на подпрограмму, которая подсчитывает произведение матриц-векторов, используя косвенную адресацию. Короче говоря, производительность equake больше зависит от времени задержки, чем от пропускной способности памяти.

Эффекты компиляции. Все результаты, приведенные в данной статье, получены при использовании одного и того же набора компиляторов с «базовой» настройкой: не более четырех ключей оптимизации, одинаковый набор ключей для всех тестов, написанных на одном и том же языке. При иной настройке или использовании иного набора компиляторов результаты были бы другими. Данные правила введены намеренно. Комплекты тестов SPEC предназначены для тестирования трех вещей: процессора, иерархии памяти и компиляторов.

Объем публикации не позволяет в подробностях обсудить даже основные эффекты компиляции, но мы можем кратко упомянуть два из них.

• Учитывая, что число строк кода в CPU2000 выросло по сравнению с предыдущей версией на 400 тысяч строк, к используемым компиляторам предъявляется требование повышенной стабильности. Например, при компиляции SPECfp_base2000 с ключом -fast все 10 приложений, написанных на Fortran, должны выдавать корректные результаты и обеспечивать приемлемую производительность.
• Некоторые тесты чувствительны к стратегии компиляции, например, к методам раскрутки и трансформации циклов. В частности, при сборке 178.galgel с максимальной оптимизацией, допускающей настройку на индивидуальной основе, производительность приложения на DS20 6/500 возрастает по сравнению с базовой настройкой на 70%.

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

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

Теперь, когда CPU2000 уже вышел, пора думать о его последователе, CPU200x. SPEC призывает тех, кто хотел бы внести вклад в следующую версию комплекта, заявить о себе. Мы приглашаем в SPEC университеты, консультантов, разработчиков компиляторов, производителей аппаратного обеспечения, независимых разработчиков ПО и конечных пользователей. Отнеситесь к нашему призыву со всей серьезностью и подумайте, не можете ли вы своим кодом, временем или советами оказать SPEC содействие в формировании новых тестов и, как следствие, помочь компьютерной индустрии в проектировании и аттестации новых вычислительных систем.

Об авторе

Джон Хеннинг - секретарь Подкомитета SPEC CPU, старший сотрудник технической службы отдела проектирования тестов оценки производительности подразделения High Performance Servers компании Compaq Computer. Хеннингу можно написать по адресу j.henning@computer.org

Литература

[1] J. McCalpin, «Stream: Sustainable Memory Bandwidth in High Performance Computers;?? http://www.cs.virginia.edu/stream/.

[2] J. Anderson et al., «Continuous Profiling: Where Have All the Cycles Gone??? Proc. 16th ACM Symp. Operating Systems Principles; http://www.unix.digital.com/dcpi/publications.htm.

[3] CPU95 gcc results; http://www.spec.org/cpu95/results/res97q4/cpu95-971027-02208.asc; and http://www.spec.org/cpu95/results/res99q1/cpu95-981221-03231.asc.

Работа по сравнению

If ((NewSim - OldSim)>SimThresh)Then
  CoordX (IX,IY)=NewX
  CoordY (IX,IY)=NewY
  Hops =Hops +1
  Improved =.TRUE.
EndIf
Sweeps =Sweeps +1
  If ((.NOT.Improved).OR.
    (Sweeps >=Params%Match%MaxSweeps))
Exit

SPEC и наука