Процессоры
Известно, что производительность любого процессора зависит от трех параметров: такта (или частоты) синхронизации, среднего количества тактов на команду и количества выполняемых команд. Таким образом, помимо тактовой частоты на производительность оказывают существенное влияние система команд и внутренняя организация процессора. Практически все поставщики компьютерной техники проводят испытания своих изделий для определения правильности выбранных архитектурных решений. Например, в таблице 2 представлены некоторые результаты измерений, полученные при прогоне теста TPC-C, построенного на базе коммерческой СУБД, на системе RISC System/6000 Model 590 (процессор POWER2) компании IBM. В таблице приняты следующие обозначения: FXU-блок обработки команд с фиксированной точкой, ICU блок обработки команд управления, FPU блок обработки команд с плавающей точкой.
| Процент команд FXU | 77.3% |
| Процент команд ICU | 22.5% |
| Процент команд FPU | 0.2% |
| Процент команд FXU, выполняемых в FXU0 | 67% |
| Процент команд FXU, выполняемых в FXU1 | 33% |
| Среднее количество тактов на команду (CPI) | 1.53 |
| Процент команд перехода, выполняемых в ICU | 93% |
| Процент команд условного перехода | 35% |
| Процент команд условного перехода, когда условие перехода выполняется | 57% |
| Процент команд перехода по счетчику | 2% |
| Средний размер базового блока в командах | 4.8 |
| Коэффициент промахов в I-кэше (на команду) | 2.1% |
| Коэффициент промахов в D-кэше (на команду) | 0.8% |
Таблица 2.
Анализ этих результатов может привести к лучшему пониманию характеристик ЦП на тестах TCP-C, которые, в свою очередь, с осторожностью можно было бы обобщить на более широкую область приложений баз данных, которую представляет данный тест.
Эти результаты показывают, что в тесте TPC-C доминируют команды FXU(операции манипуляции с целыми числами и операции вычисления адресов),довольно интенсивно используются команды перехода (ICU), а команды плавающей точки (FPU) практически не используются. Такие результаты следовало ожидать, поскольку общеизвестно, что в программном коде СУБД для преобразования адресов, необходимого при обработке указателей, интенсивно используется целочисленная арифметика.
Заметим, что в архитектуре POWER2 предусмотрено два целочисленных устройства. Второй FXU обрабатывает примерно треть целочисленных операций (при этом примерно половину времени, когда занят первый FXU, второй FPU также занят). Такая организация процессора дает почти 50% увеличение пропускной способности целочисленного кода по сравнению с процессором POWER(предыдущая версия архитектуры), в котором было всего один FPU, хотя исполняемый код СУБД не перекомпилировался. Таким образом, наличие в POWER2 двух целочисленных устройств существенно сокращает среднее количество тактов на выполнение одной команды (CPI) на рабочей нагрузке.
Почти все операции ICU представляют собой операции перехода, причем примерно треть из них составляют операции условного перехода. Почти равное соотношение выполняемых и невыполняемых условных переходов, а также небольшое число команд перехода по значению счетчика правильно отражают реализацию операторов перехода if-then-else, которые, как и следовало ожидать, доминируют в этой рабочей нагрузке. Средний размер базового блока (последовательности команд, выполняемых между двумя выполняемыми переходами) очень небольшой. Таким образом, данная рабочая нагрузка существенно отличается от нагрузки, реализующей алгоритмы из области научно-технических приложений с интенсивными вычислениями, которая связана с многократным повторением итераций циклов, включающих достаточно длинные последовательности программного кода, и дает значительно большее количество выполняемых переходов, больший процент команд перехода по значению счетчика и больший размер базового блока.
Коэффициент промахов кэша команд (I-кэша) размером 32 Kбайт довольно низок, хотя и выше, чем коэффициент промахов для многих других рабочих нагрузок. Коэффициент промахов существенно сокращается благодаря большому размеру строки I-кэша (128 байт) и локальности кода. Наличие достаточно большого кэша данных (D-кэша) емкостью 256 Кбайт объясняет наблюдающийся низкий коэффициент промахов по данным.
Таким образом, результаты подобных испытаний позволяют разработчикам процессоров оценить эффективность функциональной организации ЦП.
В современных суперскалярных процессорах Intel и RISC-процессорах (Ultra SPARC, PA-8000,MIPS R10000, PowerPC 604/620 и DEC Alpha) практически повсеместно используются параллельно работающие блоки целочисленной арифметики, предусмотрены развитые средства прогнозирования направления переходов и большие по объему кэши команд и данных. Сегодня производительность этих процессоров находится на одном уровне с производительностью самых быстрых мэйнфреймов. Тактовая частота RISC-процессоров достигла 500 МГц, а общая производительность на стандартных оценочных тестах сравнима (рис. 1).
В настоящее время стандартным средством увеличения производительности системы является симметричная мультипроцессорная обработка (SMP), предполагающая использование многими процессорами одной общей памяти и одной операционной системы, которая управляет всеми процессорами и аппаратными средствами. В современных системах SMP наиболее актуальным вопросом является создание высокопроизводительной подсистемы памяти для обеспечения высокоскоростных процессоров данными и командами. Общее решение этой проблемы заключается в использовании большой высокоскоростной кэш-памяти, т. е. создании иерархии памяти между процессорами и разделяемой общей памятью, а также общесистемной шины с высокой пропускной способностью.
В общем случае потребление процессорных ресурсов очень сильно варьируется в зависимости от используемого приложения, СУБД, особенностей отдельных пользователей и даже от времени дня. Например, результаты теста TPC-A 1994года показывали, что восьмипроцессорный SPARCserver 1000 компании Sun способен обрабатывать запросы от 4000 пользователей, или от 500 пользователей на процессор. (Эти результаты были получены на многопотоковом сервере OracleVersion 7, работающим в режиме клиент-сервер, причем в качестве фронтальной системы использовался монитор обработки транзакций Tuxedo/T.) Следует отметить, что такие высокие показатели были достигнуты специалистами компаний Sun и Oracle путем очень тщательной настройки ОС Solaris, СУБД Oracle и самого оценочного теста.
Возможности этих специалистов по настройке системы, очевидно, значительно превосходят возможности большинства пользователей. Более реалистическая верхняя граница числа пользователей на процессор, возможно, составляет порядка 100-200 пользователей на один процессор SuperSPARC 50 МГц, даже для легких транзакций типа TPC-A. Более крупные приложения, естественно, приводят к меньшему числу пользователей на процессор (соответствующие результаты представлены в таблице 3).
| Тип приложения | Количество процессоров 50 МГц SuperSPARC | |||||
| 1 | 2 | 4 | 8 | 16 | ||
| TP-монитор | Клиент/сервер | 200-300 | 350-500 | 550-850 | 800+ | 1000+ |
| Легковесное | Клиент/сервер | 150-200 | 250-350 | 450-550 | 725+ | 800+ |
| многопотоковое | Разделение времени | 50-80 | 85-135 | 150-225 | 200-300 | 250-300 |
| Тяжеловесное | Клиент/сервер | 50-100 | 85-170 | 150-250 | 200-350 | 350-600 |
| многопотоковое | Разделение времени | 20-60 | 35-100 | 60-175 | 100-300 | 150-250 |
| Тяжеловесное 2N | Клиент/сервер | 40-75 | 70-125 | 120-220 | 200-600 | 300-750 |
| Разделение времени | 15-40 | 25-70 | 45-120 | 75-200 | 110-230 |
Примерное число поддерживаемых пользователей на ЦП.
Следует отметить, что процессор Super-SPARC 50 МГц уже снят с производства, и нынешнее поколение процессоров Sun, в частности, UltraSPARC II 250 МГц, имеет почти на порядок большую производительность. Тем не менее результаты таблицы 3 весьма поучительны. Например, они показывают, что ни операционная система Solaris 2, ни СУБД не масштабируются линейно (то же самое происходит и с конкурирующими операционными системами), хотя со временем по мере дальнейшей настройки ОС и СУБД имеется определенный прогресс в этом направлении.
