A9 БГ Computer Architecture a Quantitative Approach (5th Edition)

Machine Translated by Google
В похвала на компютърната архитектура: Количествен подход

Пето издание
„5-то издание на Computer Architecture: A Quantitative Approach продължава наследството,

като предоставя на студентите по компютърна архитектура най-актуалната информация
за текущите компютърни платформи и архитектурни прозрения, които да им помогнат
да проектират бъдещи системи. Акцент в новото издание е значително преработената
глава за паралелизма на ниво данни, която демистифицира GPU архитектурите с ясни
обяснения, използвайки традиционната терминология на компютърната архитектура.“
— Кръсте Асанович, Калифорнийски университет, Бъркли
„Компютърна архитектура: Количествен подход е класика, която като хубаво вино просто
става все по-добра. Купих първото си копие, когато завърших бакалавърската си степен
и това остава един от най-често цитираните ми текстове днес.
Когато излезе четвъртото издание, имаше толкова много нов материал, че трябваше да
го накарам, за да остана актуален в областта. И докато преглеждам петото издание,
разбирам, че Хенеси и Патерсън са го направили отново. Целият текст е силно
актуализиран и само Глава 6 прави това ново издание задължително четиво за тези,
които искат наистина да разберат облачните и складовите изчисления. Само Hennessy и
Patterson имат достъп до вътрешните лица в Google, Amazon, Microsoft и други
доставчици на облачни изчисления и приложения в интернет мащаб и няма по-добро
покритие на тази важна област навсякъде в индустрията.“
— Джеймс Хамилтън, Amazon Web Services
„Хенеси и Патерсън написаха първото издание на тази книга, когато студенти изградиха
компютри с 50 000 транзистора. Днес компютрите с размер на склад съдържат толкова
много сървъри, всеки от които се състои от десетки независими процесори и милиарди
транзистори. Еволюцията на компютърната архитектура е бърза и безмилостна, но
Computer Architecture: A Quantitative Approach поддържа темпото, като всяко издание
точно обяснява и анализира важните нововъзникващи идеи, които правят тази област
толкова вълнуваща.
— Джеймс Ларус, Microsoft Research
„Това ново издание добавя страхотна нова глава за паралелизъм на ниво данни във
векторни, SIMD и GPU архитектури. Обяснява ключови архитектурни концепции в GPU
за масовия пазар, съпоставя ги с традиционните термини и ги сравнява с векторни и
SIMD архитектури. Това е навременно и уместно с широко разпространеното
преминаване към GPU паралелни изчисления. Компютърна архитектура: Количествен
подход допълва своята поредица от първи в представянето на цялостно покритие на
архитектурата на значими нови разработки!“
— Джон Никълс, NVIDIA

„Новото издание на този вече класически учебник подчертава възхода на изричния

паралелизъм (данни, нишка, заявка), като посвещава цяла глава на всеки тип. Главата за
паралелизма на данни е особено просветляваща: сравнението и контрастът между Vector
SIMD, SIMD на ниво инструкции и GPU пресича жаргона, свързан с всяка архитектура, и
разкрива приликите и разликите между тези архитектури.“
— Кунле Олукотун, Станфордски университет
„Петото издание на Computer Architecture: A Quantitative Approach изследва различните

паралелни концепции и техните съответни компромиси. Както при предишните издания,
това ново издание обхваща най-новите технологични тенденции. Два подчертани са
експлозивният растеж на персоналните мобилни устройства (PMD) и складовите изчисления
(WSC) – където фокусът е изместен към по-сложен баланс на производителност и енергийна
ефективност в сравнение със суровата производителност. Тези тенденции подхранват
нашето търсене на все повече възможности за обработка, което от своя страна ни придвижва
по-надолу по паралелния път.“
— Андрю Н. Слос, инженер-консултант, ARM Автор на

Ръководство за разработчици на ARM система
Компютърна архитектура
Количествен подход
Джон Л. Хенеси е десетият президент на Станфордския университет, където той е член на факултета от
1977 г. в отделите по електротехника и компютърни науки.
Hennessy е сътрудник на IEEE и ACM; член на Националната инженерна академия, Националната академия
на науките и Американското философско общество; и сътрудник на Американската академия за изкуства
и науки. Сред многобройните му награди са наградата Eckert-Mauchly за 2001 г. за приноса му към RISC
технологията, наградата Seymour Cray Computer Engineering за 2001 г. и наградата John von Neumann за
2000 г., която той споделя с Дейвид Патерсън. Получил е и седем почетни докторски степени.
През 1981 г. той стартира проекта MIPS в Станфорд с шепа студенти. След като завършва проекта през
1984 г., той си взема отпуск от университета, за да съучреди MIPS Computer Systems (сега MIPS Technologies),
която разработва един от първите комерсиални RISC микропроцесори. Към 2006 г. над 2 милиарда MIPS
микропроцесори са били доставени в устройства, вариращи от видео игри и палмтоп компютри до
лазерни принтери и мрежови комутатори.
Впоследствие Хенеси ръководи проекта DASH (Директорска архитектура за споделена памет), който
създаде прототип на първия кохерентен мултипроцесор с мащабируем кеш; много от ключовите идеи са
възприети в съвременните мултипроцесори. В допълнение към своите технически дейности и
отговорности в университета, той продължава да работи с множество стартиращи фирми както като
съветник на ранен етап, така и като инвеститор.
Дейвид А. Патерсън преподава компютърна архитектура в Калифорнийския университет, Бъркли, откакто

се присъедини към факултета през 1977 г., където заема катедрата по компютърни науки Pardee.
Преподаването му е отличено с наградата за изтъкнато преподаване от Калифорнийския университет,
наградата Karlstrom от ACM и медала за образование Mulligan и наградата за бакалавърско преподаване
от IEEE. Патерсън получи наградата за технически постижения на IEEE и наградата ACM Eckert-Mauchly за
принос към RISC и сподели наградата за съхранение на информация на IEEE Johnson за принос към RAID.
Той също така сподели медала на IEEE Джон фон Нойман и наградата C & C с Джон Хенеси. Подобно на
своя съавтор, Патерсън е сътрудник на Американската академия на изкуствата и науките, Музея за
компютърна история, ACM и IEEE и е избран в Националната инженерна академия, Националната
академия на науките и Силиконовата долина Инженерна зала на славата. Той е служил в Консултативния
комитет по информационни технологии към президента на САЩ, като председател на отдела за CS в
отдела EECS на Бъркли, като председател на Асоциацията за компютърни изследвания и като президент
на ACM.
Този рекорд доведе до награди за изключителни услуги от ACM и CRA.
В Бъркли Патерсън ръководи проектирането и внедряването на RISC I, вероятно първият VLSI компютър
с редуциран набор от инструкции и основата на комерсиалната SPARC архитектура. Той беше ръководител
на проекта Redundant Arrays of Inexpensive Disks (RAID), който доведе до надеждни системи за съхранение
от много компании. Той също така участва в проекта Network of Workstations (NOW), който доведе до
клъстерната технология, използвана от интернет компаниите, а по-късно и до облачните изчисления.
Тези проекти спечелиха три награди за дисертации от ACM. Текущите му изследователски проекти са
Лаборатория Алгоритъм-Машина-Хора и Лабораторията за паралелни изчисления, където той е директор.
Целта на AMP Lab е да разработи мащабируеми алгоритми за машинно обучение, модели за програмиране,
подходящи за компютър, и инструменти за краудсорсинг, за да получите бързо ценна информация от
големи данни в облака. Целта на Par Lab е да разработи технологии за доставяне на мащабируем,
преносим, ефективен и продуктивен софтуер за паралелни персонални мобилни устройства.
Компютърна архитектура
Количествен подход
Джон Л. Хенеси
Станфордски университет
Дейвид А. Патерсън
Калифорнийски университет, Бъркли
С приноси от Norman P. Jouppi HP

Labs
Кръсте Асанович
Калифорнийски университет, Бъркли Шенг Ли

HP Labs
Джейсън Д. Бакос
Навин Муралиманохар
Университет на Южна Каролина
HP Labs
Robert P. Colwell R&E
Colwell & Assoc. Inc. Университет Грегъри Д.
Томас М. Конте Питърсън в Тенеси
Държавен университет в Северна Каролина Тимъти М. Пинкстън
José Duato Университет на Южна Калифорния
Universitat Politècnica de València и Simula Parthasarathy Ranganathan HP Labs
Даяна Франклин
Дейвид А. Ууд
Калифорнийски университет, Санта Барбара
Университет на Уисконсин-Медисън
Дейвид Голдбърг
Амр Заки
Изследователският институт Скрипс
Университет на Санта Клара
Амстердам • Бостън • Хайделберг • Лондон

Ню Йорк • Оксфорд • Париж • Сан Диего
Сан Франциско • Сингапур • Сидни • Токио
Придобиващ редактор: Тод Грийн

Редактор на разработката: Nate McFadden
Ръководител на проекта: Paul Gottehrer
Дизайнер: Джоан Бланк
Morgan Kaufmann е отпечатък на Elsevier

225 Wyman Street, Waltham, MA 02451, САЩ
© 2012 Elsevier, Inc. Всички права запазени.
Никаква част от тази публикация не може да бъде възпроизвеждана или предавана под каквато и да е форма или по каквито и
да било средства, електронни или механични, включително фотокопиране, запис или каквато и да е система за съхранение и
извличане на информация, без писмено разрешение от издателя. Подробности за това как да поискате разрешение,
допълнителна информация относно политиките за разрешения на Издателя и нашите договорености с организации като
Центъра за изчистване на авторски права и Агенцията за лицензиране на авторски права, можете да намерите на нашия
уебсайт: www.elsevier.com/permissions .
Тази книга и отделните приноси, съдържащи се в нея, са защитени с авторски права от Издателя (освен както може да бъде
отбелязано тук).
Забележки
Знанията и най-добрите практики в тази област непрекъснато се променят. Тъй като новите изследвания и опитът разширяват
нашето разбиране, може да се наложи промяна в методите на изследване или професионалните практики. Практиците и
изследователите винаги трябва да разчитат на собствения си опит и знания при оценяването и използването на каквато и да е
информация или методи, описани тук. При използването на такава информация или методи те трябва да имат предвид
собствената си безопасност и безопасността на другите, включително страните, за които носят професионална отговорност.
В пълната степен на закона нито Издателят, нито авторите, сътрудниците или редакторите не поемат каквато и да е отговорност
за каквито и да било наранявания и/или щети на хора или имущество като въпрос на отговорност за продукти, небрежност
или по друг начин, или от каквото и да е използване или работа на всякакви методи, продукти, инструкции или идеи,
съдържащи се в материала тук.
Библиотеката на Конгреса на каталогизираните в публикацията данни

Заявлението е подадено
Данни за каталогизиране в публикацията на Британската
библиотека Каталожен запис за тази книга е достъпен от Британската библиотека.
ISBN: 978-0-12-383872-8
За информация относно всички публикации на MK
посетете нашия уебсайт на адрес www.mkp.com
Отпечатано в Съединените американски щати

11 12 13 14 15 10 9 8 7 6 5 4 3 2 1
Набор от: diacriTech, Ченай, Индия

На Андреа, Линда и четиримата ни сина

Тази страница умишлено е оставена празна

Предговор 1
от Луис Андре Барозу, Google Inc.
Първото издание на Hennessy и Patterson's Computer Architecture: A Quanti-tative Approach

беше пуснато през първата ми година в следдипломното училище. Следователно принадлежа
към онази първа вълна професионалисти, които научиха за нашата дисциплина, използвайки
тази книга като компас. Тъй като перспективата е основна съставка на полезен предговор, се
оказвам в неизгодно положение, като се има предвид колко много от моите собствени
възгледи са оцветени от предишните четири издания на тази книга. Друга пречка пред ясната
перспектива е, че благоговението на студентите към тези две суперзвезди на компютърните
науки все още не ме е напуснало, въпреки че (или може би поради) имах шанса да ги опозная
през годините след това. Тези недостатъци са смекчени от това, че практикувам този занаят
непрекъснато от първото издание на тази книга, което ми даде шанс да се насладя на нейната
еволюция и трайна уместност.
Последното издание пристигна само две години след като необузданата индустриална
надпревара за по-висока тактова честота на процесора приключи официално, като Intel
отмени своите 4 GHz едноядрени разработки и прегърна многоядрени процесори. Две години
бяха достатъчно време за Джон и Дейв да представят тази история не като произволна
актуализация на продуктовата линия, а като определяща инфлексна точка на компютърните
технологии през последното десетилетие. Четвъртото издание имаше намален акцент върху
паралелизма на ниво инструкции (ILP) в полза на добавен материал за паралелизма на ниво
нишка, нещо, което сегашното издание отива още повече, като посвещава две глави на
паралелизма на ниво нишка и данни, като същевременно ограничава ILP дискусия към една
глава. Читателите, които се запознават с новите машини за обработка на графики, ще се
възползват особено от новата Глава 4, която се фокусира върху паралелизма на данни,
обяснявайки различните, но бавно сближаващи се решения, предлагани от мултимедийни
разширения в процесори с общо предназначение и все по-програмируеми графични
процесори. От забележително практическо значение: Ако някога сте се борили с
терминологията на CUDA, вижте Фигура 4.24 (закачка: „Споделена памет“ е наистина локална,
докато „Глобална памет“ е по-близо до това, което смятате за споделена памет).
Въпреки че все още сме в средата на тази многоядрена технологична промяна, това
издание включва това, което изглежда следващото голямо: облачните изчисления. В този
случай повсеместното разпространение на интернет свързаността и еволюцията на
завладяващите уеб услуги извеждат в светлината на прожекторите много малки устройства (смартфони,
ix
x Предговор
и много големи (компютърни системи от складов мащаб). ARM Cortex A8, популярен CPU за смарт
телефони, се появява в раздела „Putting It All Together“ на Глава 3, а цяла нова Глава 6 е посветена
на паралелизма на ниво заявка и данни в контекста на изчисленията в складови помещения
системи. В тази нова глава Джон и Дейв представят тези нови масивни клъстери като отличително
нов клас компютри – отворена покана към компютърните архитекти да помогнат за оформянето
на това нововъзникващо поле. Читателите ще оценят как тази област се е развила през
последното десетилетие, като сравнят клъстерната архитектура на Google, описана в третото
издание, с по-модерното въплъщение, представено в глава 6 на тази версия.
Завърналите се клиенти на тази книга ще оценят отново работата на двама изключителни

компютърни учени, които през кариерата си са усъвършенствали изкуството да комбинират
принципното отношение на идеите на академик с дълбоко разбиране на водещите промишлени
продукти и технологии. Успехът на авторите в индустриалните взаимодействия няма да бъде
изненада за онези, които са били свидетели на това как Дейв провежда двугодишните си проектни
отстъпления, форуми, прецизно създадени, за да извлекат максимума от академично-
индустриалните сътрудничества. Тези, които си спомнят предприемаческия успех на Джон с MIPS
или се сблъскват с него в коридора на Google (както аз понякога правя), също няма да бъдат изненадани от това.
Може би най-важното е, че връщането и новите читатели ще получат парите си. Това, което
превърна тази книга в трайна класика, е, че всяко издание не е актуализация, а обширна ревизия,
която представя най-актуалната информация и несравнимо вникване в тази завладяваща и бързо
променяща се област. За мен, след повече от двадесет години в тази професия, това е още една
възможност да изпитам онова възхищение на студентски клас към двама забележителни учители.
Съдържание 1
Предговор ix
Предговор xv
Благодарности xxiii
Глава 1 Основи на количествения дизайн и анализ

1.1 Въведение 1.2 2
Класове компютри 1.3 5
Дефиниране на компютърна архитектура 11
1.4 Тенденции в технологиите 17
1.5 Тенденции в мощността и енергията в интегралните 21
схеми 1.6 Тенденции 27
в разходите 1.7 33
Надеждност 1.8 Измерване, отчитане и обобщаване на 36
производителността 1.9 Количествени принципи на 44
компютърния дизайн 1.10 Събиране на всичко заедно: 52
производителност , цена и 55
сила 1.11 Заблуди и клопки 59
1.12 Заключителни бележки 1.13 Исторически перспективи и препратки 61
Казуси и упражнения от Даяна Франклин 61
Глава 2 Проектиране на йерархията на паметта

Десет усъвършенствани оптимизации на производителността 78
на кеша 2.3 Технология на паметта и оптимизации 96
2.4 Защита: Виртуална памет и виртуални машини 2.5 105
Връзъчни проблеми: Дизайнът на йерархиите на паметта 2.6 112
Обединяване на всичко: Йерархии на паметта в ARM
Cortex-A8 и Intel Core i7 2.7 Заблуди 113
и клопки 125
xi
xii Съдържание
2.8 Заключителни бележки: Поглед напред 2.9 129

Историческа перспектива и препратки Казуси и 131
упражнения от Norman P. Jouppi, Naveen Muralimanohar
и Sheng Li 131
Глава 3 Паралелизъм на ниво инструкция и неговото използване
3.1 Паралелизъм на ниво инструкции: Концепции и 148

предизвикателства 3.2 Основни техники на компилатор 156
за разкриване на ILP 3.3 Намаляване на разходите на клонове с 162
разширено прогнозиране на клонове 3.4 Преодоляване на 167
опасностите за данни с динамично планиране 3.5 Динамично 176
планиране: Примери и алгоритъм 3.6 183
Хардуерно базирани спекулации 3.7 Експлоатиране на ILP U изпейте 192
Multiple Issue и статично планиране 3.8 Използване на ILP чрез динамично
планиране, 197
множество проблеми и спекулации 3.9 Усъвършенствани техники за 202
доставка на инструкции и спекулации 213
3.10 Проучвания на ограниченията на ILP 3.11 Междусекторни проблеми: 221
ILP подходи и системата за памет 3.12 Многонишковост: използване на паралелизъм на ниво нишка да подобр
Еднопроцесорна 223
пропускателна способност 3.13 Обединяване на всичко: Intel Core i7 и 233
ARM Cortex-A8 3.14 Заблуди 241
и капани 3.15 Заключителни бележки: Какво предстои? 245
3.16 Историческа перспектива и препратки 247
Казуси и упражнения от Джейсън Д. Бакос и Робърт П. Колуел 247
Глава 4 Паралелизъм на ниво данни във векторни, SIMD и GPU архитектури

Векторна архитектура 4.3 264
Разширения на SIMD набор от инструкции за мултимедия 282
4.4 Графични процесори 4.5 288
Откриване и подобряване на паралелизма на ниво цикъл 315
4.6 Проблеми с пресичане 322
4.7 Обединяване на всичко: мобилни срещу сървърни GPU
и Tesla срещу Core i7 4.8 323
Заблуди и клопки 4.9 330
Заключителни бележки 4.10 332
Историческа перспектива и препратки 334
Казус и упражнения от Джейсън Д. Бакос 334
Глава 5 Паралелизъм на ниво нишка

Централизирани архитектури със споделена памет 351
5.3 Производителност на симетрични мултипроцесори със споделена памет 366
Съдържание xiii
5.4 Разпределена споделена памет и базирана на директория 378

кохерентност 5.5 Синхронизация: 386
Основите 5.6 Модели на съгласуваност на паметта: 392
Въведение 5.7 395
Междусекторни проблеми 5.8 Обединяване на всичко: многоядрени 400
процесори и тяхната 405
производителност 5.9 409
Заблуди и капани 5.10 Заключителни бележки 412
5.11 Исторически перспективи и справка s Case Изследвания и упражнения 412
от Амр Заки и
Глава 6 Компютри с мащаб на склад за използване на ниво на заявка и

Паралелизъм на ниво данни

Програмни модели и работни натоварвания за складови компютри 436
6.3 Компютърна архитектура на компютри от складов мащаб 441
6.4 Физическа инфраструктура и разходи за компютри с мащаб на склад 446
6.5 Облачни изчисления: Завръщането на помощните 455
изчисления 6.6 461
Междусекторни проблеми 6.7 Обединяване на всичко: компютър с 464
мащаб на склад на Google 471
6.8 Заблуди и клопки 6.9 475
Заключителни бележки 6.10 Исторически перспективи и препратки 476
Казуси и упражнения от Партхасарати Ранганатан 476
Приложение A Принципи на набора от инструкции
A.1 Въведение A.2 А-2

Класифициране на архитектурите на набори от А-3
инструкции A.3 Адресиране А-7
на паметта A.4 Тип и размер на А-13
операндите A.5 Операции в набора от А-14
инструкции A.6 Инструкции за А-16
контролен поток A.7 Кодиране на А-21
набор от инструкции A.8 Преминаване Проблеми: А-24
Ролята на компилаторите A.9 Обединяване на всичко: А-32
MIPS архитектурата A.10 А-39
Заблуди и клопки A.11 А-45
Заключителни бележки A.12 Историческа А-47
перспектива и препратки Упражнения от Грегъри Д. Питърсън А-47
Приложение B Преглед на йерархията на паметта
B.1 Въведение B.2 Б-2

Ефективност на кеша B.3 Б-16
Шест основни оптимизации на кеша Б-22
xiv Съдържание
B.4 Виртуална памет B.5 Б-40
Защита и примери за виртуална памет B.6 Заблуди и Б-49

клопки B.7 Заключителни Б-57
бележки B.8 Историческа Б-59
перспектива и препратки Упражнения от Amr Zaky Б-59

Б-60
Приложение C Конвейерна обработка: основни и междинни понятия
C.1 Въведение С-2
C.2 Основното препятствие при тръбопровода — опасности от С-11
тръбопровода C.3 Как се прилага тръбопровода? С-30
C.4 Какво прави тръбопровода труден за внедряване? С-43
C.5 Разширяване на MIPS конвейера за обработка на многоциклови операции С-51

C.6 Обединяване на всичко: MIPS R4000 Pipeline C.7 С-61
Междусекторни въпроси C.8 С-70

Заблуди и клопки C.9 С-80
Заключителни бележки C.10 С-81
Историческа перспектива и препратки С-81
Актуализирани упражнения от Диана Франклин С-82
Онлайн приложения
Приложение D Системи за съхранение
Приложение E Вградени системи
От Томас М. Конте
Приложение F Мрежи за взаимно свързване
Преработено от Тимъти М. Пинкстън и Хосе Дуато
Приложение G Векторни процесори в по-голяма дълбочина
Преработено от Кръсте Асанович
Приложение H Хардуер и софтуер за VLIW и EPIC
Приложение I Мащабни мултипроцесори и научни приложения
Приложение J Компютърна аритметика
от Дейвид Голдбърг
Приложение K Проучване на архитектурите на набори от инструкции
Приложение Л Исторически перспективи и препратки
Препратки R-1
Индекс I-1
Предговор 1
Защо написахме тази книга
Чрез пет издания на тази книга нашата цел беше да опишем основните принципи,
залегнали в основата на това, което ще бъде утрешното технологично развитие.
Вълнението ни относно възможностите в компютърната архитектура не е намаляло и
ние повтаряме това, което казахме за областта в първото издание: „Това не е мрачна
наука за хартиените машини, които никога няма да работят. Не! Това е дисциплина с
голям интелектуален интерес, изискваща баланса на пазарните сили към цена-
производителност-мощност, което води до славни провали и някои забележителни успехи.“
Основната ни цел при написването на първата ни книга беше да променим начина,
по който хората учат и мислят за компютърната архитектура. Смятаме, че тази цел все
още е валидна и важна. Областта се променя ежедневно и трябва да се изучава с реални
примери и измервания на реални компютри, а не просто като колекция от дефиниции и
дизайни, които никога няма да се наложи да бъдат реализирани. Предлагаме
ентусиазирано посрещане на всеки, който е идвал с нас в миналото, както и на тези,
които се присъединяват към нас сега. Така или иначе, можем да обещаем същия
количествен подход и анализ на реални системи.
Както при по-ранните версии, ние се стремим да произведем ново издание, което ще
продължи да бъде също толкова подходящо за професионални инженери и архитекти,
колкото и за тези, които участват в напреднали курсове по компютърна архитектура и
дизайн. Подобно на първото издание, това издание има остър фокус върху новите
платформи – персонални мобилни устройства и компютри от складов мащаб – и нови
архитектури – многоядрени и GPU. Подобно на своите предшественици, това издание
има за цел да демистифицира компютърната архитектура чрез акцент върху компромисите
между цена-производителност и енергия и добър инженерен дизайн. Вярваме, че
областта продължава да се развива и да се движи към строгата количествена основа на
отдавна установени научни и инженерни дисциплини.
xv
xvi Предговор
Това издание
Казахме четвъртото издание на Компютърна архитектура: Количествен подход

може да са били най-значимите след първото издание поради преминаването към
многоядрени чипове. Обратната връзка, която получихме този път беше, че книгата е загубена
острият фокус на първото издание, обхващащ всичко еднакво, но без акцент и контекст. Сигурни
сме, че това няма да се каже за петото издание.
Вярваме, че по-голямата част от вълнението е в екстремните размери на компютрите,
с персонални мобилни устройства (PMD) като мобилни телефони и таблети като клиенти и компютри
от складов мащаб, предлагащи облачни изчисления като сървър.
(Наблюдателните читатели може да видят намек за облачни изчисления на корицата.) Ние сме
поразен от общата тема на тези две крайности по отношение на разходите, производителността и
енергийна ефективност въпреки разликата в размера им. В резултат на това текущият контекст
през всяка глава е изчисление за PMD и за складови компютри,
и Глава 6 е чисто нова глава по последната тема.
Другата тема е паралелизмът във всичките му форми. Първо идентифицираме двата вида
паралелизъм на ниво приложение в глава 1: паралелизъм на ниво данни (DLP), който
възниква, защото има много елементи от данни, с които може да се работи едновременно,
и паралелизъм на ниво задача (TLP), който възниква, защото се създават работни задачи
които могат да работят независимо и до голяма степен паралелно. След това обясняваме четирите
архитектурни стилове, които използват DLP и TLP: паралелизъм на ниво инструкции (ILP)
в глава 3; векторни архитектури и графични процесори (GPU) в гл
4, която е съвсем нова глава за това издание; паралелизъм на ниво нишка в
Глава 5; и паралелизъм на ниво заявка (RLP) чрез компютри в складов мащаб
Глава 6, която също е съвсем нова глава за това издание. Преместихме паметта
йерархия по-рано в книгата към глава 2 и преместихме системите за съхранение
глава към Приложение D. Ние сме особено горди с Глава 4, която съдържа най-подробното и най-
ясно обяснение на GPU досега, и Глава 6,
което е първата публикация на най-новите подробности за компютър от мащаба на Google
Warehouse.
Както и преди, първите три приложения в книгата дават основите на MIPS
набор от инструкции, йерархия на паметта и конвейер за читатели, които не са чели a
книга като Компютърна организация и дизайн. За да намалите разходите, но все пак да предоставите
допълнителен материал, който представлява интерес за някои читатели, достъпен онлайн на адрес
http://booksite.mkp.com/9780123838728/ има още девет приложения. Има

повече страници в тези приложения, отколкото има в тази книга!
Това издание продължава традицията на използване на примери от реалния свят за
демонстриране на идеите, а разделите „Putting It All Together“ са чисто нови. The
Разделите „Putting It Together“ на това издание включват тръбопроводните организации и
йерархиите на паметта на процесора ARM Cortex A8, Intel core i7
процесор, графичните процесори NVIDIA GTX-280 и GTX-480 и един от Google
складови компютри.
Предговор xvii
Избор и организация на теми
Както и преди, ние възприехме консервативен подход към подбора на теми, тъй като в
областта има много по-интересни идеи, отколкото разумно може да се обхване при
разглеждането на основните принципи. Ние се отклонихме от цялостно проучване на всяка
архитектура, която читателят може да срещне. Вместо това нашата презентация се фокусира
върху основните концепции, които вероятно ще бъдат намерени във всяка нова машина.
Ключовият критерий остава този за подбор на идеи, които са били проверени и използвани
достатъчно успешно, за да позволят тяхното обсъждане в количествено отношение.
Нашето намерение винаги е било да се фокусираме върху материал, който не е достъпен
в еквивалентна форма от други източници, така че продължаваме да наблягаме на разширено
съдържание, когато е възможно. Наистина тук има няколко системи, чиито описания не могат
да бъдат намерени в литературата. (Читателите, които се интересуват стриктно от по-основно
въведение в компютърната архитектура, трябва да прочетат Компютърна организация и
дизайн: Хардуерно/софтуерен интерфейс.)
Преглед на съдържанието
Глава 1 е подобрена в това издание. Той включва формули за енергия, статична мощност,
динамична мощност, разходи за интегрални схеми, надеждност и наличност.
(Тези формули се намират и на предната вътрешна корица.) Надяваме се, че тези теми могат
да бъдат използвани в останалата част от книгата. В допълнение към класическите
количествени принципи на компютърен дизайн и измерване на производителността, секцията
PIAT е надстроена, за да използва новия бенчмарк SPECPower.
Нашето мнение е, че архитектурата на набора от инструкции играе по-малка роля днес,
отколкото през 1990 г., така че преместихме този материал в Приложение A. Той все още
използва архитектурата MIPS64. (За бърз преглед, резюме на MIPS ISA може да се намери на
задната вътрешна корица.) За феновете на ISA, Приложение K обхваща 10 RISC архитектури,
80x86, DEC VAX и IBM 360/370.
След това преминаваме към йерархията на паметта в глава 2, тъй като е лесно да се
приложат принципите цена-производителност-енергия към този материал и паметта е
критичен ресурс за останалите глави. Както и в предишното издание, Приложение B съдържа
въвеждащ преглед на принципите на кеша, който е достъпен в случай, че имате нужда от него.
Глава 2 обсъжда 10 разширени оптимизации на кеша. Главата включва виртуални машини,
които предлагат предимства в защитата, управлението на софтуера и управлението на хардуера
и играят важна роля в облачните изчисления. В допълнение към покриването на SRAM и DRAM
технологиите, главата включва нов материал за Flash паметта. Примерите за PIAT са ARM Cortex
A8, който се използва в PMD, и Intel Core i7, който се използва в сървъри.
Глава 3 обхваща използването на паралелизъм на ниво инструкции във

високопроизводителни процесори, включително суперскаларно изпълнение, предвиждане на
разклонения, спекулации, динамично планиране и многопоточност. Както бе споменато по-
рано, Приложение C е преглед на тръбопровода, в случай че имате нужда от него. Глава 3
също изследва границите на ILP. Подобно на глава 2, примерите за PIAT отново са ARM Cortex
A8 и Intel Core i7. Докато третото издание съдържаше много
xviii Предговор
на Itanium и VLIW, този материал вече е в Приложение H, което показва нашето виждане
че тази архитектура не отговаря на по-ранните твърдения.
Нарастващото значение на мултимедийните приложения като игри и видео
обработката също увеличи значението на архитектурите, които могат да използват паралелизъм на
ниво данни. По-специално, има нарастващ интерес към изчисленията с помощта на графични процесори
(GPU), но малко архитекти разбират как наистина работят GPU.
Решихме да напишем нова глава до голяма степен, за да разкрием този нов стил на компютърна
архитектура. Глава 4 започва с въведение във векторните архитектури,
който действа като основа, върху която да се изграждат обяснения на мултимедийния SIMD
разширения на набор от инструкции и графични процесори. (Приложение G навлиза в още по-голяма дълбочина
векторни архитектури.) Разделът за GPU беше най-трудният за писане в това
книга, тъй като бяха необходими много повторения, за да се получи точно описание, което също беше
лесно за разбиране. Значително предизвикателство беше терминологията. Решихме да тръгваме
с нашите собствени условия и след това предоставяме превод между нашите условия и официалните
условия на NVIDIA. (Екземпляр от тази таблица може да се намери на задната вътрешна корица
страници.) Тази глава въвежда модела за изпълнение на Roofline и след това го използва
за сравняване на Intel Core i7 и графичните процесори NVIDIA GTX 280 и GTX 480. The
глава описва и Tegra 2 GPU за PMD.
Глава 5 описва многоядрени процесори. Изследва симетрични и
архитектури с разпределена памет, като се изследват както организационните принципи, така и
производителност. Темите за моделите за синхронизация и последователност на паметта са
следващия. Примерът е Intel Core i7. Читателите, които се интересуват от мрежи за взаимно свързване
на чип, трябва да прочетат Приложение F, а тези, които се интересуват от по-мащабни мултипроцесори
и научни приложения, трябва да прочетат Приложение I.
Както бе споменато по-рано, Глава 6 описва най-новата тема в компютърната архитектура,
компютрите в складов мащаб (WSC). Въз основа на помощта на инженерите от
Amazon Web Services и Google, тази глава интегрира подробности относно дизайна, разходите,
и производителност на WSC, за която малко архитекти знаят. Започва с популярния модел за
програмиране MapReduce, преди да опише архитектурата и
физическо изпълнение на WSC, включително разходи. Разходите ни позволяват да обясним
появата на облачни изчисления, чрез които може да бъде по-евтино да се използва
WSC в облака, отколкото във вашия локален център за данни. Примерът PIAT е описание на Google
WSC, което включва информация, публикувана за първи път в
тази книга.
Това ни води до приложения A до L. Приложение A обхваща принципите на

ISAs, включително MIPS64, и Приложение K описва 64-битови версии на Alpha,
MIPS, PowerPC и SPARC и техните мултимедийни разширения. Той също така включва
някои класически архитектури (80x86, VAX и IBM 360/370) и популярни вградени

набори от инструкции (ARM, Thumb, SuperH, MIPS16 и Mitsubishi M32R). Приложение H е свързано с това,
че обхваща архитектури и компилатори за VLIW ISA.
Както бе споменато по-рано, приложения B и C са уроци за основно кеширане и
конвейерни концепции. Читателите, сравнително нови в кеширането, трябва да прочетат Приложение B
преди Глава 2 , а тези, които са нови в конвейера, трябва да прочетат Приложение C преди това
Глава 3.
Предговор xix
Приложение D, “Системи за съхранение,” има разширено обсъждане на надеждността и

наличността, урок за RAID с описание на схемите RAID 6 и статистика за рядко срещани грешки на
реални системи. Той продължава да предоставя въведение в теорията на опашките и I/O
производителност. Ние оценяваме цената, производителността и надеждността на истински
клъстер: Интернет архив. Примерът „Putting It All Together“ е файлът NetApp FAS6000.
Приложение E, от Томас М. Конт, консолидира вградения материал на едно място.
Приложение F, относно мрежите за взаимно свързване, е преработено от Тимъти М.

Пинкстън и Хосе Дуато. Приложение G, написано първоначално от Крсте Асанович, включва
описание на векторни процесори. Смятаме, че тези две приложения са едни от най-добрите
материали, които познаваме по всяка тема.
Приложение H описва VLIW и EPIC, архитектурата на Itanium.
Приложение I описва приложения за паралелна обработка и протоколи за съгласуваност за
по-мащабна мултипроцесорна обработка със споделена памет. Приложение J, от David Gold-berg,
описва компютърна аритметика.
Приложение L събира „Историческа перспектива и препратки“ от всяка глава в едно
приложение. Опитва се да отдаде подходящ кредит на идеите във всяка глава и усещане за
историята около изобретенията. Обичаме да мислим за това като за представяне на човешката
драма на компютърния дизайн. Той също така предоставя препратки, които студентът по
архитектура може да иска да преследва. Ако имате време, препоръчваме да прочетете някои от
класическите статии в областта, които са споменати в тези раздели. И приятно, и образователно
е да чуеш идеите директно от създателите. „Историческа перспектива“ беше един от най-
популярните раздели на предишни издания.
Навигация в текста
Няма единен най-добър ред, в който да се подходи към тези глави и приложения, освен че всички
читатели трябва да започнат с Глава 1. Ако не искате да прочетете всичко, ето някои предложени
последователности:
Йерархия на паметта: Приложение B, Глава 2 и Приложение D. Паралелизъм
на ниво инструкции: Приложение C, Глава 3 и Приложение H Паралелизъм на ниво
данни: Глави 4 и 6, Приложение G Паралелизъм на ниво нишка:
Глава 5 , Приложения F и I Паралелизъм на ниво заявка: Глава 6 ISA:
Приложения A и K
Приложение E може да се чете по всяко време, но може да работи най-добре, ако се чете след ISA
и кеш последователностите. Приложение J може да се чете винаги, когато аритметиката ви движи.
Трябва да прочетете съответната част от Приложение L, след като завършите всяка глава.
xx Предговор
Структура на главата
Избраният от нас материал е опънат върху последователна рамка, която се следва във всяка
глава. Започваме с обяснение на идеите на дадена глава.
Тези идеи са последвани от раздел „Взаимосвързани въпроси“, функция, която показва как
идеите, обхванати в една глава, взаимодействат с тези, дадени в други глави.
Това е последвано от раздел „Сглобяване на всичко“, който обединява тези идеи, като показва
как се използват в реална машина.
Следващата в поредицата е „Заблуди и капани“, която позволява на читателите да се учат
от грешките на другите. Показваме примери за често срещани недоразумения и архитектурни
капани, които е трудно да се избегнат, дори когато знаете, че ви дебнат. Разделът „Заблуди и
клопки“ е един от най-популярните раздели на книгата. Всяка глава завършва с раздел
„Заключителни бележки“.
Казуси с упражнения
Всяка глава завършва с казуси и съпътстващи упражнения. Създадени от експерти в индустрията

и академичните среди, казусите изследват ключови концепции в главите и проверяват
разбирането чрез все по-предизвикателни упражнения. Инструкторите трябва да намерят
казусите за достатъчно подробни и стабилни, за да им позволят да създават свои собствени
допълнителни упражнения.
Скобите за всяко упражнение (<chapter.section>) показват текстовите секции от

първостепенно значение за завършване на упражнението. Надяваме се, че това помага на
читателите да избягват упражнения, за които не са прочели съответния раздел, в допълнение
към предоставянето на източника за преглед. Упражненията се оценяват, за да дадат на
читателя представа за времето, необходимо за изпълнение на дадено упражнение:
[10] По-малко от 5 минути (за четене и разбиране) [15] 5–
15 минути за пълен отговор [20] 15–20
минути за пълен отговор [25] 1 час за
пълен писмен отговор
[30] Кратък програмен проект: по-малко от 1 пълен ден програмиране
[40] Значителен програмен проект: 2 седмици изминало време
[Дискусия] Тема за обсъждане с други
Решенията на казусите и упражненията са достъпни за инструктори, които
регистрирайте се на textbooks.elsevier.com.
Допълнителни материали
Разнообразие от ресурси са достъпни онлайн на http://booksite.mkp.com/9780123838728/,

включително следното:
Предговор xxi
Справочни приложения—някои гостуващи автори от експерти по темата—покриващи a

набор от теми за напреднали
Материал от исторически перспективи, който изследва развитието на ключовите идеи,

представени във всяка от главите на текста
Слайдове на инструктора в PowerPoint
Фигури от книгата във формати PDF, EPS и PPT
Връзки към свързани материали в мрежата
Списък с грешки
Ще има нови материали и връзки към други ресурси, достъпни в мрежата
добавяни редовно.
Помощ за подобряване на тази книга
И накрая, възможно е да правите пари, докато четете тази книга. (Говорете за цена-
производителност!) Ако прочетете благодарностите, които следват, ще видите, че положихме
много усилия, за да коригираме грешките. Тъй като една книга преминава през много
печатания, имаме възможност да правим още повече корекции. Ако откриете оставащи
устойчиви грешки, моля, свържете се с издателя по електронна поща (ca5bugs@mkp.com).
Приветстваме общи коментари към текста и ви каним да ги изпратите на a

отделен имейл адрес на ca5comments@mkp.com.
Заключителни бележки
Още веднъж тази книга е истинско съавторство, като всеки от нас пише половината от главите
и равен дял от приложенията. Не можем да си представим колко време щеше да отнеме без
някой друг да свърши половината работа, да предложи вдъхновение, когато задачата
изглеждаше безнадеждна, да предостави ключовото прозрение за обяснение на трудна
концепция, да предостави прегледи през уикенда на главите и да съчувства, когато тежестта от
другите ни задължения ни беше трудно да вземем писалката. (Тези задължения са ескалирали
експоненциално с броя на изданията, както свидетелстват биографиите.) Така отново
споделяме поравно вината за това, което ще прочетете.
Джон Хенеси Дейвид Патерсън


Благодарности 1
Въпреки че това е едва петото издание на тази книга, ние всъщност създадохме десет
различни версии на текста: три версии на първото издание (алфа, бета и окончателно) и
две версии на второ, трето и четвърто издание (бета и окончателно).
По пътя получихме помощ от стотици рецензенти и потребители.
Всеки от тези хора е помогнал тази книга да стане по-добра. Затова избрахме да изброим
всички хора, които са дали принос за някоя версия на тази книга.
Сътрудници на петото издание
Подобно на предишните издания, това е усилие на общността, което включва десетки доброволци.
Без тяхната помощ това издание нямаше да е толкова изпипано.
Рецензенти
Джейсън Д. Бакос, Университет на Южна Каролина; Даяна Франклин, Калифорнийският

университет, Санта Барбара; Norman P. Jouppi, HP Labs; Грегъри Питърсън, Университет
на Тенеси; Parthasarathy Ranganathan, HP Labs; Марк Smotherman, университет Клемсън;
Гуриндар Сохи, Университет на Уисконсин–Медисън; Матео Валеро, Политехнически
университет на Каталуня; Сотириос Г. Зиаврас, Технологичен институт в Ню Джърси
Членове на Калифорнийския университет – Бъркли Par Lab и RAD Lab, които дадоха чести
прегледи на Глава 1, 4 и 6 и оформиха обяснението на
Графични процесори и WSC: Крсте Асанович, Майкъл Армбруст, Скот Биймър, Сара Бърд,
Брайън Катандзаро, Джике Чонг, Хенри Кук, Дерик Кутзи, Ранди Кац, Юн-суп Лий, Лео
Майервич, Марк Мърфи, Джанси Тан, Василий Волков и Андрю
Waterman
Консултативен панел
Луис Андре Барозу, Google Inc.; Робърт П. Колуел, R&E Colwell & Assoc.
Inc.; Krisztian Flautner, вицепрезидент на R&D в ARM Ltd.; Мери Джейн Ъруин, Пен Стейт;
xxiii
xxiv Благодарности
Дейвид Кърк, NVIDIA; Грант Мартин, главен учен, Tensilica; Гуриндар Сохи,
Университет на Уисконсин–Медисън; Матео Валеро, Universidad Politécnica de
Каталуния
Приложения
Крсте Асанович, Калифорнийски университет, Бъркли (Приложение G); Томас М.

Conte, Държавен университет на Северна Каролина (Приложение E); José Duato, Universitat
Politècnica de València и Simula (Приложение F); Дейвид Голдбърг, Xerox PARC (Приложение
J); Тимъти М. Пинкстън, Университет на Южна Калифорния (Приложение F)
José Flich от Universidad Politécnica de Valencia предостави значителен принос за

актуализирането на Приложение F.
Джейсън Д. Бакос, Университет на Южна Каролина (глави 3 и 4); Даяна Франклин,

Калифорнийски университет, Санта Барбара (Глава 1 и Приложение В); Норман П.
Jouppi, HP Labs (Глава 2); Naveen Muralimanohar, HP Labs (Глава 2); Грегъри Питърсън,
Университет на Тенеси (Приложение А); Parthasarathy Ranga-nathan, HP Labs (Глава 6); Амр
Заки, Университет на Санта Клара (Глава 5 и Приложение Б)
Jichuan Chang, Kevin Lim и Justin Meza помогнаха при разработването и тестването на
казусите и упражненията за глава 6.
Допълнителен материал
Джон Никълс, Стив Кеклър и Майкъл Токсвиг от NVIDIA (Глава 4

графични процесори NVIDIA); Виктор Лий, Intel (Глава 4 сравнение на Core i7 и GPU);
Джон Шалф, LBNL (Глава 4 скорошни векторни архитектури); Сам Уилямс, LBNL
(Модел Roofline за компютри в Глава 4); Стив Блекбърн от Австралия
Национален университет и Катрин Маккинли от Тексаския университет в Остин
(Измервания на производителността и мощността на Intel в Глава 5); Луис Барозу, Урс
Хьолцле, Джими Клидарис, Боб Фелдерман и Крис Джонсън от Google (
Google WSC в глава 6); Джеймс Хамилтън от Amazon Web Services (разпределение на
мощността и модел на разходите в глава 6)
Джейсън Д. Бакос от Университета на Южна Каролина разработи новото

лекционни слайдове за това издание.
И накрая, специални благодарности още веднъж на Марк Смодърман от университета

Клемсън, който даде окончателно техническо четене на нашия ръкопис. Марк откри
множество грешки и неясноти и в резултат на това книгата е много по-чиста.
Тази книга не би могла да бъде издадена без издател, разбира се. Искаме да благодарим
на целия персонал на Morgan Kaufmann/Elsevier за техните усилия и подкрепа.
За това пето издание искаме специално да благодарим на нашите редактори Nate McFadden
Благодарности xxv
и Тод Грийн, който координира проучванията, консултативния панел, разработването на

казуси и упражнения, фокус групи, прегледи на ръкописи и актуализиране на
приложенията.
Трябва да благодарим и на екипа на нашия университет Маргарет Роуланд и Роксана
Infante, за безброй експресни изпращания, както и за задържането на крепостта при
Станфорд и Бъркли, докато работихме по книгата.
Последните ни благодарности са на нашите съпруги за тяхното страдание през все по-ранните години
сутрини на четене, мислене и писане.
Сътрудници на предишни издания
Рецензенти
Джордж Адамс, Университет Пърдю; Сарита Адве, Университет на Илинойс в Урбана–

Шампанско; Джим Арчибалд, Университет Бригъм Йънг; Крсте Асанович, Маса Чузетски
технологичен институт; Jean-Loup Baer, Университет на Вашингтон; Пол
Бар, Североизточен университет; Раджендра В. Бопана, Тексаски университет, Сан
Антонио; Марк Брехоб, Университет на Мичиган; Дъг Бъргър, Тексаски университет,
Остин; Джон Бъргър, SGI; Майкъл Бътлър; Томас Казавант; Рохит Чандра; Петър
Чен, Университет на Мичиган; класовете в SUNY Stony Brook, Carnegie Mel-lon, Stanford,
Clemson и Wisconsin; Тим Коу, Vitesse Semiconductor; Робърт
П. Колуел; Дейвид Къмингс; Бил Дали; Дейвид Дъглас; Хосе Дуато, Университет
Politècnica de València и Simula; Антъни Дубен, Югоизточен щат Мисури
Университет; Сюзън Егърс, Вашингтонски университет; Джоел Емер; Бари Фейгин, Dart-
mouth; Джоел Фъргюсън, Калифорнийски университет, Санта Круз; Карл Файнман; Дейвид
Фило; Джош Фишър, Hewlett-Packard Laboratories; Роб Фаулър, DIKU; Марк Франк-лин,
Вашингтонски университет (Сейнт Луис); Курош Гарачорлоо; Николас Глой, Харвардски
университет; Дейвид Голдбърг, Xerox Palo Alto Research Center; Антонио
González, Intel и Universitat Politècnica de Catalunya; Джеймс Гудман, Университет на
Уисконсин–Медисън; Sudhanva Gurumurthi, Университет на Вирджиния; Дейвид
Харис, Harvey Mudd College; Джон Хайнлайн; Марк Хайнрих, Станфорд; Даниел
Хелман, Калифорнийски университет, Санта Круз; Марк Д. Хил, Университет на Уискон-
син-Медисън; Мартин Хопкинс, IBM; Джери Хък, Hewlett-Packard Laboratories;
Wen-mei Hwu, Университет на Илинойс в Урбана-Шампейн; Мери Джейн Ъруин,
Пенсилвански държавен университет; Труман Джо; Норм Жупи; Дейвид Каели, Northeast-
ern University; Роджър Кикхафер, Университет на Небраска; Лев Г. Киришчян,
Университет Райърсън; Ърл Килиан; Алън Найс, Университет Пърдю; Дон Кнут; Джеф
Кускин, Станфорд; Джеймс Р. Ларус, Microsoft Research; Корина Лий, Университет на
Торонто; Ханк Леви; Кай Ли, Принстънски университет; Лори Либрок, Университет на
Аляска, Феърбанкс; Мико Липасти, Университет на Уисконсин–Медисън; Гюла А.
Маго, Университет на Северна Каролина, Чапъл Хил; Брайън Мартин; Норман Матлоф;
Дейвид Майер; Уилям Михалсън, Политехнически институт Уорчестър; Джеймс Муни;
Тревър Мъдж, Университет на Мичиган; Рамадас Нагараджан, Тексаски университет
в Остин; Дейвид Нейгъл, Университет Карнеги Мелън; Тод Нартър; Виктор Нелсън;
Vojin Oklobdzija, Калифорнийски университет, Бъркли; Кунле Олукотун, Станфорд
Университет; Боб Оуенс, Пенсилвански държавен университет; Грег Пападапулус, Sun
xxvi Благодарности
микросистеми; Джоузеф Пфайфър; Кешав Пингали, Университет Корнел; Тимъти М.

Пинкстън, Университет на Южна Калифорния; Бруно Прайс, Университет Ватерло;
Стивън Пшибилски; Джим Куинлан; Андраш Радич; Кишор Рамачандран, Джорджия
технологичен институт; Джоузеф Раме, Тексаски университет, Остин; Антъни
Рийвс, Университет Корнел; Ричард Рийд, Мичигански държавен университет; Стив Рейн-хард,
Университет на Мичиган; Дейвид Ренълс, Калифорнийски университет, Лос Анджелес; Арнолд
Л. Розенберг, Университет на Масачузетс, Амхърст; Каушик Рой,
Университет Пърдю; Емилио Салгейро, Unysis; Karthikeyan Sankaralingam, Тексаски университет
в Остин; Питър Шнорф; Марго Зелцер; Бехруз Ширази, Южен
Методистки университет; Daniel Siewiorek, Университет Карнеги Мелън; JP Singh,
Принстън; Ашок Сингхал; Джим Смит, Университет на Уисконсин–Медисън; Майк
Смит, Харвардски университет; Марк Smotherman, университет Клемсън; Гуриндар
Сохи, Университет на Уисконсин-Медисън; Арун Сомани, Университет на Вашингтон;
Джийн Талиарин, Университет Клемсън; Shyamkumar Thoziyoor, Университет на Нотр
дама; Евън Тик, Университет на Орегон; Akhilesh Tyagi, Университет на Северна Каролина,
Chapel Hill; Дан Ъптън, Университет на Вирджиния; Матео Валеро, Универсидад
Politécnica de Cataluña, Барселона; Ануджан Варма, Калифорнийски университет, Дядо Коледа
Круз; Торстен фон Айкен, Университет Корнел; Ханк Уокър, Тексас A&M; Рой
Искам, Xerox Palo Alto Research Center; Дейвид Уивър, Sun Microsystems;
Шломо Вайс, Университет в Тел Авив; Дейвид Уелс; Майк Уестъл, университет Клемсън; Морис
Уилкс; Ерик Уилямс; Томас Уилис, Университет Пърдю; Малкълм
крило; Лари Уити, SUNY Stony Brook; Елън Уите Зегура, Институт на Джорджия
технология; Сотириос Г. Зиаврас, Технологичен институт в Ню Джърси
Приложения
Векторното приложение беше преработено от Крсте Асанович от Масачузетския технологичен

институт. Приложението с плаваща запетая е написано първоначално от Дейвид
Голдбърг от Xerox PARC.
Упражнения
Джордж Адамс, Университет Пърдю; Тод М. Безенек, Университет на Уисконсин–

Мадисън (в памет на баба му Етел Ешом); Сюзън Егърс; Ануп
Гупта; Дейвид Хейс; Марк Хил; Алън Найс; Итън Л. Милър, Университет на Калифорния, Санта
Круз; Parthasarathy Ranganathan, Compaq Western Research Labor-atory; Брандън Шварц,
Университет на Уисконсин–Медисън; Майкъл Скот; Дан
Siewiorek; Майк Смит; Марк Смътърман; Евън Тик; Томас Уилис
Andrea C. Arpaci-Dusseau, Университет на Уисконсин–Медисън; Remzi H. Arpaci-Dusseau,

Университет на Уисконсин–Медисън; Робърт П. Колуел, R&E Colwell &
Assoc., Inc.; Даяна Франклин, Калифорнийски политехнически държавен университет, Сан Луис
Обиспо; Wen-mei W. Hwu, Университет на Илинойс в Урбана-Шампейн; Норман
P. Jouppi, HP Labs; Джон У. Сиас, Университет на Илинойс в Урбана-Шампейн;
Дейвид А. Ууд, Университет на Уисконсин–Медисън
Благодарности xxvii
Специални благодарности
Дуейн Адамс, Агенция за напреднали изследователски проекти на отбраната; Том

Адамс; Сарита Адве, Университет на Илинойс в Урбана-Шампейн; Анант Агарвал;
Дейв Албонеси, Университет на Рочестър; Мич Алсуп; Хауърд Алт; Дейв Андерсън;
Питър Ашендън; Дейвид Бейли; Бил Банди, Агенция за напреднали изследователски
проекти на отбраната; Луис Барозу, Западна изследователска лаборатория на
Compaq; Анди Бехтолсхайм; К. Гордън Бел; Фред Берковиц; Джон Бест, IBM; Дилип
Бхандаркар; Джеф Биър, BDTI; Марк Бирман; Дейвид Блек; Дейвид Богс; Джим
Брейди; Форест Брюър; Арън Браун, Калифорнийски университет, Бъркли; E.
Bugnion, Западна изследователска лаборатория на Compaq; Alper Buyuk-tosunoglu,
Университет на Рочестър; Марк Калахан; Джейсън Ф. Кантин; Пол Карик; Чен-Чунг
Чанг; Лей Чен, Университет на Рочестър; Пийт Чен; Нхан Чу; Дъг Кларк, Принстънски
университет; Боб Кмелик; Джон Крауфорд; Зарка Цветанович; Майк Далин, Тексаски
университет, Остин; Мерик Дарли; персоналът на DEC Western Research Laboratory;
Джон ДеРоза; Лойд Дикман; J. Ding; Сюзън Егерс, Вашингтонски университет; Wael
El-Essawy, Университет на Рочестър; Пати Енрикес, Милс; Милош Ерцеговац; Робърт
Гарнър; K. Gharachorloo, Западна изследователска лаборатория на Compaq; Гарт
Гибсън; Роналд Грийнбърг; Бен Хао; Джон Хенинг, Compaq; Марк Хил, Университет
на Уисконсин–Медисън; Дани Хилис; Дейвид Ходжис; Урс Хьолцле, Google; Дейвид
Хаф; Ед Хъдсън; Крис Хюз, Университет на Илинойс в Урбана-Шампейн; Марк
Джонсън; Луис Джордан; Норм Жупи; Уилям Кахан; Ранди Кац; Ед Кели; Ричард
Кеслер; Лес Кон; Джон Ковалески, Compaq Computer Corp; Дан Ламбрайт; Гари
Лаутербах, Sun Microsystems; Корина Лий; Руби Лий; Дон Люайн; Чао-Хуанг Лин; Пол
Лослебен, Агенция за напреднали изследователски проекти на отбраната; Юнг-Сянг
Лу; Боб Лукас, Агенция за напреднали изследователски проекти на отбраната; Кен
Луц; Alan Mainwaring, Intel Berkeley Research Labs; Ал Марстън; Рич Мартин, Рутгерс;
Джон Маши; Люк Макдауъл; Себастиан Мироло, Trimedia Corporation; Рави Мърти;
Бисуадип Наг; Лиза Ноордграаф, Sun Microsystems; Боб Паркър, Агенция за
напреднали изследователски проекти на отбраната; Върн Паксън, Център за
интернет изследвания; Лорънс Принс; Стивън Пшибилски; Марк Пулън, Агенция за
напреднали изследователски проекти на отбраната; Крис Роуен; Маргарет Роуланд;
Грег Семераро, Университет на Рочестър; Бил Шан-нон; Бехроз Ширази; Робърт
Шомлер; Джим Слейгър; Марк Smotherman, университет Клемсън; изследователската
група за SMT във Вашингтонския университет; Стив Скуайърс, Агенция за
напреднали изследователски проекти на отбраната; Аджай Срикант; Дарън
Стейпълс; Чарлз Стапър; Хорхе Столфи; Питър Стол; студентите в Станфорд и
Бъркли, които издържаха първите ни опити да създадем тази книга; Боб Супник;
Стив Суонсън; Пол Тейсъм; Шрикант Таккар; Александър Томасян, Технологичен
институт в Ню Джърси; Джон Тул, Агенция за напреднали изследователски проекти
на отбраната; Kees A. Vissers, Trimedia Corporation; Уила Уокър; Дейвид Уивър; Рик Уилър, EMC
Джон Хенеси Дейвид Патерсън

1.1 Въведение 2
1.2 Класове по компютри 5
1.3 Дефиниране на компютърна архитектура 11
1.5 Тенденции в мощността и енергията в интегралните схеми 21
1.6 Тенденции в разходите 27
1.7 Надеждност 33
1.8 Измерване, отчитане и обобщаване на ефективността 36
1.9 Количествени принципи на компютърния дизайн 44
1.10 Събирайки всичко заедно: производителност, цена и мощност 52
1.11 Заблуди и клопки 55
1.12 Заключителни бележки 59
1.13 Исторически перспективи и препратки 61

1
Основи на количественото
Проектиране и анализ 1
Мисля, че е справедливо да се каже, че персоналните компютри са се превърнали в най-
овластяващия инструмент, който някога сме създавали. Те са инструменти за комуникация,
те са инструменти за творчество и могат да бъдат оформени от своя потребител.
Бил Гейтс, 24 февруари 2004 г
Компютърна архитектура. DOI: 10.1016/B978-0-12-383872-8.00002-1

2 Първа глава Основи на количествения дизайн и анализ
1.1 Въведение
Компютърните технологии постигнаха невероятен напредък през приблизително 65 години оттогава

е създаден първият електронен компютър с общо предназначение. Днес по-малко от $500
ще закупи мобилен компютър, който има повече производителност, повече основна памет,
и повече дисково пространство от компютър, закупен през 1985 г. за 1 милион долара. Този бърз
подобрението идва както от напредъка в технологията, използвана за изграждане на компютри, така
и от иновациите в компютърния дизайн.
Въпреки че технологичните подобрения са сравнително стабилни, напредъкът, произтичащ от
по-добрите компютърни архитектури, е много по-малко последователен. По време на
първите 25 години на електронните компютри и двете сили имаха голям принос,
осигурявайки подобрение на производителността с около 25% на година. В края на 70-те години видях
появата на микропроцесора. Способността на микропроцесора да кара
подобренията в технологията на интегралните схеми доведоха до по-висок процент на подобрение
на производителността - приблизително 35% ръст на година.
Този темп на растеж, съчетан с ценовите предимства на масовото производство
микропроцесор, доведе до нарастваща част от компютърния бизнес
на базата на микропроцесори. В допълнение, две значителни промени в компютъра
marketplace направи по-лесно от всякога постигането на търговски успех с нов
архитектура. Първо, виртуалното премахване на програмирането на асемблер
намали необходимостта от съвместимост на обектния код. Второ, създаването на стандартизирани,
независими от доставчика операционни системи, като UNIX и неговия клонинг Linux,
намали цената и риска от извеждането на нова архитектура.
Тези промени направиха възможно успешното разработване на нов набор от архитектури с по-
прости инструкции, наречен RISC (компютър с намален набор от инструкции)
архитектури, в началото на 80-те години. Машините, базирани на RISC, фокусираха вниманието
на дизайнерите относно две критични техники за изпълнение, използването на паралелизъм на
ниво инструкции (първоначално чрез конвейер и по-късно чрез множество инструкции
проблем) и използването на кешове (първоначално в прости форми и по-късно с помощта на по-
сложни организации и оптимизации).
Базираните на RISC компютри вдигнаха летвата на производителността, принуждавайки
предишните архитектури да поддържат темпото или да изчезнат. Цифровото оборудване Vax не можа и така
беше заменен от RISC архитектура. Intel се справи с предизвикателството, главно чрез
вътрешно превеждане на инструкции 80x86 в инструкции, подобни на RISC, което го позволява
да приеме много от иновациите, въведени за първи път в дизайна на RISC. Тъй като броят на
транзисторите скочи в края на 90-те години, хардуерните разходи за превод стават все по-
сложната x86 архитектура стана незначителна. В приложения от нисък клас, като напр
клетъчни телефони, разходите за енергия и силиконовата област на режийните разходи за x86-превод
помогна да се стигне до доминиране на RISC архитектура, ARM.
Фигура 1.1 показва, че комбинацията от архитектурни и организационни
подобренията доведоха до 17 години устойчив растеж на представянето на годишна база
процент от над 50% - процент, който е безпрецедентен в компютърната индустрия.
Ефектът от този драматичен темп на растеж през 20-ти век е четирикратен.
Първо, той значително подобри възможностите, достъпни за компютърните потребители. За
много приложения, днешните микропроцесори с най-висока производителност превъзхождат
суперкомпютъра отпреди по-малко от 10 години.
100 000
Intel Xeon 6 ядра, 3,3 GHz (ускоряване до 3,6 GHz)

Intel Xeon 4 ядра, 3,3 GHz (ускоряване до 3,6 GHz)
Intel Core i7 Extreme 4 ядра 3,2 GHz (усилване до 3,5 GHz) 24,129
Intel Core Duo Extreme 2 ядра, 3.0 GHz
Intel Core 2 Extreme 2 ядра, 2,9 GHz AMD
10 000 Athlon 64, 2,8 GHz AMD
Athlon, 2,6 GHz
11,86514,38719,48421,871
Intel Xeon EE 3,2 GHz 7,108
Дънна платка Intel D850EMVR (3,06 GHz, процесор Pentium 4 с технология Hyper-Threading) 6,043 6,681
4195
IBM Power4, 1,3 GHz
3016
Intel VC820 дънна платка, 1.0 GHz Pentium III процесор
1779
Професионална работна станция XP1000, 667 MHz 21264A
1267
1000 Цифров AlphaServer 8400 6/575, 575 MHz 21264
993
AlphaServer 4000 5/600, 600 MHz 21164
649
Digital Alphastation 5/500, 500 MHz
481
AсП
р
оXп V(
Digital Alphastation 5/300, 300 MHz

0д
тсонлет)и 8о я-р
1з1и
7о/вм
280 22%/година
Digital Alphastation 4/266, 266 MHz 183
IBM POWERstation 100, 150 MHz
100 117
Цифров 3000 AXP/500, 150 MHz 80
HP 9000/750, 66 MHz
51
IBM RS6000/540, 30 MHz 24 52%/година

MIPS M2000, 25 MHz
18
MIPS M/120, 16,7 MHz
13
10 Sun-4/260, 16,7 MHz 9
VAX 8700, 22 MHz 5
AX-11/780, 5 MHz
25%/година 1.5, VAX-11/785

1
1 1978 1980 1982 1984 1986 1988 1990 1992 1994 1996 1998 2000 2002 2004 2006 2008 2010 2012
Фигура 1.1 Ръст в производителността на процесора от края на 70-те години. Тази диаграма показва производителността по отношение
на VAX 11/780, измерена от SPEC бенчмарковете (вижте раздел 1.8). Преди средата на 80-те години на миналия век ръстът на
производителността на процесорите беше до голяма степен обусловен от технологиите и беше средно около 25% годишно.
Увеличението на растежа до около 52% оттогава се дължи на по-напредналите архитектурни и организационни идеи. До 2003 г. този
растеж доведе до разлика в представянето от около коефициент 25 в сравнение с това, ако бяхме продължили със скорост от 25%.
Производителността за изчисления, ориентирани към плаваща запетая, се увеличи още по-бързо. От 2003 г. ограниченията на
мощността и наличния паралелизъм на ниво инструкции забавиха еднопроцесорната производителност до не повече от 22% годишно,
или около 5 пъти по-бавно, отколкото ако продължихме с 52% годишно. (Най-бързата производителност на SPEC от 2007 г. включва
автоматично паралелизиране с нарастващ брой ядра на чип всяка година, така че скоростта на еднопроцесорния процесор е по-
трудна за измерване. Тези резултати са ограничени до системи с един сокет, за да се намали въздействието на автоматичното
паралелизиране. ) Фигура 1.11 на страница 24 показва подобрението на тактовите честоти за същите тези три ери. Тъй като SPEC се
промени през годините, производителността на по-новите машини се оценява чрез коефициент на мащабиране, който свързва
производителността за две различни версии на SPEC (напр. SPEC89, SPEC92, SPEC95, SPEC2000 и SPEC2006).
Второ, това драматично подобрение на разходите и производителността води до нови

класове компютри. Персоналните компютри и работните станции се появяват през 80-те
години на миналия век с наличието на микропроцесора. Последното десетилетие видя
възхода на смарт клетъчните телефони и таблетните компютри, които много хора
използват като свои основни компютърни платформи вместо компютри. Тези мобилни
клиентски устройства все повече използват интернет за достъп до складове, съдържащи
десетки хиляди сървъри, които са проектирани така, сякаш са един-единствен гигантски компютър.
Трето, продължаващото усъвършенстване на производството на полупроводници,
както е предсказано от закона на Мур, доведе до господството на базираните на
микропроцесори компютри в цялата гама компютърен дизайн. Миникомпютри, които бяха
традиционно направени от готова логика или от гейт масиви, бяха заменени от

сървъри, направени с помощта на микропроцесори. Дори мейнфрейм компютрите и
високопроизводителните суперкомпютри са набор от микропроцесори.
Хардуерните иновации по-горе доведоха до ренесанс в компютърния дизайн,
който наблегна както на архитектурните иновации, така и на ефективното използване на технологиите
подобрения. Този темп на растеж се усложни, така че до 2003 г. високопроизводителните микропроцесори
бяха 7,5 пъти по-бързи от това, което биха били
получени чрез разчитане единствено на технология, включително подобрен дизайн на веригата; че
е 52% на година срещу 35% на година.
Този хардуерен ренесанс доведе до четвъртото въздействие, което е върху софтуера

развитие. Това 25 000-кратно подобрение на производителността от 1978 г. насам (вж
Фигура 1.1) позволява на програмистите днес да търгуват с производителност за производителност. в
на мястото на ориентирани към производителността езици като C и C++, много повече програмиране днес
се извършва в управлявани езици за програмиране като Java и C#. Нещо повече, скриптови езици като
Python и Ruby, които са още по-продуктивни,
набират популярност заедно с програмните рамки като Ruby on
Релси. За да поддържате производителността и да се опитате да преодолеете разликата в производителността, преводачи
с компилатори точно навреме и базирано на проследяване компилиране заменят традиционните

компилатор и линкер от миналото. Внедряването на софтуер също се променя,
със софтуер като услуга (SaaS), използван през интернет, заместващ пакетиран софтуер, който трябва да
бъде инсталиран и стартиран на локален компютър.
Естеството на приложенията също се променя. Реч, звук, изображения и видео
стават все по-важни, заедно с предвидимото време за реакция, т.е
толкова критични за потребителското изживяване. Вдъхновяващ пример е Google Goggles. Това
приложението ви позволява да вдигнете мобилния си телефон, за да насочите камерата му към обект и
изображението се изпраща безжично по интернет до компютър от складов мащаб, който
разпознава обекта и ви съобщава интересна информация за него. Може
превежда текст върху обекта на друг език; прочетете баркода на корицата на книга
да ви кажем дали дадена книга е достъпна онлайн и нейната цена; или, ако се насладите на ерата на
телефонната камера, ще ви каже какви фирми има наблизо, заедно с техните уебсайтове, телефонни
номера и упътвания.
Уви, Фигура 1.1 също показва, че този 17-годишен хардуерен ренесанс приключи.
От 2003 г. подобрението на производителността на един процесор е спаднало до по-малко от
22% на година поради двойното препятствие на максималното разсейване на мощността на чиповете с
въздушно охлаждане и липсата на повече паралелизъм на ниво инструкции, който да се използва
ефективно. Всъщност през 2004 г. Intel отмени своите проекти за високопроизводителни еднопроцесорни процесори
и се присъедини към други в декларацията, че пътят към по-висока производителност ще бъде през
множество процесори на чип, а не чрез по-бързи еднопроцесорни процесори.
Този крайъгълен камък сигнализира за историческо преминаване от разчитане единствено на
паралелизъм на ниво инструкции (ILP), основният фокус на първите три издания на тази книга,
към паралелизъм на ниво данни (DLP) и паралелизъм на ниво нишка (TLP), които бяха
включен в четвъртото издание и разширен в това издание. Това издание също добавя
складови компютри и паралелизъм на ниво заявка (RLP). като има предвид, че
компилаторът и хардуерът заговорничат да използват ILP имплицитно без вниманието на програмиста,
DLP, TLP и RLP са изрично паралелни, изисквайки
1.2 Класове компютри 5
преструктуриране на приложението, така че да може да използва явен паралелизъм. В някои

случаи, това е лесно; в много от тях това е голямо ново бреме за програмистите.
Този текст е за архитектурните идеи и съпътстващия компилатор
подобрения, които направиха възможен невероятният темп на растеж през миналия век,
причините за драматичната промяна и предизвикателствата и първоначалните обещания
подходи към архитектурните идеи, компилатори и интерпретатори за 21 век.
В основата е количествен подход към компютърния дизайн и анализ, който използва
емпирични наблюдения на програми, експериментиране и симулация като негови инструменти.
Именно този стил и подход към компютърния дизайн са отразени в този текст. The
целта на тази глава е да постави количествената основа, на която се основават следващите
глави и приложения.
Тази книга е написана не само за да обясни този стил на проектиране, но и за да ви
стимулира да допринесете за този напредък. Вярваме, че този подход ще работи за
изрично паралелни компютри на бъдещето точно както работеше за имплицитно паралелните
компютри от миналото.
1.2 Класове по компютри
Тези промени поставиха началото на драматична промяна в начина, по който гледаме на

компютрите, компютърните приложения и компютърните пазари в този нов век. Не
от създаването на персоналния компютър сме виждали такива драматични промени
в начина, по който се появяват компютрите и в това как се използват. Тези промени в
използването на компютри доведоха до пет различни компютърни пазара, всеки от които се
характеризира с различни приложения, изисквания и компютърни технологии. Фигура 1.2
обобщава тези основни класове компютърни среди и техните
важни характеристики.
Лично
Клъстери/складови
Особеност мобилно устройство работен плот сървър Вграден
компютри
(PMD)
Цена на $100–$1000 $300–$2500 $5000–$10 000 000 $100 000–$200 000 000 $10–$100 000
системата
Цена на $10–$100 $50–$500 $200 – $2000 $50–$250 $0,01–$100

микро-
процесор
Критични
Цена, енергия, Цена- Пропускателна Цена-производителност, Цена, енергия,
проблеми
медийно производителност, способност, производителност, производителност,
при представяне, енергия, енергийна пропорционалност
достъпност, мащабируемост, енергия специфична за приложението
отзивчивост
проектирането на системата
графична
производителност
Фигура 1.2 Обобщение на петте основни компютърни класа и техните системни характеристики. Продажбите през 2010г
включва около 1,8 милиарда PMD (90% мобилни телефони), 350 милиона настолни компютри и 20 милиона сървъри. Общият брой
от продадените вградени процесори е близо 19 милиарда. Бяха доставени общо 6,1 милиарда чипове, базирани на ARM технология
2010. Обърнете внимание на широкия диапазон в системните цени за сървъри и вградени системи, които преминават от USB ключове до мрежа
рутери. За сървърите този диапазон възниква от необходимостта от много големи многопроцесорни системи за висок клас
обработка на транзакции.
Персонално мобилно устройство (PMD)
Персонално мобилно устройство (PMD) е терминът, който прилагаме за колекция от безжични устройства
устройства с мултимедиен потребителски интерфейс като мобилни телефони, таблетни компютри,
и така нататък. Цената е основна грижа, като се има предвид, че потребителската цена за целия продукт е
няколкостотин долара. Въпреки че акцентът върху енергийната ефективност често се дължи на използването
на батерии, необходимостта от използване на по-евтини опаковки -
пластмаса срещу керамика - и липсата на вентилатор за охлаждане също ограничава общото количество
консумация на енергия. Разглеждаме въпроса за енергията и мощността по-подробно в
Раздел 1.5. Приложенията на PMD често са уеб базирани и медийно ориентирани, като например
примерът на Google Goggles по-горе. Изискванията за енергия и размер водят до използването на
Флаш памет за съхранение (Глава 2) вместо магнитни дискове.
Отзивчивостта и предвидимостта са ключови характеристики за медийните приложения. Изискване за
производителност в реално време означава сегмент от приложението
има абсолютно максимално време за изпълнение. Например, при възпроизвеждане на видео на a
PMD, времето за обработка на всеки видеокадър е ограничено, тъй като процесорът трябва
приемете и обработете следващия кадър скоро. В някои приложения, по-нюансиран
съществува изискване: средното време за конкретна задача също е ограничено

като броя на случаите, когато е надвишено някакво максимално време. Такива
Подходите - понякога наричани меко реално време - възникват , когато е възможно от време на време да се
пропусне ограничението във времето за дадено събитие, стига да не бъдат пропуснати твърде много.
Производителността в реално време обикновено зависи силно от приложението.
Други ключови характеристики в много PMD приложения са необходимостта от минимизиране
паметта и необходимостта от ефективно използване на енергията. Енергийната ефективност се ръководи от
мощност на батерията и разсейване на топлината. Паметта може да бъде значителна част
от цената на системата и е важно да се оптимизира размерът на паметта в такива случаи. The
значението на размера на паметта се превръща в акцент върху размера на кода, тъй като размера на данните
се диктува от приложението.
Настолни компютри
Първият и вероятно все още най-големият пазар в доларово изражение е настолните компютри. Настолните
компютри обхващат от нисък клас нетбуци, които се продават за под $300 до
работни станции от висок клас, силно конфигурирани, които може да се продават за $2500. От 2008 г.
повече от половината настолни компютри, произведени всяка година, са лаптопи, работещи с батерии.
В целия този диапазон на цена и възможности пазарът на настолни компютри е склонен да бъде
насочени към оптимизиране на съотношението цена-производителност. Тази комбинация от производителност
(измерена предимно по отношение на изчислителна производителност и графична производителност) и
цената на една система е това, което има най-голямо значение за клиентите на този пазар, а оттам и за
компютърни дизайнери. В резултат на това най-новите микропроцесори с най-висока производителност и
микропроцесорите с намалена цена често се появяват първи в настолните системи (вж.
Раздел 1.6 за обсъждане на проблемите, засягащи цената на компютрите).
Настолните компютри също са сравнително добре характеризирани по отношение на
приложения и сравнителен анализ, въпреки че нарастващото използване на уеб-ориентирани, интерактивни
приложения поставя нови предизвикателства при оценката на ефективността.

Сървъри
С преминаването към настолни компютри през 80-те години на миналия век ролята на сървърите нараства
за предоставяне на по-мащабни и по-надеждни файлови и компютърни услуги. Такива сървъри се
превърнаха в гръбнака на широкомащабните корпоративни компютри, заменяйки
традиционен мейнфрейм.
За сървърите са важни различни характеристики. Първо, наличността е критична. (Ние обсъждаме

наличността в раздел 1.7.) Помислете за сървърите, работещи с ATM
машини за банки или резервационни системи на авиокомпании. Отказ на такива сървърни системи
е много по-катастрофално от отказ на един работен плот, тъй като тези сървъри трябва
работи седем дни в седмицата, 24 часа в денонощието. Фигура 1.3 оценява разходите за приходи от
прекъсване на сървърните приложения.
Втора ключова характеристика на сървърните системи е мащабируемостта. Сървърни системи често
растат в отговор на нарастващото търсене на услугите, които поддържат или
повишаване на функционалните изисквания. По този начин възможността за мащабиране на изчисленията
капацитетът, паметта, съхранението и I/O честотната лента на сървъра са от решаващо значение.
И накрая, сървърите са проектирани за ефективна пропускателна способност. Тоест, общата
производителност на сървъра - по отношение на транзакции на минута или обслужени уеб страници
в секунда - това е от решаващо значение. Отзивчивостта на индивидуална заявка остава
важно, но цялостна ефективност и рентабилност, както се определя от това как
много заявки могат да бъдат обработени за единица време, са ключовите показатели за повечето сървъри.
Връщаме се към въпроса за оценката на производителността за различни видове изчисления
среди в раздел 1.8.
Годишни загуби с престой от
Приложение
Разходи за престой на час 1% 0,5% 0,1%
(87,6 часа/година) (43,8 часа/година) (8,8 часа/година)
Брокерски операции $6,450,000 $565,000,000 $283,000,000 56 500 000 долара
Авторизация на кредитна карта $2,600,000 $228,000,000 $114,000,000 22 800 000 долара
Услуги за доставка на пакети $150,000 $13,000,000 $6,600,000 1 300 000 долара
Канал за домашно пазаруване $113,000 $9,900,000 $4,900,000 $1 000 000
Център за каталожна продажба $90,000 $7,900,000 $3,900,000 800 000 долара
Резервационен център за авиокомпании $89,000 $7,900,000 $3,900,000 800 000 долара
Активиране на клетъчна услуга $41,000 $3,600,000 $1,800,000 400 000 долара
Онлайн мрежови такси $25,000 $2,200,000 $1,100,000 200 000 долара
Такси за обслужване на банкомат $14,000 $1,200,000 $600,000 100 000 долара
Фигура 1.3 Разходите, закръглени до най-близките $100 000 на неналична система, са показани чрез анализиране на разходите за
престой (по отношение на незабавно загубени приходи), като се приемат три различни нива на наличност и това време на престой се разпределя равномерно. Тези данни са
от Kembel [2000] и са събрани и анализирани от Contingency
Планиране на изследвания.
Клъстери/Компютри с мащаб на склад
Растежът на софтуера като услуга (SaaS) за приложения като търсене, социални мрежи, споделяне на
видео, мултиплейър игри, онлайн пазаруване и т.н. доведе до растежа на клас компютри, наречени
клъстери . Клъстерите са колекции от настолни компютри или сървъри, свързани чрез локални
мрежи, за да действат като един по-голям компютър. Всеки възел работи със собствена операционна
система и възлите комуникират с помощта на мрежов протокол. Най-големите от клъстерите се
наричат компютри от складов мащаб (WSC), тъй като са проектирани така, че десетки хиляди сървъри
да могат да действат като един. Глава 6 описва този клас изключително големи компютри.
Цена-производителност и мощност са от решаващо значение за WSC, тъй като те са толкова

големи. Както се обяснява в глава 6 , 80% от цената на склад на стойност 90 милиона долара е
свързана със захранването и охлаждането на компютрите вътре. Самите компютри и мрежовото
оборудване струват още 70 милиона долара и трябва да се сменят на всеки няколко години.
Когато купувате толкова много компютри, трябва да купувате разумно, тъй като 10% подобрение в
съотношението цена-производителност означава спестяване на $7 милиона (10% от $70 милиона).
WSC са свързани със сървъри, тъй като наличността е критична. Например, Ama-zon.com имаше
13 милиарда долара продажби през четвъртото тримесечие на 2010 г. Тъй като има около 2200 часа
на тримесечие, средният приход на час беше почти 6 милиона долара. В пиковия час за коледно
пазаруване потенциалната загуба би била в пъти по-голяма.
Както обяснява Глава 6 , разликата от сървърите е, че WSC използват излишни евтини компоненти
като градивни елементи, като разчитат на софтуерен слой, за да уловят и изолират многото повреди,
които ще се случат с изчисленията в този мащаб.
Имайте предвид, че мащабируемостта за WSC се управлява от локалната мрежа, свързваща
компютрите, а не от интегриран компютърен хардуер, както в случая със сървърите.
Суперкомпютрите са свързани с WSC по това, че са еднакво скъпи, струвайки стотици милиони
долари, но суперкомпютрите се различават по това, че наблягат на производителността с плаваща
запетая и изпълняват големи пакетни програми с интензивна комуникация, които могат да работят
седмици наред. Това тясно свързване води до използване на много по-бързи вътрешни мрежи. За
разлика от това, WSC наблягат на интерактивни приложения, широкомащабно съхранение,
надеждност и висока интернет честотна лента.
Вградени компютри
Вградените компютри се намират в ежедневните машини; микровълнови печки, перални машини,

повечето принтери, повечето мрежови превключватели и всички автомобили съдържат прости
вградени микропроцесори.
Процесорите в PMD често се считат за вградени компютри, но ние ги запазваме като отделна
категория, тъй като PMD са платформи, които могат да изпълняват външно разработен софтуер и
споделят много от характеристиките на настолните компютри. Други вградени устройства са по-
ограничени по отношение на сложността на хардуера и софтуера. Използваме възможността за
стартиране на софтуер на трети страни като разделителна линия между невградени и вградени
компютри.
Вградените компютри имат най-голямо разпространение на процесорна мощност и цена.
Те включват 8-битови и 16-битови процесори, които може да струват по-малко от стотинка, 32-битови
микропроцесори, които изпълняват 100 милиона инструкции в секунда и струват под $5, и процесори
от висок клас за мрежови комутатори, които струват $100 и могат да изпълняват милиарди инструкции
в секунда. Въпреки че гамата от изчислителна мощност на пазара на вградени компютри е много
голяма, цената е ключов фактор при проектирането на компютри за това пространство. Изискванията
за производителност съществуват, разбира се, но основната цел често е да се отговори на
необходимостта от производителност на минимална цена, вместо да се постигне по-висока
производителност на по-висока цена.
По-голямата част от тази книга се отнася за проектирането, използването и производителността
на вградените процесори, независимо дали са готови микропроцесори или микропроцесорни ядра,
които ще бъдат сглобени с друг хардуер със специално предназначение. Наистина, третото издание на
тази книга включваше примери от вградени компютри, за да илюстрира идеите във всяка глава.
Уви, повечето читатели намират тези примери за незадоволителни, тъй като данните, които
управляват количествения дизайн и оценката на други класове компютри, все още не са разширени
добре до вградените компютри (вижте предизвикателствата с EEMBC, например, в раздел 1.8) .
Следователно засега оставаме с качествени описания, които не се вписват добре в останалата част от
книгата. В резултат на това в това и предишното издание консолидирахме вградения материал в
Приложение E. Вярваме, че отделно приложение подобрява потока от идеи в текста, като същевременно
позволява на читателите да видят как различните изисквания влияят на вградените компютри.
Класове паралелизъм и паралелни архитектури
Паралелизмът на множество нива сега е движещата сила на компютърния дизайн във всичките четири
класа компютри, като енергията и цената са основните ограничения.
Има основно два вида паралелизъм в приложенията:
1. Паралелизмът на ниво данни (DLP) възниква, защото има много елементи от данни, с които може да
се работи едновременно.
2. Паралелизмът на ниво задача (TLP) възниква, защото се създават работни задачи, които могат да
работят независимо и до голяма степен паралелно.
Компютърният хардуер от своя страна може да използва тези два вида паралелизъм на приложения по
четири основни начина:
1. Паралелизмът на ниво инструкции използва паралелизма на ниво данни на скромни нива с помощта
на компилатора, използвайки идеи като конвейер и на средни нива, използвайки идеи като
спекулативно изпълнение.
2. Векторните архитектури и графичните процесори (GPU) използват паралелизъм на ниво данни чрез
прилагане на една инструкция към колекция от данни паралелно.
3. Паралелизмът на ниво нишка използва или паралелизъм на ниво данни, или паралелизъм на ниво
задача в тясно свързан хардуерен модел, който позволява взаимодействие между паралелни
нишки.
4. Паралелизмът на ниво заявка използва паралелизма между до голяма степен отделени

задачи, определени от програмиста или операционната система.
Тези четири начина хардуерът да поддържа паралелизма на ниво данни и паралелизма

на ниво задача датира от 50 години. Когато Майкъл Флин [1966] изучава усилията за
паралелни изчисления през 60-те години на миналия век, той открива проста класификация,
чиито съкращения все още използваме днес. Той разгледа паралелизма в инструкциите и
потоците от данни, изискван от инструкциите на най-ограничения компонент на
мултипроцесора, и постави всички компютри в една от четирите категории:
1. Единичен поток от инструкции, единичен поток от данни (SISD) – Тази категория е

еднопроцесор. Програмистът мисли за него като за стандартен последователен
компютър, но той може да използва паралелизъм на ниво инструкции. Глава 3
обхваща SISD архитектури, които използват ILP техники като суперскаларно и
спекулативно изпълнение.
2. Единичен поток от инструкции, множество потоци от данни (SIMD) — Една и съща

инструкция се изпълнява от множество процесори, използващи различни потоци от данни.
Компютрите SIMD използват паралелизъм на ниво данни , като прилагат едни и същи
операции към множество елементи от данни паралелно. Всеки процесор има своя
собствена памет за данни (следователно MD на SIMD), но има единична памет за
инструкции и контролен процесор, който извлича и изпраща инструкции.
Глава 4 обхваща DLP и три различни архитектури, които го използват: векторни
архитектури, мултимедийни разширения към стандартни набори от инструкции и
графични процесори.
3. Множество потоци от инструкции, единичен поток от данни (MISD) – До момента не е

изграден комерсиален мултипроцесор от този тип, но той допълва тази проста
класификация.
4. Множество потоци от инструкции, множество потоци от данни (MIMD) – Всеки процесор

извлича свои собствени инструкции и работи със собствените си данни и е насочен
към паралелизъм на ниво задача. Като цяло MIMD е по-гъвкав от SIMD и по този
начин по-общо приложим, но по своята същност е по-скъп от SIMD. Например MIMD
компютрите могат също да използват паралелизъм на ниво данни, въпреки че
режийните разходи вероятно ще бъдат по-високи, отколкото биха се видели в SIMD
компютър. Това наддаване означава, че размерът на зърното трябва да бъде
достатъчно голям, за да се използва ефективно паралелизма. Глава 5 обхваща тясно
свързани MIMD архитектури, които използват паралелизъм на ниво нишка , тъй като
множество взаимодействащи нишки работят паралелно. Глава 6 обхваща слабо
свързани MIMD архитектури - по-специално, клъстери и компютри от складов мащаб
- които използват паралелизъм на ниво заявка, където много независими задачи
могат да се изпълняват паралелно естествено с малка нужда от комуникация или
синхронизация.
Тази таксономия е груб модел, тъй като много паралелни процесори са хибриди на
класовете SISD, SIMD и MIMD. Въпреки това е полезно да поставим рамка върху
пространството за проектиране на компютрите, които ще видим в тази книга.
1.3 Дефиниране на компютърна архитектура
Задачата, пред която е изправен компютърният дизайнер, е сложна: да определи какво

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

може да включва дизайн на интегрална схема, опаковка, захранване и охлаждане. Оптимизирането на
дизайна изисква познаване на много широк набор от технологии,
от компилатори и операционни системи до логически дизайн и пакетиране.
Преди няколко години терминът компютърна архитектура често се отнасяше само до
дизайн на набор от инструкции. Други аспекти на компютърния дизайн се наричат имплементация,
като често се намеква, че имплементацията е безинтересна или по-малко предизвикателна.
Ние вярваме, че това мнение е неправилно. Работата на архитекта или дизайнера е много
повече от дизайна на набора от инструкции и техническите препятствия в другите аспекти на
проектът вероятно е по-предизвикателен от тези, срещани в набора от инструкции
дизайн. Ще прегледаме бързо архитектурата на набора от инструкции, преди да опишем
по-големи предизвикателства за компютърния архитект.
Архитектура на набора от инструкции: късогледият изглед на компютъра

Архитектура
Ние използваме термина архитектура на набор от инструкции (ISA), за да обозначим действителния

набор от инструкции, видим от програмиста в тази книга. ISA служи като граница между
софтуер и хардуер. Този бърз преглед на ISA ще използва примери от 80x86,
ARM и MIPS, за да илюстрират седемте измерения на ISA. Приложения А и
K даде повече подробности за трите МОС.
1. Клас ISA—Почти всички ISA днес се класифицират като регистър с общо предназначение
архитектури, където операндите са или регистри, или места в паметта.
80x86 има 16 регистъра с общо предназначение и 16, които могат да съхраняват данни с плаваща
запетая, докато MIPS има 32 регистъра с общо предназначение и 32 регистъра с плаваща запетая
(виж Фигура 1.4). Двете популярни версии на този клас са регистър-памет
ISA, като 80x86, които имат достъп до паметта като част от много инструкции, и ISA за зареждане ,
като ARM и MIPS, които имат достъп до паметта само с инструкции за зареждане или съхраняване.
Всички скорошни ISA са заредени.
2. Адресиране на паметта - почти всички настолни и сървърни компютри, включително

80x86, ARM и MIPS използват байтово адресиране за достъп до операндите на паметта.
Някои архитектури, като ARM и MIPS, изискват обектите да бъдат
подравнен. Достъп до обект с размер s байта на байт адрес A е подравнен, ако
A mod s = 0. (Вижте Фигура A.5 на страница A-8.) 80x86 не изисква
подравняване, но достъпите обикновено са по-бързи, ако операндите са подравнени.
3. Режими на адресиране – В допълнение към определянето на регистри и постоянни операнди,

режимите на адресиране определят адреса на обект от паметта. MIPS адресиране
Име Използване на номера Запазено при повикване?
$нула 0 Постоянната стойност 0 NA
$при 1 Асемблер временен Не
$v0–$v1 2–3 Стойности за резултати от Не

функция и оценка на израз
$a0–$a3 4–7 Аргументи Не
$t0–$t7 8–15 Временни изделия Не
$s0–$s7 16–23 Запазени временни изделия да
$t8–$t9 24–25 Временни изделия Не
$k0–$k1 26–27 Запазено за ядрото на ОС Не
$gp 28 Глобален показалец да
$sp 29 Указател на стека да
$fp 30 Показалец на рамка да
$ra 31 Адрес за връщане да
Фигура 1.4 MIPS регистри и конвенции за използване. В допълнение към 32-те регистъра с общо
предназначение (R0–R31), MIPS има 32 регистъра с плаваща запетая (F0–F31), които могат да съдържат
или 32-битово число с единична точност, или 64-битово число с двойна точност.
режимите са регистър, незабавно (за константи) и изместване, където a

постоянното отместване се добавя към регистър, за да формира адреса на паметта. 80x86
поддържа тези три плюс три варианта на изместване: без регистър (абсолютен), два регистъра
(базиран индексиран с изместване) и два регистъра
където един регистър се умножава по размера на операнда в байтове (на база
с мащабиран индекс и изместване). Има повече като последните три, минус
поле за изместване, плюс регистър индиректен, индексиран и базиран с мащабиран
индекс. ARM има три MIPS режима на адресиране плюс PC-относително адресиране, сумата от
два регистъра и сумата от два регистъра, където един регистър
се умножава по размера на операнда в байтове. Освен това има автоинкремент и
автоматично декрементно адресиране, където изчисленият адрес замества съдържанието
на един от регистрите, използвани при формирането на адреса.
4. Типове и размери на операндите – като повечето ISA, 80x86, ARM и MIPS

поддържа размери на операнди от 8 бита (ASCII символ), 16 бита (символ Unicode
или половин дума), 32-битов (цяло число или дума), 64-битов (двойна дума или дълго цяло число)
и IEEE 754 с плаваща запетая в 32-битов (единична точност) и 64-битов
(двойна точност). 80x86 също поддържа 80-битова плаваща запетая (разширена
двойна точност).
5. Операции – Общите категории операции са пренос на данни, аритметично-логически, контролни

(обсъдени по-нататък) и с плаваща запетая. MIPS е проста и
лесна за конвейер архитектура на набор от инструкции и е представителна за RISC
архитектури, използвани през 2011 г. Фигура 1.5 обобщава MIPS ISA. The
80x86 има много по-богат и по-голям набор от операции (вижте Приложение K).
Тип на инструкцията/операционен код Значение на инструкцията
Трансфери на данни Преместване на данни между регистри и памет или между цяло число и FP или специални регистри;
единственият режим на адрес на паметта е 16-битово изместване + съдържание на GPR
LB, LBU, SB Зареждане на байт, зареждане на байт без знак, съхраняване на байт (към/от целочислени регистри)
LH, LHU, SH Зареждане на половин дума, зареждане на половин дума без знак, съхраняване на половин дума (към/от целочислени регистри)
LW, LWU, SW Зареждане на дума, зареждане на неподписана дума, съхраняване на дума (към/от целочислени регистри)
LD, SD Зареждане на двойна дума, съхраняване на двойна дума (към/от целочислени регистри)
LS, LD, SS, SD Заредете SP float, заредете DP float, запазете SP float, запазете DP float
MFC0, MTC0 Копиране от/в GPR към/от специален регистър
MOV.S, MOV.D Копирайте един SP или DP FP регистър в друг FP регистър
MFC1, MTC1 Копирайте 32 бита към/от FP регистри от/към цели числа
Аритметично/логическо Операции с целочислени или логически данни в GPR; аритметично прихващане със знак при препълване
DADD, DADDI, DADDU, DADDIU Добавяне, незабавно добавяне (всички непосредствени са 16 бита); подписани и неподписани
ДСУБ, ДСУБУ Изваждане, със знак и без знак
DMUL, DMULU, DDIV, Умножение и деление, със знак и без знак; умножение-събиране; всички операции приемат и дават 64-битови
ДДИВУ, МАДД стойности
И, АНДИ И, и незабавно
ИЛИ, ORI, XOR, XORI Или, или незабавно, изключително или, изключително или незабавно
LUI Заредете горната част незабавно; зарежда битове от 32 до 47 от регистъра с незабавно, след което разширява знака
DSLL, DSRL, DSRA, DSLLV, Промени: незабавни (DS__) и променлива форма (DS__V); отместванията са отместване наляво логическо, дясно
DSRLV, DSRAV логическо, дясно аритметично
SLT, SLTI, SLTU, SLTIU Задайте по-малко от, задайте по-малко от непосредствено, със знак и без знак
контрол Условни разклонения и скокове; PC-роднина или чрез регистър
BEQZ, BNEZ GPR на разклонения са равни/не равни на нула; 16-битово отместване от PC + 4
BEQ, BNE Клон GPR равен/не е равен; 16-битово отместване от PC + 4
BC1T, BC1F Бит за тестово сравнение в регистъра на състоянието на FP и разклонението; 16-битово отместване от PC + 4
MOVN, MOVZ Копирайте GPR в друг GPR, ако третият GPR е отрицателен, нула
J, JR Скокове: 26-битово отместване от PC + 4 (J) или цел в регистър (JR)
ДЖАЛ, ДЖАЛР Прескачане и връзка: запазване на PC + 4 в R31, целта е свързана с PC (JAL) или регистър (JALR)
КАПАН Прехвърляне към операционна система на векторизиран адрес
ERET Връщане към потребителски код от изключение; възстановяване на потребителския режим
С плаваща запетая FP операции върху DP и SP формати
ADD.D, ADD.S, ADD.PS SUB.D, Добавете DP, SP номера и двойки SP номера
SUB.S, SUB.PS MUL.D, MUL.S, Извадете DP, SP числа и двойки SP числа
MUL.PS MADD.D, MADD.S, Умножете DP, SP с плаваща запетая и двойки SP числа
MADD.PS DIV.D, DIV.S, DIV.PS CVT._._ Умножение-събиране на DP, SP числа и двойки SP числа
Разделете DP, SP с плаваща запетая и двойки SP числа
Инструкции за преобразуване: CVT.xy преобразува от тип x в тип y, където x и y са L

(64-битово цяло число), W (32-битово цяло число), D (DP) или S (SP). И двата операнда са FPR.
C.__.D, C.__.S DP и SP сравнява: “__” = LT,GT,LE,GE,EQ,NE; задава бит в регистъра на състоянието на FP
Фигура 1.5 Подгрупа от инструкции в MIPS64. SP = единична точност; DP = двойна точност. Приложение А дава
много повече подробности за MIPS64. За данни най-значимият битов номер е 0; най-малкото е 63.
6. Инструкции за контрол на потока - Поддържат се практически всички ISA, включително тези три
условни разклонения, безусловни скокове, извиквания на процедури и връщания. всичко
три използват PC-относително адресиране, където адресът на клона е посочен от an
адресно поле, което се добавя към компютъра. Има някои малки разлики. MIPS
условните разклонения (BE, BNE и т.н.) тестват съдържанието на регистрите, докато

80x86 и клоновете ARM тестват кодови битове за условие, зададени като странични ефекти на
аритметични/логически операции. Извикването на процедурата ARM и MIPS поставя връщането

адрес в регистър, докато повикването 80x86 (CALLF) поставя обратния адрес
на стек в паметта.
7. Кодиране на ISA—Има два основни варианта за кодиране: фиксирана дължина и

променлива дължина. Всички ARM и MIPS инструкции са дълги 32 бита, което опростява
декодирането на инструкциите. Фигура 1.6 показва форматите на MIPS инструкции.
Кодирането 80x86 е с променлива дължина, варираща от 1 до 18 байта. Инструкциите с
променлива дължина могат да заемат по-малко място от инструкциите с фиксирана дължина, така че a
програмата, компилирана за 80x86, обикновено е по-малка от същата програма
компилиран за MIPS. Имайте предвид, че изборите, споменати по-горе, ще повлияят на това как
инструкциите са кодирани в двоично представяне. Например, броят на регистрите и броят на
режимите на адресиране имат значително значение
влияние върху размера на инструкциите, като регистрационно поле и режим на адресиране
полето може да се появи много пъти в една инструкция. (Имайте предвид, че ARM и
MIPS по-късно предложи разширения, за да предложи инструкции с 16-битова дължина, така че
намаляване на размера на програмата, наречена съответно Thumb или Thumb-2 и MIPS16.)
Основни формати на инструкции
R код за операция rs rt rd шамт функция
31 26 25 21 20 16 15 11 10 65 0
аз
операционен код
rs rt незабавно
31 26 25 21 20 16 15
J код за операция адрес
31 26 25
Формати на инструкции с плаваща запетая
FR код за операция fmt фута fs fd функция
31 26 25 21 20 16 15 11 10 65 0
FI код на операцията fmt фута незабавно
31 26 25 21 20 16 15
Фигура 1.6 Формати на архитектурата на набора инструкции MIPS64. Всички инструкции са 32 бита
дълго. Форматът R е за целочислени операции от регистър към регистър, като DADDU, DSUBU,
и така нататък. Форматът I е за прехвърляне на данни, разклонения и незабавни инструкции, като такива
като LD, SD, BEQZ и DADDI. Форматът J е за скокове, форматът FR за плаваща запетая
операции и FI формат за разклонения с плаваща запетая.
Другите предизвикателства пред компютърния архитект извън дизайна на ISA са

особено остро в настоящето, когато разликите между наборите от инструкции са
малки и когато има различни области на приложение. Следователно, започвайки с
последното издание, по-голямата част от материала за набор от инструкции извън този бърз преглед е намерен
в приложенията (вижте приложения А и К).

Използваме подмножество на MIPS64 като примерен ISA в тази книга, защото е и двете
доминиращата ISA за мрежи и е елегантен пример за RISC архитектурите, споменати по-рано,
от които ARM (Advanced RISC Machine) е най-голямата
популярен пример. ARM процесорите са били в 6,1 милиарда чипа, доставени през 2010 г., или
приблизително 20 пъти повече чипове, които се доставят с процесори 80x86.
Истинска компютърна архитектура: Проектиране на организацията

и хардуера за постигане на целите и функционалните изисквания
Реализацията на компютъра има два компонента: организация и

хардуер. Терминът организация включва аспектите на високо ниво на компютъра
дизайн, като например системата с памет, свързването на паметта и дизайна на
вътрешния процесор или CPU (централен процесор - където аритметика, логика,
разклоняване и трансфер на данни са реализирани). Терминът микроархитектура е
също се използва вместо организация. Например два процесора с еднакви
архитектури на набор от инструкции, но различни организации са AMD Opteron и
Intel Core i7. И двата процесора изпълняват набора от инструкции x86, но те
имат много различни тръбопроводи и организации на кеша.
Преминаването към множество процесори на микропроцесор доведе до термина ядро
да се използва и за процесор. Вместо да казвате многопроцесорен микропроцесор,
терминът многоядрени се утвърди. Като се има предвид, че почти всички чипове имат
множество процесори, терминът централен процесор или CPU избледнява в популярност.
Хардуерът се отнася до спецификата на компютъра, включително подробната логика
дизайн и технология на опаковане на компютъра. Често линия от компютри
съдържа компютри с идентична архитектура на набор от инструкции и почти идентични
организации, но те се различават по детайлната хардуерна реализация. Например, Intel Core i7
(вижте глава 3) и Intel Xeon 7560 (вижте глава 5) са
почти идентични, но предлагат различни тактови честоти и различни системи за памет,
правейки Xeon 7560 по-ефективен за сървърни компютри.
В тази книга думата архитектура обхваща и трите аспекта на компютъра
дизайн—архитектура, организация или микроархитектура на набор от инструкции и
хардуер.
Компютърните архитекти трябва да проектират компютър, който да отговаря на функционалните изисквания
както и цели за цена, мощност, производителност и наличност. Фигура 1.7 обобщава

изискванията, които трябва да се имат предвид при проектирането на нов компютър. Често архитекти
също трябва да определи какви са функционалните изисквания, които могат да бъдат основни
задача. Изискванията може да са специфични характеристики, вдъхновени от пазара.
Приложният софтуер често ръководи избора на определени функционални изисквания, като
определя как ще се използва компютърът. Ако съществува голямо количество софтуер за a
определена архитектура на набор от инструкции, архитектът може да реши, че нов компютър
Функционални изисквания Необходими или поддържани типични функции
Област на приложение Цел на компютъра
Лично мобилно устройство Изпълнение в реално време за набор от задачи, включително интерактивно изпълнение за графики,
видео и аудио; енергийна ефективност (гл. 2, 3, 4, 5; приложение A)
Десктоп с общо предназначение Балансирана производителност за набор от задачи, включително интерактивна производителност за
графики, видео и аудио (Ch. 2, 3, 4, 5; App. A)
Сървъри Поддръжка на бази данни и обработка на транзакции; подобрения за надеждност и наличност; поддръжка
за мащабируемост (гл. 2, 5; приложение A, D, F)
Клъстери/складови компютри Производителност за много независими задачи; корекция на грешки в паметта; пропорционалност
на енергията (гл. 2, 6; приложение F)
Вградени компютри Често изисква специална поддръжка за графики или видео (или друго специфично за приложението
разширение); може да са необходими ограничения на мощността и контрол на мощността;
ограничения в реално време (гл. 2, 3, 5; приложение A, E)
Ниво на софтуерна съвместимост Определя количеството съществуващ софтуер за компютър
На език за програмиране Най-гъвкав за дизайнер; нужда от нов компилатор (гл. 3, 5; приложение A)
Обектен код или двоична Архитектурата на набора от инструкции е напълно дефинирана – малка гъвкавост – но не е
съвместимост необходима инвестиция в софтуер или програми за пренасяне (приложение A)
Изисквания към операционната система Необходими функции за поддръжка на избрана ОС (гл. 2; приложение B)
Размер на адресното пространство Много важна характеристика (гл. 2); може да ограничи приложенията
Управление на паметта Изисква се за съвременна ОС; могат да бъдат странирани или сегментирани (гл. 2)
защита Различни нужди от ОС и приложения: страница срещу сегмент; виртуални машини (гл. 2)
Стандарти Някои стандарти може да се изискват от пазара. Формат и
Плаваща запетая аритметика: стандарт IEEE 754 (приложение J), специална аритметика за обработка на графики или сигнали
I/O интерфейси За I/O устройства: Serial ATA, Serial Attached SCSI, PCI Express (приложение D, F)
Операционна система UNIX, Windows, Linux, CISCO IOS
мрежи Необходима поддръжка за различни мрежи: Ethernet, Infiniband (Приложение F)
Програмни езици Езиците (ANSI C, C++, Java, Fortran) засягат набора от инструкции (приложение A)
Фигура 1.7 Обобщение на някои от най-важните функционални изисквания, пред които е изправен един архитект. Лявата ръка
колоната описва класа на изискването, докато дясната колона дава конкретни примери. Дясната ръка
колоната също така съдържа препратки към глави и приложения, които се занимават с конкретни въпроси.
трябва да имплементира съществуващ набор от инструкции. Наличието на голям пазар за a

определен клас приложения може да насърчи дизайнерите да ги включат
изисквания, които биха направили компютъра конкурентен на този пазар. По късно
главите разглеждат много от тези изисквания и функции в дълбочина.
Архитектите също трябва да са наясно с важни тенденции както в технологиите, така и в
използването на компютри, тъй като подобни тенденции засягат не само бъдещите разходи, но и върху
дълголетие на една архитектура.
1.4 Тенденции в технологиите
Ако архитектурата на набора от инструкции трябва да бъде успешна, тя трябва да бъде проектирана така, че да оцелее
бързи промени в компютърните технологии. В края на краищата, успешен нов набор от инструкции
архитектурата може да продължи десетилетия - например ядрото на IBM мейнфрейм има
се използва от близо 50 години. Архитектът трябва да планира технологичните промени
които могат да удължат живота на един успешен компютър.
За да планира еволюцията на един компютър, дизайнерът трябва да е наясно с бързината
промени в технологията на изпълнение. Пет технологии за внедряване, които
промяна с драматични темпове, са критични за съвременните реализации:
Логическа технология на интегрирана схема—Плътността на транзисторите се увеличава с около
35% годишно, учетворявайки донякъде за четири години. Увеличава размера на матрицата
са по-малко предвидими и по-бавни, вариращи от 10% до 20% годишно. Комбинираният ефект е
скорост на нарастване на броя на транзисторите на чип от около 40% до 55%
на година или удвояване на всеки 18 до 24 месеца. Тази тенденция е популярна като
Закон на Мур. Скоростта на устройството се мащабира по-бавно, както ще обсъдим по-долу.
Полупроводникова DRAM (динамична памет с произволен достъп)—Сега повечето
DRAM чиповете се доставят предимно в DIMM модули, по-трудно е да се проследят
капацитет на чипа, тъй като производителите на DRAM обикновено предлагат няколко продукта с
капацитет едновременно, за да отговарят на капацитета на DIMM. Капацитет на DRAM чип има
нарасна с около 25% до 40% годишно напоследък, удвоявайки се приблизително на всеки
две до три години. Тази технология е в основата на основната памет и
ние го обсъждаме в Глава 2. Обърнете внимание, че темпът на подобрение продължава
бавно в изданията на тази книга, както показва фигура 1.8 . Има дори опасения дали темпът на растеж
ще спре в средата на това десетилетие поради
нарастващата трудност при ефективното производство на още по-малки DRAM
клетки [Kim 2005]. Глава 2 споменава няколко други технологии, които могат
сменете DRAM, ако удари стената на капацитета.
Скорост на растеж на Характеризиране на въздействието

CA:AQA издание година DRAM върху капацитета на DRAM
1 1990 г 60%/година Учетворяване на всеки 3 години
2 1996 г 60%/година Учетворяване на всеки 3 години
3 2003 г 40%–60%/година Учетворяване на всеки 3 до 4 години
4 2007 г 40%/година Удвояване на всеки 2 години
5 2011 г 25%–40%/година Удвояване на всеки 2 до 3 години
Фигура 1.8 Промяна в скоростта на подобряване на капацитета на DRAM с течение на времето. Първите две
изданията дори нарекоха този процент DRAM Growth Rule of Thumb, тъй като беше така
надежден от 1977 г. с 16-килобитовата DRAM до 1996 г. с 64-мегабитовата
DRAM. Днес някои се съмняват дали капацитетът на DRAM изобщо може да се подобри с 5 до 7
години, поради трудностите при производството на все по-триизмерна DRAM

клетка [Kim 2005].
Semiconductor Flash (електрически изтриваема програмируема памет само за четене)—Тази

енергонезависима полупроводникова памет е стандартното устройство за съхранение в PMD и
нейната бързо нарастваща популярност подхранва бързия темп на нарастване на капацитета.
Капацитетът на флаш чип напоследък се е увеличил с около 50% до 60% годишно, като се
удвоява приблизително на всеки две години. През 2011 г. флаш паметта е 15 до 20 пъти по-
евтина на бит от DRAM. Глава 2 описва флаш паметта.
Технология на магнитния диск—Преди 1990 г. плътността се увеличаваше с около 30% годишно,

удвоявайки се за три години. След това той се повиши до 60% на година и се увеличи до 100%
на година през 1996 г. От 2004 г. той спадна обратно до около 40% на година или се удвоява на
всеки три години. Дисковете са 15 до 25 пъти по-евтини на бит от Flash. Предвид забавения
темп на растеж на DRAM, дисковете сега са 300 до 500 пъти по-евтини на бит от DRAM. Тази
технология е централна за сървърно и складово съхранение и ние обсъждаме тенденциите
подробно в Приложение D. Мрежова технология – Мрежовата производителност зависи
както от производителността
на комутаторите, така и от производителността на преносната система. Ние обсъждаме тенденциите

в работата в мрежа в Приложение F.
Тези бързо променящи се технологии оформят дизайна на компютър, който със скорост и
технологични подобрения може да има живот от три до пет години. Ключови технологии като
DRAM, Flash и диск се променят достатъчно, така че дизайнерът трябва да планира тези промени.
Наистина, дизайнерите често проектират за следващата технология, знаейки, че когато даден
продукт започне да се доставя в обем, следващата технология може да бъде най-рентабилната или
може да има предимства в производителността. Традиционно цената е намаляла приблизително
със скоростта, с която се увеличава плътността.
Въпреки че технологията се подобрява непрекъснато, въздействието на тези подобрения

може да бъде в дискретни скокове, когато се достигне праг, който позволява нова способност.
Например, когато технологията MOS достигна точка в началото на 80-те години, когато между 25
000 и 50 000 транзистора могат да се поберат на един чип, стана възможно да се изгради 32-битов
микропроцесор с един чип. До края на 80-те години кешовете от първо ниво можеха да бъдат
поставени на чип. Чрез елиминирането на кръстосването на чипове в процесора и между процесора
и кеша беше възможно драматично подобрение на разходите и енергийната производителност.
Този дизайн беше просто неосъществим, докато технологията не достигна определена точка. С
многоядрени микропроцесори и нарастващ брой ядра с всяко поколение дори сървърните
компютри все повече се насочват към един чип за всички процесори. Такива технологични прагове
не са рядкост и имат значително влияние върху голямо разнообразие от дизайнерски решения.
Тенденции в производителността: честотна лента над латентност
Както ще видим в раздел 1.8, честотната лента или пропускателната способност е общото количество
работа, извършена за дадено време, като например мегабайта в секунда за прехвърляне на диск.
За разлика от това, латентността или времето за реакция е времето между началото и завършването
на събитие, като например милисекунди за достъп до диска. Фигура 1.9 изобразява относителната
100 000
Микропроцесор
10 000
мрежа
1000
памет
ритба
илнеаетн
атаен етП
соа
ттдн
сооо н
ч
о
л
диск
100
10
(Подобрение на латентността
= подобрение на честотната лента)
1
1 10 100
Подобрение на относителната латентност
Фигура 1.9 Графика логаритмичен график на честотната лента и етапите на закъснение от Фигура 1.10
по отношение на първия етап. Обърнете внимание, че латентността се подобри 6X до 80X, докато
честотната лента се подобри около 300X до 25 000X. Актуализирано от Patterson [2004].
подобряване на честотната лента и латентността за технологични етапи за микропроцесори,

памет, мрежи и дискове. Фигура 1.10 описва примерите и етапите по-подробно.
Производителността е основният отличителен фактор за микропроцесорите и мрежите,

така че те са видели най-големите печалби: 10 000–25 000 пъти в честотната лента и 30–80 пъти
в латентността. Капацитетът обикновено е по-важен от производителността за паметта и
дисковете, така че капацитетът се е подобрил най-много, но напредъкът на честотната лента
от 300–1200X все още е много по-голям от печалбите в латентността от 6–8X.
Ясно е, че честотната лента е изпреварила латентността в тези технологии и вероятно ще
продължи да го прави. Едно просто правило е, че честотната лента нараства поне с квадрата
на подобрението на латентността. Компютърните дизайнери трябва да планират съответно.
Мащабиране на производителността на транзистора и проводниците
Процесите на интегрирана схема се характеризират с размера на характеристиката, който е

минималният размер на транзистор или проводник в измерението x или y . Размерите на
характеристиките са намалели от 10 микрона през 1971 г. до 0,032 микрона през 2011 г.;
всъщност сменихме единиците, така че производството през 2011 г. се нарича „32 нанометра“
и 22 нанометрови чипове са в ход. Тъй като броят на транзистора на квадрат
Микропроцесор 16-битов 32-битов 5-степенен 2-посочен Извън ред Извън ред Многоядрени
адрес/ адрес/ тръбопровод, суперскаларен, 3-посочен свръхтръбопроводен, OOO 4-пътен
автобус, автобус, на чип I & D 64-битова шина суперскаларен на чип L2 L3 кеш на
микрокодиран микрокодиран кешове, FPU кеш памет чип, Turbo
Продукт Intel 80286 Intel 80386 Intel 80486 Intel Pentium Intel Pentium Pro Intel Pentium 4 Intel Core i7
година 1982 г 1985 г 1989 г 1993 г 1997 г 2001 г 2010 г
Размер на матрицата (mm2 ) 47 43 81 90 308 217 240
Транзистори 134 000 275 000 1 200 000 3 100 000 5 500 000 42 000 000 1 170 000 000
Процесори/чип 1 1 1 1 1 1 4
Карфици 68 132 168 273 387 423 1366
Латентност (часовници) 6 5 5 5 10 22 14
Ширина на шината (битове) 16 32 32 64 64 64 196
Тактова честота (MHz) 12.5 16 25 66 200 1500 3333
Ширина на честотната лента (MIPS) 2 6 25 132 600 4500 50 000
Закъснение (ns) 320 313 200 76 50 15 4
Модул памет Режим DRAM страница Бърза страница Бърза страница Синхронен Двойни данни DDR3
DRAM режим DRAM режим DRAM DRAM скорост SDRAM SDRAM
Ширина на модула (битове) 16 16 32 64 64 64 64
година 1980 г 1983 г 1986 г 1993 г 1997 г 2000 г 2010 г
Mbits/DRAM чип 0,06 0,25 1 16 64 256 2048 г
Размер на матрицата (mm2 ) 35 45 70 130 170 204 50
Пинове/DRAM чип 16 16 18 20 54 66 134
Честотна лента (MBytes/s) 13 40 160 267 640 1600 16 000
Закъснение (ns) 225 170 125 75 62 52 37
Локална мрежа Ethernet Бърз Гигабит 10 гигабита 100 гигабита

Ethernet Ethernet Ethernet Ethernet
IEEE стандарт 802.3 803.3u 802.3ab 802.3ac 802.3ba
година 1978 г 1995 г 1999 г 2003 г 2010 г
Честотна лента (Mbits/sec) 10 100 1000 10 000 100 000
Латентност (μsec) 3000 500 340 190 100
Твърд диск 3600 RPM 5400 RPM 7200 RPM 10 000 RPM 15 000 RPM 15 000 RPM
Продукт CDC WrenI Seagate Seagate Seagate Seagate Seagate

94145-36 ST41600 ST15150 ST39102 ST373453 ST3600057
година 1983 г 1990 г 1994 г 1998 г 2003 г 2010 г
Капацитет (GB) 0,03 1.4 4.3 9.1 73.4 600
Формат на диска 5,25 инча 5,25 инча 3,5 инча 3,5 инча 3,5 инча 3,5 инча
Диаметър на носителя 5,25 инча 5,25 инча 3,5 инча 3,0 инча 2,5 инча 2,5 инча
Интерфейс ST-412 SCSI SCSI SCSI SCSI SAS
Честотна лента (MBytes/s) 0,6 4 9 24 86 204
Закъснение (ms) 48.3 17.1 12.7 8.8 5.7 3.6
Фигура 1.10 Етапи на производителността за период от 25 до 40 години за микропроцесори, памет, мрежи и дискове. The
етапи на микропроцесора са няколко поколения процесори IA-32, преминаващи от 16-битова шина, микрокодирани
80286 към 64-битова шина, многоядрен, извънредно изпълнение, суперконвейерен Core i7. Важните етапи на модула памет са извършени
от 16-битова обикновена DRAM до 64-битова синхронна DRAM с двойна скорост на предаване на данни версия 3. Ethernet напреднал от
10 Mbits/sec до 100 Gbits/sec. Важните етапи на диска се основават на скоростта на въртене, подобрявайки се от 3600 RPM на 15 000
RPM. Всеки случай е честотната лента в най-добрия случай, а латентността е времето за проста операция, без да се допуска конкуренция.
Актуализирано от Patterson [2004].
милиметър силиций се определя от повърхността на транзистора, плътността
на транзисторите се увеличава квадратично с линейно намаляване на размера на характеристиките.
Увеличаването на производителността на транзистора обаче е по-сложно. Като функция
размерите се свиват, устройствата се свиват квадратично в хоризонталното измерение и също
свиване във вертикалното измерение. Свиването във вертикалното измерение изисква a
намаляване на работното напрежение за поддържане на правилна работа и надеждност на
транзистори. Тази комбинация от фактори за мащабиране води до сложна взаимовръзка между
производителността на транзистора и размера на характеристиките на процеса. В първо приближение
производителността на транзистора се подобрява линейно с намаляване на размера на характеристиката.
Фактът, че броят на транзисторите се подобрява квадратично с линейно подобрение в производителността
на транзисторите, е едновременно предизвикателство и възможност за
кои компютърни архитекти са създадени! В първите дни на микропроцесорите,
по-високият процент на подобрение на плътността беше използван за бързо преминаване от 4-битов,
към 8-битови, към 16-битови, към 32-битови, към 64-битови микропроцесори. Съвсем наскоро, плътност
подобренията подпомогнаха въвеждането на множество процесори на чип,
по-широки SIMD единици и много от иновациите в спекулативното изпълнение и
кешове, открити в глави 2, 3, 4 и 5.
Въпреки че транзисторите обикновено подобряват производителността си с намален размер на
характеристиките, кабелите в интегралната схема не го правят. По-специално, забавянето на сигнала за a
проводник се увеличава пропорционално на произведението на неговото съпротивление и капацитет. На
разбира се, тъй като размерът на характеристиките се свива, проводниците стават по-къси, но съпротивлението
и капацитетът на единица дължина се влошават. Тази връзка е сложна, тъй като и съпротивлението, и
капацитетът зависят от подробни аспекти на процеса, геометрията на
тел, натоварването върху жица и дори съседството с други структури. Там
са случайни подобрения на процеса, като въвеждането на мед, което
осигуряват еднократни подобрения в забавянето на кабела.
Като цяло обаче забавянето на кабела се мащабира слабо в сравнение с производителността на
транзистора, което създава допълнителни предизвикателства за дизайнера. През последните няколко години, в
в допълнение към границата на разсейване на мощността, забавянето на кабела се превърна в основен дизайн
ограничение за големи интегрални схеми и често е по-критично от транзистора
забавяне на превключването. Все по-големи и по-големи части от тактовия цикъл са изразходвани от
забавянето на разпространението на сигналите по проводниците, но мощността сега играе равномерно
по-голяма роля от забавянето на кабела.
1.5 Тенденции в мощността и енергията в интегралните схеми
Днес мощността е най-голямото предизвикателство пред компютърния дизайнер от почти
всеки клас компютър. Първо, властта трябва да бъде въведена и разпределена наоколо
чипът, а съвременните микропроцесори използват стотици щифтове и множество слоеве за свързване само
за захранване и заземяване. Второ, мощността се разсейва като топлина и

трябва да бъдат премахнати.
Мощност и енергия: Системна перспектива
Как един системен архитект или потребител трябва да мисли за производителност, мощност и
енергия? От гледна точка на системния дизайнер има три основни грижи.

Първо, каква е максималната мощност, която един процесор изисква? Среща с това
търсенето може да бъде важно за осигуряване на правилна работа. Например, ако процесорът се опита да черпи
повече енергия, отколкото захранващата система може да осигури (чрез
черпене на повече ток, отколкото системата може да достави), резултатът обикновено е спад на напрежението,
което може да причини неизправност на устройството. Съвременните процесори могат
варират значително в консумацията на енергия с високи пикови токове; следователно те предоставят
методи за индексиране на напрежението, които позволяват на процесора да забавя и регулира
напрежение в по-широк диапазон. Очевидно това намалява производителността.
Второ, каква е продължителната консумация на енергия? Този показател е широко разпространен
наречена топлинна проектна мощност (TDP), тъй като определя изискването за охлаждане. TDP не е нито пикова
мощност, която често е 1,5 пъти по-висока, нито е
действителната средна мощност, която ще бъде консумирана по време на дадено изчисление, което е
вероятно ще бъде още по-ниско. Типичното захранване за една система обикновено е оразмерено до
надвишават TDP и охладителната система обикновено е проектирана да съответства или надвишава
TDP. Ако не се осигури адекватно охлаждане, температурата на кръстовището ще се повиши
процесорът да надхвърли максималната си стойност, което води до повреда на устройството и евентуално до
трайна повреда. Съвременните процесори осигуряват две функции за подпомагане на управлението на
топлината, тъй като максималната мощност (и следователно топлината и повишаването на температурата) може
надвишава дългосрочната средна стойност, определена от TDP. Първо, когато топлинната температура се
доближи до границата на температурата на прехода, веригата намалява тактовата честота,
като по този начин намалява мощността. Ако тази техника не е успешна, се активира второ прекъсване при
термично претоварване, за да се изключи захранването на чипа.
Третият фактор, който дизайнерите и потребителите трябва да вземат предвид, е енергията и
енергийна ефективност. Спомнете си, че мощността е просто енергия за единица време: 1 ват =
1 джаул в секунда. Кой показател е правилният за сравняване на процесори:
енергия или сила? Като цяло енергията винаги е по-добра метрика, защото е свързана с
конкретна задача и времето, необходимо за тази задача. По-специално, енергията за изпълнение на работно
натоварване е равна на средната мощност, умножена по времето за изпълнение на

натовареност.
Така, ако искаме да знаем кой от двата процесора е по-ефективен за дадено
задача, трябва да сравним консумацията на енергия (не мощност) за изпълнение на задачата.
Например, процесор A може да има 20% по-висока средна консумация на енергия
отколкото процесор B, но ако A изпълни задачата само за 70% от времето, необходимо на B,
неговата консумация на енергия ще бъде 1,2 × 0,7 = 0,84, което е очевидно по-добро.
Някой може да възрази, че в голям сървър или облак е достатъчно да се вземе предвид
средна мощност, тъй като натоварването често се приема за безкрайно, но това е погрешно. Ако нашият облак
беше запълнен с процесори B, а не As, тогава
облакът би свършил по-малко работа за същото количество изразходвана енергия. Използване на енергия
сравняването на алтернативите избягва този капан. Всеки път, когато имаме фиксирано работно натоварване,
независимо дали за облак с размер на склад или смартфон, сравняването на енергията ще
бъде правилният начин за сравняване на алтернативи на процесора, като сметката за електричество за
облака и живота на батерията на смартфона се определят от
консумирана енергия.
Кога консумацията на енергия е полезна мярка? Основната законна употреба е
като ограничение: например един чип може да бъде ограничен до 100 вата. Може да се използва
като показател, ако работното натоварване е фиксирано, но тогава това е просто вариант на истинския показател
енергия за задача.
Енергия и мощност в микропроцесор

За CMOS чиповете традиционната първична консумация на енергия е в превключващи
транзистори, наричана още динамична енергия. Необходимата енергия на транзистор е
пропорционално на произведението на капацитивния товар, управляван от транзистора и
квадрат на напрежението:
×
Енергодинамичен Капацитивен товар Напрежение2
Това уравнение е енергията на импулса на логическия преход от 0 1 0 или 1 0 1.

Тогава енергията на един преход (0 1 или 1 0) е:
× ×
Енергийна динамичност 1 2⁄ Капацитивен товар Напрежение2
Мощността, необходима на транзистор, е просто продукт на енергията на прехода

умножено по честотата на преходите:
×
Powerdinamical 1 2⁄ × Капацитивен товар Напрежение2 × Превключване на честотата
За фиксирана задача забавянето на тактовата честота намалява мощността, но не и енергията.
Ясно е, че динамичната мощност и енергия се намаляват значително чрез понижаване на

напрежение, така че напрежението е спаднало от 5V до малко под 1V за 20 години. The
капацитивният товар е функция на броя на транзисторите, свързани към изхода
и технологията, която определя капацитета на проводниците и транзисторите.
Пример Някои микропроцесори днес са проектирани да имат регулируемо напрежение, така че 15%
намаляването на напрежението може да доведе до 15% намаление на честотата. Какво би било
въздействието върху динамичната енергия и върху динамичната мощност?
Отговор Тъй като капацитетът е непроменен, отговорът за енергията е отношението на волта-

старее, тъй като капацитетът е непроменен:
2
Energynew
------------------------ )(Напрежение
0,852 = == 0,72 0,85 ×
------------------------------------------
Energyold Напрежение2
като по този начин намалява енергията до около 72% от първоначалната. За мощност добавяме съотношението
на честотите
Powernew (Честота на превключване 0,85 × ) =

---------------------- = 0,72 0,61
× -------------------------------------------------- --------------------
Powerold Превключване на честотата
свиваща мощност до около 61% от първоначалната.

Докато преминаваме от един процес към следващ, увеличаването на броя на

превключващите се транзистори и честотата, с която те превключват, доминират
намаляването на капацитета на натоварване и напрежението, което води до общо
нарастване на консумацията на енергия и енергия. Първите микропроцесори консумираха
по-малко от ват, а първите 32-битови микропроцесори (като Intel 80386) използваха около
2 вата, докато 3,3 GHz Intel Core i7 консумира 130 вата. Като се има предвид, че тази
топлина трябва да се разсейва от чип, чиято страна е около 1,5 см, достигнахме границата
на това, което може да се охлажда с въздух.
Като се има предвид горното уравнение, бихте очаквали нарастването на тактовата
честота да се забави, ако не можем да намалим напрежението или да увеличим
мощността на чип. Фигура 1.11 показва, че това наистина е така от 2003 г. насам, дори
за микропроцесорите на Фигура 1.1 , които са били най-ефективни всяка година. Обърнете
внимание, че този период на равни тактови честоти съответства на периода на бавно
подобрение на производителността на Фигура 1.1.
10 000
Intel Nehalem Xeon
Intel Pentium4 Xeon
3330 MHz през 2010 г
Intel Pentium III

1000
Digital Alpha 21164A

Една година
Digital Alpha 21064
100
ач
)zтHскM
авто е Т(
MIPS M2000
40%/година
Sun-4 SPARC 16,7

10
MHz през 1986 г
Цифров VAX-11/780
15%/година
1 1978 1980 1982 1984 1986 1988 1990 1992 1994 1996 1998 2000 2002 2004 2006 2008 2010 2012
Фигура 1.11 Нарастване на тактовата честота на микропроцесорите на Фигура 1.1. Между 1978 г. и 1986 г. тактовата честота се подобрява
с по-малко от 15% на година, докато производителността се подобрява с 25% на година. По време на „ренесансовия период“ на 52%
подобрение на производителността на година между 1986 г. и 2003 г., тактовите честоти скочиха с почти 40% на година. Оттогава честотата
на часовника е почти равна, нараствайки с по-малко от 1% на година, докато производителността на един процесор се подобрява с по-
малко от 22% на година.
Разпределянето на мощността, премахването на топлината и предотвратяването на горещи точки имат
стават все по-трудни предизвикателства. Мощността сега е основното ограничение за
използване на транзистори; в миналото това е била зона със суров силиций. Следователно съвременните
микропроцесори предлагат много техники за подобряване на енергийната ефективност въпреки изтощения
тактови честоти и постоянни захранващи напрежения:
1. Не правете нищо добре. Повечето микропроцесори днес изключват часовника на неактивни
модули за пестене на енергия и динамична мощност. Например, ако няма плаваща запетая
инструкциите се изпълняват, часовникът на модула с плаваща запетая е деактивиран. Ако
някои ядра не работят, часовниците им са спрени.
2. Динамично мащабиране на напрежението и честотата (DVFS). Идва втората техника
директно от горните формули. Лични мобилни устройства, лаптопи и дори
сървърите имат периоди на ниска активност, когато няма нужда да работят на
най-висока тактова честота и напрежение. Съвременните микропроцесори обикновено
предлагат няколко тактови честоти и напрежения, в които да работят, които използват по-ниски
сила и енергия. Фигура 1.12 показва потенциалните икономии на енергия чрез DVFS
за сървър, тъй като работното натоварване се свива за три различни тактови честоти: 2,4 GHz,
1,8 GHz и 1 GHz. Общата икономия на енергия на сървъра е около 10% до 15%
за всяка от двете стъпки.
3. Дизайн за типичен случай. Като се има предвид, че PMD и лаптопите често са неактивни, паметта и
съхранението предлагат режими с ниска мощност за пестене на енергия. Например,
DRAM имат серия от режими на все по-ниска мощност за удължаване на батерията
живот в PMD и лаптопи и имаше предложения за дискове, които имат a
режим, който се върти с по-ниски скорости, когато е неактивен, за да пести енергия. Уви, не можете
достъп до DRAM или дискове в тези режими, така че трябва да се върнете към напълно активни
режим за четене или запис, без значение колко ниска е скоростта на достъп. Както е споменато
100
2,4 GHz
1,8 GHz
80
1 GHz
60
тМ
%
акои
тсон)щ п
о(
40
20
DVS спестявания (%)

0
Неактивен 7 14 21 29 36 43 50 57 64 71 79 86 93 100
Изчислително натоварване (%)
Фигура 1.12 Икономия на енергия за сървър, използващ микропроцесор AMD Opteron,

8 GB DRAM и един ATA диск. При 1,8 GHz сървърът може да се справи само с до две трети от натоварването,
без да причинява нарушения на нивото на обслужване, а при 1,0 GHz може
безопасно се справят само с една трета от работното натоварване. (Фигура 5.11 в Barroso and Hölzle [2009].)
по-горе, микропроцесорите за компютри са проектирани вместо това за повече
типичен случай на тежка употреба при високи работни температури, разчитайки на вграден чип
температурни сензори за откриване кога активността трябва да се намали автоматично, за да се избегне
прегряване. Това „аварийно забавяне“ позволява на производителите да проектират за по-типичен случай
и след това да разчитат на тази безопасност
механизъм, ако някой наистина изпълнява програми, които консумират много повече
мощност, отколкото е типично.
4. Овърклок. Intel започна да предлага режим Turbo през 2008 г., където чип
решава, че е безопасно да работи на по-висока тактова честота за кратко време, евентуално на
само няколко ядра, докато температурата започне да се повишава. Например 3,3 GHz
Core i7 може да работи на кратки импулси за 3,6 GHz. Всъщност най-ефективният
микропроцесорите всяка година от 2008 г. на Фигура 1.1 предлагат временно овърклокване с около 10% над
номиналната тактова честота. За необвързани
резбован код, тези микропроцесори могат да изключат всички ядра освен едно и да го стартират
при още по-висока тактова честота. Имайте предвид, че докато операционната система може да се изключи
Турбо режимът няма известие, след като е активиран, така че програмистите
може да се изненадат да видят, че техните програми се различават в производителността поради помещението
температура!
Въпреки че динамичната сила традиционно се смята за основен източник на
разсейването на мощността в CMOS, статичната мощност се превръща във важен проблем, защото
ток на утечка протича дори когато транзисторът е изключен:
Powerstatic Ток статичен × Напрежение
Тоест статичната мощност е пропорционална на броя на устройствата.
По този начин увеличаването на броя на транзисторите увеличава мощността, дори и да са
празен ход и токът на утечка се увеличава в процесори с по-малки размери на транзистори.
В резултат на това системи с много ниска мощност дори изключват захранването
(захранване) към неактивни модули за контрол на загубата поради изтичане. През 2011 г.,
целта за изтичане е 25% от общата консумация на енергия, като изтичането при високопроизводителни
конструкции понякога далеч надхвърля тази цел. Изтичането може да бъде толкова високо
като 50% за такива чипове, отчасти поради големите SRAM кешове, които се нуждаят от захранване
за поддържане на стойностите за съхранение. (S в SRAM е за статичен.) Единствената надежда да
спирането на изтичането е да се изключи захранването на подгрупи от чипове.
И накрая, тъй като процесорът е само част от цялата енергийна цена на a
система, може да има смисъл да използвате по-бърз, по-малко енергийно ефективен процесор
оставете останалата част от системата да премине в режим на заспиване. Тази стратегия е известна като
състезание до спиране.
Значението на мощността и енергията увеличи контрола върху ефективността на иновациите, така че
основната оценка сега е задачи на джаул или производителност на ват, за разлика от производителността на
mm2 силиций . Това ново
метриката засяга подходите към паралелизма, както ще видим в глави 4 и 5.

1.6 Тенденции в разходите
Въпреки че разходите обикновено са по-малко важни в някои компютърни дизайни - по-специално
суперкомпютри – чувствителните към разходите проекти са от нарастващо значение. Наистина, в
през последните 30 години, използването на технологични подобрения за по-ниски разходи, както и
увеличаване на производителността, е основна тема в компютърната индустрия.
Учебниците често пренебрегват половината цена от ефективността, защото разходите
промяна, като по този начин датира книги за запознанства, и защото проблемите са фини и се различават в различните
индустриални сегменти. И все пак, разбирането на цената и нейните фактори е от съществено значение за
компютърни архитекти, за да вземат интелигентни решения за това дали нов или не
функцията трябва да бъде включена в проекти, където цената е проблем. (Представете си архитекти
проектиране на небостъргачи без никаква информация за разходите за стоманени греди и

бетон!)
Този раздел обсъжда основните фактори, които влияят върху цената на компютъра
и как тези фактори се променят във времето.
Въздействието на времето, обема и комерсиализацията
Цената на произведения компютърен компонент намалява с течение на времето дори без големи подобрения
в основната технология за внедряване. Основният
Принципът, който намалява разходите, е кривата на обучение – производствените разходи
намаляват с времето. Самата крива на обучение се измерва най-добре чрез промяна в
добив— процентът на произведените устройства, които оцеляват след процедурата за тестване. Независимо
дали става въпрос за чип, платка или система, дизайни, които имат два пъти по-висока производителност
ще има половината от цената.
Разбирането как кривата на обучение подобрява добива е от решаващо значение за проектирането
разходи през живота на продукта. Един пример е цената на мегабайт DRAM
е спаднал в дългосрочен план. Тъй като DRAM паметите обикновено се оценяват в тясна връзка с цената - с
изключение на периоди, когато има недостиг или
свръхпредлагане – цената и цената на DRAM се проследяват отблизо.
Цените на микропроцесорите също падат с течение на времето, но тъй като те са по-малко
стандартизирани от DRAM, връзката между цена и цена е по-сложна.
В период на значителна конкуренция обаче цената има тенденция да следи отблизо разходите
доставчиците на микропроцесори вероятно рядко продават на загуба.
Обемът е вторият ключов фактор при определяне на разходите. Увеличаването на обемите влияе
разходи по няколко начина. Първо, те намаляват времето, необходимо за преминаване по кривата на
обучение, което е отчасти пропорционално на броя на произведените системи (или чипове). Второ, обемът
намалява разходите, тъй като увеличава покупките и
ефективност на производството. Като правило някои дизайнери са преценили това
цената намалява с около 10% за всяко удвояване на обема. Освен това, обем
намалява размера на разходите за разработка, които трябва да бъдат амортизирани от всеки компютър, като
по този начин позволява разходите и продажната цена да бъдат по-близки.
Стоките са продукти, които се продават от множество доставчици в големи количества
и по същество са идентични. На практика всички продукти, продавани по рафтовете на магазините за
хранителни стоки, са стоки, както и стандартните DRAM, флаш памети, дискове,

монитори и клавиатури. През последните 25 години голяма част от персоналните компютри

индустрията се превърна в стоков бизнес, фокусиран върху създаването на настолни и преносими
компютри, работещи с Microsoft Windows.
Тъй като много доставчици доставят практически идентични продукти, пазарът е висок
конкурентен. Разбира се, тази конкуренция намалява разликата между разходите и продажната
цена, но също така намалява разходите. Намаления възникват, защото един стоков пазар има както
обем, така и ясна продуктова дефиниция, което позволява множество
доставчиците да се конкурират в изграждането на компоненти за стоковия продукт. Като
в резултат на това общата цена на продукта е по-ниска поради конкуренцията между
доставчиците на компонентите и обемната ефективност, която доставчиците могат
постигам. Това съперничество доведе до това, че ниският клас на компютърния бизнес е в състояние
за постигане на по-добро съотношение цена-производителност в сравнение с други сектори и доведе до по-голям растеж
в ниския край, макар и с много ограничени печалби (както е типично за всяка стока
бизнес).
Цена на интегрална схема

Защо една книга за компютърна архитектура ще има раздел за интегрална схема
разходи? В един все по-конкурентен компютърен пазар, където стандартът
части - дискове, флаш памети, DRAM и т.н. - стават значими
част от цената на всяка система, разходите за интегрални схеми стават все по-голяма част от цената,
която варира между компютрите, особено в големия обем,
чувствителна към разходите част от пазара. Всъщност с лични мобилни устройства
нарастващото разчитане на цели системи на чип (SOC), цената на интегрирания
вериги е голяма част от цената на PMD. Следователно компютърните дизайнери трябва да разберат
цената на чиповете, за да разберат цената на настоящите компютри.
Въпреки че разходите за интегрални схеми са спаднали експоненциално,
основният процес на производство на силиций е непроменен: една пластина все още се тества и
нарязани на матрици , които са опаковани (вижте фигури 1.13, 1.14 и 1.15). По този начин,
цената на пакетирана интегрална схема е
Разходи за матрица + Разходи за тестване на матрица + Разходи за опаковане и окончателен тест

Цена на интегрална схема =
Краен резултат от теста
В този раздел се фокусираме върху цената на матриците, като обобщаваме ключовите проблеми при тестването
и опаковка накрая.
Първо трябва да се научите как да прогнозирате броя на добрите чипове на вафла
научаване колко матрици пасват на пластина и след това научаване как да прогнозирате процента
на тези, които ще работят. Оттам е лесно да се предвидят разходите:
Цена на вафла
Цена на матрицата = -------------------------------------------------- --------------
×
Матрица за пластина Добив на матрица
Най-интересната характеристика на този първи член от уравнението за цената на чипа е неговата чувствителност
към размера на матрицата, показана по-долу.

Фигура 1.13 Снимка на матрица на микропроцесор Intel Core i7, която е оценена в глави 2 до 5.
Размерите са 18,9 mm на 13,6 mm (257 mm2 ) при 45 nm процес. (С любезното съдействие на
Intel.)
Контролер на паметта
Извън
ред
планиране и Изпълнителни
единици
ангажимент
за инструкции
М М
и и
с с
Ядро Ядро Ядро Ядро Декодиране
°С °С
М Q на
I/O I/O Подреждане L1
д u инструкции,
кеш
и изпълнение
м д преименуване
на паметта данни
о u
на регистър и микрокод
r д
г
L1 inst L2 кеш &

Клон
Q Споделен L3 Q кеш & Виртуален
П П inst памет прекъсване

кеш fetch
предсказание
аз аз
на обслужването
Фигура 1.14 Етажен план на матрицата Core i7 на Фигура 1.13 отляво с близък план на етажния план на второто ядро вдясно.
Фигура 1.15 Тази пластина от 300 mm съдържа 280 пълни матрици Sandy Bridge, всяка 20,7 на
10,5 mm при 32 nm процес. (Sandy Bridge е наследникът на Intel на Nehalem, използван в
Core i7.) При 216 mm2 , формулата за матрици на пластина оценява 282. (С любезното съдействие на Intel.)
Броят матрици на пластина е приблизително равен на площта на разделената пластина

от площта на матрицата. Може да се оцени по-точно от
2
× Диаметър на вафлата/2 ) π × диаметър на пластината
= π( ----------------------------------------------
Матрица на вафла
– -------------------------------------------------- ---------
Зона на матрицата
2 Площ
× на матрицата
Първият член е съотношението на площта на пластината (πr2 ) към площта на матрицата. Второто компенсира
за проблема с „квадратно колче в кръгла дупка“ — правоъгълни матрици близо до

периферията на кръгли пластини. Разделяне на обиколката (πd ) на диагонала на квадрат
матрицата е приблизително броят на матриците по ръба.
Пример Намерете броя на матриците на 300 mm (30 cm) пластина за матрица, която е 1,5 cm на
страна и за матрица, която е 1,0 см отстрани.
Отговор Когато площта на матрицата е 2,25 cm2 :
2
× π × 30 706.9 94.2
= π ( ) 30 2⁄
– ---------------------------- ----------------------- = ------------- –
= ---------- 270
2.25 2 2,25 × 2.25 2.12
Тъй като площта на по-голямата матрица е 2,25 пъти по-голяма, има приблизително 2,25 като
много по-малки матрици на пластина:
2
× π × 30 706.9 94.2
= π ( ) 30 2⁄
– ---------------------------- ----------------------- = ------------- –
= ---------- 640
1,00 2 1,00 × 1,00 1.41
Тази формула обаче дава само максималния брой матрици на пластина.

Критичният въпрос е: Каква е частта от добрите матрици върху пластина или матрицата
добив? Прост модел на добива на интегрална схема, който предполага наличието на дефекти
произволно разпределени върху вафлата и този добив е обратно пропорционален на
сложността на производствения процес води до следното:
= н
× ⁄ (1 1 Дефекти
Добив на матрицата Добив на пластини + на единица площ Площ ×
на матрицата )
Тази формула на Бозе-Айнщайн е емпиричен модел, разработен чрез разглеждане на

добив на много производствени линии [Sydow 2006]. Сметките за добив на вафли
вафли, които са напълно лоши и затова не е необходимо да се тестват. За простота ще го направим
просто приемете, че добивът на вафла е 100%. Дефектите на единица площ са мярка за възникващите
произволни производствени дефекти. През 2010 г. стойността обикновено е била 0,1 до 0,3
дефекти на квадратен инч, или 0,016 до 0,057 дефекта на квадратен сантиметър, за
40 nm процес, тъй като зависи от зрелостта на процеса (припомнете си обучението
крива, спомената по-рано). И накрая, N е параметър, наречен сложност на процеса
фактор, мярка за производствена трудност. За 40 nm процеси през 2010 г., N
варира от 11,5 до 15,5.
Пример Намерете добива на матрицата за матрици, които са 1,5 cm отстрани и 1,0 cm отстрани, като приемем-
с плътност на дефектите от 0,031 на cm2 и N е 13,5.
Отговор Общата площ на матрицата е 2,25 cm2 и 1,00 cm2 . За по-голямата матрица добивът е
= (1⁄ 1 0,031 2,25) + × 13.5

Добив на матрица
= 0,40
За по-малката матрица добивът е
= (1⁄ 1 0,031 1,00) + × 13.5

Добив на матрица
= 0,66
Тоест по-малко от половината от всички големи матрици са добри, но две трети от малките
матриците са добри.
Долната линия е броят на добрите матрици на пластина, който идва от умножаването

на матриците на пластина по добива на матрицата, за да се включат ефектите от дефектите.
Примерите по-горе предвиждат около 109 добри матрици от 2,25 cm2 от 300 mm пластина
и 424 добри матрици от 1,00 cm2. Много микропроцесори попадат между тези два размера.
Вградените 32-битови процесори от нисък клас понякога са толкова малки, колкото , и
0,10 cm2, процесорите, използвани за вграден контрол (в принтери, микровълнови печки
и т.н.), често са под 0,04 .
cm2 Като се има предвид огромният натиск върху цените на стоковите продукти като
DRAM и SRAM, дизайнерите са включили резервирането като начин за повишаване на добива.
В продължение на няколко години DRAM редовно включват някои излишни клетки на
паметта, така че да могат да бъдат коригирани определен брой недостатъци. Дизайнерите
са използвали подобни техники както в стандартните SRAM, така и в големите SRAM масиви,
използвани за кешове в микропроцесорите. Очевидно наличието на излишни записи може
да се използва за значително увеличаване на добива.
Обработката на пластина с диаметър 300 mm (12 инча) в най-съвременна
технология струва между $5000 и $6000 през 2010 г. Ако приемем, че обработената
пластина струва $5500, цената на матрицата от 1,00 cm2 ще бъде около $13, но цената
на матрица от 2,25 cm2 матрица ще бъде около $51, или почти четири пъти цената за
матрица, която е малко над два пъти по-голяма.
Какво трябва да помни един компютърен дизайнер относно разходите за чипове?
Производственият процес диктува разходите за пластини, добив на пластини и дефекти на
единица площ, така че единственият контрол на дизайнера е площта на матрицата. На практика,
тъй като броят на дефектите на единица площ е малък, броят на добрите матрици на пластина, а
оттам и цената на матрица, нараства приблизително като квадрат на площта на матрицата.
Компютърният дизайнер влияе върху размера на матрицата, а оттам и върху цената, както от
това какви функции са включени или изключени от матрицата, така и от броя на I/O пинове.
Преди да имаме част, която е готова за използване в компютър, матрицата трябва да бъде
тествана (за да се отделят добрите матрици от лошите), опакована и тествана отново след
опаковането. Всички тези стъпки добавят значителни разходи.
Горният анализ се фокусира върху променливите разходи за производство на
функционална матрица, която е подходяща за интегрални схеми с голям обем. Има обаче една
много важна част от фиксираните разходи, която може значително да повлияе на цената на
интегрална схема за малки обеми (по-малко от 1 милион части), а именно цената на комплект
маска. Всяка стъпка в процеса на интегрална схема изисква отделна маска. По този начин, за
съвременни производствени процеси с висока плътност с четири до шест метални слоя,
разходите за маски надхвърлят $1 милион. Очевидно тази голяма фиксирана цена влияе на
разходите за прототипиране и отстраняване на грешки и, за производство в малък обем, може
да бъде значителна част от производствените разходи. Тъй като разходите за маски вероятно
ще продължат да се увеличават, дизайнерите могат да включат реконфигурируема логика, за
да подобрят гъвкавостта на дадена част или да изберат да използват гейт масиви (които имат
по-малко персонализирани нива на маска) и по този начин да намалят разходите за маски.
Цена срещу цена
С комодитизацията на компютрите маржът между разходите за производство

на продукт и цената, на която продуктът се продава, намалява. Тези
маржовете плащат за научноизследователска и развойна дейност (R&D), маркетинг, продажби,

поддръжка на производствено оборудване, наем на сгради, разходи за финансиране, печалби
преди данъци и данъци. Много инженери са изненадани да открият, че повечето компании
харчат само 4% (в бизнеса с персонални компютри) до 12% (в бизнеса със сървъри от висок клас)
от приходите си за R&D, което включва цялото инженерство.
Разходите за производство спрямо разходите за експлоатация
За първите четири издания на тази книга цената означаваше цената за изграждане на компютър,
а цената означаваше цената за закупуване на компютър. С появата на складови компютри,
които съдържат десетки хиляди сървъри, разходите за работа с компютрите са значителни в
допълнение към разходите за покупка.
Както показва Глава 6 , амортизираната покупна цена на сървъри и мрежи е малко над 60%
от месечните разходи за работа с компютър от складов мащаб, като се предполага кратък живот
на ИТ оборудването от 3 до 4 години. Около 30% от месечните оперативни разходи са за
потребление на електроенергия и амортизирана инфраструктура за разпределяне на енергия и
охлаждане на ИТ оборудването, въпреки че тази инфраструктура се амортизира за 10 години.
По този начин, за да намалят оперативните разходи в компютър от складов мащаб, компютърните
архитекти трябва да използват енергията ефективно.
1.7 Надеждност
В исторически план интегралните схеми са били един от най-надеждните компоненти на
компютъра. Въпреки че техните изводи може да са уязвими и могат да възникнат грешки по
комуникационните канали, процентът на грешки вътре в чипа е много нисък. Тази
конвенционална мъдрост се променя, тъй като се насочваме към размери на характеристиките
от 32 nm и по-малки, тъй като както преходните дефекти, така и постоянните дефекти ще станат
по-често срещани, така че архитектите трябва да проектират системи, за да се справят с тези
предизвикателства. Този раздел дава бърз преглед на проблемите, свързани с надеждността,
оставяйки официалната дефиниция на термините и подходите към Раздел D.3 в Приложение D.
Компютрите са проектирани и конструирани на различни нива на абстракция. Можем да се
спуснем рекурсивно надолу през компютър, виждайки как компонентите се разширяват до цели
подсистеми, докато не се натъкнем на отделни транзистори. Въпреки че някои неизправности
са широко разпространени, като загубата на мощност, много от тях могат да бъдат ограничени
до единичен компонент в модул. По този начин пълният отказ на модул на едно ниво може да
се счита просто за грешка на компонента в модул от по-високо ниво. Това разграничение е
полезно в опитите да се намерят начини за изграждане на надеждни компютри.
Един труден въпрос е да се реши кога една система работи правилно. Тази философска
точка се конкретизира с популярността на интернет услугите.
Доставчиците на инфраструктура започнаха да предлагат споразумения за ниво на обслужване
(SLA) или цели за ниво на обслужване (SLO), за да гарантират, че техните мрежови или енергийни
услуги ще бъдат надеждни. Например, те биха платили на клиента неустойка, ако не изпълни
споразумението повече от няколко часа на месец. По този начин SLA може да се използва, за да
се реши дали системата работи или не работи.
Системите се редуват между две състояния на обслужване по отношение на SLA:
1. Изпълнение на услугата, когато услугата се доставя, както е посочено 2.
Прекъсване на услугата, когато предоставената услуга е различна от SLA
Преходите между тези две състояния се причиняват от повреди (от състояние 1 към
състояние 2) или възстановявания (2 към 1). Количественото определяне на тези преходи
води до двете основни мерки за надеждност:
Надеждността на модула е мярка за непрекъснатото изпълнение на услугата (или,

еквивалентно, на времето до повреда) от референтен начален момент. Следователно
средното време до отказ (MTTF) е мярка за надеждност. Реципрочната стойност на MTTF
е процентът на отказите, обикновено отчитан като откази на милиард часове работа
или FIT (за откази във времето). По този начин MTTF от 1 000 000 часа се равнява на
109 /106 или 1000 FIT. Прекъсването на услугата се измерва като средно време за
ремонт (MTTR). Средното време между отказите (MTBF) е просто сумата от MTTF + MTTR.
Въпреки че MTBF се използва широко, MTTF често е по-подходящият термин. Ако
колекция от модули има експоненциално разпределен живот — което означава, че
възрастта на модула не е важна за вероятността от повреда — общият процент на
повреда на колекцията е сумата от нивата на повреда на модулите.
Наличността на модула е мярка за изпълнение на услугата по отношение на редуването

между двете състояния на изпълнение и прекъсване.
За нередундантни системи с ремонт наличността на модула е
MTTF
= -------------------------------------------
Наличност на модула
( MTTF MTTR + )
Имайте предвид, че надеждността и достъпността вече са количествено измерими

показатели, а не синоними на надеждност. От тези дефиниции можем да оценим
надеждността на системата количествено, ако направим някои допускания относно
надеждността на компонентите и че отказите са независими.
Пример Да приемем дискова подсистема със следните компоненти и MTTF:
10 диска, всеки с оценка на 1 000 000 часа MTTF
1 ATA контролер, 500 000 часа MTTF
1 захранване, 200 000 часа MTTF
1 вентилатор, 200 000 часа MTTF
1 ATA кабел, 1 000 000 часа MTTF
Използвайки опростяващите допускания, че животът е експоненциално разпределен и че

отказите са независими, изчислете MTTF на системата като цяло.
Отговор Сумата от нивата на неуспех е

1 1 1 1 1
× -----------------------
------------------- +
= +++ -----------------------
------------------- -------------------
Система за процент на неуспех 10
1 000 000 500 000 200 000 1 000 000 200 000
10 2 5 5 1 ++++ 23 23 000
= ------------------------------------------- = ----------------------- = --------------------------------------------------
1 000 000 часа 1 000 000 1 000 000 000 часа
или 23 000 FIT. MTTF за системата е точно обратното на степента на отказ:
1 1 000 000 000 часа

= ---------------------------------------------- = 43 500 часа Система
= --------------------------------------------------
MTTF система 23 000
за процент на откази
или малко под 5 години.
Основният начин за справяне с провала е излишъкът, или във времето (повторете

операция, за да видите дали все още е грешна) или в ресурсите (имате други компоненти за
поемете от неуспешния). След като компонентът бъде сменен и системата е напълно
ремонтирана, надеждността на системата се приема за толкова добра, колкото
нов. Нека да определим количествено ползите от съкращенията с пример.
Пример Дисковите подсистеми често имат резервни захранвания за подобряване на надеждността.

Използвайки компонентите и MTTF от по-горе, изчислете надеждността на
резервни захранвания. Да приемем, че едно захранване е достатъчно за работа на диска
подсистема и че добавяме едно резервно захранване.
Отговор Имаме нужда от формула, за да покажем какво да очакваме, когато можем да толерираме провал и все пак
предоставят услуги. За да опростим изчисленията, приемаме, че животът на
компонентите са експоненциално разпределени и че няма зависимост
между повредите на компонентите. MTTF за нашите резервни захранвания е
средното време до повреда на едно захранване, разделено на шанса другото да се повреди
се провали, преди първият да бъде заменен. По този начин, ако шансът за втори провал преди
ремонтът е малък, тогава MTTF на двойката е голям.
Тъй като имаме две захранвания и независими повреди, средното време
до отказ на един диск е MTTFзахранване/2. Добро приближение на вероятността

на втори отказ е MTTR през средното време, докато другото захранване се повреди.
Следователно, разумно приближение за резервна двойка захранвания е
2 2
MTTF захранване
⁄2 MTTF захранване
⁄2 MTTF захранване
------------------------------------------------
=== ----------------------------------------------------- ------------------------------------------------
----
MTTF двойка захранване ×
MTTR захранване
----------------------------------------------
MTTR захранване 2 MTTR захранване
Използвайки числата на MTTF по-горе, ако приемем, че отнема средно 24 часа за a

човешкият оператор да забележи, че дадено захранване е повредено и да го смени,
надеждността на устойчивата на грешки двойка захранвания е
2
= 200 0002
MTTF двойка захранване = --------------------- 830 000 000
-------------------------------------------------- -
×
2 MTTR захранване 2 24 ×
което прави двойката около 4150 пъти по-надеждна от едно захранване.
След като определихме количествено цената, мощността и надеждността на компютърната технология, ние сме готови
да определим количествено производителността.
1.8 Измерване, отчитане и обобщаване на ефективността
Когато казваме, че един компютър е по-бърз от друг, какво имаме предвид? Потребителят на
настолен компютър може да каже, че компютърът е по-бърз, когато програмата се изпълнява за
по-малко време, докато администратор на Amazon.com може да каже, че компютърът е по-бърз,
когато извършва повече транзакции на час. Потребителят на компютъра се интересува от
намаляване на времето за реакция – времето между началото и завършването на дадено събитие
– наричано още време за изпълнение. Операторът на компютър от складов мащаб може да се
интересува от увеличаване на производителността - общото количество работа, извършена за
дадено време.
При сравняване на алтернативи на дизайна често искаме да свържем производителността на
два различни компютъра, да речем, X и Y. Фразата „X е по-бърз от Y“ се използва тук, за да означава,
че времето за реакция или времето за изпълнение е по-ниско на X, отколкото на Y за дадената
задача. По-специално, „X е n пъти по-бързо от Y“ ще означава:
Време за изпълнение Y
= n
--------------------------------------
Време за изпълнение X
Тъй като времето за изпълнение е реципрочната стойност на производителността, важи следната

връзка:
1
----------------------------------
Време за изпълнение Y Изпълнение Y PerformanceX

n= ------------------------------------------------ = ---------------------------------- = ----------------------------------
1
Време за изпълнение X ---------------------------------- Изпълнение Y
PerformanceX
Фразата „производителността на X е 1,3 пъти по-висока от Y“ тук означава, че броят на задачите,

изпълнени за единица време на компютър X, е 1,3 пъти по-голям от броя, изпълнени на Y.
За съжаление, времето не винаги е показателят, цитиран при сравняване на

производителността на компютрите. Нашата позиция е, че единствената последователна и
надеждна мярка за производителност е времето за изпълнение на реални програми и че всички
предложени алтернативи на времето като метрика или на реалните програми като измервани
елементи в крайна сметка са довели до подвеждащи твърдения или дори грешки в компютърния дизайн .
Дори времето за изпълнение може да бъде определено по различни начини в зависимост от
това какво броим. Най-простата дефиниция на времето се нарича време на стенния часовник,
време за реакция или изминало време, което е латентността за изпълнение на задача, включително
достъп до диска, достъп до паметта, входно/изходни дейности, операционна система над главата
– всичко. При мултипрограмирането процесорът работи върху друга програма, докато чака I/O и
може да не минимизира непременно изминалото време на една програма. Следователно се
нуждаем от термин, за да разгледаме тази дейност. Времето на процесора разпознава това
разграничение и означава времето, през което процесорът изчислява, без да се включва времето
за изчакване на I/O или изпълнение на други програми. (Ясно е, че времето за отговор, видяно от
потребителя, е изминалото време на програмата, а не времето на процесора.)
Потребителите на компютри, които рутинно изпълняват едни и същи програми, биха били перфектните
кандидати за оценка на нов компютър. За да оценят нова система, потребителите биха
просто сравняват времето за изпълнение на техните натоварвания – комбинацията от програми
и команди на операционната система, които потребителите изпълняват на компютър. Малцина са в това
щастлива ситуация обаче. Повечето трябва да разчитат на други методи за оценка на компютри, а често и на
други оценители, надявайки се, че тези методи ще предскажат производителността за тяхното използване на
новия компютър.
Бенчмаркове
Най-добрият избор от показатели за измерване на производителността са реални приложения, като например
като Google Goggles от раздел 1.1. Опитите за стартиране на програми, които са
много по-прости от реално приложение са довели до капани в производителността. Примери

включват:
Ядра, които са малки ключови части от реални приложения Програми
играчки, които са 100-редови програми от началото на програмирането
присвоявания, като бързо сортиране
Синтетични бенчмаркове, които са фалшиви програми, измислени, за да се опитат да съпоставят
профил и поведение на реални приложения, като Dhrystone
И тримата са дискредитирани днес, обикновено защото авторът и архитектът на компилатора
могат да заговорничат, за да накарат компютъра да изглежда по-бързо в тези резервни програми от
върху реални приложения. Депресиращо за вашите автори - които се отказаха от заблудата
относно използването на синтетични програми за характеризиране на производителността в четвъртото издание
на тази книга, тъй като смятахме, че компютърните архитекти се съгласиха, че е непочтена-
синтетичната програма Dhrystone все още е най-широко цитираният бенчмарк за
вградени процесори!
Друг въпрос са условията, при които се провеждат бенчмарковете. един
начинът за подобряване на производителността на бенчмарк е със специфични за бенчмарк флагове; тези
флагове често причиняват трансформации, които биха били незаконни
много програми или ще забави работата на други. За да ограничат този процес и да увеличат значимостта
на резултатите, често разработчиците на бенчмаркове
изискват от доставчика да използва един компилатор и един набор от флагове за всички програми в
същия език (C++ или C). В допълнение към въпроса за флаговете на компилатора,
друг въпрос е дали са разрешени модификации на изходния код. Има
три различни подхода за справяне с този въпрос:
1. Не са разрешени модификации на изходния код.
2. Модификациите на изходния код са разрешени, но по същество са невъзможни. За
например бенчмарковете на бази данни разчитат на стандартни програми за бази данни, които са
десетки милиони редове код. Компаниите за бази данни са много малко вероятни
за да направите промени за подобряване на производителността на конкретен компютър.
3. Модификациите на изходния код са разрешени, стига модифицираната версия да произвежда
същият изход.
Ключовият въпрос, пред който са изправени дизайнерите на бенчмаркове, когато решават да

разрешат модификация на източника, е дали такива модификации ще отразяват реалната практика
и ще осигурят полезна представа за потребителите, или такива модификации просто намаляват
точността на бенчмарковете като предиктори на реалната производителност.
За да се преодолее опасността от поставяне на твърде много яйца в една кошница, колекции от
приложения за сравнение, наречени комплекти за сравнение, са популярна мярка за производителност
на процесори с различни приложения. Разбира се, такива пакети са толкова добри, колкото и
съставните отделни показатели. Независимо от това, ключово предимство на такива пакети е, че
слабостта на всеки един бенчмарк се намалява от присъствието на другите бенчмаркове. Целта на
пакета за сравнение е той да характеризира относителната производителност на два компютъра,
особено за програми, които не са в пакета, който клиентите вероятно ще изпълняват.
Предупредителен пример са еталонните показатели на консорциума за вградени

микропроцесори на Electronic Design News (или EEMBC, произнася се „посолство“). Това е набор от
41 ядра, използвани за прогнозиране на производителността на различни вградени приложения:
автомобилни/промишлени, потребителски, мрежови, офис автоматизация и телекомуникации.
EEMBC съобщава за непроменена производителност и производителност „пълна ярост“, където
почти всичко е възможно. Тъй като тези бенчмаркове използват ядра и поради опциите за отчитане,
EEMBC няма репутацията на добър предсказател на относителната производителност на различни
вградени компютри в областта. Тази липса на успех е причината Dhrystone, който EEMBC се опитваше
да замени, все още се използва.
Един от най-успешните опити за създаване на стандартизирани пакети от приложения

за бенчмарк е SPEC (Standard Performance Evaluation Corporation), който има своите корени в
усилията в края на 80-те години на миналия век да предостави по-добри бенчмаркове за
работни станции. Точно както компютърната индустрия се е развила с течение на времето,

така се е развила и необходимостта от различни пакети за сравнение и сега има SPEC
показатели за покриване на много класове приложения. Всички комплекти за сравнение на
SPEC и техните отчетени резултати се намират на www.spec.org.
Въпреки че фокусираме нашата дискусия върху SPEC бенчмарковете в много от следващите
раздели, много бенчмаркове също са разработени за компютри, работещи с операционна система
Windows.
Настолни бенчмаркове
Настолните бенчмаркове се разделят на два широки класа: бенчмаркове с интензивно използване

на процесора и бенчмаркове с интензивна графика, въпреки че много графични бенчмаркове
включват интензивна активност на процесора. SPEC първоначално създаде набор от показатели,
фокусиран върху производителността на процесора (първоначално наречен SPEC89), който еволюира
в своето пето поколение: SPEC CPU2006, който следва SPEC2000, SPEC95 SPEC92 и SPEC89. SPEC
CPU2006 се състои от набор от 12 целочислени бенчмарка (CINT2006) и 17 бенчмарка с плаваща
запетая (CFP2006). Фигура 1.16 описва текущите тестове на SPEC и тяхното потекло.
SPEC бенчмарковете са реални програми, модифицирани да бъдат преносими и да минимизират

ефекта на I/O върху производителността. Целочислените бенчмаркове варират от част от C
Име на бенчмарк по SPEC поколение
Описание на бенчмарка SPEC2006 SPEC2006 SPEC2000 SPEC95 SPEC92 SPEC89
GNU C компилатор gcc
Обработка на интерпретиран низ perl еспресо
Комбинаторна оптимизация mcf ли
Компресия за сортиране на блокове bzip2 компресирам eqntott
Игра Go (AI) отивам

вихър отивам
sc
Видео компресия h264avc gzip ijpeg
Игри/намиране на път звезда еон m88ksim
Търсете генна последователност хмър twolf
Квантова компютърна симулация libquantum вихър
Библиотека за симулация на дискретни събития omnetpp vpr
Игра на шах (AI) sjeng хитър
Анализ на XML xalancbmk анализатор
CFD/взривни вълни bwaves fpppp
Числена относителност кактусADM tomcatv
Код на крайните елементи калкуликс додук
Рамка за решаване на диференциални уравнения dealll nasa7
Квантова химия игри подправка
EM решаване (честота/времева област) GemsFDTD плувам матрица300
Мащабируема молекулярна динамика (~NAMD) грамаци apsi хидро2д
Решетъчен метод на Болцман (флуиден/въздушен поток) lbm mgrid su2cor
Големи вихрови симулации/турбулентни CFD LESlie3d wupwise приложение вълна5
Решетъчна квантова хромодинамика мляко Приложи turb3d
Молекулярна динамика намд галгел
Проследяване на лъчи на изображения povray меса
Резервна линейна алгебра соплекс изкуство
Гласово разпознаване сфинкс3 изравнявам се
Квантова химия/обектно ориентиран тонто facerec
Проучване и прогнозиране на времето wrf усилвател
Магнитна хидродинамика (астрофизика) zeusmp Лукас
fma3d
sixtrack
Фигура 1.16 Програми SPEC2006 и еволюцията на SPEC бенчмарковете във времето, с цели програми над линията и
програми с плаваща запетая под линията. От 12 цели програми SPEC2006, 9 са написани на C, а останалите на C++.
За програмите с плаваща запетая разделянето е 6 във Fortran, 4 в C++, 3 в C и 4 в смесени C и Fortran. Фигурата
показва всичките 70 програми в изданията от 1989, 1992, 1995, 2000 и 2006 г. Описанията на бенчмарковете вляво
са само за SPEC2006 и не се отнасят за по-ранни версии. Програми в един и същи ред от различни поколения на
SPEC обикновено не са свързани; например fpppp не е CFD код като bwaves. Gcc е възрастният гражданин на групата.
Само 3 програми с цели числа и 3 програми с плаваща запетая са оцелели след три или повече поколения. Имайте
предвид, че всички програми с плаваща запетая са нови за SPEC2006. Въпреки че някои се пренасят от поколение
на поколение, версията на програмата се променя и или входът, или размерът на бенчмарка често се променят, за
да се увеличи времето за изпълнение и да се избегнат смущения в измерването или доминиране на времето за
изпълнение от някакъв фактор, различен от процесорното време.
компилатор към шахматна програма към квантова компютърна симулация. Бенчмарковете с

плаваща запетая включват структурирани мрежови кодове за моделиране с крайни елементи,
кодове на метода на частиците за молекулярна динамика и редки кодове за линейна алгебра за
динамика на течностите. Пакетът SPEC CPU е полезен за сравнителен анализ на процесори за
както настолни системи, така и еднопроцесорни сървъри. Ще видим данни за много от
тези програми в този текст. Имайте предвид обаче, че тези програми споделят малко с
програмните езици и среди и Google Goggles
приложение, описано в Раздел 1.1 . Седем използват C++, осем използват C и девет използват
Fortran! Те дори са статично свързани, а самите приложения са тъпи.
Не е ясно дали SPECINT2006 и SPECFP2006 улавят това, което е вълнуващо
за компютрите през 21 век.
В раздел 1.11 ние описваме клопките, възникнали при разработването на
SPEC бенчмарк пакет, както и предизвикателствата при поддържането на полезен и предсказващ
бенчмарк пакет.
SPEC CPU2006 е насочен към производителност на процесора, но SPEC предлага много

други показатели.
Сървърни бенчмаркове
Точно както сървърите имат множество функции, така има и множество видове бенчмаркове.
Най-простият бенчмарк е може би ориентиран към производителността на процесора
бенчмарк. SPEC CPU2000 използва бенчмарковете на SPEC CPU, за да създаде прост бенчмарк за
пропускателна способност, при който скоростта на обработка на мултипроцесор може да бъде

измерено чрез стартиране на множество копия (обикновено толкова, колкото има процесори) на
всеки SPEC CPU бенчмарк и преобразуване на процесорното време в скорост. Това води
към измерване, наречено SPECrate, и това е мярка за паралелизъм на ниво заявка от раздел 1.2.
За измерване на паралелизма на ниво нишка SPEC предлага какво
те наричат високопроизводителни изчислителни показатели около OpenMP и MPI.
Освен SPECrate, повечето сървърни приложения и бенчмаркове имат значителна I/O
активност, произтичаща от дисков или мрежов трафик, включително бенчмаркове за файлови
сървърни системи, за уеб сървъри и за бази данни и системи за обработка на транзакции. SPEC
предлага както бенчмарк за файлов сървър (SPECSFS), така и a
Сравнителен тест за уеб сървър (SPECWeb). SPECSFS е еталон за измерване
NFS (Network File System) производителност с помощта на скрипт от заявки за файлов сървър; то
тества производителността на I/O системата (както дисков, така и мрежов I/O), както и на
процесор. SPECSFS е ориентиран към производителността показател, но с важно значение
изисквания за време за реакция. (Приложение D обсъжда някои файлови и I/O системи
бенчмаркове в детайли.) SPECWeb е бенчмарк за уеб сървър, който симулира множество клиенти,
изискващи както статични, така и динамични страници от сървър, както и
клиенти, публикуващи данни на сървъра. SPECjbb измерва производителността на сървъра за уеб
приложения, написани на Java. Най-новият бенчмарк на SPEC е
SPECvirt_Sc2010, който оценява производителността от край до край на виртуализирани сървъри
за центрове за данни, включително хардуер, слой на виртуална машина и виртуализирани
гост операционна система. Друг скорошен бенчмарк на SPEC измерва мощността, която
разглеждаме в раздел 1.10.
Бенчмарковете за обработка на транзакции (TP) измерват способността на системата да
обработва транзакции, които се състоят от достъп до база данни и актуализации. Системите за резервации
на авиолинии и банкоматите са типични прости примери за TP; Повече
сложните TP системи включват сложни бази данни и вземане на решения. В
в средата на 80-те години на миналия век група загрижени инженери сформираха независимия от доставчика
Съвет за обработка на транзакции (TPC), за да се опита да създаде реалистични и справедливи показатели
за TP. TPC бенчмарковете са описани на www.tpc.org.
Първият TPC бенчмарк, TPC-A, беше публикуван през 1985 г. и оттогава е публикуван
заменени и подобрени от няколко различни бенчмарка. TPC-C, първоначално създаден
през 1992 г. симулира сложна среда за заявки. TPC-H модели ad hoc решение
поддръжка—заявките не са свързани и знанието за минали заявки не може да се използва
за оптимизиране на бъдещи заявки. TPC-E е нова он-лайн обработка на транзакции
(OLTP) работно натоварване, което симулира клиентски акаунти на брокерска фирма. Повечето
скорошно усилие е TPC Energy, което добавя енергийни показатели към всички съществуващи TPC
бенчмаркове.
Всички TPC бенчмаркове измерват производителността в транзакции в секунда. в
Освен това те включват изискване за време за реакция, така че производителността на пропускателната
способност се измерва само когато ограничението за време за реакция е спазено. За моделиране на системи
от реалния свят, по-високите нива на транзакции също се свързват с по-големи системи, в
условия както на потребителите, така и на базата данни, към която се прилагат транзакциите.
И накрая, цената на системата за бенчмарк система също трябва да бъде включена, позволявайки
точни сравнения на разходите и ефективността. TPC промени своята ценова политика така
че има единна спецификация за всички показатели на TPC и да позволи проверка на цените, които TPC
публикува.
Отчитане на резултатите от ефективността
Водещият принцип при отчитане на измерванията на ефективността трябва да бъде възпроизводимостта -
избройте всичко, което друг експериментатор би трябвало да дублира
резултати. Докладът за сравнителен анализ на SPEC изисква обширно описание на компютъра и флаговете
на компилатора, както и публикуване както на базовата линия, така и
оптимизирани резултати. В допълнение към описанията на параметрите за настройка на хардуера, софтуера
и базовата линия, докладът SPEC съдържа действителните времена на производителност, показани
както в таблична форма, така и като графика. Докладът за сравнителен анализ на TPC е още по-пълен, тъй
като трябва да включва резултати от одит за сравнителен анализ и информация за разходите.
Тези доклади са отлични източници за намиране на реалните разходи за изчислителни системи, тъй като
производителите се конкурират с висока производителност и цена-производителност.
Обобщаване на резултатите от изпълнението
В практическия компютърен дизайн трябва да оцените безброй дизайнерски решения за техните
относителни количествени ползи в набор от показатели, за които се смята, че са уместни. По същия начин
потребителите, които се опитват да изберат компютър, ще разчитат на производителността
измервания от бенчмаркове, които се надяваме да са подобни на приложенията на потребителя. И в двата

случая е полезно да имате измервания за набор от пейка-
марки, така че производителността на важни приложения да е подобна на тази на един или

повече сравнителни тестове в пакета и че променливостта в производителността може да бъде
разбрана. В идеалния случай пакетът прилича на статистически валидна извадка от пространството
на приложението, но такава извадка изисква повече сравнителни показатели, отколкото
обикновено се намират в повечето пакети, и изисква произволна извадка, която по същество не
използва нито един сравнителен пакет.
След като сме избрали да измерваме ефективността с пакет за сравнение, бихме искали да
можем да обобщим резултатите от ефективността на пакета в едно число. Един прост подход за
изчисляване на обобщен резултат би бил да се сравнят средните аритметични стойности на
времето за изпълнение на програмите в пакета.
Уви, някои SPEC програми отнемат четири пъти повече време от други, така че тези програми
биха били много по-важни, ако средноаритметичната стойност беше единственото число,
използвано за обобщаване на производителността. Алтернатива би била да се добави коефициент
на тежест към всеки бенчмарк и да се използва среднопретеглената аритметична стойност като
единствено число за обобщаване на ефективността. Тогава проблемът ще бъде как да изберете
тежести; тъй като SPEC е консорциум от конкурентни компании, всяка компания може да има
свой любим набор от тегла, което би затруднило постигането на консенсус. Един подход е да се
използват тегла, които карат всички програми да се изпълняват еднакво време на някакъв
референтен компютър, но това отклонява резултатите спрямо характеристиките на
производителността на референтния компютър.
Вместо да избираме тегла, бихме могли да нормализираме времето за изпълнение към
референтен компютър, като разделим времето на референтния компютър на времето на
компютъра, който се оценява, като се получи съотношение, пропорционално на
производителността. SPEC използва този подход, наричайки съотношението SPECRatio. Той има
особено полезно свойство, че съвпада с начина, по който сравняваме производителността на
компютъра в този текст - а именно, сравнявайки коефициенти на производителност. Да
предположим например, че SPECRatio на компютър A на бенчмарк е 1,25 пъти по-висок от
компютър B; тогава ще знаем:
Референция за времето за изпълнение

-------------------------------------------------- ---
SPECRatioA Време за изпълнение A Време за изпълнение Б ИзпълнениеA

1.25 == = ------------------------------ -------------------------------------------------- --- ------------------------------------------------ = ---------------------------------
SPECRatioB Референция за времето за изпълнение

-------------------------------------------------- ---
Време за изпълнение A ИзпълнениеB
Време за изпълнение Б
Забележете, че времето за изпълнение на референтния компютър отпада и изборът на

референтния компютър е без значение, когато сравненията се правят като съотношение, което е
подходът, който използваме постоянно. Фигура 1.17 дава пример.
Тъй като SPECRatio е съотношение, а не абсолютно време за изпълнение, средната стойност
трябва да се изчисли с помощта на средната геометрична стойност. (Тъй като SPECRatios нямат
единици, сравняването на SPECRatios аритметично е безсмислено.) Формулата е
н н
Средна геометрична
= samplei
i=1
Ултра 5
време Opteron Итаний 2 Opteron/Itanium Itanium/Opteron
Бенчмаркове (сек) време (сек) SPECRatio време (сек) SPECRatio пъти (сек) SPECRatios
wupwise 1600 51.5 31.06 56.1 28.53 0,92 0,92
плувам 3100 125,0 24.73 70.7 43,85 1.77 1.77
mgrid 1800 г 98,0 18.37 65.8 27.36 1.49 1.49
приложение 2100 94,0 22.34 50.9 41.25 1,85 1,85
меса 1400 64.6 21,69 108,0 12,99 0,60 0,60
галгел 2900 86.4 33,57 40,0 72,47 2.16 2.16
изкуство 2600 92.4 28.13 21.0 123,67 4.40 4.40
изравнявам се
1300 72.6 17.92 36.3 35,78 2.00 2.00
facerec 1900 г 73.6 25.80 86.9 21.86 0,85 0,85
усилвател 2200 136,0 16.14 132,0 16.63 1.03 1.03
Лукас 2000 г 88.8 22.52 107,0 18.76 0,83 0,83
fma3d 2100 120,0 17.48 131,0 16.09 0,92 0,92
sixtrack 1100 123,0 8,95 68.8 15,99 1,79 1,79
apsi 2600 150,0 17.36 231,0 11.27 0,65 0,65
Средна геометрична 20,86 27.12 1.30 1.30
Фигура 1.17 Времена за изпълнение на SPECfp2000 (в секунди) за Sun Ultra 5—референтния компютър на SPEC2000—
и времена за изпълнение и SPECRatios за AMD Opteron и Intel Itanium 2. (SPEC2000 умножава съотношението на времената за изпълнение
по 100, за да премахне десетичната запетая от резултата, така че 20,86 се отчита като 2086.) Последните две колони
показва съотношенията на времето за изпълнение и SPECRatios. Тази фигура показва неуместността на референтния компютър
в относителна производителност. Съотношението на времената за изпълнение е идентично на съотношението на SPECRatios, а съотношението на
средно геометрично (27,12/20,86 = 1,30) е идентично със средното геометрично на съотношенията (1,30).
В случая на SPEC, samplei е SPECRatio за програма i. Използването на средната геометрична стойност

гарантира две важни свойства:
1. Средното геометрично на съотношенията е същото като съотношението на геометричното

означава.
2. Съотношението на средните геометрични е равно на средното геометрично на съотношенията на
производителност, което предполага, че изборът на референтния компютър е

неуместен.
Следователно мотивите за използване на средното геометрично са съществени, особено
когато използваме коефициенти на ефективност, за да правим сравнения.
Пример Покажете, че съотношението на средното геометрично е равно на средното геометрично на
коефициенти на производителност и че референтният компютър на SPECRatio няма значение.
Отговор Да приемем два компютъра A и B и набор от SPECRatios за всеки.

n SPECRatio Ai
н
Средногеометрично A i=1 SPECRatio Ai
------------------------------------------- = ------------------------------------------------ = ----------------------------------
н
n SPECRatio Bi
Средна геометрична Б i=1
n SPECRatio Bi
i=1
Референция за време на изпълнение

-------------------------------------------------- -------
н н н
Време за изпълнение Ai Време за изпълнение Изпълнение
----------------------------------
= = ---------------------------------------------- =
Ai n
-------------------------------------------------- -------
Bi n
н
i=1 Референция за време на изпълнение
-------------------------------------------------- -------
i=1 Време за изпълнение Ai i=1 PerformanceBi
Време за изпълнениеBi
Това означава, че съотношението на средните геометрични стойности на SPECRatios на A и B е

средното геометрично на съотношенията на ефективността на A към B на всички сравнителни
тестове в пакета. Фигура 1.17 демонстрира тази валидност, използвайки примери от SPEC.
1.9 Количествени принципи на компютърния дизайн
Сега, след като видяхме как да дефинираме, измерваме и обобщаваме производителността,

разходите, надеждността, енергията и мощността, можем да изследваме насоки и принципи, които
са полезни при проектирането и анализа на компютрите. Този раздел въвежда важни наблюдения
относно дизайна, както и две уравнения за оценка на алтернативи.
Възползвайте се от паралелизма
Възползването от паралелизма е един от най-важните методи за подобряване на производителността.

Всяка глава в тази книга има пример за това как производителността се подобрява чрез използването
на паралелизма. Тук даваме три кратки примера, които са изложени в следващите глави.
Нашият първи пример е използването на паралелизъм на ниво система. За да се подобри

пропускателната способност на типичен бенчмарк на сървър, като SPECWeb или TPC-C, могат да се
използват множество процесори и множество дискове. След това работното натоварване на
заявките за обработка може да бъде разпределено между процесорите и дисковете, което води до
подобрена производителност. Възможността за разширяване на паметта и броя на процесорите и
дисковете се нарича мащабируемост и е ценен актив за сървърите. Разпространението на данни в
много дискове за паралелно четене и запис позволява паралелизъм на ниво данни.
SPECWeb също така разчита на паралелизъм на ниво заявка, за да използва много процесори, докато
TPC-C използва паралелизъм на ниво нишка за по-бърза обработка на заявки към база данни.
На ниво отделен процесор, възползването от паралелизма между инструкциите е от решаващо
значение за постигане на висока производителност. Един от най-простите начини да направите това
е чрез конвейер. (Обяснено е по-подробно в Приложение C и е основен акцент в Глава 3.) Основната
идея зад конвейера
е да се припокрие изпълнението на инструкции, за да се намали общото време за изпълнение на

последователност от инструкции. Ключово прозрение, което позволява конвейерната работа е, че не всеки
инструкцията зависи от нейния непосредствен предшественик, така че изпълнението на инструкциите
възможно е напълно или частично паралелно. Конвейерът е най-известният
пример за паралелизъм на ниво инструкция.
Паралелизмът може да се използва и на ниво детайлен цифров дизайн. За
например набор-асоциативните кешове използват множество банки памет, които обикновено са
търсите успоредно, за да намерите желания артикул. Съвременни ALU (аритметично-логически
единици) използват пренос-изглед напред, който използва паралелизъм, за да ускори процеса на
изчисляване на суми от линейни до логаритмични в броя битове на операнд. Тези
са повече примери за паралелизъм на ниво данни.
Принцип на местността
Важни фундаментални наблюдения идват от свойствата на програмите.

Най-важното свойство на програмата, което редовно използваме, е принципът на
местоположение: Програмите са склонни да използват повторно данни и инструкции, които са използвали наскоро. А
широко разпространеното правило е, че една програма прекарва 90% от времето си за изпълнение в

само 10% от кода. Изводът от локалността е, че можем да предвидим с разумна точност какви
инструкции и данни ще използва програмата в близко бъдеще
въз основа на достъпите му в близкото минало. Принципът на локалност важи и за
достъп до данни, макар и не толкова силно, колкото достъп до код.
Наблюдавани са два различни типа находища. Времеви локални състояния
че наскоро достъпните елементи е вероятно да бъдат достъпни в близко бъдеще. Пространствени
locality казва, че елементите, чиито адреси са близо един до друг, обикновено се препращат близо
един до друг във времето. Ще видим тези принципи приложени в Глава 2.
Съсредоточете се върху общия случай
Може би най-важният и широко разпространен принцип на компютърния дизайн е да

съсредоточете се върху обичайния случай: При компромис в дизайна предпочитайте честите
случай над редките случаи. Този принцип се прилага, когато се определя как да
харчат ресурси, тъй като ефектът от подобрението е по-голям, ако се случва често.
Фокусирането върху общия случай работи както за мощност, така и за разпределение на ресурси
и производителност. Устройството за извличане и декодиране на инструкции на процесора може
да се използва много по-често от множителя, така че първо го оптимизирайте. Работи върху
надеждност също. Ако сървър на база данни има 50 диска за всеки процесор, надеждността на
съхранението ще доминира над надеждността на системата.
В допълнение, честият случай често е по-прост и може да се направи по-бързо от
рядък случай. Например, когато събираме две числа в процесора, можем
очаква препълването да бъде рядко обстоятелство и следователно може да подобри производителността
чрез оптимизиране на по-често срещания случай на липса на препълване. Този акцент може
забавете случая, когато възникне препълване, но ако това е рядко, цялостната производителност ще
бъде подобрена чрез оптимизиране за нормалния случай.
В този текст ще видим много случаи на този принцип. При прилагането на това
прост принцип, ние трябва да решим какъв е честият случай и доколко производителността може да
бъде подобрена, като направим този случай по-бърз. Основен закон, т.нар
Законът на Амдал може да се използва за количествено определяне на този принцип.
Законът на Амдал
Увеличаването на производителността, което може да се получи чрез подобряване на част от

компютъра, може да се изчисли с помощта на закона на Амдал. Законът на Амдал гласи, че подобрението
на производителността, което може да се постигне от използването на някакъв по-бърз режим на изпълнение, е
ограничен от частта от времето, в което може да се използва по-бързият режим.
Законът на Амдал определя ускорението , което може да се постигне чрез използване на конкретен
особеност. Какво е ускорение? Да предположим, че можем да направим подобрение на компютър, което
ще подобри производителността, когато се използва. Ускоряването е съотношението:
Производителност за цялата задача с помощта на подобрението, когато е възможно

Ускоряване =
Производителност за цялата задача без използване на подобрението
Алтернативно,
Време за изпълнение за цялата задача без използване на подобрението

Ускоряване =
Време за изпълнение за цялата задача с помощта на подобрението, когато е възможно
Speedup ни казва колко по-бързо ще се изпълнява задача, използвайки компютъра с

подобрение за разлика от оригиналния компютър.
Законът на Амдал ни дава бърз начин да намерим ускоряването от някои подобрения-
мент, който зависи от два фактора:
1. Частта от времето за изчисление в оригиналния компютър, която може да бъде

преобразувани, за да се възползват от подобрението – например, ако 20
секунди от времето за изпълнение на програма, което отнема общо 60 секунди
може да използва подобрение, фракцията е 20/60. Тази стойност, която ще наречем
Подсилено с дроби, винаги е по-малко или равно на 1.
2. Подобрението, получено от подобрения режим на изпълнение, тоест колко

по-бързо задачата ще се изпълнява, ако подобреният режим се използва за целия
програма—Тази стойност е времето на оригиналния режим спрямо времето на
подобрен режим. Ако подобреният режим отнема, да речем, 2 секунди за част от
програмата, докато е 5 секунди в оригиналния режим, подобрението е 5/2. Ще наречем тази
стойност, която винаги е по-голяма от 1, Speedupenhanced.
Времето за изпълнение с помощта на оригиналния компютър с подобрен режим ще бъде

времето, прекарано при използване на неподобрената част на компютъра плюс прекараното време
използване на подобрението:
Фракционно подобрено
+ -------------------------------------
Време за изпълнениеново = Старо време за изпълнение × ( 1 – Подобрена фракция )
Подобрена скорост
Общото ускоряване е съотношението на времената за изпълнение:
Старо време на изпълнение 1

---------------------------------------------- =
Speedupoverall =
-------------------------------------------------- ----------------------------------------------
Фракционно подобрено
Време за изпълнениеново
( 1 – Подобрена фракция ) + -------------------------------------
Пример Да предположим, че искаме да подобрим процесора, използван за уеб обслужване. Новото

процесорът е 10 пъти по-бърз при изчисления в приложението за уеб обслужване от
оригиналния процесор. Ако приемем, че оригиналният процесор е зает с изчисления 40% от
времето и чака I/O 60% от времето, какво е общото
ускоряване, получено чрез включване на подобрението?
1 1
--------------------- = ---------- 1,56
Отговор фракционно подобрен = 0,4; Повишена скорост = 10; Speedupoverall =
0,4 0,64
0,6 + -------
10
Законът на Амдал изразява закона за намаляващата възвръщаемост: Инкременталната

подобрението в ускоряването, постигнато чрез подобрение само на част от изчислението, намалява
с добавянето на подобрения. Важно следствие от
Законът на Амдал е, че ако едно подобрение е използваемо само за част от задача, тогава
не можем да ускорим задачата с повече от реципрочната стойност на 1 минус тази дроб.
Често срещана грешка при прилагането на закона на Амдал е да се обърква „част от времето
преобразуван за използване на подобрение“ и „част от времето след въвеждане на подобрение
използвай.” Ако вместо да измерваме времето, бихме могли да използваме подобрението в a
изчисление, ние измерваме времето след като подобрението е в употреба, резултатите
ще е неправилно!
Законът на Амдал може да послужи като ръководство за това колко ще бъде подобрението
подобряване на производителността и как да се разпределят ресурсите, за да се подобри
ефективността на разходите. Целта, разбира се, е да се харчат ресурси пропорционално на времето
се изразходва. Законът на Амдал е особено полезен за сравняване на цялостната система
производителност на две алтернативи, но може да се приложи и за сравняване на две алтернативи
на дизайна на процесора, както показва следният пример.
Пример Обичайна трансформация, изисквана в графичните процесори, е корен квадратен. Реализациите на корен
квадратен с плаваща запетая (FP) се различават значително по отношение на производителността,
особено сред процесорите, предназначени за графика. Да предположим, че FP корен квадратен
(FPSQR) е отговорен за 20% от времето за изпълнение на критична графика
бенчмарк. Едно предложение е да се подобри хардуерът на FPSQR и да се ускори това
операция с коефициент 10. Другата алтернатива е просто да се опитате да направите всички FP
инструкциите в графичния процесор се изпълняват по-бързо с коефициент 1,6; FP инструкции
са отговорни за половината от времето за изпълнение на приложението. Дизайнерският екип
вярва, че могат да накарат всички FP инструкции да работят 1,6 пъти по-бързо със същото
усилие, както се изисква за бърз квадратен корен. Сравнете тези две алтернативи на дизайна.
Отговор Можем да сравним тези две алтернативи, като сравним ускоренията:
1 1
---------------------------------- = ---------- = 1,22
SpeedupFPSQR = 0,2 0,82
( 1 0,2 – ) + -------
10
1 1
SpeedupFP =
---------------------------------- = ---------------- = 1,23
0,5 0,8125
( 1 0,5 – ) + -------
1.6
Подобряването на производителността на FP операциите като цяло е малко по-добро, защото

на по-високата честота.
Законът на Амдал е приложим отвъд изпълнението. Нека повторим надеждността

пример от страница 35 след подобряване на надеждността на захранването чрез
резервиране от 200 000 часа до 830 000 000 часа MTTF или 4150X по-добро.
Пример Изчисляването на процентите на отказ на дисковата подсистема беше
1 1 1 1 1
= +++
10 ----------------------
× ----------------------- + ------------------- ------------------- -------------------
Система за процент на неуспех
1 000 000 500 000 200 000 200 000 1 000 000
10 2 5 5 1 ++++ 23
= ---------------------------------------------- = --------------------------------------
1 000 000 часа 1 000 000 часа
Следователно процентът на неуспехите, който може да бъде подобрен, е 5 на милион

часа от 23 за цялата система, или 0,22.
Отговор Подобряването на надеждността би било
1 1
= ---------------------------------------------- = ---------- = 1,28
Подобряване на захранващата двойка 0,22 0,78
( 1 0,22 – ) + -----------
4150
Въпреки впечатляващото 4150X подобрение на надеждността на един модул, от

от гледна точка на системата, промяната има измерима, но малка полза.
В примерите по-горе ни трябваше частта, изразходвана от новия и

подобрена версия; често е трудно тези времена да се измерят директно. В следващите
раздел, ще видим друг начин за извършване на такива сравнения въз основа на използването на
уравнение, което разлага времето за изпълнение на процесора на три отделни компонента. Ако
знаем как една алтернатива влияе на тези три компонента, можем
определя цялостното му представяне. Освен това, често е възможно да се изградят симулатори, които
измерват тези компоненти, преди хардуерът действително да бъде проектиран.
Уравнението за производителност на процесора
По същество всички компютри са конструирани с помощта на часовник, работещ с постоянна скорост.

Тези дискретни времеви събития се наричат тиктакове, тиктакания на часовника, периоди на часовника, часовници,
цикли или часовникови цикли. Компютърните дизайнери се отнасят за времето на часовниковия период с
нейната продължителност (напр. 1 ns) или по нейната скорост (напр. 1 GHz). Процесорното време за една програма може
тогава се изразява по два начина:
=
Време на процесора Тактови цикли на процесора за програма ×Време на тактовия цикъл
или
Тактови цикли на процесора за програма

Процесорно време = -------------------------------------------------- --------------------------
Тактова честота
В допълнение към броя тактови цикли, необходими за изпълнение на програма, ние

може също така да преброи броя на изпълнените инструкции - дължината на пътя на инструкцията
или брой инструкции (IC). Ако знаем броя на тактовите цикли и броя на инструкциите, можем да изчислим
средния брой тактови цикли на инструкция
(CPI). Защото е по-лесно да се работи с него и защото ще се занимаваме с прости
процесори в тази глава, ние използваме CPI. Дизайнерите понякога също използват инструкции
на такт (IPC), което е обратното на CPI.
CPI се изчислява като
Тактови цикли на процесора за програма

CPI = -------------------------------------------------- --------------------------
Брой инструкции
Тази стойност на процесора дава представа за различни стилове на обучение

набори и имплементации и ще го използваме широко в следващите четири глави.
Чрез транспониране на броя на инструкциите в горната формула, часовниковите цикли могат
се определя като IC × CPI. Това ни позволява да използваме CPI във формулата за времето за изпълнение:
= ×
CPU време Брой инструкции Цикли на инструкция Време на тактовия цикъл×
Разширяването на първата формула в мерните единици показва как парчетата

прилягат заедно:
Инструкции Цикли на часовника Секунди Секунди

--------------------------- × ------------------------------ × ---------------------------- = -------------------- = процесорно време
програма Инструкция Цикъл на часовника програма
Както показва тази формула, производителността на процесора зависи от три

характеристики: тактов цикъл (или честота), тактови цикли за инструкция и инструкция
броя. Освен това времето на процесора зависи еднакво от тези три характеристики; например, 10%
подобрение във всеки един от тях води до 10%
подобряване на процесорното време.
За съжаление е трудно да се промени един параметър в пълна изолация

от други, тъй като основните технологии, включени в промяната на всяка характеристика, са
взаимозависими:
Време на тактовия цикъл —хардуерна технология и организация
CPI—организация и архитектура на набора от инструкции
Брой инструкции —Архитектура на набора инструкции и технология на компилатора

За щастие много потенциални техники за подобряване на ефективността се подобряват предимно

един компонент от производителността на процесора с малки или предвидими въздействия върху
другите две.
Понякога е полезно при проектирането на процесора да се изчисли броят на

общи тактови цикли на процесора като
н
Тактови цикли на процесора = ICi CPIi ×
i=1
където ICi представлява броя пъти, в които инструкция i се изпълнява в програма

и CPIi представлява средният брой часовници на инструкция за инструкция i.
Тази форма може да се използва за изразяване на процесорно време като
н
=
процесорно време
ICi CPIi × × Време на цикъла на часовника
i=1
и общия CPI като
н
ICi CPIi ×
н
i=1 ICi
CPI = ---------------------------------------------- =
---------------------------------------------- CPIi ×
Брой инструкции Брой инструкции
i=1
Последната форма на изчисление на CPI използва всеки отделен CPIi и частта

на срещанията на тази инструкция в програма (т.е. ICi ÷ брой инструкции). CPIi
трябва да се измерва, а не просто да се изчислява от таблица в края на справката
ръчно, тъй като трябва да включва ефекти на конвейер, пропуски в кеша и всякакви други
неефективности на системата на паметта.
Разгледайте нашия пример за изпълнение на страница 47, тук модифициран да използва
измервания на честотата на инструкциите и на стойностите на CPI на инструкциите,
които на практика се получават чрез симулация или чрез апаратно оборудване.
Пример Да предположим, че сме направили следните измервания:
Честота на FP операции = 25%
Среден CPI на FP операции = 4,0
Среден CPI на други инструкции = 1,33
Честота на FPSQR = 2%
CPI на FPSQR = 20
Да приемем, че двете алтернативи на дизайна са да се намали CPI на FPSQR до 2 или

да намали средния CPI на всички FP операции до 2,5. Сравнете тези две
алтернативи за проектиране, използвайки уравнението за производителност на процесора.
Отговор Първо, забележете, че се променя само CPI; тактовата честота и броя на инструкциите
остават идентични. Започваме с намирането на оригиналния CPI без нито едно подобрение:
н
= ICi
---------------------------------------------- ×
CPIоригинал CPIi Брой инструкции
i=1
= ( 4 25% × ) + ( 1,33 75% × ) = 2,0
Можем да изчислим CPI за подобрения FPSQR, като извадим циклите

запазени от оригиналния CPI:
CPI с нов FPSQR = CPI оригинален – 2% CPI × ( стар FPSQR – CPIof ) само нов FPSQR
= (2,0 – 2% 20
× – 2) 1,64 =
Можем да изчислим CPI за подобряване на всички FP инструкции по същия начин

или чрез сумиране на FP и не-FP CPI. Използването на последното ни дава:
CPInew FP = (75% 1,33 × ) + (25% 2,5 × ) = 1,625
Тъй като CPI на цялостното подобрение на FP е малко по-нисък, неговата производителност

ще бъде малко по-добре. По-конкретно, ускоряването за цялостното подобряване на FP е
×
IC Тактов цикъл CPIоригинал
×
Speedupnew FP = Процесорно време оригинално
------------------------------------- = -------------------------------------------------- ---------------------
CPU timenew FP ×
IC Тактов × FP
цикъл CPInew
CPIоригинал 2.00
= == -----------------------
------------- 1.23
CPIнов FP 1,625
За щастие получихме същото ускоряване, използвайки закона на Амдал на страница 46.
Често е възможно да се измерят съставните части на уравнението за производителност на

процесора. Това е ключово предимство на използването на производителността на процесора
уравнението срещу закона на Амдал в предишния пример. По-специално може да бъде
трудни за измерване неща като частта от времето за изпълнение, за което набор
на инструкциите е отговорен. На практика това вероятно ще бъде изчислено от
сумиране на произведението от броя на инструкциите и CPI за всяка от инструкциите в
комплекта. Тъй като началната точка често е индивидуален брой инструкции и
CPI измервания, уравнението за производителност на процесора е невероятно полезно.
За да използваме уравнението за производителност на процесора като инструмент за проектиране, трябва да сме
в състояние да измерва различни фактори. За съществуващ процесор е лесно да се получи

времето за изпълнение чрез измерване и знаем тактовата честота по подразбиране. The
предизвикателството се крие в откриването на броя на инструкциите или CPI. Повечето нови
процесори включват броячи както за изпълнени инструкции, така и за тактови цикли. от
периодично следене на тези броячи, също е възможно да се прикачи време за изпълнение
и брой инструкции към сегменти от кода, което може да бъде полезно за
програмисти, които се опитват да разберат и настроят производителността на приложение.
Често дизайнер или програмист ще иска да разбере производителността на повече
фино ниво от това, което се предлага от хардуерните броячи. Например, те може да искат да знаят
защо CPI е такъв, какъвто е. В такива случаи симулация
използваните техники са като тези за процесорите, които се проектират.
Техники, които помагат за енергийната ефективност, като например динамично мащабиране
на напрежението и честотата и овърклок (вижте раздел 1.5), правят това уравнение по-трудно за
използване, тъй като тактовата честота може да варира, докато измерваме програмата. Едно просто
подходът е да изключите тези функции, за да направите резултатите възпроизводими. За щастие,
тъй като производителността и енергийната ефективност често са силно свързани – вземане
по-малкото време за изпълнение на програма обикновено спестява енергия - вероятно е безопасно да се обмисли
производителност, без да се притеснявате за въздействието на DVFS или овърклок върху

резултати.
1.10 Обединяване на всичко: производителност, цена

и мощност
В разделите „Сглобяване на всичко“, които се появяват в края на всяка глава,

предоставяме реални примери, които използват принципите в тази глава. В тази секция,
ние разглеждаме мерките за производителност и енергийна производителност в малки сървъри
използвайки бенчмарка SPECpower.
Фигура 1.18 показва трите мултипроцесорни сървъра, които оценяваме заедно
с тяхната цена. За да запазим сравнението на цените справедливо, всички са Dell PowerEdge
сървъри. Първият е PowerEdge R710, който е базиран на Intel Xeon X5670
микропроцесор с тактова честота 2,93 GHz. За разлика от Intel Core i7 в глави 2 до 5, който има 4
ядра и 8 MB L3 кеш, този чип на Intel има
6 ядра и 12 MB L3 кеш, въпреки че самите ядра са идентични. Ние
избра система с два гнезда с 12 GB ECC-защитена 1333 MHz DDR3
DRAM. Следващият сървър е PowerEdge R815, който е базиран на AMD
Микропроцесор Opteron 6174. Един чип има 6 ядра и 6 MB L3 кеш и то
работи на 2,20 GHz, но AMD поставя два от тези чипове в един сокет. По този начин, a
socket има 12 ядра и два 6 MB L3 кеша. Вторият ни сървър има два сокета
с 24 ядра и 16 GB ECC-защитена 1333 MHz DDR3 DRAM и нашата

трети сървър (също PowerEdge R815) има четири сокета с 48 ядра и 32 GB
на DRAM. Всички работят с IBM J9 JVM и Microsoft Windows 2008
Операционна система Server Enterprise x64 Edition.
Обърнете внимание, че поради силите на сравнителния анализ (вижте раздел 1.11), това са
необичайно конфигурирани сървъри. Системите на фигура 1.18 имат малко памет в сравнение с
количеството изчисления и само малък 50 GB твърд диск. то е
евтино за добавяне на ядра, ако не е необходимо да добавяте съразмерни увеличения
памет и съхранение!
Вместо да изпълнява статично свързани C програми на SPEC CPU, SPECpower използва
по-модерен софтуерен стек, написан на Java. Базиран е на SPECjbb и представлява сървърната
страна на бизнес приложенията, като производителността се измерва като
броя транзакции за секунда, наречен ssj_ops за Java операции от страна на сървъра за секунда. Той
упражнява не само процесора на сървъра, както прави SPEC
1.10 Обединяване на всичко: производителност, цена и мощност 53
Система 1 Система 2 Система 3
Компонент Разходи (% разходи) Разходи (% разходи) Разходи (% разходи)
Базов сървър PowerEdge R710 $653 (7%) PowerEdge R815 $1437 (15%) PowerEdge R815 $1437 (11%)
Захранване 570 W 1100 W 1100 W
Процесор Xeon X5670 $3738 (40%) Opteron 6174 $2679 (29%) Opteron 6174 $5358 (42%)
Тактова честота 2,93 GHz 2,20 GHz 2,20 GHz
Общо ядра 12 24 48
Гнезда 2 2 4
Ядра/гнездо 6 12 12
DRAM 12 GB $484 (5%) 16 гигабайта $693 (7%) 32 GB $1386 (11%)

Ethernet Inter. Двоен 1-Gbit $199 (2%) двоен 1-Gbit $199 (2%) двоен 1-Gbit $199 (2%)
диск 50 GB SSD $1279 (14%) 50 GB SSD $1279 (14%) 50 GB SSD $1279 (10%)
Windows OS $2999 (32%) $2999 (33%) $2999 (24%)
Обща сума $9352 (100%) $9286 (100%) $12 658 (100%)
Макс. ssj_ops 910,978 926,676 1,840,450
Макс. ssj_ops/$ 97 100 145
Фигура 1.18 Три измервани сървъра Dell PowerEdge и техните цени към август 2010 г. Изчислихме
цената на процесорите чрез изваждане на цената на втори процесор. По подобен начин изчислихме общата цена на
памет, като видите каква е цената на допълнителната памет. Следователно базовата цена на сървъра се коригира чрез премахване
прогнозната цена на процесора и паметта по подразбиране. Глава 5 описва как са тези системи с множество гнезда
свързани заедно.
CPU, но също и кеш паметта, системата с памет и дори системата за мултипроцесорна връзка. В
допълнение, той упражнява Java Virtual Machine (JVM), включително JIT компилатор за изпълнение и
събирач на отпадъци, както и части от
основната операционна система.
Както показват последните два реда на Фигура 1.18 , победителят в производителността и
съотношението цена-производителност е PowerEdge R815 с четири гнезда и 48 ядра. Удря
1,8 милиона ssj_ops, а ssj_ops за долар е най-висок при 145. Удивително е, че компютърът с най-голям
брой ядра е най-рентабилен. На второ място
е двуцокълният R815 с 24 ядра, а на последно място е R710 с 12 ядра.
Докато повечето бенчмаркове (и повечето компютърни архитекти) се интересуват само от
производителността на системите при пиково натоварване, компютрите рядко работят при пиково
натоварване. Наистина, фигура 6.2 в глава 6 показва резултатите от измерването на използването на десетки
хиляди сървъри за 6 месеца в Google и по-малко от 1% работят на an
средно използване на 100%. Повечето имат средно използване между
10% и 50%. По този начин бенчмаркът SPECpower улавя мощността като цел
работното натоварване варира от пика си на интервали от 10% до 0%, което се нарича
Активен празен ход.
Фигура 1.19 изобразява ssj_ops (SSJ операции/секунда) на ват и средната мощност, тъй като
целевият товар варира от 100% до 0%. Intel R710 винаги има
най-ниската мощност и най-добрите ssj_ops на ват за всяко целево ниво на натоварване.
4500 550
710 Intel 12 ядрен
815 AMD 48 ядра W 815 AMD 24 ядра 500

4000
815 AMD 48 ядро
450
3500 815 AMD 24 ядра W
400
3000
350
710 Intel 12 ядрен W
2500 300
евотав
250
/spo_тjаsвs
2000 г
200
1500
150
1000
100
500
50
0 0
100% 90% 80% 70% 60% 50% 40% 30% 20% 10% Активен празен ход
Целево натоварване
Фигура 1.19 Енергийна производителност на трите сървъра на Фигура 1.18. Стойностите на Ssj_ops/watt са на лявата ос, с трите колони,
свързани с нея, а ватовете са на дясната ос, с трите линии, свързани с нея. Хоризонталната ос показва целевото работно натоварване,
тъй като то варира от 100% до Active Idle. Базираният на Intel R715 има най-добрите ssj_ops/watt при всяко ниво на натоварване и също
така консумира най-ниската мощност на всяко ниво.
Една от причините е много по-голямото захранване за R815, 1100 вата срещу 570 вата
при R715. Както показва глава 6 , ефективността на захранването е много важна за
цялостната енергийна ефективност на компютъра. Тъй като ватове = джаули/секунда,
този показател е пропорционален на SSJ операциите на джаул:
ssj_operations/сек
------------------------------------------- = ssj_operations/сек
------------------------------------------- ssj_operations
= ----------------------------------
ват Джаул/сек Джаул
За да изчисли едно число, което да се използва за сравняване на енергийната ефективност на

системите, SPECpower използва:
ssj_ops
= ------------------------
Общо ssj_ops/ват
мощност
Общият ssj_ops/watt на трите сървъра е 3034 за Intel R710, 2357 за AMD с двоен сокет
R815 и 2696 за AMD с четири сокета R815. следователно
Intel R710 има най-добрата мощност. Разделяйки на цената на
сървъри, ssj_ops/watt/$1000 е 324 за Intel R710, 254 за AMD R815 с двоен сокет и 213 за MD R815 с четири
сокета. По този начин, добавяйки
силата обръща резултатите от конкуренцията цена-производителност и
трофеят цена-мощност-производителност отива при Intel R710; идва 48-ядреният R815
на последно място.
1.11 Заблуди и клопки
Целта на този раздел, който ще намерите във всяка глава, е да обясни
някои често срещани погрешни вярвания или погрешни схващания, които трябва да избягвате. Ние
наричаме такива погрешни вярвания заблуди. Когато обсъждаме заблуда, ние се опитваме да дадем
обратен пример. Ние също така обсъждаме клопките - лесни грешки. Често има клопки
обобщения на принципи, които са верни в ограничен контекст. Целта на
тези раздели са, за да ви помогнат да избегнете тези грешки в компютрите, които вие
дизайн.
Fallacy Мултипроцесорите са сребърен куршум.
Преминаването към няколко процесора на чип около 2005 г. не дойде от някои
пробив, който драматично опрости паралелното програмиране или го направи лесно
изграждане на многоядрени компютри. Промяната се случи, защото нямаше друга възможност
благодарение на ILP стените и силовите стени. Няколко процесора на чип не гарантират по-ниска мощност;
със сигурност е възможно да се проектира многоядрен чип, който използва повече
мощност. Потенциалът е само, че е възможно да продължите да подобрявате производителността
чрез замяна на неефективно ядро с висока тактова честота с няколко ефективни ядра с по-ниска тактова
честота. Тъй като технологията се подобрява за свиване на транзисторите, това може да свие и двете
капацитет и захранващото напрежение малко, за да можем да получим умерено увеличение на
брой ядра на поколение. Например през последните няколко години Intel е
добавяне на две ядра на поколение.
Както ще видим в глави 4 и 5, производителността вече е тежест за програмиста. Програмистската ера
на La-Z-Boy, в която се разчита на хардуерни дизайнери
техните програми вървят по-бързо, без да си мръднат пръста, официално приключи. Ако програмистите
искат техните програми да вървят по-бързо с всяко поколение, те трябва да направят своите програми по-
паралелни.
Популярната версия на закона на Мур - повишаване на производителността с всяко поколение
усъвършенстване на технологията – вече зависи от програмистите.
Клопка Да станеш жертва на сърцераздирателния закон на Амдал.
На практика всеки практикуващ компютърен архитект знае закона на Амдал. Въпреки това,
почти всички понякога полагаме огромни усилия за оптимизиране на някои функции
преди да измерим използването му. Направете го само когато общото ускоряване е разочароващо
припомняме, че трябваше първо да измерим, преди да похарчим толкова много усилия
подобрявайки го!
Клопка Една единствена точка на провал.
Изчисленията за подобряване на надеждността с помощта на закона на Amdahl на страница 48 показват
че надеждността не е по-силна от най-слабото звено във веригата. Без значение как
много по-надеждни ние правим захранванията, както направихме в нашия пример,
единичният вентилатор ще ограничи надеждността на дисковата подсистема. Това е законът на Амдал
наблюдението доведе до основно правило за устойчиви на грешки системи, за да се гарантира, че
всеки компонент беше излишен, така че нито една повреда на компонента не можеше да доведе
надолу по цялата система. Глава 6 показва как софтуерният слой избягва единичните
точки на повреда в компютри от складови площи.
Fallacy Хардуерните подобрения, които увеличават производителността, подобряват енергийната ефективност или
в най-лошия случай са енергийно неутрални.
Esmaeilzadeh и др. [2011] измерва SPEC2006 само на едно ядро от 2,67 GHz
Intel Core i7 с помощта на Turbo режим (Раздел 1.5). Производителността е увеличена с фактор
от 1,07, когато тактовата честота се увеличи до 2,94 GHz (или фактор 1,10), но i7
използва фактор от 1,37 повече джаула и фактор от 1,47 повече ватчаса!
Fallacy Benchmarks остават валидни за неопределено време.
Няколко фактора влияят върху полезността на бенчмарка като предиктор на реалната производителност, а
някои се променят с времето. Голям фактор, влияещ върху полезността на a
бенчмарк е неговата способност да устои на „бенчмарк инженерство“ или „бенчмаркетинг“.
След като даден бенчмарк стане стандартизиран и популярен, има огромен натиск за подобряване на
производителността чрез целеви оптимизации или чрез агресивно тълкуване на правилата за изпълнение
на бенчмарка. Малки ядра или програми, които
прекарват времето си в малко количество код са особено уязвими.
Например, въпреки най-добрите намерения, първоначалният пакет за сравнение SPEC89
включваше малко ядро, наречено matrix300, което се състоеше от осем различни
300 × 300 матрични умножения. В това ядро 99% от времето за изпълнение беше
в един ред (виж SPEC [1989]). Когато компилаторът на IBM оптимизира този вътрешен
цикъл (използвайки идея, наречена блокиране, обсъдена в глави 2 и 4), производителност
подобрен с коефициент 9 спрямо предишна версия на компилатора! Този показател
тества настройката на компилатора и, разбира се, не беше добра индикация за цялостната производителност,
нито за типичната стойност на тази конкретна оптимизация.
В продължение на дълъг период от време тези промени могат да направят дори добре избран
бенчмарк остарял; Gcc е единственият оцелял от SPEC89. Фигура 1.16 на страница 39

изброява състоянието на всички 70 бенчмарка от различните версии на SPEC. Учудващо, почти 70% от
всички програми от SPEC2000 или по-стари бяха премахнати

от следващото издание.
Грешка Номиналното средно време до повреда на дисковете е 1 200 000 часа или почти 140 години, така че
дисковете практически никога не се провалят.
Настоящите маркетингови практики на производителите на дискове могат да подведат потребителите. Как е
изчислена такава MTTF? В началото на процеса производителите ще поставят хиляди

на дискове в една стая, пуснете ги за няколко месеца и пребройте броя на неуспешните.
Те изчисляват MTTF като общия брой часове, през които дисковете са работили кумулативно, разделен
на броя на неуспешните.
Един проблем е, че този брой далеч надвишава живота на диска, което е
обикновено се приема за 5 години или 43 800 часа. За да направите този голям MTTF
в известен смисъл производителите на дискове твърдят, че моделът отговаря на потребител, който
купува диск и след това продължава да сменя диска на всеки 5 години - планираният живот
на диска. Твърдението е, че ако много клиенти (и техните правнуци)
направиха това през следващия век, средно ще сменят диск 27 пъти
преди провал, или около 140 години.
По-полезна мярка би бил процентът на дисковете, които се провалят. Да приемем 1000
дискове с 1 000 000 часа MTTF и че дисковете се използват 24 часа на ден. Ако
сте заменили повредени дискове с нови със същите характеристики на надеждност, броят на
повредените за една година (8760 часа) е
× 1000 диска 8760 × часа/диск =

Неизправни дискове = Брой дискове Период от време
-------------------------------------------------- ------------------------
-------------------------------------------------- ----------------------------- 9 =
MTTF 1 000 000 часа/отказ
Казано алтернативно, 0,9% ще се провалят на година или 4,4% за 5-годишен живот.

Нещо повече, тези високи числа са цитирани при допускане на ограничени диапазони на
температура и вибрации; ако те бъдат надвишени, тогава всички залози са изключени. Проучване на диска
дискове в реални среди [Gray and van Ingen 2005] установяват, че 3% до 7% от
дискове неуспешни на година, за MTTF от около 125 000 до 300 000 часа. Четен
по-голямо проучване установи годишни нива на повреда на диска от 2% до 10% [Pinheiro, Weber и
Барозу 2007]. Следователно MTTF в реалния свят е около 2 до 10 пъти по-лош от
MTTF на производителя.
Производителността на Flacy Peak проследява наблюдаваната ефективност.
Единственото универсално вярно определение за върхова производителност е „производителността

ниво, което компютърът гарантирано няма да превиши. Фигура 1.20 показва процента
максимална производителност за четири програми на четири мултипроцесора. Тя варира от
5% до 58%. Тъй като разликата е толкова голяма и може да варира значително според бенчмарка,
пиковата производителност обикновено не е полезна за прогнозиране на наблюдаваната производителност.
Клопка Откриването на грешки може да намали достъпността.
Тази очевидно иронична клопка е, защото компютърният хардуер има доста

състояние, което не винаги може да е критично за правилната работа. Например не е
фатално, ако възникне грешка в предсказател на разклонения, тъй като може да пострада само производителността.
В процесори, които се опитват агресивно да използват паралелизма на ниво инструкции, не

всички операции са необходими за правилното изпълнение на програмата. Мукерджи
et al. [2003] установяват, че по-малко от 30% от операциите потенциално са на
критичен път за бенчмарковете SPEC2000, работещи на Itanium 2.
Същото наблюдение важи и за програмите. Ако даден регистър е „мъртъв“ в a
програма—т.е. програмата ще го напише, преди да бъде прочетена отново—тогава грешките го правят
70%
Мощност4
Итаний 2
60% 58%
54% 54% NEC Земен симулатор
50% Cray X1
40%
33% 34% 34%

онвео
тсонлетидта и
зц ор
р
хо аП
ъ
рнп
в
30%
20%
20%
16%
10% 11% 11%

10% 7%
6% 6% 6% 5%
0%
Paratec LBMHD GTC
физика на плазмата материалознание Астрофизика на кактус магнитен синтез
Фигура 1.20 Процент на пикова производителност за четири програми на четири мултипроцесора, мащабирани до 64 процесора.
Earth Simulator и X1 са векторни процесори (вижте Глава 4 и Приложение G). Те не само осигуряваха по-висока част от пиковата
производителност, но също така имаха най-високата пикова производителност и най-ниските тактови честоти. С изключение на
програмата Paratec, системите Power 4 и Itanium 2 доставят между 5% и 10% от своя пик. От Oliker et al. [2004].
Няма значение. Ако трябваше да сринете програмата при откриване на преходна грешка в
мъртъв регистър, това би намалило наличността ненужно.
Sun Microsystems преживя този капан през 2000 г. с L2 кеш, който включва паритет, но не
и коригиране на грешки, в своите системи Sun E3000 до Sun E10000. SRAM, които са използвали
за изграждане на кешовете, са имали периодични грешки, които паритетът е открил. Ако
данните в кеша не са променени, процесорът просто препрочита данните от кеша. Тъй като
дизайнерите не са защитили кеша с ECC (код за коригиране на грешки), операционната
система няма друг избор, освен да съобщи за грешка на мръсни данни и да срине програмата.
Полевите инженери не откриха проблеми при проверка в повече от 90% от случаите.
За да намали честотата на подобни грешки, Sun модифицира операционната система

Solaris, за да „изчисти“ кеша чрез процес, който проактивно записва мръсни данни в паметта.
Тъй като чиповете на процесора нямаха достатъчно пинове за добавяне на ECC, единствената
хардуерна опция за мръсни данни беше да се дублира външният кеш, като се използва
копието без грешката на паритета, за да се коригира грешката.
Клопката е в откриването на грешки, без да се осигури механизъм за коригирането им.
Тези инженери едва ли ще проектират друг компютър без ECC на външни кешове.
1.12 Заключителни бележки

Тази глава въвежда редица понятия и предоставя количествени показатели
рамка, която ще разширим в цялата книга. Започвайки с това издание, енергийната ефективност е
новият спътник на производителността.
В Глава 2 започваме с изключително важната област на проектирането на системата с памет.
Ще разгледаме широк набор от техники, които заговорничат, за да направят паметта да изглежда
безкрайно голям, като същевременно е възможно най-бърз. (Приложение B предоставя въвеждащ
материал за кешовете за читатели без много опит и подготовка
в тях.) Както в по-късните глави, ще видим това хардуерно-софтуерно сътрудничество
се превърна в ключ към високопроизводителните системи с памет, както и към високопроизводителните
тръбопроводи. Тази глава също така обхваща виртуални машини, все повече
важна техника за защита.
В Глава 3 разглеждаме паралелизма на ниво инструкция (ILP), от който конвейерирането е най-
простата и най-разпространена форма. Използването на ILP е един от най-много
важни техники за изграждане на високоскоростни еднопроцесорни процесори. Глава 3 започва
с обширно обсъждане на основни понятия, които ще ви подготвят за широкото
набор от идеи, разгледани в двете глави. Глава 3 използва примери, които обхващат
около 40 години, черпейки от един от първите суперкомпютри (IBM 360/91) до
най-бързите процесори на пазара през 2011 г. Той набляга на това, което се нарича
динамичен или по време на изпълнение подход за използване на ILP. Говори се и за границите на
ILP идеи и въвежда многопоточност, която е доразвита и в двете
Глави 4 и 5. Приложение C предоставя въвеждащ материал за конвейерната обработка на
читатели без много опит и опит в конвейера. (Очакваме да
бъде рецензия за много читатели, включително тези на нашия уводен текст, Компютър
Организация и дизайн: Хардуерен/софтуерен интерфейс.)
Глава 4 е нова за това издание и обяснява три начина за използване на паралелизма на ниво
данни. Класическият и най-стар подход е векторната архитектура и ние
започнете там, за да положите принципите на дизайна на SIMD. (Приложение G влиза в
по-голяма дълбочина върху векторните архитектури.) След това обясняваме набора инструкции SIMD
разширения, намиращи се в повечето настолни микропроцесори днес. Третата част е задълбочено
обяснение как работят съвременните графични процесори (GPU). Повечето
Описанията на GPU са написани от гледна точка на програмиста, което обикновено
скрива как наистина работи компютърът. Този раздел обяснява графичните процесори от an
вътрешна гледна точка, включително съпоставяне между GPU жаргона и по-традиционните термини
за архитектура.
Глава 5 се фокусира върху въпроса за постигане на по-висока производителност при използване

на множество процесори или мултипроцесори. Вместо да използва паралелизъм за припокриване
на отделни инструкции, мултипроцесорът използва паралелизъм, за да позволи множество инструкции
потоци, които да се изпълняват едновременно на различни процесори. Фокусът ни е върху
все пак доминиращата форма на мултипроцесори, мултипроцесори със споделена памет
представяме и други типове и обсъждаме широките проблеми, които възникват във всеки
мултипроцесор. Тук отново изследваме различни техники, като се фокусираме върху
важни идеи, въведени за първи път през 80-те и 90-те години на миналия век.
Глава 6 също е нова за това издание. Въвеждаме клъстери и след това навлизаме
дълбочина на складови компютри (WSC), за които компютърните архитекти помагат
дизайн. Дизайнерите на WSC са професионални наследници на пионерите
на суперкомпютри като Seymour Cray, тъй като те проектират екстремни
компютри. Те съдържат десетки хиляди сървъри и оборудването и
сградата, която ги държи, струва близо 200 милиона долара. Притесненията за цена-производителност
и енергийната ефективност от по-ранните глави се отнася за WSCs, както и количественият подход за
вземане на решения.
Тази книга идва с изобилие от материали онлайн (вижте Предговор за повече
подробности), както за намаляване на разходите, така и за запознаване на читателите с различни
усъвършенствани теми. Фигура 1.21 ги показва всички. Приложения A, B и C, които се появяват в
книга, ще бъде рецензия за много читатели.
В Приложение D се отдалечаваме от изглед, ориентиран към процесора, и обсъждаме
проблеми в системите за съхранение. Ние прилагаме подобен количествен подход, но един
въз основа на наблюдения на поведението на системата и използване на подход от край до край
анализ на ефективността. Той разглежда важния въпрос за това как да се съхранява ефективно
и извличане на данни, използвайки основно евтини технологии за магнитно съхранение. Нашите
фокусът е върху изследването на производителността на дисковите системи за съхранение за
типични I/O-интензивни работни натоварвания, като OLTP бенчмарковете, които видяхме в тази глава. Ние
подробно проучете напреднали теми в RAID-базирани системи, които използват излишни дискове, за
да постигнат както висока производителност, така и висока наличност. И накрая, на
глава въвежда теорията на опашките, която дава основа за размяна на използването
и латентност.
Приложение E прилага вградена компютърна перспектива към идеите на всеки от тях
на главите и ранните приложения.
Приложение F изследва темата за свързване на системата широко, включително широко
зонални и системни мрежи, които позволяват на компютрите да комуникират.
Приложение Заглавие
А Принципи на набора от инструкции
б Преглед на йерархиите на паметта
°С Конвейерна обработка: основни и междинни понятия

д Системи за съхранение
д Вградени системи
Е Мрежи за взаимно свързване
Ж Векторни процесори в по-голяма дълбочина
з Хардуер и софтуер за VLIW и EPIC
аз
Мащабни мултипроцесори и научни приложения
Дж
Компютърна аритметика
К Проучване на архитектурите на набор от инструкции
Л Исторически перспективи и препратки
Фигура 1.21 Списък с приложения.

Приложение H прави преглед на хардуера и софтуера на VLIW, които за разлика от тях са

по-малко популярен, отколкото когато EPIC се появи на сцената точно преди последното издание.
Приложение I описва големи мултипроцесори за използване при висока производителност
изчисления.
Приложение J е единственото приложение, останало от първото издание, и то
обхваща компютърна аритметика.
Приложение К предоставя преглед на архитектурите на инструкции, включително
80x86, IBM 360, VAX и много RISC архитектури, включително ARM,
MIPS, Power и SPARC.
Ние описваме Приложение L по-долу.
1.13 Исторически перспективи и препратки

Приложение L (достъпно онлайн) включва исторически перспективи на ключовите идеи
представени във всяка от главите на този текст. Тези раздели с историческа перспектива
ни позволяват да проследим развитието на една идея чрез поредица от машини или
описват значими проекти. Ако се интересувате от проучване на първоначалното развитие на идея или
машина или се интересувате от допълнително четене, препратките са предоставени в края на всяка
история. За тази глава вижте Раздел L.2, Ранното
Развитие на компютрите, за дискусия относно ранното развитие на цифровите технологии
компютри и методологии за измерване на производителността.
Докато четете историческия материал, скоро ще разберете, че един от
важни ползи от младостта на компютрите, в сравнение с много други области на инженерството, е, че
много от пионерите са все още живи - можем да научим историята чрез
просто ги питам!
Казуси и упражнения от Даяна Франклин
Казус 1: Разходи за производство на чип
Концепции, илюстрирани от този казус
Разходи за производство
Производствен добив
Толерантност към дефекти чрез излишък
Има много фактори, които участват в цената на компютърния чип. Нов, по-малък
технологията дава тласък на производителността и намаляване на необходимата площ на чипа. В
по-малка технология, човек може или да запази малката площ, или да постави повече хардуер
чипа, за да получите повече функционалност. В този казус ние изследваме как различните дизайнерски
решения включват производствена технология, площ и излишък
влияят на цената на чиповете.
Размер на Очакван процент Производствен Транзистори

Чип
матрицата (mm2) дефекти (на cm2) размер (nm) (милиони)
IBM Power5 389 .30 130 276
Слънчева Ниагара 380 .75 90 279
AMD Opteron 199 .75 90 233
Фигура 1.22 Фактори на производствените разходи за няколко съвременни процесора.
1.1 [10/10] <1.6> Фигура 1.22 дава съответните статистически данни за чипове, които влияят върху цената
от няколко актуални чипа. В следващите няколко упражнения ще изследвате
ефект на различни възможни дизайнерски решения за IBM Power5.
а. [10] <1.6> Какъв е добивът за IBM Power5?
b. [10] <1.6> Защо IBM Power5 има по-нисък процент на дефекти от Niag-ara и Opteron?
1.2 [20/20/20/20] <1.6> Изграждането на ново производствено съоръжение струва 1 милиард долара. Вие
ще продава набор от чипове от тази фабрика и вие трябва да решите как
голям капацитет за отделяне на всеки чип. Вашият чип Woods ще бъде 150 mm2 и
ще направи печалба от $20 на бездефектен чип. Вашият чип Markon ще бъде 250
mm2 и ще реализира печалба от $25 на бездефектен чип. Вашето производствено съоръжение
ще бъде идентичен с този за Power5. Всяка вафла е с диаметър 300 мм.
а. [20] <1.6> Каква печалба правите от всяка вафла чип Woods?
b. [20] <1.6> Каква печалба правите от всяка вафла чип Markon?
° С. [20] <1.6> Кой чип трябва да произвеждате в това съоръжение?
д. [20] <1.6> Каква е печалбата от всеки нов Power5 чип? Ако вашето търсене е
50 000 чипа Woods на месец и 25 000 чипа Markon на месец, и
вашето съоръжение може да произвежда 150 вафли на месец, колко вафли трябва да направите
направи на всеки чип?
1.3 [20/20] <1.6> Вашият колега от AMD предполага, че тъй като добивът е толкова слаб,
може да правите чипове по-евтино, ако поставите допълнително ядро върху матрицата и
изхвърли само чипове, на които и двата процесора са се провалили. Ние ще решим това
упражняване, като разглеждате добива като вероятност да не се появят дефекти в определен
площ при процент на дефекти. Изчислете вероятностите въз основа на всяко ядро на Opteron
отделно (това може да не е напълно точно, тъй като уравнението за добив се основава на
емпирични доказателства, а не математическо изчисление, свързващо вероятностите за
намиране на грешки в различни части на чипа).
а. [20] <1.6> Каква е вероятността да възникне дефект на не повече от

едно от двете процесорни ядра?
b. [20] <1.6> Ако старият чип струва $20 долара на чип, каква ще бъде цената на
новия чип, като се вземат предвид новата площ и добив?
Казус 2: Консумация на енергия в компютърни системи
Закон на Амдал
Излишък
MTTF
Консумирана мощност
Консумацията на енергия в съвременните системи зависи от различни фактори,

включително тактова честота на чипа, ефективност, скорост на дисковото устройство, използване на
дисковото устройство и DRAM. Следващите упражнения изследват въздействието върху властта, която
различни дизайнерски решения и сценарии за използване.
1.4 [20/10/20] <1.5> Фигура 1.23 представя консумацията на енергия на няколко компонента на компютърната
система. В това упражнение ще проучим как твърдият диск
влияе върху консумацията на енергия за системата.
а. [20] <1.5> Приема се максимално натоварване за всеки компонент и мощност

ефективност на захранването от 80%, каква мощност трябва да захранва захранването на сървъра
достави към система с чип Intel Pentium 4, 2 GB 240-пинов Kingston
DRAM и един твърд диск със 7200 rpm?
b. [10] <1.5> Колко енергия ще консумира дисковото устройство със 7200 rpm, ако е
празен ход приблизително 60% от времето?
° С. [20] <1.5> Като се има предвид, че времето за четене на данни от дисково устройство със 7200 rpm ще бъде
приблизително 75% от диск с 5400 rpm, при какво време на празен ход на диска с 7200 rpm ще
консумацията на енергия да е еднаква средно за двата диска?
1.5 [10/10/20] <1.5> Един критичен фактор при захранването на сървърна група е охлаждането. Ако топлината
не се отстранява ефективно от компютъра, вентилаторите ще духат горещ въздух обратно
компютъра, а не студения въздух. Ще разгледаме как влияят различните дизайнерски решения
необходимото охлаждане и съответно цената на системата. Използвайте фигура 1.23 за вашия
изчисления на мощността.
Тип компонент
Продукт Мощност на производителността
Процесор Sun Niagara 8-ядрен 1,2 GHz 72–79 W пикова

Intel Pentium 4 2 GHz 48,9–66 W
DRAM Kingston X64C3AD2 1 GB 184-пинов 3,7 W
Kingston D2N3 1 GB 240-пинов 5400 rpm 2,3 W
Твърд диск DiamondMax 16 7200 rpm 7,0 W четене/търсене, 2,9 W неактивен
DiamondMax 9 7,9 W четене/търсене, 4,0 W неактивен
Фигура 1.23 Консумация на енергия на няколко компютърни компонента.

а. [10] <1.5> Охлаждаща врата за шкаф струва $4000 и разсейва 14 KW (в

стаята; изискват се допълнителни разходи, за да го извадите от стаята). Колко
сървъри с процесор Intel Pentium 4, 1 GB 240-pin DRAM и единичен
7200 rpm твърд диск можете ли да охлаждате с една охлаждаща врата?
b. [10] <1.5> Обмисляте да осигурите устойчивост на грешки за вашия твърд диск.

RAID 1 удвоява броя на дисковете (вижте Глава 6). Сега колко системи можете да поставите на
един шкаф с един охладител?
° С. [20] <1.5> Типичните сървърни ферми могат да разсейват максимум 200 W на

квадратен фут. Като се има предвид, че сървърната стойка изисква 11 квадратни фута (включително предната част
и отзад), колко сървъра от част (a) могат да бъдат поставени на един шкаф и колко охлаждащи
врати са необходими?
1.6 [Дискусия] <1.8> Фигура 1.24 дава сравнение на мощност и производителност

за няколко бенчмарка, сравняващи два сървъра: Sun Fire T2000 (който използва
Niagara) и IBM x346 (с помощта на процесори Intel Xeon). Тази информация беше
съобщава на уеб сайт на Sun. Съобщават се две части от информацията: мощност
и скорост на два бенчмарка. За показаните резултати Sun Fire T2000 е
явно превъзхожда. Какви други фактори могат да бъдат важни и по този начин да причинят на някого
да изберете IBM x346, ако е по-добър в тези области?
1.7 [20/20/20/20] <1.6, 1.9> Вътрешните проучвания на вашата компания показват, че едноядрен
системата е достатъчна за търсенето на вашата процесорна мощност; обаче ти си
проучване дали бихте могли да спестите енергия, като използвате две ядра.
а. [20] <1.9> Да приемем, че вашето приложение е 80% паралелно. С колко

бихте ли могли да намалите честотата и да получите същото представяне? b. [20]
<1.6> Да приемем, че напрежението може да намалява линейно с честотата. Използвайки

уравнението в раздел 1.5, колко динамична мощност би
двуядрената система изисква в сравнение с едноядрената система?
° С. [20] <1.6, 1.9> Сега приемете, че напрежението може да не намалее под 25% от
оригинално напрежение. Това напрежение се нарича дъно на напрежението и всяко напрежение
по-ниско от това ще загуби състоянието. Какъв процент паралелизиране дава
имате напрежение на пода на напрежението?
д. [20] <1.6, 1.9> Използвайки уравнението в раздел 1.5, колко динамична мощност
би ли изисквала двуядрената система в сравнение с едноядрената система
като се вземе предвид пода на напрежението?
Sun Fire T2000 IBM x346
Мощност (ватове) 298 438
SPECjbb (операции/сек) 63,378 39,985
Мощност (ватове) 330 438
SPECWeb (композитен) 14 001 4348
Фигура 1.24 Сравнение мощност/производителност на Sun, както избирателно докладва Sun.

1.8 [10/15/15/10/10] <1.4, 1.5> Едно предизвикателство за архитектите е, че създаденият днес дизайн
ще изисква няколко години изпълнение, проверка и тестване, преди да се появи на пазара.
Това означава, че архитектът трябва да проектира каква ще бъде технологията няколко години
предварително. Понякога това е трудно да се направи.
а. [10] <1.4> Според тенденцията в мащабирането на устройствата, наблюдавана от закона на

Мур, броят на транзисторите на чип през 2015 г. трябва да бъде колко пъти броят през
2005 г.?
b. [15] <1.5> Увеличаването на тактовите честоти някога отразяваше тази тенденция. Ако темповете на часовника
бяха продължили да се покачват със същата скорост, както през 90-те години, приблизително колко бързо
биха били темповете на часовника през 2015 г.?
° С. [15] <1.5> При сегашния темп на нарастване, какви са прогнозните часови честоти през
2015 г.?
д. [10] <1.4> Какво е ограничило скоростта на нарастване на тактовата честота и какво правят
архитектите с допълнителните транзистори сега, за да увеличат производителността?
д. [10] <1.4> Скоростта на нарастване на капацитета на DRAM също се забави. В продължение

на 20 години капацитетът на DRAM се подобрява с 60% всяка година. Този процент спадна
до 40% всяка година и сега подобрението е 25 до 40% на година. Ако тази тенденция
продължи, какъв ще бъде приблизителният темп на нарастване на капацитета на DRAM
до 2020 г.?
1.9 [10/10] <1.5> Вие проектирате система за приложение в реално време, в което трябва да се спазват
конкретни срокове. По-бързото завършване на изчислението не печели нищо.
Откривате, че вашата система може да изпълни необходимия код, в най-лошия случай, два
пъти по-бързо от необходимото.
а. [10] <1.5> Колко енергия спестявате, ако изпълнявате с текущата скорост

и да изключите системата, когато изчислението приключи?
b. [10] <1.5> Колко енергия спестявате, ако зададете напрежението и честотата

честотата да е наполовина по-малко?
1.10 [10/10/20/20] <1.5> Сървърни ферми като Google и Yahoo! осигурете достатъчно изчислителен
капацитет за най-високата честота на заявки за деня. Представете си, че през повечето време
тези сървъри работят само с 60% капацитет. Освен това приемете, че мощността не се
мащабира линейно с товара; тоест, когато сървърите работят с 60% капацитет, те консумират
90% от максималната мощност. Сървърите могат да бъдат изключени, но ще им отнеме твърде
много време, за да се рестартират в отговор на по-голямо натоварване.
Предложена е нова система, която позволява бързо рестартиране, но изисква 20% от
максималната мощност, докато е в това състояние „едва жив“. а.
[10] <1.5> Колко икономии на енергия ще бъдат постигнати чрез изключване на 60%
на сървърите?
b. [10] <1.5> Колко икономии на енергия ще бъдат постигнати чрез поставяне на 60% от
сървърите в състояние „едва живи“?
° С. [20] <1,5> Колко спестявания на енергия ще бъдат постигнати чрез намаляване на

напрежение с 20% и честота с 40%?
д. [20] <1.5> Колко икономии на енергия ще бъдат постигнати чрез поставяне на 30% от
сървърите в състояние „едва живи“ и 30% намаление?
1.11 [10/10/20] <1.7> Наличността е най-важното съображение за проектиране на сървъри, следвано

плътно от скалируемостта и пропускателната способност. а.
[10] <1.7> Имаме един процесор с откази във времето (FIT) от 100.
Какво е средното време до отказ (MTTF) за тази система?
b. [10] <1.7> Ако отнеме 1 ден, за да стартира системата отново, каква е наличността на
системата?
° С. [20] <1.7> Представете си, че правителството, за да намали разходите, ще изгради

суперкомпютър от евтини компютри, а не от скъпи, надеждни компютри. Какво е MTTF
за система с 1000 процесора? Приемете, че ако един се провали, всички се провалят.
1.12 [20/20/20] <1.1, 1.2, 1.7> В сървърна група като тази, използвана от Amazon или eBay, единична
повреда не причинява срив на цялата система. Вместо това ще намали броя на заявките,
които могат да бъдат удовлетворени във всеки един момент. а. [20]
<1.7> Ако една компания има 10 000 компютъра, всеки с MTTF от 35 дни, и претърпи
катастрофален срив само ако 1/3 от компютрите се повредят, каква е MTTF за системата?
b. [20] <1.1, 1.7> Ако удвояването на MTTF струва допълнителни $1000 на компютър, ще бъде
ли това добро бизнес решение? Покажете работата си.
° С. [20] <1.2> Фигура 1.3 показва средната цена на прекъсванията, като се приема, че цената
е еднаква по всяко време на годината. За търговците на дребно обаче коледният сезон
е най-печелившият (и следователно най-скъпият период за загуба на продажби). Ако
център за каталожни продажби има два пъти повече трафик през четвъртото тримесечие,
отколкото всяко друго тримесечие, каква е средната цена на престой на час през
четвъртото тримесечие и останалата част от годината?
1.13 [10/20/20] <1.9> Вашата компания се опитва да избере между закупуването на Opteron или
Itanium 2. Вие сте анализирали приложенията на вашата компания и 60% от времето ще
изпълнява приложения, подобни на wupwise, 20% от приложенията за време, подобни на
ammp, и 20% от приложенията за време, подобни на apsi. а. [10] Ако избирате само въз
основа на цялостната производителност на SPEC, което

бихте ли избрали и защо?
b. [20] Каква е среднопретеглената стойност на коефициентите на време за изпълнение за тази комбинация от
приложения за Opteron и Itanium 2?
° С. [20] Какво е ускоряването на Opteron спрямо Itanium 2?
1.14 [20/10/10/10/15] <1.9> В това упражнение приемете, че обмисляме подобряване на машина

чрез добавяне на векторен хардуер към нея. Когато едно изчисление се изпълнява в режим
vec-tor на векторния хардуер, то е 10 пъти по-бързо от нормалния режим на изпълнение.
Наричаме процента на времето, което може да бъде прекарано при използване на векторен режим
процентът на векторизация. Векторите се обсъждат в глава 4, но не е нужно да знаете нищо за

това как работят, за да отговорите на този въпрос! а. [20] <1.9> Начертайте графика,
която изобразява ускоряването като процент от изчислението, извършено във векторен режим.
Етикетирайте оста y „Нетно ускоряване“ и етикетирайте оста x „Процентна векторизация“.
b. [10] <1.9> Какъв процент векторизация е необходим за постигане на ускорение

от 2?
° С. [10] <1.9> Какъв процент от времето за изпълнение на изчислението се изразходва във

векторен режим, ако се постигне ускорение от 2?
д. [10] <1.9> Какъв процент векторизация е необходим за постигане на половината от

максималното ускоряване, постижимо при използване на векторен режим?
д. [15] <1.9> Да предположим, че сте измерили процента на векторизация на програмата да бъде

70%. Групата за проектиране на хардуер изчислява, че може да ускори още повече векторния
хардуер със значителни допълнителни инвестиции. Чудите се дали екипът на компилатора
може вместо това да увеличи процента на векторизация. Какъв процент на векторизация би
трябвало да постигне екипът на компилатора, за да се равнява на допълнително 2× ускорение
във векторната единица (отвъд първоначалните 10×)?
1.15 [15/10] <1.9> Да приемем, че правим подобрение на компютър, което подобрява някакъв режим на
изпълнение с фактор 10. Подобреният режим се използва 50% от времето, измерено като процент
от времето за изпълнение, когато използва се подобрен режим. Спомнете си, че законът на
Amdahl зависи от частта от първоначалното, неусъвършенствано време за изпълнение, което
може да използва подобрения режим. По този начин не можем директно да използваме това
измерване от 50%, за да изчислим ускоряването със закона на Амдал.
а. [15] <1.9> Какво е ускорението, което сме получили от бързия режим? b. [10] <1.9>
Какъв процент от първоначалното време за изпълнение е кон-

превключен на бърз режим?
1.16 [20/20/15] <1.9> Когато правите промени за оптимизиране на част от процесор, често се случва
ускоряването на един тип инструкции да се дължи на забавяне на нещо друго. Например, ако
поставим сложна бърза единица с плаваща запетая, това отнема място и може да се наложи
нещо да се премести по-далеч от средата, за да се приспособи, добавяйки допълнителен цикъл
на забавяне, за да достигне тази единица. Основното уравнение на закона на Амдал не взема
предвид този компромис. а. [20] <1.9> Ако новият бърз модул с плаваща запетая ускорява
операциите с плаваща запетая средно 2 пъти и операциите с плаваща запетая отнемат 20% от
времето за изпълнение на оригиналната програма, какво е цялостно ускоряване (игнориране
на наказанието за други инструкции)?
b. [20] <1.9> Сега приемете, че ускоряването на модула с плаваща запетая забави достъпа до кеша
на данни, което доведе до забавяне 1,5 пъти (или 2/3 ускоряване). Достъпите до кеша на
данни отнемат 10% от времето за изпълнение. Какво е общото ускорение сега?
° С. [15] <1.9> След прилагането на новите операции с плаваща запетая, какъв процент от
времето за изпълнение се изразходва за операции с плаваща запетая? Какъв процент
се изразходва за достъп до кеша на данни?
1.17 [10/10/20/20] <1.10> Вашата компания току-що закупи нов двуядрен процесор Intel Core i5 и вие
сте получили задачата да оптимизирате софтуера си за този процесор. Ще стартирате две
приложения на този двуядрен, но изискванията за ресурси не са еднакви. Първото
приложение изисква 80% от ресурсите, а другото само 20% от ресурсите. Да приемем, че
когато паралелизирате част от програмата, ускоряването за тази част е 2. a. [10] <1.10> Като
се има предвид, че 40% от първото приложение може да се
паралелизира, колко ускоряване бихте постигнали с това приложение, ако се изпълнява

изолирано? b. [10] <1.10> Като се има предвид, че 99% от второто приложение може
да се паралелизира, колко ускоряване ще наблюдава това приложение, ако работи

изолирано? ° С. [20] <1.10> Като се има предвид, че 40% от първото
приложение може да се паралелизира, колко общо ускоряване на системата бихте

наблюдавали, ако го паралелизирате?
д. [20] <1.10> Като се има предвид, че 99% от второто приложение може да се паралелизира,
колко общо ускоряване на системата бихте наблюдавали, ако го паралелизирате?
1.18 [10/20/20/20/25] <1.10> Когато паралелизирате приложение, идеалното ускоряване е ускоряването

с броя на процесорите. Това е ограничено от две неща: процентна възраст на приложението,
което може да бъде паралелизирано, и цената на комуникацията.
Законът на Амдал взема предвид първото, но не и второто.
а. [10] <1.10> Какво е ускоряването с N процесора, ако 80% от приложението

е паралелизируем, игнорирайки цената на комуникацията?
b. [20] <1.10> Какво е ускоряването с 8 процесора, ако за всеки добавен процесор разходите
за комуникация са 0,5% от първоначалното време за изпълнение. ° С. [20] <1.10>
Какво е ускоряването с 8 процесора, ако за всеки път, когато броят на процесорите се удвои,
комуникационните разходи се увеличават с 0,5% от първоначалното време за
изпълнение? д. [20] <1.10> Какво е
ускоряването с N процесора, ако всеки път, когато броят на процесорите се удвои,

комуникационните разходи се увеличават с 0,5% от първоначалното време за
изпълнение?
д. [25] <1.10> Напишете общото уравнение, което решава този въпрос: Какъв е броят на
процесорите с най-висока скорост в приложение, в което P% от първоначалното време
за изпълнение е паралелно, и за всеки път броят на процесори се удвоява,
комуникацията се увеличава с 0,5% от първоначалното време за изпълнение?

2.2 Десет разширени оптимизации на производителността на кеша 78

2.3 Технология на паметта и оптимизации 96
2.4 Защита: Виртуална памет и виртуални машини 105
2.5 Междусекторни въпроси: Дизайнът на йерархиите на паметта 112
2.6 Събирайки всичко заедно: Йерахии на паметта в

ARM Cortex-A8 и Intel Core i7 113
2.8 Заключителни бележки: Поглед напред, 129
2.9 историческа перспектива и препратки, 131
казуси и упражнения от Норман П. Джупи, Навийн

Муралиманохар и Шенг Ли 131
2
Йерархия на паметта
Дизайн 1
В идеалния случай човек би желал неограничено голям капацитет на

паметта, така че всяка конкретна... дума да бъде незабавно достъпна. …
Ние сме... принудени да признаем възможността за изграждане на йерархия
от спомени, всяка от които има по-голям капацитет от предходната, но
която е по-малко достъпна.
AW Burks, HH Goldstine,
и Й. фон Нойман
Предварително обсъждане на
Логически дизайн на електроника
Изчислителен инструмент (1946)

72 Глава втора Дизайн на йерархията на паметта
Компютърните пионери правилно прогнозираха, че програмистите ще искат неограничени

количества бърза памет. Икономично решение на това желание е йерархията на паметта,
която се възползва от локалността и компромисите в съотношението цена-производителност
на технологиите за памет. Принципът на локалност, представен в първата глава, казва, че
повечето програми не осъществяват достъп до целия код или данни еднакво. Локалността
възниква във времето (времева локалност) и в пространството (пространствена локалност).
Този принцип, плюс указанието, че за дадена технология за внедряване и бюджет за мощност
по-малък хардуер може да бъде направен по-бърз, доведоха до йерархии, базирани на памети
с различни скорости и размери. Фигура 2.1 показва многостепенна йерархия на паметта,
включително типични размери и скорости на достъп.
Тъй като бързата памет е скъпа, йерархията на паметта е организирана в няколко нива -
всяко по-малко, по-бързо и по-скъпо на байт от следващото по-ниско ниво, което е по-далеч
от процесора. Целта е да се осигури система с памет с цена на байт почти толкова ниска,
колкото най-евтиното ниво на памет и скорост почти толкова висока, колкото най-бързото
ниво. В повечето случаи (но не във всички) данните, съдържащи се в по-ниско ниво, са
надмножество на следващото по-високо ниво. Това свойство, наречено свойство за включване,
винаги се изисква за най-ниското ниво на йерархията, което се състои от основна памет в
случай на кеш памет и дискова памет в случай на виртуална памет.
L1 L2 L3
°С °С °С Шина на
процесор а а а паметта
памет I/O шина Дисково съхранение
°С °С °С
Регистри
ч ч ч
д д д
диск
препратка
Ниво 1 Ниво 2 Ниво 3 Препратка
сн
,гр
т8тн 3каев
тн ъм
ю
е
д2ач
и ти
,м
1
о
д хN
ф
и
:гл
сп 0рсм
1о нх
л
рд оъ
утеB
1
8
в кн
й
р
0
7
оа S.ж
т,М ;г,еI.©
е
п
К
Б
о
0
2
9
а П
Л
Д
А
Х
Справка
:,7а
н
53а 8
нн в
р
еръ т,ъ
3уи
към паметта
по регистъра Кеш Кеш Кеш към паметта
справка справка справка
размер: 1000 байта 64 KB 1 256 KB 3– 2 – 4 MB 10 4 –16 GB 50 4 –16 TB 5 –
Скорост: 300 ps ns 10 ns – 20 ns –100 ns 10 ms
(a) Йерархия на паметта за сървъра
L1 L2
°С °С Шина на
процесор а а паметта
памет Съхранение
°С °С
Регистри
ч ч
д д
Светкавица
препратка
Справка Ниво 1 Ниво 2 Препратка
към паметта
по регистъра Кеш Кеш към паметта
справка справка
Размер: 500 байта 64 KB 2 256 KB 10 256 – 512 MB 50 – 4 – 8 GB 25
Скорост: 500 ps ns – 20 ns 100 ns – 50 us
(b) Йерархия на паметта за персонално мобилно устройство
Фигура 2.1 Нивата в типична йерархия на паметта в сървърен компютър, показан отгоре (a) и в
персонално мобилно устройство (PMD) отдолу (b). Тъй като се отдалечаваме от процесора, паметта
на нивото по-долу става по-бавна и по-голяма.
Обърнете внимание, че единиците за време се променят с коефициент 109 — от пикосекунди до
милисекунди — и че единиците за размер се променят с коефициент 1012 — от байтове до терабайти.
PMD има по-бавна тактова честота и по-малки кешове и основна памет. Ключова разлика е, че
сървърите и настолните компютри използват дисково съхранение като най-ниско ниво в йерархията,
докато PMD използват Flash, който е изграден от EEPROM технология.
Значението на йерархията на паметта се увеличи с напредъка в производителността на

процесорите. Фигура 2.2 начертава прогнози за производителността на един процесор спрямо
историческото подобрение на производителността във времето за достъп до основния
памет. Линията на процесора показва увеличението на заявките за памет в секунда
средно (т.е. обратното на латентността между препратките към паметта), докато
линията на паметта показва увеличението на DRAM достъпите за секунда (т.е
обратно на забавянето на достъпа до DRAM). Ситуацията в еднопроцесорната всъщност е
малко по-лошо, тъй като пиковата скорост на достъп до паметта е по-бърза от средната
скорост, която е начертана.
Съвсем наскоро процесорите от висок клас преминаха към множество ядра
увеличаване на изискванията за честотна лента спрямо единични ядра. Всъщност съвкупността
пиковата честотна лента по същество нараства с нарастването на броя на ядрата. Модерен
процесор от висок клас като Intel Core i7 може да генерира две препратки към памет за данни
на ядро всеки такт; с четири ядра и тактова честота от 3,2 GHz, i7 може
генерира пик от 25,6 милиарда 64-битови препратки към памет за данни в секунда, в допълнение
към пиковото търсене на инструкции от около 12,8 милиарда 128-битови препратки към
инструкции; това е обща пикова честотна лента от 409,6 GB/sec! Тази невероятна честотна лента
се постига чрез мултипортиране и конвейериране на кеш паметта; чрез използване на множество
нива на кешове, като се използват отделни кешове от първо и понякога второ ниво за всяко ядро;
и чрез използване на отделни инструкции и кеш данни на първо ниво. За разлика от тях,
пиковата честотна лента към DRAM основната памет е само 6% от това (25 GB/sec).
100 000
10 000
1000
Процесор
тсонлетидовзиорп
100
10
памет
1
1980 г 1985 г 1990 г 1995 г 2000 г 2005 г 2010 г
година
Фигура 2.2 Започвайки с производителността от 1980 г. като базова линия, разликата в производителността,
измерено като разликата във времето между заявките за памет на процесора (за a
единичен процесор или ядро) и латентността на достъп до DRAM, се нанася във времето.
Обърнете внимание, че вертикалната ос трябва да е в логаритмична скала, за да се запише размерът на
разлика в производителността на процесора и DRAM. Базовата линия на паметта е 64 KB DRAM през 1980 г., с
1,07 на година подобрение на производителността в латентността (вижте Фигура 2.13 на страница 99). The
процесорната линия предполага подобрение от 1,25 на година до 1986 г., подобрение от 1,52
до 2000 г., подобрение с 1,20 между 2000 г. и 2005 г. и без промяна в процесора
производителност (на база ядро) между 2005 г. и 2010 г.; вижте Фигура 1.1 в Глава 1.
Традиционно дизайнерите на йерархии на паметта се фокусират върху оптимизирането на

средното време за достъп до паметта, което се определя от времето за достъп до кеша, скоростта на
пропуски и наказанието за пропуски. Съвсем наскоро обаче мощността се превърна в основен
фактор. В микропроцесорите от висок клас може да има 10 MB или повече кеш памет в чипа, а голям
кеш от второ или трето ниво ще консумира значителна мощност както като изтичане, когато не
работи (наречена статична мощност), така и като активна мощност , т.к. когато извършвате четене
или запис (наречено динамично захранване), както е описано в раздел 2.3. Проблемът е още по-
остър при процесорите в PMD, където CPU е по-малко агресивен и бюджетът за мощност може да
бъде 20 до 50 пъти по-малък. В такива случаи кеш паметта може да представлява 25% до 50% от
общата консумация на енергия. По този начин повече дизайни трябва да вземат предвид както
производителността, така и компромисите с мощността и ние ще разгледаме и двете в тази глава.
Основи на йерархиите на паметта: Бърз преглед
Нарастващият размер и следователно значението на тази празнина доведе до миграцията на

основите на йерархията на паметта в бакалавърски курсове по компютърна архитектура и дори в
курсове по операционни системи и компилатори. Така ще започнем с бърз преглед на кешовете и
тяхната работа. По-голямата част от главата обаче описва по-напреднали иновации, които атакуват
ефективността на процесора и паметта.
mance gap.
Когато дума не бъде намерена в кеша, думата трябва да бъде извлечена от по-ниско ниво в
йерархията (което може да е друг кеш или основната памет) и поставена в кеша, преди да
продължите. Множество думи, наречени блок (или ред), се преместват от съображения за
ефективност и защото е вероятно скоро да са необходими поради пространствената локализация.
Всеки кеш блок включва таг , за да посочи на кой адрес на паметта съответства.
Ключово дизайнерско решение е къде могат да бъдат поставени блокове (или редове) в кеш
паметта. Най-популярната схема е асоциативната набор, където наборът е група от блокове в кеша.
Един блок първо се картографира върху набор и след това блокът може да бъде поставен навсякъде
в този набор. Намирането на блок се състои от първо картографиране на адреса на блока към
набора и след това търсене в набора - обикновено паралелно - за намиране на блока. Комплектът
се избира по адреса на данните:
(Блокиране на адрес) MOD (Брой набори в кеша)
Ако има n блока в набор, разположението на кеша се нарича асоциативно на n-way set.
Крайните точки на асоциативността на множеството имат свои имена. Кешът с директно
картографиране има само един блок на набор (така че блокът винаги се поставя на едно и също
място), а напълно асоциативният кеш има само един набор (така че блокът може да бъде поставен навсякъде).
Кеширането на данни, които се четат само, е лесно, тъй като копието в кеша и паметта ще
бъдат идентични. Кеширането на записи е по-трудно; например, как копието в кеша и паметта може
да се поддържа последователно? Има две основни стратегии.
Кешът за запис актуализира елемента в кеша и записва, за да актуализира
Главна памет. Кешът за обратно записване актуализира само копието в кеша. Когато
блок е на път да бъде заменен, той се копира обратно в паметта. И двамата пишат стратегии
може да използва буфер за запис , за да позволи на кеша да продължи веднага след като данните бъдат поставени
в буфера, вместо да чака пълното забавяне, за да запише данните в паметта.
Една мярка за предимствата на различните организации на кеша е процентът на пропуски.
Процентът на пропуски е просто частта от достъпите до кеша, които водят до пропуск – т.е.
броят на пропуснатите достъпи, разделен на броя на достъпите.
Да получите представа за причините за високия процент пропуски, което може да вдъхнови по-добре
дизайни на кеша, трите модела Cs сортират всички пропуски в три прости категории:
Задължително— първият достъп до блок не може да бъде в кеша, така че
блок трябва да бъде пренесен в кеша. Задължителните пропуски са тези, които се случват
дори ако имате кеш с безкраен размер.
Капацитет—Ако кешът не може да съдържа всички блокове, необходими по време на изпълнение
на програма, ще възникнат пропуски на капацитет (в допълнение към задължителните пропуски).
поради блокове, които се изхвърлят и по-късно извличат.
Конфликт—Ако стратегията за поставяне на блокове не е напълно асоциативна, конфликт
пропуски (в допълнение към задължителните пропуски и пропуски на капацитет) ще възникнат, защото a
блок може да бъде отхвърлен и по-късно извлечен, ако множество блокове се съпоставят с неговия набор
и достъпите до различните блокове се смесват.
Фигури B.8 и B.9 на страници B-24 и B-25 показват относителната честота на
пропуски в кеша, разбити по трите C. Както ще видим в глави 3 и 5,
многонишковостта и множеството ядра добавят усложнения за кеш паметта, като и двете се увеличават
потенциалът за пропуски на капацитета, както и добавянето на четвърто C, за кохерентност
пропуски поради промиване на кеша, за да се поддържа кохерентност на множество кеши в мултипроцесор;
ще разгледаме тези въпроси в Глава 5.
Уви, пропуснатият процент може да бъде подвеждаща мярка по няколко причини. Следователно някои
дизайнерите предпочитат да измерват пропуските на инструкция , а не пропуските на памет

справка (пропуснат процент). Тези две са свързани:
Госпожици × Достъп до паметта

------------------------ = Пропуснат процент на достъп до паметта =
-------------------------------------------------- --------------------
Пропуснат процент × ------------------------------------------------
Инструкция Брой инструкции Инструкция
(Често се съобщава като пропуски на 1000 инструкции за използване на цели числа вместо
дроби.)
Проблемът и с двете мерки е, че те не вземат предвид цената на пропуска.

По-добра мярка е средното време за достъп до паметта:
Средно време за достъп до паметта = време на попадение + степен на пропуски × наказание за пропуски
където времето за попадение е времето за попадение в кеша, а наказанието за пропуск е времето за замяна
блокът от паметта (т.е. цената на пропуск). Средното време за достъп до паметта е
все още косвена мярка за изпълнение; въпреки че е по-добра мярка от пропуска
процент, не е заместител на времето за изпълнение. В глава 3 ще видим, че спекулативните процесори
могат да изпълняват други инструкции по време на пропуск, като по този начин намаляват
ефективно наказание за пропуск. Използването на многопоточност (въведено в глава 3) също позволява на
процесора да толерира пропуски, без да бъде принуден да пази. Както ще разгледаме скоро, за да се възползваме
от такива техники за толериране на латентност, се нуждаем от кеш памети, които могат да обслужват заявки,
докато обработват изключителни пропуски.
Ако този материал е нов за вас или ако този бърз преглед се движи твърде бързо, вижте Приложение B.
Той обхваща същия уводен материал по-задълбочено и включва примери за кешове от реални компютри и
количествени оценки на тяхната ефективност.
Раздел B.3 в Приложение B представя шест основни оптимизации на кеша, които набързо преглеждаме
тук. Приложението също така дава количествени примери за ползите от тези оптимизации. Ние също така
коментираме накратко последиците от тези компромиси върху мощността.
1. По-голям размер на блока за намаляване на честотата на пропускане – Най-лесният начин да намалите
процента на пропускане е да се възползвате от пространствената локалност и да увеличите размера на
блока. По-големите блокове намаляват задължителните пропуски, но също така увеличават наказанието за пропуски.
Тъй като по-големите блокове намаляват броя на етикетите, те могат леко да намалят статичната мощност.
По-големите размери на блокове също могат да увеличат капацитета или пропуските на конфликти,
особено в по-малки кешове. Изборът на правилния размер на блока е сложен компромис, който зависи от
размера на кеша и наказанието за пропуск.
2. По-големи кешове за намаляване на честотата на пропуски – Очевидният начин за намаляване на пропуските
на капацитет е да се увеличи капацитетът на кеша. Недостатъците включват потенциално по-дълго време
за попадение на по-голямата кеш памет и по-висока цена и мощност. По-големите кешове увеличават както
статичната, така и динамичната мощност.
3. По-висока асоциативност за намаляване на честотата на пропуски – Очевидно увеличаването на
асоциативността намалява пропуските на конфликти. По-голямата асоциативност може да дойде с цената
на увеличено време за попадение. Както ще видим скоро, асоциативността също увеличава консумацията
на енергия.
4. Многостепенни кешове за намаляване на наказанието за пропуски - Трудно решение е дали да направите
времето за попадение на кеша бързо, за да сте в крак с високата тактова честота на процесорите, или да
направите кеша голям, за да намалите разликата между достъпите на процесора и достъп до основната
памет. Добавянето на друго ниво на кеш между оригиналния кеш и паметта опростява решението (вижте
Фигура 2.3). Кешът от първо ниво може да бъде достатъчно малък, за да отговаря на бърз цикъл на
часовника, но кешът от второ ниво (или трето ниво) може да бъде достатъчно голям, за да улови много
достъпи, които биха отишли в основната памет. Фокусът върху пропуските в кешовете от второ ниво води
до по-големи блокове, по-голям капацитет и по-висока асоциативност. Многостепенните кешове са по-
енергийно ефективни от един общ кеш. Ако L1 и L2 се отнасят съответно за кешове от първо и второ ниво,
можем да предефинираме средното време за достъп до паметта:
Време за попадение L1 + степен на пропуск L1 × (време за попадение L2 + процент на пропуск L2 × наказание за пропуск L2)
5. Даване на приоритет на пропуските при четене пред записите, за да се намали наказанието за пропуски –
Буферът за запис е добро място за прилагане на тази оптимизация. Буферите за запис създават опасности,
защото държат актуализираната стойност на местоположение, необходимо при четене

900 1-посочен 2-посочен

4-посочен 8-посочен
800
700
600
500
оъм
иднукеспе оам
р
рткеси В
д
вз
400
300
200
100
0
16 KB 32 KB 64 KB 128 KB 256 KB
Размер на кеша
Фигура 2.3 Времената за достъп обикновено се увеличават с увеличаване на размера на кеша и

асоциативността. Тези данни идват от CACTI модел 6.5 от Tarjan, Thoziyoor и Jouppi [2005]. Данните
предполагат размер на характеристиката от 40 nm (което е между технологията, използвана в най-
бързата и втората най-бърза версия на i7 на Intel, и същата като технологията, използвана в най-
бързите вградени ARM процесори), една банка и 64-байтови блокове. Предположенията за
оформлението на кеша и сложните компромиси между закъсненията на взаимното свързване
(които зависят от размера на кеш блока, до който се осъществява достъп) и цената на проверките
на таговете и мултиплексирането водят до резултати, които понякога са изненадващи, като
например по-ниското време за достъп за 64 KB с двупосочна асоциативност на набор срещу
директно картографиране. По подобен начин резултатите с осемпосочна асоциативност генерират
необичайно поведение при увеличаване на размера на кеша. Тъй като такива наблюдения са силно
зависими от технологията и детайлните допускания за проектиране, инструменти като CACTI служат
за намаляване на пространството за търсене, а не за прецизен анализ на компромисите.
пропуск—т.е. опасност от четене след запис през паметта. Едно решение е да се провери
съдържанието на буфера за запис при пропуск на четене. Ако няма конфликти и ако
системата с памет е налична, изпращането на четене преди записите намалява наказанието
за пропуск. Повечето процесори дават приоритет на четене пред запис.
Този избор има малък ефект върху консумацията на енергия.
6. Избягване на преобразуването на адреси по време на индексирането на кеша, за да се намали

времето за попадение – Кешовете трябва да се справят с преобразуването на виртуален
адрес от процесора към физически адрес за достъп до паметта. (Виртуалната памет е
разгледана в раздели 2.4 и B.4.) Обща оптимизация е да се използва отместването на
страницата – частта, която е идентична както във виртуалните, така и във физическите
адреси – за индексиране на кеша, както е описано в Приложение B, страница Б-38. Този
метод на виртуален индекс/физически етикет въвежда някои системни усложнения и/или
ограничения за размера и структурата на L1 кеша, но предимствата на

премахване на достъпа до буфера за превод отстрани (TLB) от критичния
пътя надделява над недостатъците.
Имайте предвид, че всяка от шестте оптимизации по-горе има потенциален недостатък

което може да доведе до увеличаване, а не до намаляване на средното време за достъп до паметта.
Останалата част от тази глава предполага запознаване с материала по-горе и
подробности в Приложение Б. В раздела Събиране на всичко заедно разглеждаме
йерархия на паметта за микропроцесор, предназначен за сървър от висок клас, Intel
Core i7, както и един, предназначен за използване в PMD, Arm Cortex-A8, който е
основата за процесора, използван в Apple iPad и няколко от висок клас
смартфони. Във всеки от тези класове има значително разнообразие в
подход поради предназначението на компютъра. Докато процесорът от висок клас
използван в сървъра има повече ядра и по-големи кешове от процесорите на Intel
предназначени за настолни приложения, процесорите имат сходни архитектури. Разликите се дължат
на производителността и естеството на работното натоварване; настолните компютри работят
предимно едно приложение наведнъж върху операционна система
система за един потребител, докато сървърните компютри могат да имат стотици потребители
изпълнявайки потенциално десетки приложения едновременно. Заради тези
разликите в работното натоварване, настолните компютри обикновено са по-загрижени
средно забавяне от йерархията на паметта, докато сървърните компютри също са
загрижен за честотната лента на паметта. Дори в рамките на класа настолни компютри има голямо
разнообразие от нетбуци от по-нисък клас с умалени процесори, по-подобни на тези в PMD от висок
клас, до настолни компютри от висок клас, чиито
процесорите съдържат множество ядра и чиято организация наподобява тази на a
сървър от нисък клас.
За разлика от тях PMD не само обслужват един потребител, но обикновено имат и по-малки
операционни системи, обикновено по-малко мултитаскинг (изпълнение на няколко приложения
едновременно) и по-прости приложения. PMD също обикновено използват Flash
памет, а не дискове, и повечето отчитат както производителността, така и консумацията на енергия,
което определя живота на батерията.
2.2 Десет разширени оптимизации на производителността на кеша
Формулата за средно време за достъп до паметта по-горе ни дава три показателя за кеша
оптимизации: време за попадение, процент на пропуски и наказание за пропуск. Предвид последните тенденции, добавяме
кеш честотна лента и консумация на енергия към този списък. Можем да класифицираме десетте
разширени оптимизации на кеша, които разглеждаме в пет категории въз основа на тях
метрика:
1. Намаляване на времето за попадение—Малки и прости кешове от първо ниво и предсказване на

пътя. И двете техники обикновено намаляват консумацията на енергия.
2. Увеличаване на честотната лента на кеша – конвейерни кешове, мултибанкови кешове и

неблокиращи кешове. Тези техники имат различно въздействие върху консумацията на енергия.
3. Намаляване на наказанието за пропуски - първа критична дума и обединяване на буферите за запис.
Тези оптимизации имат малко влияние върху мощността.
4. Намаляване на процента на пропуски—Оптимизации на компилатора. Очевидно всяко подобрение-
ментът по време на компилиране подобрява консумацията на енергия.
5. Намаляване на наказанието за пропуски или честотата на пропуски чрез паралелизъм—Хардуерно предварително
извличане и предварително извличане на компилатор. Тези оптимизации обикновено увеличават мощността
потребление, главно поради предварително изтеглени данни, които не се използват.
Като цяло сложността на хардуера се увеличава, докато преминаваме през тези оптимизации. В допълнение,
някои от оптимизациите изискват сложен компилатор
технология. Ще завършим с обобщение на сложността на внедряването
и ползите от производителността на десетте техники, представени на Фигура 2.11
страница 96. Тъй като някои от тях са ясни, ние ги разглеждаме накратко; други
изискват повече описание.
Първа оптимизация: малки и прости кешове от първо ниво за

Намалете времето и мощността на удара
Натискът както от бързия тактов цикъл, така и от ограниченията на мощността насърчава ограниченото
размер за кешове от първо ниво. По същия начин използването на по-ниски нива на асоциативност може
намалете както времето за попадение, така и мощността, въпреки че подобни компромиси са по-сложни от
тези, включващи размера.
Критичният времеви път при попадение в кеша е процесът на адресиране в три стъпки
паметта на етикета, използвайки индексната част на адреса, сравнявайки прочетения етикет
стойност към адреса и настройка на мултиплексора да избере правилния елемент от данни, ако
кешът е зададен асоциативно. Директно картографираните кешове могат да припокриват проверката на етикета
предаването на данните, което ефективно намалява времето за попадение. Освен това по-ниско
нивата на асоциативност обикновено ще намалят мощността, защото трябва да има по-малко кеш линии
да бъде достъпен.
Въпреки че общият размер на кеша в чипа се е увеличил драстично с
нови поколения микропроцесори, поради влиянието на тактовата честота, произтичащо от a
по-голям L1 кеш, размерът на L1 кешовете наскоро се е увеличил леко
или изобщо не. В много скорошни процесори дизайнерите са избрали повече асоциативност, отколкото по-
големи кешове. Допълнително съображение при избора на
асоциативността е възможността за елиминиране на адресните псевдоними; обсъждаме това
скоро.
Един подход за определяне на въздействието върху времето за попадение и консумацията на енергия
Преди изграждането на чип е да използвате CAD инструменти. CACTI е програма за оценка на времето за достъп
и консумацията на енергия на алтернативни кеш структури
CMOS микропроцесори в рамките на 10% от по-подробните CAD инструменти. За даденост

минимален размер на функцията, CACTI оценява времето за попадение на кеша като вариации на размера на
кеша, асоциативност, брой портове за четене/запис и по-сложни параметри.
Фигура 2.3 показва очакваното въздействие върху времето за попадение като размер на кеша и асоциативност
са разнообразни. В зависимост от размера на кеша, за тези параметри моделът предполага това
времето за попадение за директно картографиране е малко по-бързо от двупосочно задаване на асоциативни и

че асоциативният двупосочен набор е 1,2 пъти по-бърз от четирипосочният, а четирипосочният е 1,4
пъти по-бързо от осемпосочен. Разбира се, тези оценки зависят от технологията като
както и размера на кеша.
Пример Като използвате данните от Фигура B.8 в Приложение B и Фигура 2.3, определете дали a
32 KB четирипосочен асоциативен L1 кеш има по-бързо време за достъп до паметта от a
32 KB двупосочен набор асоциативен L1 кеш. Да приемем, че наказанието за пропуск на L2 е 15
пъти времето за достъп за по-бързия L1 кеш. Игнорирайте пропуските след L2. Който
има по-бързо средно време за достъп до паметта?
Отговор Нека времето за достъп за двупосочния набор асоциативен кеш е 1. Тогава, за двупосочния кеш:
+ ×
Средно време за достъп до паметта 2-way = време за попадение Процент на пропуски Наказание за пропуски
= 1+
0,038 15 × = 1.38
За четиристранния кеш времето за достъп е 1,4 пъти по-дълго. Изминалото време на
наказанието за пропуск е 15/1,4 = 10,1. Приемете 10 за простота:
×
Средно време за достъп до паметта 4-посочен Hit time2-way = × 1,4 + Степен на пропуск Наказание за пропуск
= 1,4 0,037 10 + × = 1.77
Ясно е, че по-високата асоциативност изглежда като лош компромис; обаче, тъй като кеша
достъпът в съвременните процесори често е конвейерен, точното въздействие върху часовника
времето на цикъла е трудно за оценка.
Консумацията на енергия също е съображение при избора както на размера на кеша
и асоциативност, както показва фигура 2.4 . Енергийната цена на по-високата асоциативност
варира от повече от коефициент 2 до незначителен в кешове от 128 KB или 256 KB
при преминаване от директно съпоставяне към двупосочен набор асоциативно.
В последните дизайни има три други фактора, които са довели до използването на
по-висока асоциативност в кешовете от първо ниво. Първо, много процесори приемат поне две
часовникови цикли за достъп до кеша и по този начин въздействието на по-дългото време на попадение може да не е така
бъди критичен. Второ, за да запазите TLB извън критичния път (закъснение, което би било
по-голям от този, свързан с повишена асоциативност), почти всички L1 кешове
трябва да бъдат виртуално индексирани. Това ограничава размера на кеша до размера на страницата
пъти асоциативността, защото тогава само битовете в страницата се използват за
индекс. Има и други решения на проблема с индексирането на кеша преди
адрес превод е завършен, но увеличаване на асоциативността, която също има

други предимства, е най-привлекателна. Трето, с въвеждането на многопоточност (вижте глава 3), пропуските
на конфликти могат да се увеличат, което прави по-висока асоциативност

по-атрактивен.
0,5
0,45
0,4
0,35
0,3
0,25
елн
яии ен
н
етж
н
уреа
го а ч
д
в
Е
0,2
0,15
0,1
0,05
0
16 KB 32 KB 64 KB 128 KB 256 KB
Фигура 2.4 Консумацията на енергия за четене се увеличава с увеличаване на размера на

кеша и асоциативността. Както в предишната фигура, CACTI се използва за моделиране със
същите технологични параметри. Голямото наказание за асоциативните кешове с осем
посоки се дължи на разходите за паралелно четене на осем тагова и съответните данни.
Втора оптимизация: Предсказване на начина за намаляване на времето за попадение
Друг подход намалява пропуските на конфликти и въпреки това поддържа скоростта на попадение
на директно картографирания кеш. При предсказване на пътя допълнителните битове се съхраняват
в кеша, за да се предвиди пътя или да се блокира в рамките на набора от следващия достъп до кеша.
Това предвиждане означава, че мултиплексорът е настроен рано, за да избере желания блок, и само
едно сравнение на тагове се извършва в този тактов цикъл успоредно с четенето на данните от кеша.
Пропускът води до проверка на другите блокове за съвпадения в следващия часовников цикъл.
Към всеки блок от кеша се добавят битове за предсказване на блокове. Битовете избират кой от
блоковете да се опита при следващия достъп до кеша. Ако предикторът е правилен, забавянето на
достъпа до кеша е бързото време за попадение. Ако не, той опитва другия блок, променя
предсказателя на пътя и има латентност от един допълнителен тактов цикъл. Симулациите
предполагат, че точността на предсказване на набор е над 90% за двупосочен набор асоциативен
кеш и 80% за четирипосочен набор асоциативен кеш, с по-добра точност при I-кешове отколкото D-
кешове. Предсказването на пътя дава по-ниско средно време за достъп до паметта за двупосочен
набор от асоциативен кеш, ако е поне 10% по-бърз, което е доста вероятно. Предсказването на пътя
беше използвано за първи път в MIPS R10000 в средата на 90-те години. Той е популярен в процесори,
които използват двупосочна асоциативност и се използва в ARM Cortex-A8 с четирипосочни
асоциативни кешове. За много бързи процесори може да се окаже предизвикателство да се приложи
спирането на един цикъл, което е от решаващо значение за запазване на наказанието за
прогнозиране на пътя малко.
Разширена форма на предсказване на пътя може също да се използва за намаляване на консумацията
на енергия чрез използване на битовете за предсказване на пътя, за да се реши кой кеш блок действително
да се осъществи достъп (битовете за предсказване на начина са по същество допълнителни адресни битове); това
подходът, който може да се нарече избор на начин, спестява енергия, когато предсказването на пътя е
правилно, но добавя значително време за погрешно предсказване на пътя, тъй като
достъпът, а не само съвпадението на етикета и изборът, трябва да се повтори. Такава оптимизация
вероятно ще има смисъл само при процесори с ниска мощност. Иноуе, Ишихара и
Murakami [1999] изчислява, че използването на подхода за избор на начин с асоциативен кеш с
четирипосочен набор увеличава средното време за достъп до I-кеша с
1.04 и за D-кеша с 1.13 на тестовете SPEC95, но дава
средна консумация на енергия на кеша спрямо нормален четирипосочен асоциативен набор
кеш, който е 0,28 за I-cache и 0,35 за D-cache. Един съществен недостатък при избора на начин е, че
затруднява конвейерирането на достъпа до кеша.
Пример Да предположим, че има наполовина по-малко достъпи до D-cache от достъпите до I-cache и

че I-cache и D-cache са отговорни за 25% и 15% от процесора
консумация на енергия при нормална асоциативна реализация на четирипосочен набор. Определете
дали изборът на начин подобрява производителността на ват въз основа на оценките
от проучването по-горе.
Отговор За I-cache спестяванията на енергия са 25 × 0,28 = 0,07 от общата мощност, докато

за D-кеша е 15 × 0,35 = 0,05 за общо спестяване от 0,12. Версията за предсказване на начина изисква 0,88
от изискваната мощност на стандартния 4-посочен кеш.
Увеличаването на времето за достъп до кеша е увеличението на средното време за достъп на I-cache
плюс половината от увеличението на времето за достъп до D-кеша, или 1,04 + 0,5 × 0,13 = 1,11
пъти по-дълго. Този резултат означава, че изборът на начин има 0,90 от ефективността на
стандартен четирипосочен кеш. По този начин изборът на начин подобрява производителността на джаул
много малко със съотношение 0,90/0,88 = 1,02. Тази оптимизация се използва най-добре там, където
мощността, а не производителността е ключова цел.
Трета оптимизация: Конвейерният достъп до кеша за увеличаване

Ширина на честотната лента на кеша
Тази оптимизация е просто да насочи достъпа до кеша, така че ефективното забавяне

на попадение в кеша от първо ниво може да бъде множество тактови цикли, което дава бързо време на тактовия цикъл
и висока честотна лента, но бавни удари. Например тръбопроводът за инструкцията

достъпът до кеша за процесори Intel Pentium в средата на 1990-те отне 1 тактов цикъл,
за Pentium Pro до Pentium III в средата на 1990-те до 2000 г. бяха необходими 2
часовници и за Pentium 4, който стана достъпен през 2000 г., и текущия
Intel Core i7 отнема 4 часовника. Тази промяна увеличава броя на тръбопроводите

етапи, което води до по-голямо наказание за неправилно предвидени разклонения и повече часовник
циклично преминава между издаване на зареждане и използване на данните (вижте глава 3), но го прави
улесняват включването на високи степени на асоциативност.
Четвърта оптимизация: Неблокиране на кешове за

Увеличете честотната лента на кеша
За конвейерни компютри, които позволяват изпълнение извън ред (обсъдено в глава 3),
процесорът не трябва да спира при пропуск на кеш данни. Например, процесорът може да
продължи да извлича инструкции от кеша за инструкции, докато чака кешът за данни да върне
липсващите данни. Неблокиращ кеш или кеш без блокиране ескалира потенциалните ползи от
такава схема, като позволява на кеша за данни да продължи да предоставя попадения в кеша по
време на пропуск. Тази оптимизация „попадение под пропуск“ намалява ефективното наказание
за пропуск, като е полезна по време на пропуск, вместо да игнорира заявките на процесора. Една
фина и сложна опция е, че кешът може допълнително да намали ефективното наказание за
пропуски, ако може да припокрие множество пропуски: оптимизация „попадение под множество
пропуски“ или „пропуск под пропуск“. Вторият вариант е полезен само ако системата с памет
може да обслужва множество пропуски; повечето високопроизводителни процесори (като Intel
Core i7) обикновено поддържат и двете, докато процесорите от по-нисък клас, като ARM A8,
предоставят само ограничена неблокираща поддръжка в L2.
За да изследват ефективността на неблокиращите кешове за намаляване на наказанието за

пропускане на кеша, Farkas и Jouppi [1994] направиха проучване, приемайки 8 KB кеша с наказание
за пропуск от 14 цикъла; те наблюдават намаление на ефективното наказание за пропуск от 20%
за показателите SPECINT92 и 30% за показателите SPECFP92, когато допускат едно попадение под
пропуск.
Li, Chen, Brockman и Jouppi [2011] наскоро актуализираха това проучване, за да използват
многостепенен кеш, по-модерни допускания относно наказанията за пропуски и по-големите и
по-взискателни тестове SPEC2006. Проучването е направено, като се приема модел, базиран на
едно ядро на Intel i7 (вижте раздел 2.6) , изпълняващ тестовете SPEC2006. Фигура 2.5 показва
намаляването на забавянето на достъпа до кеша за данни, когато се допускат 1, 2 и 64 попадения
при пропуск; надписът описва допълнителни подробности за системата с памет. По-големите кеш
памети и добавянето на L3 кеш след по-ранното проучване са намалили ползите с показателите
SPECINT2006, показващи средно намаление на латентността на кеша от около 9%, а показателите
SPECFP2006 около 12,5%.
Пример Кое е по-важно за програмите с плаваща запетая: асоциативността на двупосочен набор или попадение
под един пропуск за първичните кешове на данни? Какво ще кажете за целочислените програми?
Да приемем следните средни нива на пропуски за 32 KB кеш данни: 5,2% за програми с плаваща
запетая с директно преобразуван кеш, 4,9% за тези програми с двупосочен асоциативен кеш,
3,5% за цели програми с директно преобразуван кеш кеш и 3,2% за целочислени програми с
двупосочен асоциативен кеш. Да приемем, че наказанието за пропуск на L2 е 10 цикъла, а
пропуските и наказанията за L2 са еднакви.
Отговор За програми с плаваща запетая средните времена на задържане на паметта са
Miss rateDM × Miss penalty = 5,2% × 10 = 0,52
Miss rate2-way × Miss penalty = 4,9% × 10 = 0,49

Хит-под-1-пропускане Хит-под-2-пропускания Хит-под-64-пропуски
100%
90%
80%
70%
60%
50%
ап
ен яв о
са
ъаатш
б ен
З
д
к
40%
frw
2pfcciczm
g
b
mbl
ечsеuлeмz
адзевз
отнот
pm
bjh
isl
дман
н
qe2
4n6
mutfneargu
скелпос
lurcvloapc
ръмх
xyia
3скнифс
ирги
ицамарг
pptenmo
MDAсуткак
DTDFsmeG
СПЕЦИНТ SPECFP
Фигура 2.5 Ефективността на неблокиращ кеш се оценява чрез допускане на 1, 2 или 64

попадения под пропуск на кеш с 9 SPECINT (вляво) и 9 SPECFP (вдясно) показатели. Системата
за памет за данни, моделирана след Intel i7, се състои от 32KB L1 кеш с четири цикъла
закъснение на достъпа. Кешът L2 (споделен с инструкции) е 256 KB с латентност за достъп от
10 тактови цикъла. L3 е 2 MB и латентност за достъп от 36 цикъла. Всички кешове са
осемпосочни асоциативни и имат 64-байтов размер на блока. Позволяването на едно
попадение под пропуск намалява наказанието за пропуск с 9% за целочислените бенчмаркове
и 12,5% за плаващата запетая. Разрешаването на второ попадение подобрява тези резултати
до 10% и 16%, а допускането на 64 води до малко допълнително подобрение.
Забавянето на достъпа до кеша (включително спирания) за двупосочна асоциативност е 0,49/0,52 или

94% от директно картографирания кеш. Надписът на Фигура 2.5 казва, че попадението под един пропуск
намалява средното забавяне на достъпа до кеша за данни за програми с плаваща запетая до 87,5% от
блокиращия кеш. Следователно, за програмите с плаваща запетая, директно картографираният кеш на
данни, поддържащ едно попадение под едно пропускане, дава по-добра производителност от двупосочен
набор-асоциативен кеш, който блокира при пропуск.
За целочислени програми изчислението е
Miss rateDM × Miss penalty = 3,5% × 10 = 0,35
Miss rate2-way × Miss penalty = 3,2% × 10 = 0,32
Забавянето на достъпа до кеша за данни на асоциативен кеш с двупосочен набор следователно е

0,32/0,35 или 91% от директно картографирания кеш, докато намаляването на закъснението за достъп
при допускане на попадение под един пропуск е 9%, което прави двата избора приблизително еднакви .
Истинската трудност при оценката на производителността на неблокиращите кешове е, че пропускът

в кеша не спира непременно процесора. В този случай е трудно да се прецени въздействието на всеки
един пропуск и следователно да се изчисли средното време за достъп до паметта. Ефективното наказание
за пропуски не е сумата от пропуските, а времето без припокриване, през което процесорът е спрял.
Ползата от неблокиращите кешове е сложна, тъй като зависи от наказанието за пропуск, когато има
множество пропуски, референтния модел на паметта и колко инструкции процесорът може да изпълни
с пропуск.
Като цяло процесорите, които не са в ред, са в състояние да скрият голяма част от пропуските
наказание за пропуск на L1 кеш за данни, който попада в L2 кеша, но не може да
скриване на значителна част от пропуск на кеш памет от по-ниско ниво. Вземането на решение за това
колко неуредени пропуска да се подкрепят зависи от различни фактори:
Времевата и пространствена локализация в потока пропуски, която определя

дали пропуск може да инициира нов достъп до кеш памет от по-ниско ниво или до памет
Честотната лента на отговарящата памет или кеш
За да позволите повече неизяснени пропуски на най-ниското ниво на кеша (където

времето за пропуск е най-дългото) изисква поддръжка на поне толкова много пропуски на a
по-високо ниво, тъй като пропускът трябва да започне в кеша на най-високо ниво
Закъснението на системата с памет
Следващият опростен пример показва ключовата идея.
Пример Да приемем, че времето за достъп до основната памет е 36 ns и системата с памет може да a

поддържана скорост на трансфер от 16 GB/sec. Ако размерът на блока е 64 байта, какъв е
максимален брой неуредени пропуски, които трябва да поддържаме, ако приемем, че ние
може да поддържа пиковата честотна лента, дадена на потока от заявки и този достъп
никога не влизайте в конфликт. Ако вероятността препратка да се сблъска с една от предишните
четири е 50% и приемаме, че достъпът трябва да изчака до по-ранния достъп
завършва, преценете броя на максималните неизпълнени препратки. За простота игнорирайте времето

между пропуските.
Отговор В първия случай, ако приемем, че можем да поддържаме пиковата честотна лента, системата с памет може
да поддържа (16 × 10)9 /64 = 250 милиона препратки в секунда. От
всяка референция отнема 36 ns, можем да поддържаме 250 × 106 × 36 × 10 9 = 9 референции. Ако
вероятността за сблъсък е по-голяма от 0, тогава имаме нужда от повече неизпълнени референции, тъй
като не можем да започнем работа по тези референции; на
системата с памет се нуждае от повече независими препратки не по-малко! За да сравним това, можем
просто да приемем, че половината препратки към паметта не е необходимо да бъдат
издаден на паметта. Това означава, че трябва да поддържаме два пъти повече неуредени препоръки,
или 18.
В проучването на Li, Chen, Brockman и Jouppi те установиха, че намаляването на CPI

за целочислените програми беше около 7% за едно попадение под пропуск и около 12,7%
за 64. За програмите с плаваща запетая намаленията бяха 12,7% за едно попадение
под пропуск и 17,8% за 64. Тези намаления проследяват доста точно намаленията
в латентността на достъпа до кеша за данни, показана на фигура 2.5.
Пета оптимизация: Multibanked Caches to

Увеличете честотната лента на кеша
Вместо да третираме кеша като единичен монолитен блок, можем да го разделим на

независими банки, които могат да поддържат едновременен достъп. Банките първоначално са били
Блокиране Банка 0 Блокиране Банка 1 Блокирайте Банка 2 Блокирайте Банка 3
на адрес 0 4 8 12 на адрес 1 5 9 13 адрес 2 6 10 14 адрес 3 7 11 15
Фигура 2.6 Четиристранно подредени кеш банки, използващи блоково адресиране. Ако
приемем 64 байта на блок, всеки от тези адреси ще бъде умножен по 64, за да се получи
байтово адресиране.
използвани за подобряване на производителността на основната памет и сега се използват в

съвременните DRAM чипове, както и с кешове. Arm Cortex-A8 поддържа от една до четири банки
в своя L2 кеш; Intel Core i7 има четири банки в L1 (за поддържане на до 2 достъпа до паметта на
такт), а L2 има осем банки.
Ясно е, че банкирането работи най-добре, когато достъпите естествено се разпространяват
между банките, така че картографирането на адресите към банките влияе върху поведението
на системата с памет. Едно просто картографиране, което работи добре, е последователното
разпръскване на адресите на блока между банките, наречено последователно разплитане.
Например, ако има четири банки, банка 0 има всички блокове, чийто адрес по модул 4 е 0,
банка 1 има всички блокове, чийто адрес по модул 4 е 1 и т.н. Фигура 2.6 показва това
преплитане. Множеството банки също са начин за намаляване на консумацията на енергия
както в кеш паметта, така и в DRAM.
Шеста оптимизация: Първа критична дума и

Ранно рестартиране за намаляване на наказанието за пропуск
Тази техника се основава на наблюдението, че процесорът обикновено се нуждае само от една

дума от блока наведнъж. Тази стратегия е нетърпение: Не чакайте пълният блок да бъде
зареден, преди да изпратите исканата дума и да рестартирате процесора. Ето две конкретни
стратегии:
Първа критична дума —Първо поискайте пропуснатата дума от паметта и я изпратете на

процесора веднага щом пристигне; оставете процесора да продължи изпълнението, докато
попълва останалите думи в блока.
Ранно рестартиране—Извличане на думите в нормален ред, но веднага щом поисканата

дума от блока пристигне, я изпратете до процесора и оставете процесора да продължи
изпълнението.
Като цяло, тези техники са от полза само за проекти с големи кеш блокове, тъй като ползата
е малка, освен ако блоковете не са големи. Имайте предвид, че кешовете обикновено
продължават да задоволяват достъпите до други блокове, докато останалата част от блока се запълва.
Уви, като се има предвид пространственото местоположение, има голям шанс следващата
препратка да е към останалата част от блока. Точно както при неблокиращите кешове,
наказанието за пропуск не е лесно за изчисляване. Когато има втора заявка в критичната дума
първа, ефективното наказание за пропуск е времето без припокриване от препратката до
пристига второ парче. Ползите от първата критична дума и ранното рестартиране зависят
върху размера на блока и вероятността за друг достъп до частта от
блок, който все още не е извлечен.
Седма оптимизация: Обединяване на буфер за запис към
Намаляване на наказанието за пропуск
Кешовете за запис разчитат на буфери за запис, тъй като всички магазини трябва да бъдат изпратени до следващия
по-ниско ниво на йерархията. Дори кешовете за обратно записване използват прост буфер, когато a
блокът е заменен. Ако буферът за запис е празен, данните и пълният адрес се записват в буфера и записът
е завършен от гледна точка на процесора; процесорът продължава да работи, докато буферът за запис се
подготвя да запише думата
памет. Ако буферът съдържа други модифицирани блокове, адресите могат да бъдат проверени
за да видите дали адресът на новите данни съвпада с адреса на валиден буфер за запис
влизане. Ако е така, новите данни се комбинират с този запис. Напишете обединяване е името на
тази оптимизация. Intel Core i7, наред с много други, използва сливане при запис.
Ако буферът е пълен и няма съвпадение на адреса, кешът (и процесорът)
трябва да изчака, докато буферът има празен запис. Тази оптимизация използва паметта по-ефективно,
тъй като записите на много думи обикновено са по-бързи от записите, извършвани една дума наведнъж.
Skadron и Clark [1997] установяват, че дори a
сливането на буфер за запис с четири входа генерира спирания, които водят до 5% до 10% загуба на
производителност.
Оптимизацията също така намалява спиранията поради това, че буферът за запис е пълен.
Фигура 2.7 показва буфер за запис със и без обединяване на запис. Да приемем, че имахме
четири записа в буфера за запис и всеки запис може да съдържа четири 64-битови думи.
Без тази оптимизация четири магазина към последователни адреси биха запълнили буфера с една дума на
запис, въпреки че тези четири думи, когато се слеят, пасват точно
в рамките на един запис в буфера за запис.
Обърнете внимание, че регистрите на входно/изходното устройство често се преобразуват във физическото
адресно пространство. Тези входно/изходни адреси не могат да позволят сливане на запис, защото са разделени
I/O регистрите може да не действат като масив от думи в паметта. Например те
може да изисква един адрес и дума с данни за I/O регистър, вместо да използва много думи
пише с помощта на един адрес. Тези странични ефекти обикновено се прилагат от
маркиране на страниците като изискващи несливащ се запис от кешовете.
Осма оптимизация: Оптимизации на компилатора към

Намалете процента на пропускане
Досега нашите техники изискваха промяна на хардуера. Тази следваща техника намалява процента на
пропуски без промени в хардуера.
Това магическо намаление идва от оптимизиран софтуер – хардуер
любимото решение на дизайнера! Нарастващата разлика в производителността между процесорите
и основната памет е вдъхновила авторите на компилатори да изследват внимателно йерархията на паметта
за да видите дали оптимизациите на времето за компилиране могат да подобрят производителността. Още веднъж, изследвания
Напиши адрес V V V V
100 1 Мем [100] 0 0 0
108 1 Мем [108] 0 0 0
116 1 Мем [116] 0 0 0
124 1 Мем [124] 0 0 0
Напиши адрес V V V V
100 1 Мем [100] 1 Мем [108] 1 Мем [116] 1 Мем [124]
0 0 0 0
0 0 0 0
0 0 0 0
Фигура 2.7 За да илюстрира сливането на запис, буферът за запис отгоре не го

използва, докато буферът за запис отдолу го използва. Четирите записа се обединяват
в един запис в буфера със сливане на запис; без него буферът е пълен, въпреки че
три четвърти от всеки запис се губят. Буферът има четири записа и всеки запис
съдържа четири 64-битови думи. Адресът за всеки запис е отляво, с валиден бит (V),
показващ дали следващите 8 байта в този запис са заети. (Без обединяване на писане,
думите вдясно в горната част на фигурата ще се използват само за инструкции, които
са написали няколко думи едновременно.)
се разделя между подобрения в пропуските на инструкции и подобрения в пропуските на

данни. Представените по-долу оптимизации се намират в много съвременни компилатори.
Loop Interchange
Някои програми имат вложени цикли, които осъществяват достъп до данни в паметта в
непоследователен ред. Просто размяната на вложеността на циклите може да направи кода
достъп до данните в реда, в който са съхранени. Ако приемем, че масивите не се побират в
кеша, тази техника намалява пропуските чрез подобряване на пространствената локалност;
пренареждането увеличава максимално използването на данни в кеш блок, преди те да
бъдат изхвърлени. Например, ако x е двуизмерен масив с размер [5000,100], разпределен
така, че x[i,j] и x[i,j+1] да са съседни (ред, наречен основен ред, тъй като масивът е положен
по редове), тогава двете части от код по-долу показват как достъпите могат да бъдат оптимизирани:
/* Преди */ за (j
= 0; j < 100; j = j+1) за (i = 0; i < 5000; i = i+1)
x[i][j] = 2 * x[i ][j];
/* След */ за (i
= 0; i < 5000; i = i+1)
за (j = 0; j < 100; j = j+1) x[i][j] = 2 * x[i][j];
Оригиналният код ще прескочи през паметта в крачки от 100 думи, докато

преработената версия има достъп до всички думи в един кеш блок, преди да премине
към следващия блок. Тази оптимизация подобрява производителността на кеша, без
да засяга броя на изпълнените инструкции.
Блокиране
Тази оптимизация подобрява локалността във времето, за да намали пропуските.

Отново имаме работа с множество масиви, като някои масиви са достъпни от редове,
а други от колони. Съхраняването на масивите ред по ред (основен ред на ред) или
колона по колона (основен ред на колони ) не решава проблема, тъй като и редовете,
и колоните се използват във всяка итерация на цикъла. Такива ортогонални достъпи
означават, че трансформации като обмен на контури все още оставят много място за
подобрение.
Вместо да работят с цели редове или колони от масив, блокираните алгоритми
работят с подматрици или блокове. Целта е да се увеличи максимално достъпът до
данните, заредени в кеша, преди данните да бъдат заменени. Примерът на код по-
долу, който изпълнява матрично умножение, помага за мотивиране на оптимизацията:
/* Преди */ за (i
= 0; i < N; i = i+1) за (j = 0; j < N; j = j+1)
{r = 0; за (k = 0; k < N; k = k + 1) r = r +
y[i][k]*z[k]
[j]; x[i][j] = r; };
Двата вътрешни цикъла четат всички N-по-N елемента от z, четат същите N елемента
в ред от y многократно и записват един ред от N елемента от x. Фигура 2.8 дава
моментна снимка на достъпите до трите масива. Тъмният нюанс показва скорошен
достъп, светлият нюанс показва по-стар достъп, а бялото означава, че все още не е
достъпен.
Броят пропуски на капацитета ясно зависи от N и размера на кеша.
Ако може да побере и трите матрици N-by-N, тогава всичко е наред, при условие че
няма конфликти в кеша. Ако кешът може да побере една N-на-N матрица и един ред
от N, тогава поне i-тият ред от y и масивът z могат да останат в кеша. По-малко от това
и пропуски могат да възникнат както за x, така и за z. В най-лошия случай ще има 2N3
+ N2 думи от паметта, достъпни за N3 операции.
й
к й
х г z
0 2345 1 0 2345 1 0 2345 1
0 0 0
1 1 1
2 2 2
аз аз к
3 3 3
4 4 4
5 5 5
Фигура 2.8 Моментна снимка на трите масива x, y и z, когато N = 6 и i = 1. Възрастта на достъпите до елементите на масива е
обозначена със сянка: бяло означава, че все още не е докоснато, светло означава по-стари достъпи и тъмно означава по-нов
достъп. В сравнение с Фигура 2.9, елементите на y и z се четат многократно, за да се изчислят нови елементи на x.
Променливите i, j и k са показани покрай редовете или колоните, използвани за достъп до масивите.
За да се гарантира, че елементите, до които се осъществява достъп, могат да се поберат в кеша,

оригиналният код се променя, за да изчислява върху подматрица с размер B по B. Два вътрешни
цикъла сега изчисляват на стъпки с размер B, а не с пълната дължина на x и z. B се нарича блокиращ
фактор. (Да приемем, че x е инициализирано на нула.)
/* След */ за (jj =
0; jj < N; jj = jj+B) за (kk = 0; kk < N; kk = kk+B) за (i =
0; i < N; i = i +1) за (j = jj; j < min(jj+B,N); j = j+1) {r =
0; за (k = kk; k < min(kk+B,N); k = k + 1) r = r +
y[i][k]*z[k][j]; x[i][j] = x[i][j] + r; };
Фигура 2.9 илюстрира достъпите до трите масива чрез блокиране. Разглеждайки само пропуските
на капацитета, общият брой на достъпните думи в паметта е 2N3 /B + N2 .
Това общо е подобрение с около фактор B. Следователно блокирането използва комбинация от
пространствена и времева локалност, тъй като y се възползва от пространствената локалност, а z се
възползва от времевата локалност.
Въпреки че се стремим да намалим пропуските в кеша, блокирането може да се използва и за
подпомагане на разпределението на регистрите. Като вземем малък размер на блокиране, така че
блокът да може да се съхранява в регистри, можем да минимизираме броя на зарежданията и съхраняванията в
програма.
Както ще видим в Раздел 4.8 на Глава 4, блокирането на кеша е абсолютно необходимо, за да се
получи добра производителност от базирани на кеш процесори, работещи с приложения, използващи
матрици като първична структура от данни.
й
к й
х г z
0 2345 1 0 2345 1 0 2345 1
0 0 0
1 1 1
2 2 2
аз аз к
3 3 3
4 4 4
5 5 5
Фигура 2.9 Възрастта на достъпите до масивите x, y и z, когато B = 3. Обърнете внимание, че за разлика от Фигура 2.8 се осъществява
достъп до по-малък брой елементи.
Девета оптимизация: Хардуерно предварително извличане на инструкции и данни за
намаляване на наказанието за пропуски или процента на пропуски
Неблокиращите кешове ефективно намаляват наказанието за пропуски чрез припокриване на

изпълнението с достъп до паметта. Друг подход е предварително извличане на елементи,
преди процесорът да ги поиска. Както инструкциите, така и данните могат да бъдат предварително
изтеглени или директно в кеш паметта, или във външен буфер, който може да бъде по-бързо
достъпен от основната памет.
Предварителното извличане на инструкции често се извършва в хардуер извън кеша.
Обикновено процесорът извлича два блока при пропуск: заявения блок и следващия
последователен блок. Заявеният блок се поставя в кеша на инструкциите, когато се върне, а
предварително избраният блок се поставя в буфера на потока от инструкции. Ако исканият блок
присъства в буфера на потока от инструкции, първоначалната заявка за кеш се отменя, блокът
се чете от буфера на потока и се издава следващата заявка за предварително извличане.
Подобен подход може да се приложи за достъп до данни [Jouppi 1990]. Palacharla и Kessler
[1994] разглеждат набор от научни програми и разглеждат множество буфери на потока, които
могат да обработват инструкции или данни. Те открили, че осем буфера за поток могат да уловят
50% до 70% от всички пропуски от процесор с два 64 KB четирипосочни набора асоциативни
кеша, единият за инструкции, а другият за данни.
Intel Core i7 поддържа хардуерно предварително извличане както в L1, така и в L2, като най-
често срещаният случай на предварително извличане е достъп до следващия ред. Някои по-
ранни процесори на Intel използваха по-агресивно хардуерно предварително извличане, но
това доведе до намалена производителност за някои приложения, карайки някои сложни
потребители да изключат възможността.
Фигура 2.10 показва цялостното подобрение на производителността за подгрупа от програми
SPEC2000, когато хардуерното предварително извличане е включено. Обърнете внимание, че
тази фигура включва само 2 от 12 цели програми, докато включва по-голямата част от SPEC
програмите с плаваща запетая.
2.20
2.00 1,97
1,80
1.60
аП
р
отееннаяввяартбсоддео н
п
1.49
1.45
1.40
1.40
1.32
1.29
1.26
1.20 1.21
1.20 1.16 1.18
1,00
празнина
mcf fam3d wupwise галгел facerec плувам приложение Лукас mgrid изравнявам се
SPECint2000 SPECfp2000
Фигура 2.10 Ускоряване поради хардуерно предварително извличане на Intel Pentium 4 с включено хардуерно предварително
извличане за 2 от 12 SPECint2000 бенчмарка и 9 от 14 SPECfp2000 бенчмарка. Показани са само програмите, които имат най-голяма
полза от предварителното извличане; предварителното извличане ускорява липсващите 15 SPEC бенчмарка с по-малко от 15% [Singhal 2004].
Предварителното извличане разчита на използване на честотната лента на паметта, която иначе би била неизползвана,
но ако пречи на пропуските на търсенето, всъщност може да намали производителността.
Помощта от компилаторите може да намали безполезното предварително извличане. Когато предварителното извличане
работи добре, въздействието му върху мощността е незначително. Когато не се използват предварително извлечени данни
или полезните данни са изместени, предварителното извличане ще има много отрицателно въздействие върху мощността.
Десета оптимизация: Контролирано от компилатора предварително извличане на
Намалете наказанието за пропуски или процента на пропуски
Алтернатива на хардуерното предварително извличане е компилаторът да вмъкне инструкции за предварително извличане,
за да поиска данни, преди процесорът да има нужда от тях. Има два варианта на предварително извличане:
Предварителното извличане на регистър ще зареди стойността в регистър.
Предварителното извличане на кеша зарежда данни само в кеша, а не в регистъра.
Всяко от тях може да бъде или без грешка ; това означава, че адресът причинява или не изключение за грешки на
виртуалния адрес и нарушения на защитата. Използвайки тази терминология, нормална инструкция за зареждане може да се
счита за „инструкция за предварително извличане на повреден регистър“. Предварителните извличания без грешки просто
се превръщат в no-ops, ако обикновено водят до изключение, което е, което искаме.

Най-ефективното предварително извличане е „семантично невидимо“ за програмата: то не променя

съдържанието на регистрите и паметта и не може да причини грешки във виртуалната памет. Повечето
процесори днес предлагат предварително извличане на кеша без грешки.
Този раздел предполага предварително извличане на кеш без грешка, наричано още необвързващо предварително
извличане.
Предварителното извличане има смисъл само ако процесорът може да продължи, докато извлича
предварително данните; това означава, че кешовете не спират, а продължават да доставят инструкции
и данни, докато чакат предварително изтеглените данни да се върнат. Както бихте очаквали, кешът на
данни за такива компютри обикновено не блокира.
Подобно на хардуерно контролираното предварително извличане, целта е да се припокрие
изпълнението с предварителното извличане на данни. Циклите са важните цели, тъй като те се поддават
на предварително извличане на оптимизации. Ако наказанието за пропуск е малко, компилаторът просто
разгръща цикъла веднъж или два пъти и планира предварителното извличане с изпълнението. Ако
наказанието за пропуск е голямо, то използва софтуерна конвейерна обработка (вижте Приложение H)
или разгъва много пъти, за да извлече предварително данни за бъдеща итерация.
Издаването на инструкции за предварително извличане обаче води до допълнителни разходи за инструкции,
така че компилаторите трябва да се погрижат да гарантират, че тези допълнителни разходи не надвишават
ползите. Като се концентрират върху препратки, които е вероятно да бъдат пропуски в кеша, програмите могат
да избегнат ненужните предварителни извличания, като същевременно подобряват значително средното време
за достъп до паметта.
Пример За кода по-долу определете кои достъпи е вероятно да причинят пропуски в кеша на данни. След това вмъкнете
инструкции за предварително извличане, за да намалите пропуските. Накрая изчислете броя на
изпълнените инструкции за предварително извличане и пропуските, избегнати чрез предварително извличане.
Да приемем, че имаме 8 KB директно картографиран кеш за данни с 16-байтови блокове и това е кеш за
обратно записване, който разпределя записа. Елементите на a и b са с дължина 8 байта, тъй като са
масиви с плаваща запетая с двойна точност. Има 3 реда и 100 колони за a и 101 реда и 3 колони за b.
Нека също така приемем, че те не са в кеша в началото на програмата.
за (i = 0; i < 3; i = i+1) за (j = 0; j < 100; j = j+1)
a[i][j] = b[j][0] * b[j+1][0];
Отговор Компилаторът първо ще определи кои достъпи е вероятно да причинят пропуски в кеша; в противен случай
ще губим време за издаване на инструкции за предварително извличане на данни, които биха били
попадения. Елементите на a са записани в реда, в който са съхранени в паметта, така че a ще се
възползва от пространствената локалност: четните стойности на j ще пропуснат, а нечетните стойности
ще се появят. Тъй като a има 3 реда и 100 колони, неговите достъпи ще доведат до 3 × (100/2), или 150
пропуска.
Масивът b не се възползва от пространствената локалност, тъй като достъпите не са в реда, в който

се съхранява. Масивът b се възползва два пъти от времевата локалност: едни и същи елементи са
достъпни за всяка итерация на i и всяка итерация на j използва същата стойност на b като последната
итерация. Пренебрегвайки потенциални конфликтни пропуски, пропуските, дължащи се на b, ще бъдат

за b[j+1][0] достъпи, когато i = 0, а също и първото
достъп до b[j][0], когато j = 0. Тъй като j преминава от 0 до 99, когато i = 0, достъпът до b води до 100
+ 1 или 101 пропуска.
Така този цикъл ще пропусне кеша за данни приблизително 150 пъти за плюс 101 пъти за b,
или 251 пропуска.
За да опростим нашата оптимизация, няма да се тревожим за предварителното извличане на
първите достъпи на цикъла. Те може вече да са в кеша или ще платим наказанието за пропуск на
първите няколко елемента от a или b. Нито ще се тревожим за потискане на предварителното
извличане в края на цикъла, което се опитва да извлече предварително отвъд края на a (a[i][100] . . .
a[i][106]) и края на b (b[ 101][0] . . . b[107][0]). Ако това бяха предварително извличане с грешки, не
бихме могли да приемем този лукс. Да приемем, че наказанието за пропуск е толкова голямо, че
трябва да започнем предварително извличане на поне, да кажем, седем итерации предварително.
(Казано алтернативно, приемаме, че предварителното извличане няма полза до осмата итерация.)
Подчертаваме промените в кода по-горе, необходими за добавяне на предварително извличане.
за (j = 0; j < 100; j = j+1) { предварително

извличане (b[j+7][0]); /* b(j,0)
за 7 итерации по-късно */ prefetch(a[0][j+7]); /* a(0,j) за
7 итерации по-късно */ a[0][j]
= b[j][0] * b[j+1][0];}; for (i = 1; i < 3; i = i+1) for (j = 0; j <
100; j = j+1) { prefetch(a[i][j+7]); /* a(i,j) за +7
итерации */ a[i][j] = b[j][0] * b[j+1][0];}
Този преработен код предварително извлича a[i][7] до a[i][99] и b[7][0] до b[100][0], намалявайки броя
на пропуските без предварително извличане до
7 пропуска за елементи b[0][0], b[1][0], . . . , b[6][0] в първия цикъл

4 пропуска ([7⁄2]) за елементи a[0][0], a[0][1], . . . , a[0][6] в първия цикъл
(пространствената локализация намалява пропуските до 1 на 16-байтов кеш блок)
4 пропуска ([7⁄2]) за елементи a[1][0], a[1] [1], . . . , a[1][6] във втория

цикъл
4 пропуска ([7⁄2]) за елементи a[2][0], a[2][1], . . . , a[2][6] във втория

цикъл
или общо 19 неочаквани пропуска. Цената за избягване на 232 пропуска в кеша е изпълнението на
400 инструкции за предварително извличане, вероятно добър компромис.
Пример Изчислете спестеното време в горния пример. Игнорирайте пропуските в кеша на инструкциите и приемете,
че няма конфликт или пропуски в капацитета в кеша за данни. Да приемем, че предварителното
извличане може да се припокрива едно с друго и по този начин с пропуски в кеша
прехвърляне при максимална честотна лента на паметта. Ето времената на ключовите цикли,
игнориращи пропуските в кеша: Оригиналният цикъл отнема 7 тактови цикъла на итерация, първият
цикъл с предварително извличане отнема 9 тактови цикъла на итерация, а вторият цикъл с
предварително извличане отнема 8 тактови цикъла на итерация (включително режийните разходи на външния за ц
За пропуск са необходими 100 тактови цикъла.
Отговор Оригиналният двойно вложен цикъл изпълнява умножението 3 × 100 или 300 пъти.
Тъй като цикълът отнема 7 тактови цикъла на итерация, общата сума е 300 × 7 или 2100 тактови цикъла
плюс пропуски в кеша. Пропуските в кеша добавят 251 × 100 или 25 100 тактови цикъла, което дава общо
27 200 тактови цикъла. Първият цикъл за предварително извличане се повтаря 100 пъти; при 9 тактови
цикъла на итерация общото е 900 тактови цикъла плюс пропуски в кеша. Сега добавете 11 × 100 или
1100 тактови цикъла за пропуски в кеша, което дава общо 2000. Вторият цикъл се изпълнява 2 × 100 или
200 пъти, а при 8 тактови цикъла на итерация са необходими 1600 тактови цикъла плюс 8 × 100 или 800
тактови цикъла за пропуски в кеша. Това дава общо 2400 тактови цикъла. От предишния пример знаем,
че този код изпълнява 400 инструкции за предварително извличане по време на 2000 + 2400 или 4400
тактови цикъла, за да изпълни тези два цикъла. Ако приемем, че предварителното извличане е напълно
припокрито с останалата част от изпълнението, тогава кодът за предварително извличане е 27
200/4400, или 6,2 пъти по-бърз.
Въпреки че оптимизациите на масиви са лесни за разбиране, съвременните програми са по-

склонни да използват указатели. Luk и Mowry [1999] демонстрираха, че базираното на компилатор
предварително извличане понякога може да бъде разширено и до указатели. От 10 програми с
рекурсивни структури от данни, предварителното извличане на всички указатели при посещение на
възел подобрява производителността с 4% до 31% в половината от програмите.
От друга страна, останалите програми все още бяха в рамките на 2% от първоначалното си представяне.
Проблемът е както дали предварителното извличане е на данни, които вече са в кеша, така и дали се
случва достатъчно рано, за да пристигнат данните до момента, в който са необходими.
Много процесори поддържат инструкции за предварително извличане на кеша, а процесорите от

висок клас (като Intel Core i7) често също извършват някакъв вид автоматизирано предварително
извличане в хардуера.
Обобщение на оптимизацията на кеша
Техниките за подобряване на времето за попадение, честотната лента, наказанието за пропуски и

честотата на пропуски като цяло влияят върху другите компоненти на уравнението за средния достъп
до паметта, както и върху сложността на йерархията на паметта. Фигура 2.11 обобщава тези техники и
оценява въздействието върху сложността, като + означава, че техниката подобрява фактора, – което
означава, че вреди на този фактор, и празно означава, че няма влияние. Като цяло никоя техника не
помага на повече от една категория.
Хит Широчина Мис Мис Хардуерни разходи/

Техника време на лентата дузпа процент Консумация на енергия
сложност Коментирайте
+ – + 0
Малки и прости кешове Тривиално; широко използван
Кешове за предсказване на пътя + + 1 Използва се в Pentium 4
– + 1
Конвейерен достъп до кеша Широко използван
Неблокиращи кешове + + 3 Широко използван
Банкирани кешове + + 1 Използва се в L2 както на i7, така и на
Cortex-A8
Първа критична дума + 2 Широко използван
и ранно рестартиране
Обединяване на буфер за запис + 1 Широко използван с писане
Техники на компилатор за + 0 Софтуерът е предизвикателство,

намаляване на пропуските в кеша но много компилатори се
справят с общи изчисления
на линейната алгебра
Хардуерно предварително + + 2 инстр., Повечето предоставят инструкции

извличане на инструкции и данни 3 данни за предварително извличане; модерните
процесори от висок клас също
автоматично извличат предварително

в хардуера.
Контролирано от компилатора + + 3 Нуждае се от неблокиращ кеш;

предварително извличане възможни режийни инструкции; в
много процесори
Фигура 2.11 Обобщение на 10 разширени оптимизации на кеша, показващи въздействието върху производителността на кеша, консумацията на
енергия и сложността. Въпреки че като цяло техниката помага само на един фактор, предварителното извличане може да намали пропуските, ако
направено достатъчно рано; ако не, може да намали наказанието за пропуск. + означава, че техниката подобрява фактора, – означава го
вреди на този фактор, а празното означава, че няма влияние. Мярката за сложност е субективна, като 0 е най-лесният и
3 е предизвикателство.
2.3 Технология на паметта и оптимизации

… единственото развитие, което изправи компютрите на крака, беше изобретението
на надеждна форма на памет, а именно основната памет. … Цената му беше разумна,

беше надежден и тъй като беше надежден, можеше след време да бъде направен голям.
[стр. 209]
Морис Уилкс
Мемоарите на компютърния пионер (1985)
Основната памет е следващото ниво надолу в йерархията. Основната памет удовлетворява

изисква кешове и служи като I/O интерфейс, тъй като е местоназначението на входа
както и източника за изход. Мерките за производителност на основната памет наблягат както
на латентността, така и на честотната лента. Традиционно латентността на основната памет (която
засяга наказанието за пропуск на кеша) е основната грижа на кеша, докато честотната лента на
основната памет е основната грижа на мултипроцесорите и I/O.
Въпреки че кешовете се възползват от паметта с ниска латентност, обикновено е по-лесно да
се подобри честотната лента на паметта с нови организации, отколкото да се намали латентността.
Популярността на многостепенните кешове и техните по-големи размери на блокове правят
честотната лента на основната памет важна и за кешовете. Всъщност дизайнерите на кеша
увеличават размера на блока, за да се възползват от високата честотна лента на паметта.
Предишните раздели описват какво може да се направи с организацията на кеша, за да се
намали тази разлика в производителността на процесора и DRAM, но простото увеличаване на
кешовете или добавянето на повече нива на кеш паметта не може да премахне разликата.
Необходими са и иновации в основната памет.
В миналото иновацията беше как да се организират множеството DRAM чипове, съставляващи
основната памет, като например множество банки памет. По-висока честотна лента е достъпна при
използване на банки с памет, чрез разширяване на паметта и нейната шина или чрез и двете. По
ирония на съдбата, тъй като капацитетът на чип с памет се увеличава, има по-малко чипове в една
и съща по размер система с памет, което намалява възможностите за по-широки системи с памет
със същия капацитет.
За да позволят на системите с памет да се справят с изискванията за честотна лента на
съвременните процесори, иновациите в паметта започнаха да се случват вътре в самите DRAM
чипове. Този раздел описва технологията вътре в чиповете памет и тези иновативни вътрешни
организации. Преди да опишем технологиите и опциите, нека прегледаме показателите за
ефективност.
С въвеждането на памети за пакетен трансфер, които сега се използват широко както във Flash,
така и в DRAM, латентността на паметта се цитира с помощта на две мерки – време за достъп и
време на цикъл. Времето за достъп е времето между заявката за четене и пристигането на желаната
дума, а времето за цикъл е минималното време между несвързаните заявки към паметта.
На практика всички компютри от 1975 г. насам са използвали DRAM за основна памет и SRAM
за кеш, с едно до три нива, интегрирани в процесорния чип с CPU. В PMDs технологията на паметта
често балансира мощност и скорост, като системите от по-висок клас използват бърза технология
за памет с висока честотна лента.
Технология SRAM
Първата буква на SRAM означава статичен. Динамичният характер на веригите в DRAM изисква
данните да бъдат записани обратно, след като бъдат прочетени - оттук и разликата между времето
за достъп и времето на цикъла, както и необходимостта от опресняване. SRAM не се нуждаят от
опресняване, така че времето за достъп е много близо до времето на цикъла. SRAM обикновено
използват шест транзистора на бит, за да предотвратят нарушаване на информацията при четене.
SRAM се нуждае само от минимална мощност, за да поддържа заряда в режим на готовност.
В по-ранни времена повечето настолни и сървърни системи са използвали SRAM чипове за

своите първични, вторични или третични кешове; днес и трите нива на кеш паметта са интегрирани
в процесорния чип. В момента най-големият кеш от трето ниво в чипа е 12 MB, докато системата с
памет за такъв процесор вероятно ще има от 4 до
16 GB DRAM. Времената за достъп за големи кешове от трето ниво в чипа обикновено са два
до четири пъти по-големи от тези за кеш от второ ниво, което все пак е три до пет пъти по-
бързо от достъпа до DRAM памет.
DRAM технология
Тъй като капацитетът на ранните DRAM памети нарастваше, цената на пакет с всички
необходими адресни линии беше проблем. Решението беше да се мултиплексират адресните
линии, като по този начин се намали наполовина броят на адресните пинове. Фигура 2.12
показва основната организация на DRAM. Половината от адреса се изпраща първи по време на
светкавицата за достъп до ред (RAS). Другата половина от адреса, изпратена по време на
светкавицата за достъп до колона (CAS), го следва. Тези имена идват от вътрешната организация
на чипа, тъй като паметта е организирана като правоъгълна матрица, адресирана от редове и колони.
Допълнително изискване на DRAM произтича от свойството, обозначено с първата буква,
D, за динамичен. За да опаковат повече битове на чип, DRAM използват само един транзистор
за съхраняване на малко. Четенето на този бит унищожава информацията, така че тя трябва да
бъде възстановена. Това е една от причините, поради които времето за цикъл на DRAM
традиционно е по-дълго от времето за достъп; напоследък DRAM въведоха множество банки,
които позволяват частта от цикъла за пренаписване да бъде скрита. В допълнение, за да се
предотврати загуба на информация, когато битът не се чете или записва, битът трябва
периодично да се „опреснява“. За щастие, всички битове в един ред могат да бъдат опреснени
едновременно само чрез четене на този ред. Следователно всяка DRAM в системата с памет
трябва да има достъп до всеки ред в рамките на определен времеви прозорец, като например
8 ms. Контролерите на паметта включват хардуер за периодично опресняване на DRAM.
Това изискване означава, че системата с памет понякога е недостъпна, защото изпраща
сигнал, който казва на всеки чип да се опресни. Времето за опресняване обикновено е пълен
достъп до паметта (RAS и CAS) за всеки ред на DRAM.
Тъй като матрицата на паметта в DRAM концептуално е квадратна, броят на стъпките
банка
Колона
Rd/Wr
действайте
Пред
Редете
Фигура 2.12 Вътрешна организация на DRAM. Съвременните DRAM са организирани в банки,

обикновено четири за DDR3. Всяка банка се състои от поредица от редове. Изпращането на
команда PRE (предварително зареждане) отваря или затваря банка. Адресът на ред се изпраща
с акт (активиране), което кара реда да се прехвърли в буфер. Когато редът е в буфера, той може
да бъде прехвърлен чрез последователни адреси на колони, независимо от ширината на
DRAM (обикновено 4, 8 или 16 бита в DDR3) или чрез указване на блоково прехвърляне и начален адрес.
Всяка команда, както и блоковите трансфери, се синхронизират с часовник.
при опресняване обикновено е корен квадратен от капацитета на DRAM. DRAM дизайнери

опитайте се да запазите времето, прекарано в освежаване, до по-малко от 5% от общото време.
Досега сме представяли основната памет така, сякаш работи като швейцарски влак,
последователна доставка на стоките точно по график. Опресняване опровергава
тази аналогия, тъй като някои достъпи отнемат много повече време от други. Така освежете
е друга причина за променливостта на латентността на паметта и следователно наказанието за пропуск на кеша.
Amdahl предложи като основно правило, че капацитетът на паметта трябва да нараства линейно
със скоростта на процесора, за да се поддържа балансирана система, така че процесор от 1000 MIPS
трябва да има 1000 MB памет. Дизайнерите на процесори разчитат на DRAM за
задоволява това търсене. В миналото те очакваха четирикратно подобрение на капацитета на всеки три
години, или 55% на година. За съжаление изпълнението на
DRAM паметта расте с много по-бавна скорост. Фигура 2.13 показва изпълнение
подобрение във времето за достъп до ред, което е свързано със закъснението, от около 5% на
година. CAS или времето за пренос на данни, което е свързано с честотната лента, нараства с
повече от два пъти този процент.
Въпреки че говорихме за отделни чипове, DRAM се продават обикновено на малки платки, наречени
двойни вградени модули памет (DIMM).
DIMM модулите обикновено съдържат от 4 до 16 DRAM и обикновено са организирани така
Ширина 8 байта (+ ECC) за настолни и сървърни системи.
Строб за достъп до редове (RAS)
Най-бавно Най-бързият Строб за достъп до колона (CAS)/ Цикъл

Година на производство Размер на чипа тип DRAM DRAM (ns) DRAM (ns) време за трансфер на данни (ns) време (ns)
1980 г 64K битова DRAM 180 150 75 250
1983 г 256K битова DRAM 150 120 50 220
1986 г 1M bit DRAM 120 100 25 190
1989 г 4M bit DRAM 100 80 20 165
1992 г 16M bit DRAM 80 60 15 120
1996 г 64M bit SDRAM 70 50 12 110
1998 г 128M bit SDRAM 70 50 10 100
2000 г 256M бит DDR1 65 45 7 90
2002 г 512M бит DDR1 60 40 5 80
2004 г 1G бит DDR2 55 35 5 70
2006 г 2G бит DDR2 50 30 2.5 60
2010 г 4G бит DDR3 36 28 1 37
2012 г 8G бит DDR3 30 24 0,5 31
Фигура 2.13 Времената на бързи и бавни DRAM варират с всяко поколение. (Времето на цикъла е определено на страница 97.)
Подобряването на производителността на времето за достъп до ред е около 5% на година. Подобрението с фактор 2 в достъпа до колони в
1986 г. придружава преминаването от NMOS DRAM към CMOS DRAM. Въвеждането на различни пакетни трансфери
режими в средата на 1990-те и SDRAM в края на 1990-те значително усложниха изчисляването на времето за достъп
за блокове от данни; обсъждаме това по-късно в този раздел, когато говорим за време за достъп и мощност на SDRAM. DDR4
дизайните трябва да бъдат представени в средата до края на 2012 г. Обсъждаме тези различни форми на DRAM в следващите няколко страници.
В допълнение към опаковката на DIMM и новите интерфейси за подобряване на времето за

трансфер на данни, обсъдени в следващите подраздели, най-голямата промяна в DRAM е забавянето на
растежа на капацитета. DRAM се подчиняват на закона на Мур в продължение на 20 години, извеждайки
нов чип с четири пъти по-голям капацитет на всеки три години. Поради предизвикателствата при
производството на еднобитова DRAM, новите чипове удвояват капацитета само на всеки две години от
1998 г. насам. През 2006 г. темпото се забави още повече, като през четирите години от 2006 до 2010 г.
капацитетът се удвоява само.
Подобряване на производителността на паметта в DRAM чип
Тъй като законът на Мур продължава да доставя повече транзистори и тъй като празнината между
процесор и памет увеличава натиска върху производителността на паметта, идеите от предишния
раздел са си проправили път вътре в DRAM чипа. Като цяло иновациите са довели до по-голяма честотна
лента, понякога с цената на по-голямо забавяне. Този подраздел представя техники, които се възползват
от естеството на DRAM.
Както бе споменато по-рано, достъпът до DRAM се разделя на достъп до редове и достъп до колони.
DRAM трябва да буферира ред от битове вътре в DRAM за достъп до колоната и този ред обикновено е
квадратен корен от размера на DRAM - например 2 Kb за 4 Mb DRAM. С нарастването на DRAM бяха

добавени допълнителна структура и няколко възможности за увеличаване на честотната лента.
Първо, DRAM добавя времеви сигнали, които позволяват повтарящи се достъпи до буфера на реда
без друго време за достъп до ред. Такъв буфер идва естествено, тъй като всеки масив ще буферира 1024
до 4096 бита за всеки достъп. Първоначално трябваше да се изпращат отделни адреси на колони за
всяко прехвърляне със закъснение след всеки нов набор от адреси на колони.
Първоначално DRAM имаха асинхронен интерфейс към контролера на паметта, така че всяко
прехвърляне включваше допълнителни разходи за синхронизиране с контролера. Втората основна
промяна беше да се добави часовников сигнал към интерфейса на DRAM, така че повтарящите се
трансфери да не носят това натоварване. Синхронна DRAM (SDRAM) е името на тази оптимизация.
SDRAM обикновено също имат програмируем регистър за задържане на заявения брой байтове и
следователно могат да изпращат много байтове за няколко цикъла на заявка. Обикновено 8 или повече
16-битови трансфера могат да се осъществят без изпращане на нови адреси чрез поставяне на DRAM в
пакетен режим; този режим, който поддържа прехвърляне на критична дума първа, е единственият
начин, по който могат да бъдат постигнати пиковите честотни ленти, показани на Фигура 2.14 .
Трето, за да се преодолее проблемът с получаването на широк поток от битове от паметта, без да

се налага системата с памет да се прави твърде голяма с увеличаването на плътността на системата с
памет, DRAMS бяха направени по-широки. Първоначално те предлагаха четирибитов режим на
прехвърляне; през 2010 г. DDR2 и DDR3 DRAM имаха до 16-битови шини.
Четвъртата основна иновация на DRAM за увеличаване на честотната лента е прехвърлянето на
данни както по нарастващия, така и по спадащия фронт на тактовия сигнал на DRAM, като по този
начин се удвоява пиковата скорост на данни. Тази оптимизация се нарича двойна скорост на данни (DDR).
За да осигурят някои от предимствата на преплитането, както и да подпомогнат управлението на
мощността, SDRAM също така въведоха банки, разбивайки единична SDRAM на 2 до 8 блока (в
настоящите DDR3 DRAM), които могат да работят независимо. (Вече сме виждали банки, използвани във
вътрешни кешове, и те често се използват в големи
Стандартен Тактова честота (MHz) M трансфера за секунда DRAM име MB/sec /DIMM DIMM име
DDR 133 266 DDR266 2128 PC2100
DDR 150 300 DDR300 2400 PC2400
DDR 200 400 DDR400 3200 PC3200
DDR2 266 533 DDR2-533 4264 PC4300
DDR2 333 667 DDR2-667 5336 PC5300
DDR2 400 800 DDR2-800 6400 PC6400
DDR3 533 1066 DDR3-1066 8528 PC8500
DDR3 666 1333 DDR3-1333 10 664 PC10700
DDR3 800 1600 DDR3-1600 12 800 PC12800
DDR4 1066–1600 2133–3200 DDR4-3200 17 056–25 600 PC25600
Фигура 2.14 Тактови честоти, честотна лента и имена на DDR DRAM и DIMM през 2010 г. Обърнете внимание на числената
връзка между колоните. Третата колона е два пъти по-голяма от втората, а четвъртата използва числото от третата колона в
името на DRAM чипа. Петата колона е осем пъти третата колона и е заоблена версия на това
номер се използва в името на DIMM. Въпреки че не са показани на тази фигура, DDR също определят латентност в тактови цикли
като четири числа, които са определени от стандарта DDR. Например DDR3-2000 CL 9 има закъснения от 9-9-9-28.
Какво означава това? С часовник от 1 ns (тактовият цикъл е половината от скоростта на трансфер), това показва 9 ns за адрес от
ред към колона (RAS време), 9 ns за достъп до данни на колона (CAS време) и минимално време за четене от 28 ns. Затваряне на
редът отнема 9 ns за предварително зареждане, но се случва само когато четенията от този ред са завършени. В пакетен режим, прехвърляния
се появяват на всеки часовник на двата края, когато първите RAS и CAS времена са изтекли. Освен това предварителната такса е
не е необходимо, докато не бъде прочетен целият ред. DDR4 ще бъде произведен през 2012 г. и се очаква да достигне тактова честота от 1600
MHz през 2014 г., когато се очаква DDR5 да поеме. Упражненията изследват допълнително тези подробности.
основни памети.) Създаването на множество банки вътре в DRAM ефективно добавя

друг сегмент към адреса, който сега се състои от банков номер, ред
адрес и адрес на колона. Когато се изпрати адрес, който обозначава нов
банка, тази банка трябва да бъде отворена, което води до допълнително забавяне. Управлението
на банки и буфери на редове се обработва изцяло от модерни интерфейси за управление на
паметта, така че когато последващ достъп посочи същия ред за отворена банка,
достъпът може да се случи бързо, като се изпрати само адресът на колоната.
Когато DDR SDRAM са опаковани като DIMM, те са объркващо етикетирани
от пиковата честотна лента на DIMM . Следователно името DIMM PC2100 идва от 133
MHz × 2 × 8 байта или 2100 MB/сек. Поддържайки объркването, самите чипове са етикетирани с
броя на битовете в секунда, а не с тактовата си честота,
така че 133 MHz DDR чип се нарича DDR266. Фигура 2.14 показва връзките между тактовата
честота, трансферите в секунда на чип, името на чипа, честотната лента на DIMM и името на
DIMM.
DDR вече е поредица от стандарти. DDR2 намалява мощността чрез отпадане на
напрежение от 2,5 волта до 1,8 волта и предлага по-високи тактови честоти: 266 MHz,
333 MHz и 400 MHz. DDR3 пада напрежението до 1,5 волта и има максимум
тактова честота 800 MHz. DDR4, планиран за производство през 2014 г., отпада
напрежение от 1 до 1,2 волта и има максимална очаквана тактова честота от 1600 MHz.
DDR5 ще последва около 2014 или 2015 г. (Както обсъждаме в следващия раздел,
GDDR5 е графична RAM и е базирана на DDR3 DRAM.)
RAM памети за графични данни
GDRAM или GSDRAM (графични или графични синхронни DRAM) са специален клас DRAM, базиран
на дизайн на SDRAM, но пригоден за справяне с по-високите изисквания за честотна лента на
графичните процесори. GDDR5 е базиран на DDR3 с по-ранни GDDR, базирани на DDR2. Тъй като
графичните процесори (GPU; вижте Глава 4) изискват по-голяма честотна лента за DRAM чип,
отколкото CPU, GDDR имат няколко важни разлики: 1. GDDR имат по-широки интерфейси: 32-бита
срещу 4, 8 или 16 в настоящите дизайни.
2. GDDR имат по-висока максимална тактова честота на щифтовете за данни. За да се позволи по-
висока скорост на трансфер, без да възникват проблеми със сигнализирането, GDRAMs
обикновено се свързват директно към GPU и се прикрепят чрез запояване към платката, за
разлика от DRAM, които обикновено са подредени в разширяем масив от DIMM.
Като цяло, тези характеристики позволяват на GDDR да работят с два до пет пъти по-голяма
честотна лента на DRAM спрямо DDR3 DRAM, което е значително предимство при поддръжката
на GPU. Поради по-ниската локализация на заявките за памет в GPU, burst режимът обикновено
е по-малко полезен за GPU, но поддържането на отворени множество банки памет и управлението
на тяхното използване подобрява ефективната честотна лента.
Намаляване на консумацията на енергия в SDRAM
Консумацията на енергия в чиповете с динамична памет се състои както от динамична мощност,

използвана при четене или запис, така и от статична мощност или мощност в режим на готовност;
и двете зависят от работното напрежение. В най-модерните DDR3 SDRAM памети работното
напрежение е спаднало до 1,35 до 1,5 волта, което значително намалява мощността в сравнение
с DDR2 SDRAM. Добавянето на банки също намали мощността, тъй като само редът в една банка
се чете и зарежда предварително.
В допълнение към тези промени, всички скорошни SDRAM поддържат режим на изключване,
който се въвежда, като се каже на DRAM да игнорира часовника. Режимът на изключване
деактивира SDRAM, с изключение на вътрешното автоматично опресняване (без което влизането
в режим на изключване за по-дълго от времето за опресняване ще доведе до загуба на
съдържанието на паметта). Фигура 2.15 показва консумацията на енергия за три ситуации в 2 Gb
DDR3 SDRAM. Точното забавяне, необходимо за връщане от режим на ниска мощност, зависи от
SDRAM, но типичното време от автоматично опресняване в режим на ниска мощност е 200
тактови цикъла; може да е необходимо допълнително време за нулиране на регистъра на
режима преди първата команда.
Флаш памет
Флаш паметта е вид EEPROM (електронно изтриваема програмируема памет само за четене),
която обикновено е само за четене, но може да бъде изтрита. Другото ключово свойство на флаш
паметта е, че тя държи съдържанието си без никакво захранване.
600
500
400
Четете, пишете, прекратете
300 захранването
оm
тсонщW М
в
200 Активирайте захранването
Фоново захранване
100
0
ниско Типична Напълно
режим на употреба активен
захранване
Фигура 2.15 Консумация на енергия за DDR3 SDRAM, работеща при три условия: режим на
ниска мощност (изключване), типичен системен режим (DRAM е активна 30% от времето за
четене и 15% за запис) и напълно активен режим, където DRAM непрекъснато чете или
записва, когато не е в предварително зареждане. Четенето и записването предполагат
поредици от 8 трансфера. Тези данни са базирани на Micron 1.5V 2Gb DDR3-1066.
Flash се използва като резервно хранилище в PMD по същия начин, по който

функционира диск в лаптоп или сървър. Освен това, тъй като повечето PMD имат
ограничено количество DRAM, Flash може също да действа като ниво на йерархията на
паметта, в много по-голяма степен, отколкото може да се наложи да го прави в настолен
компютър или сървър с основна памет, която може да е 10 до 100 пъти по-големи.
Flash използва много различна архитектура и има различни свойства от стандартната
DRAM. Най-важните разлики са 1. Флаш паметта трябва
да бъде изтрита (оттук и името Flash за процеса на изтриване на „flash“), преди да бъде
презаписана, и се изтрива на блокове (във Flash с висока плътност, наречена NAND
Flash, което е се използва в повечето компютърни приложения), а не отделни байтове
или думи. Това означава, че когато данните трябва да бъдат записани във Flash, трябва
да се сглоби цял блок, или като нови данни, или чрез сливане на данните, които трябва
да бъдат записани, и останалото съдържание на блока.
2. Флаш паметта е статична (т.е. запазва съдържанието си дори когато не е включено

захранване) и черпи значително по-малко енергия, когато не чете или пише (от по-
малко от половината в режим на готовност до нула, когато е напълно неактивна).
3. Флаш паметта има ограничен брой цикли на запис за всеки блок, обикновено най-малко
100 000. Чрез осигуряване на равномерно разпределение на записаните блокове в
паметта, системата може да увеличи максимално живота на система с флаш памет.
4. Flash с висока плътност е по-евтин от SDRAM, но по-скъп от дисковете: приблизително $2/

GB за Flash, $20 до $40/GB за SDRAM и $0,09/GB за магнитни дискове.
5. Flash е много по-бавен от SDRAM, но много по-бърз от диска. Например, прехвърлянето

на 256 байта от типична флаш памет с висока плътност отнема около 6,5 μs (използвайки
прехвърляне в пакетен режим, подобно на това, но по-бавно от това, използвано в
SDRAM). Сравним трансфер от DDR SDRAM отнема около една четвърт по-дълго време,
а за диск около 1000 пъти повече. За пише, на
разликата е значително по-голяма, като SDRAM е поне 10 и дори 100 пъти по-бърз от Flash в
зависимост от обстоятелствата.
Бързите подобрения във Flash с висока плътност през последното десетилетие направиха
технологията жизнеспособна част от йерархиите на паметта в мобилни устройства и като
заместители на твърди дискове. Тъй като скоростта на увеличаване на плътността на DRAM
продължава да намалява, Flash може да играе все по-голяма роля в бъдещите системи с памет,
действайки едновременно като заместител на твърдите дискове и като междинно хранилище
между DRAM и диска.
Подобряване на надеждността на системите с памет
Големите кеш памети и основните памети значително увеличават възможността за възникване

на грешки както по време на производствения процес, така и динамично, главно от космически
лъчи, удрящи клетка с памет. Тези динамични грешки, които са промени в съдържанието на
клетката, а не промяна в схемата, се наричат меки грешки. Всички DRAM, флаш памети и много
SRAM се произвеждат с резервни редове, така че малък брой производствени дефекти могат да
бъдат коригирани чрез програмиране на замяната на дефектен ред с резервен ред. В допълнение
към производствените грешки, които трябва да бъдат коригирани по време на конфигуриране, по
време на работа могат да възникнат сериозни грешки, които са постоянни промени в работата на
една или повече клетки с памет.
Динамичните грешки могат да бъдат открити чрез битове за четност и открити и коригирани
чрез използването на кодове за коригиране на грешки (ECC). Тъй като кешовете на инструкциите
са само за четене, паритетът е достатъчен. В по-големите кешове за данни и в основната памет,
ECC се използва, за да позволи грешките да бъдат откривани и коригирани. Паритетът изисква
само един бит зареждане, за да открие единична грешка в поредица от битове. Тъй като
многобитова грешка няма да бъде открита с паритет, броят на битовете, защитени от бит за
паритет, трябва да бъде ограничен. Един бит за четност на 8 бита данни е типично съотношение.
ECC може да открие две грешки и да коригира една грешка с цена от 8 бита режийни разходи за 64 бита данни.
В много големи системи възможността за множество грешки, както и пълна повреда на
единичен чип памет става значителна. Chipkill беше въведена от IBM за решаване на този проблем
и много много големи системи, като IBM и SUN сървъри и Google Clusters, използват тази
технология. (Intel нарича тяхната версия SDDC.) Подобно по естество на подхода RAID, използван
за дискове, Chipkill разпределя данните и ECC информацията, така че пълната повреда на
единичен чип с памет може да бъде обработена чрез поддържане на реконструкцията на
липсващи данни от останалите чипове памет. Използването на анализ от IBM и приемането на
сървър с 10 000 процесора с 4 GB на процесор дава следните нива на непоправими грешки за три
години работа:
Само паритет—около 90 000, или една невъзстановима (или неоткрита) повреда всеки
17 минути
Само ECC—около 3500 или около една неоткрита или непоправима повреда на всеки
7,5 часа
Chipkill—6, или около една неоткрита или непоправима повреда на всеки 2 месеца
Друг начин да разгледате това е да намерите максималния брой сървъри (всеки с 4 GB),
които могат да бъдат защитени, като същевременно се постигне същият процент грешки,
както е показано за Chipkill. За паритет, дори сървър само с един процесор ще има процент
непоправими грешки, по-висок от система, защитена от 10 000 сървъра Chipkill. За ECC
система със 17 сървъра би имала приблизително същия процент на отказ като система
Chipkill с 10 000 сървъра. Следователно Chipkill е изискване за 50 000 до 100 000 сървъра в
компютри от складов мащаб (вижте раздел 6.8 от глава 6).
2.4 Защита: Виртуална памет и виртуални машини

Виртуалната машина се приема като ефективен изолиран дубликат на реалната машина.
Ние обясняваме тези понятия чрез идеята за монитор на виртуална машина (VMM). . . .
VMM има три основни характеристики. Първо, VMM осигурява среда за програми, която по
същество е идентична с оригиналната машина; второ, програмите, изпълнявани в тази
среда, показват в най-лошия случай само незначителни намаления на скоростта; и
последно, VMM има пълен контрол върху системните ресурси.
Джералд Попек и Робърт Голдбърг

„Официални изисквания за виртуализируеми архитектури от трето поколение,“
Съобщения на ACM (юли 1974 г.)
Сигурността и поверителността са две от най-обезпокоителните предизвикателства пред

информационните технологии през 2011 г. Електронни кражби, често включващи списъци
с номера на кредитни карти, се обявяват редовно и се смята, че много други остават
незаявлени. Следователно както изследователите, така и практиците търсят нови начини
да направят изчислителните системи по-сигурни. Въпреки че защитата на информацията
не се ограничава до хардуера, според нас истинската сигурност и поверителност вероятно
ще включват иновации в компютърната архитектура, както и в системния софтуер.
Този раздел започва с преглед на поддръжката на архитектурата за защита на
процесите един от друг чрез виртуална памет. След това се описва добавената защита,
осигурена от виртуални машини, изискванията за архитектурата на виртуалните машини
и производителността на виртуалната машина. Както ще видим в глава 6, виртуалните
машини са основополагаща технология за облачни изчисления.
Защита чрез виртуална памет
Виртуалната памет, базирана на страници, включително буфер за превод, който кешира

записи в таблицата на страниците, е основният механизъм, който защитава процесите
един от друг. Раздели B.4 и B.5 в Приложение B разглеждат виртуалната памет, включително
подробно описание на защитата чрез сегментиране и страниране в 80x86. Този подраздел
действа като бърз преглед; вижте тези раздели, ако е твърде бързо.
Мултипрограмирането, при което няколко програми, работещи едновременно,
споделят един компютър, доведе до изисквания за защита и споделяне между програми и
към концепцията за процес. Метафорично, процесът е въздухът за дишане и жизненото пространство на

програмата - тоест работеща програма плюс всяко състояние, необходимо за продължаване на нейното
изпълнение. Във всеки момент трябва да е възможно превключването от един процес към друг. Този
обмен се нарича превключване на процес или превключване на контекст.
Операционната система и архитектурата обединяват усилията си, за да позволят на процесите да
споделят хардуера, но без да си пречат един на друг. За да направи това, архитектурата трябва да ограничи
достъпа на даден процес, когато изпълнява потребителски процес, но същевременно да позволи на
процеса на операционната система да има повече достъп. Като минимум архитектурата трябва да прави следното:
1. Осигурете поне два режима, като посочите дали изпълняваният процес е потребителски процес или
процес на операционна система. Последният процес понякога се нарича процес на ядрото или процес
на надзорник .
2. Осигурете част от състоянието на процесора, която потребителският процес може да използва, но не и

да записва. Това състояние включва бит за режим потребител/супервизор, бит за разрешаване/
дезактивиране на изключение и информация за защита на паметта. Потребителите са възпрепятствани
да пишат това състояние, тъй като операционната система не може да контролира потребителските
процеси, ако потребителите могат да си дадат привилегии на надзорник, да деактивират изключения
или да променят защитата на паметта.
3. Осигурете механизми, чрез които процесорът може да премине от потребителски режим в режим на
супервизьор и обратно. Първата посока обикновено се изпълнява чрез системно повикване,
реализирано като специална инструкция, която прехвърля контрола към специално място в
пространството на кода на надзорника. Компютърът се запазва от точката на системното повикване
и процесорът се поставя в режим на надзорник. Връщането към потребителски режим е като връщане
на подпрограма, която възстановява предишния потребителски/супервизор режим.
4. Осигурете механизми за ограничаване на достъпа до паметта, за да защитите състоянието на паметта на

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

ограничения за защита към всяка страница от виртуалната памет.
Страниците с фиксиран размер, обикновено с дължина 4 KB или 8 KB, се преобразуват от виртуалното
адресно пространство във физическо адресно пространство чрез таблица на страниците. Ограниченията
за защита са включени във всеки запис в таблицата на страниците. Ограниченията за защита могат да
определят дали потребителски процес може да чете тази страница, дали потребителски процес може да
пише на тази страница и дали кодът може да бъде изпълнен от тази страница. В допълнение, процесът не
може нито да чете, нито да пише страница, ако не е в таблицата на страниците. Тъй като само
операционната система може да актуализира таблицата на страниците, механизмът за страниране
осигурява пълна защита на достъпа.
Странираната виртуална памет означава, че всеки достъп до паметта логично отнема поне два пъти
повече време, с един достъп до паметта за получаване на физическия адрес и втори достъп за получаване
на данните. Тази цена би била твърде висока. Решението е да се разчита на принципа на местността; ако
достъпите имат локалност, тогава преводите на адресите за достъпите също трябва да имат локалност.
Като съхранява тези преводи на адреси в специален кеш, достъпът до паметта рядко изисква втори достъп
за преобразуване на адреса. Този специален кеш за транслация на адреси се нарича транслационен буфер
(TLB).
Записът в TLB е като запис в кеша, където етикетът съдържа части от виртуалния адрес, а частта с
данни съдържа физически адрес на страница, поле за защита, валиден бит и обикновено бит за
използване и бит за мръсен. Операционната система променя тези битове, като променя стойността в
таблицата на страниците и след това обезсилва съответния TLB запис. Когато записът се презареди от
таблицата на страниците, TLB получава точно копие на битовете.
Ако приемем, че компютърът вярно се подчинява на ограниченията за страниците и картографира

виртуални адреси към физически адреси, изглежда, че сме готови. Заглавията във вестниците показват
друго.
Причината да не сме готови е, че зависим от точността на операционната система, както и от
хардуера. Днешните операционни системи се състоят от десетки милиони редове код. Тъй като грешките
се измерват в брой на хиляда реда код, има хиляди грешки в производствените операционни системи.
Пропуските в операционната система са довели до уязвимости, които се използват рутинно.
Този проблем и възможността, че неналагането на защита може да бъде много по-скъпо, отколкото
в миналото, накара някои да търсят модел на защита с много по-малка кодова база от пълната
операционна система, като виртуални машини.
Защита чрез виртуални машини
Една идея, свързана с виртуалната памет, която е почти толкова стара, са виртуалните машини (VM). Те
са разработени за първи път в края на 60-те години и остават важна част от мейнфрейм компютрите
през годините. Макар и до голяма степен игнорирани в областта на еднопотребителските компютри през
80-те и 90-те години на миналия век, те напоследък придобиха популярност поради
Нарастващото значение на изолацията и сигурността в съвременните системи Провалите
в сигурността и надеждността на стандартните операционни системи Споделянето на един
компютър между много несвързани потребители, като например в

център за данни или облак
Драматичните увеличения на необработената скорост на процесорите, което прави претоварването

на виртуалните машини по-приемливо
Най-широката дефиниция на VM включва основно всички методи за емулация, които предоставят

стандартен софтуерен интерфейс, като Java VM. Интересуваме се от виртуални машини, които предоставят
цялостна среда на системно ниво на ниво двоична архитектура на набора от инструкции (ISA). Най-често
виртуалната машина поддържа същата ISA като основния хардуер; но също така е възможно да се
поддържа различен ISA и такива подходи често се използват при мигриране между ISA, така че да се
позволи използването на софтуер от напускащия ISA, докато може да бъде пренесен към новия ISA.
Нашият фокус тук ще бъде върху виртуални машини, където ISA, представен от виртуалната машина, и
основният хардуер съвпадат. Такива виртуални машини се наричат (операционни) системни виртуални
машини. IBM VM/370, VMware ESX Server и Xen са примери. Те представят илюзията, че потребителите на
VM имат цял компютър за себе си,
включително копие на операционната система. Един компютър работи с множество виртуални машини
и може да поддържа редица различни операционни системи (ОС). На конвенционална платформа една
ОС „притежава“ всички хардуерни ресурси, но с VM
множество ОС споделят хардуерните ресурси.
Софтуерът, който поддържа виртуални машини, се нарича монитор на виртуална машина (VMM)
или хипервизор; VMM е сърцето на технологията за виртуална машина. Основната хардуерна платформа
се нарича хост и нейните ресурси се споделят между
виртуални машини за гости . VMM определя как да картографирате виртуални ресурси към физически
ресурси: Физическият ресурс може да бъде споделен във времето, разделен или дори емулиран
в софтуера. VMM е много по-малък от традиционната ОС; изолиращата част на VMM е може би само 10
000 реда код.
Като цяло цената на виртуализацията на процесора зависи от натоварването.
Програмите, обвързани с процесор на потребителско ниво, като SPEC CPU2006, имат нула
режийни разходи за виртуализация, защото ОС рядко се извиква, така че всичко работи
нативни скорости. Обратно, I/O-интензивните работни натоварвания обикновено са също и OS-
интензивни и изпълняват много системни повиквания (които I/O изисква) и привилегировани
инструкции, които могат да доведат до високи разходи за виртуализация. Режийните разходи са
определен от броя инструкции, които трябва да бъдат емулирани от VMM
и колко бавно се емулират. Следователно, когато виртуалните машини за гости работят по същия начин
ISA като хост, както предполагаме тук, целта на архитектурата и VMM е
за изпълнение на почти всички инструкции директно на родния хардуер. От друга страна,
ако I/O-интензивното работно натоварване също е свързано с I/O, цената на виртуализацията на
процесора може да бъде напълно скрита от ниското използване на процесора, тъй като често се чака за
I/O.
Въпреки че интересът ни тук е към виртуалните машини за подобряване на защитата, виртуалните машини предоставят
две други предимства, които са търговски значими:
1. Софтуер за управление – виртуалните машини предоставят абстракция, която може да работи напълно
софтуерен стек, включително стари операционни системи като DOS. Типичен
разгръщането може да бъде някои виртуални машини, работещи с наследени операционни системи, много с текущата стабилна
версия на операционната система и няколко, които тестват следващата версия на операционната система.
2. Управление на хардуера – Една от причините за множество сървъри е всяко приложение да работи

със собствена съвместима версия на операционната система на
отделни компютри, тъй като това разделяне може да подобри надеждността. VM позволяват
тези отделни софтуерни стекове да работят независимо, но споделят хардуер,
като по този начин консолидира броя на сървърите. Друг пример е, че някои
VMM поддържат мигриране на работеща VM към друг компютър, или към
балансиране на натоварването или за евакуация от повреден хардуер.
Тези две причини са защо базираните в облак сървъри, като този на Amazon, разчитат на виртуални
машини.
Изисквания за монитор на виртуална машина
Какво трябва да прави VM монитор? Той представя софтуерен интерфейс към софтуера за гости, it
трябва да изолира състоянието на гостите един от друг и трябва да се защити от
софтуер за гости (включително операционни системи за гости). Качествените изисквания са
Софтуерът за гости трябва да се държи на VM точно така, както ако работи на
роден хардуер, с изключение на свързано с производителността поведение или ограничения на
фиксирани ресурси, споделени от множество виртуални машини.
Софтуерът за гости не трябва да може да променя разпределението на реалната система
ресурси директно.
За да "виртуализира" процесора, VMM трябва да контролира почти всичко -
достъп до привилегировано състояние, превод на адреси, I/O, изключения и прекъсвания—
въпреки че изпълняваната в момента виртуална машина за гости и операционна система временно се използват
тях.
Например, в случай на прекъсване на таймера, VMM ще спре работещата в момента виртуална машина за
гости, ще запази състоянието й, ще обработи прекъсването, ще определи кой гост
VM да стартира следващата и след това да зареди нейното състояние. Виртуалните машини за гости, които разчитат на прекъсване на таймера, са
снабден с виртуален таймер и емулирано прекъсване на таймера от VMM.
За да отговаря, VMM трябва да е на по-високо ниво на привилегия от госта
VM, която обикновено работи в потребителски режим; това също така гарантира, че изпълнението на
всяка привилегирована инструкция ще се обработва от VMM. Основните изисквания
на системните виртуални машини са почти идентични с тези за странирана виртуална памет, изброени по-горе:
Поне два режима на процесора, системен и потребителски.
Привилегирован поднабор от инструкции, който е достъпен само в системен режим,
което води до прихващане, ако се изпълни в потребителски режим. Всички системни ресурси трябва да бъдат
може да се контролира само чрез тези инструкции.
(Липса на) Поддръжка на архитектура на набор от инструкции за

Виртуални машини
Ако VM са планирани по време на проектирането на ISA, това е относително лесно и за двете
намаляване на броя на инструкциите, които трябва да бъдат изпълнени от VMM и как
отнема много време, за да им подражават. Архитектура, която позволява на VM да се изпълнява
директно върху хардуера печели титлата виртуализируема, а архитектурата на IBM 370 гордо носи този етикет.
Уви, тъй като виртуалните машини се разглеждат като десктоп и компютърно базиран сървър
приложения съвсем наскоро, повечето набори от инструкции бяха създадени без виртуализация в ума. Тези
виновници включват 80x86 и повечето RISC архитектури.
Тъй като VMM трябва да гарантира, че системата за гости взаимодейства само с виртуални ресурси,
конвенционалната ОС за гости работи като програма в потребителски режим върху
VMM. След това, ако операционна система за гости се опита да получи достъп или да промени информация, свързана с
към хардуерни ресурси чрез привилегирована инструкция - например четене или запис на указателя на
таблицата на страницата - той ще прихване към VMM. След това VMM може да въздейства
съответните промени в съответните реални ресурси.
Следователно, ако има инструкция, която се опитва да прочете или напише такава чувствителна информация
traps, когато се изпълнява в потребителски режим, VMM може да го прихване и да поддържа виртуален
версия на чувствителната информация, както очаква операционната система за гости.

При липса на такава подкрепа трябва да се вземат други мерки. VMM трябва да вземе специални
предпазни мерки, за да открие всички проблемни инструкции и да гарантира, че те се държат
правилно, когато се изпълняват от гост OS, като по този начин увеличава сложността на VMM и
намалява производителността при изпълнение на VM.
Раздели 2.5 и 2.7 дават конкретни примери за проблемни инструкции в архитектурата 80x86.
Влияние на виртуалните машини върху виртуалната памет и I/O
Друго предизвикателство е виртуализацията на виртуалната памет, тъй като всяка гост OS във всяка
VM управлява свой собствен набор от таблици на страници. За да направи тази работа, VMM разделя
понятията за реална и физическа памет (които често се третират като синоними) и прави реалната
памет отделно, междинно ниво между виртуалната памет и физическата памет. (Някои използват
термините виртуална памет, физическа памет и машинна памет , за да назоват едни и същи три
нива.) OS за гости картографира виртуалната памет към реалната памет чрез своите таблици на
страници, а таблиците на VMM страници картографират реалната памет на гостите към физическата
памет . Архитектурата на виртуалната памет се определя или чрез таблици на страници, както в IBM
VM/370 и 80x86, или чрез TLB структура, както в много RISC архитектури.
Вместо да плаща допълнително ниво на ненасочване при всеки достъп до паметта, VMM
поддържа таблица със сенчести страници , която се преобразува директно от виртуалното адресно
пространство на гост към физическото адресно пространство на хардуера. Чрез откриване на всички
модификации в таблицата на страниците на госта, VMM може да гарантира, че записите в таблицата
на страниците в сянка, използвани от хардуера за преводи, съответстват на тези на средата на OS на
госта, с изключение на правилните физически страници, заместени за реални страници в таблиците
за гости. Следователно VMM трябва да улавя всеки опит на гост OS да промени своята таблица на
страници или да получи достъп до указателя на таблицата на страниците. Това обикновено се прави
чрез защита от запис на таблиците на страниците за гости и прихващане на всеки достъп до указателя
на таблицата на страниците от ОС за гости. Както беше отбелязано по-горе, последното се случва
естествено, ако достъпът до указателя на таблицата на страницата е привилегирована операция.
Архитектурата на IBM 370 реши проблема с таблицата на страниците през 70-те години с
допълнително ниво на индиректност, което се управлява от VMM. Гост ОС запазва своите таблици на
страници както преди, така че страниците в сянка са ненужни. AMD предложи подобна схема за
тяхната ревизия Pacifica на 80x86.
За виртуализиране на TLB в много RISC компютри, VMM управлява истинския TLB и има копие на
съдържанието на TLB на всяка гост VM. За да направите това, всички инструкции, които имат достъп
до TLB, трябва да прихванат. TLB с етикети за идентификатор на процес могат да поддържат
комбинация от записи от различни VM и VMM, като по този начин се избягва изтриването на TLB на
VM комутатор. Междувременно във фонов режим VMM поддържа съпоставяне между виртуалните
идентификатори на процеси на виртуалните машини и истинските идентификатори на процеси.
Последната част от архитектурата за виртуализиране е I/O. Това е най-трудната част от

виртуализацията на системата поради нарастващия брой I/O устройства, свързани към компютъра, и
нарастващото разнообразие от типове I/O устройства.
Друга трудност е споделянето на реално устройство между множество виртуални машини, а друга
трудност идва от поддържането на безброй драйвери за устройства, които са необходими,
особено ако различни операционни системи за гости се поддържат на една и съща VM система. VM
илюзията може да се поддържа, като на всяка виртуална машина се предоставят общи версии на всеки тип I/O
драйвер на устройство и след това го оставя на VMM да обработва реални I/O.
Методът за съпоставяне на виртуално към физическо I/O устройство зависи от типа
на устройството. Например, физическите дискове обикновено се разделят от VMM на
създава виртуални дискове за виртуални машини за гости, а VMM поддържа картографирането на виртуални пътеки
и сектори към физическите. Мрежовите интерфейси често се споделят
между VM за много кратки отрязъци от време и работата на VMM е да следи
на съобщения за адресите на виртуалната мрежа, за да се гарантира, че виртуалните машини за гости получават
само съобщения, предназначени за тях.
Примерен VMM: Виртуалната машина Xen

В началото на разработването на виртуални машини станаха очевидни редица неефективности.
Например, операционна система за гости управлява своята виртуална към реална страница, но това картографиране
се игнорира от VMM, който извършва действителното картографиране към физическа
страници. С други думи, значително количество пропиляни усилия се изразходват само за
поддържайте операционната система за гости щастлива. За да намалят тази неефективност, разработчиците на VMM
реши, че може да си струва да позволи на ОС за гости да знае, че работи на VM. Например, операционна система за
гости може да приеме реална памет, голяма колкото
неговата виртуална памет, така че не се изисква управление на паметта от операционната система за гости.
Позволяването на малки модификации на операционната система за гости за опростяване на виртуализацията е
наричана паравиртуализация, а Xen VMM с отворен код е добър пример. Xen VMM, който се използва в центровете
за данни на уеб услугите на Amazon, предоставя на ОС за гости абстракция на виртуална машина, подобна на
физическата
хардуер, но изпуска много от проблемните части. Например за избягване
изчиствайки TLB, Xen се картографира в горните 64 MB на адресното пространство на
всяка VM. Тя позволява на операционната система за гости да разпределя страници, като просто проверява дали го прави
не нарушават ограниченията за защита. За да защити операционната система за гости от потребителските програми
във VM, Xen се възползва от четирите нива на защита, налични в
80х86. Xen VMM работи на най-високото ниво на привилегия (0), операционната система за гости
работи на следващото ниво (1), а приложенията работят на най-ниското ниво на привилегия
(3). Повечето операционни системи за 80x86 поддържат всичко на ниво на привилегия 0 или 3.
За да работи правилно подмножеството, Xen модифицира операционната система за гости, за да не използва
проблемни части от архитектурата. Например прехвърлянето на Linux към Xen
променя около 3000 реда или около 1% от специфичния за 80x86 код. Тези
промените обаче не засягат двоичните интерфейси на приложението на операционната система за гости.
За да опрости I/O предизвикателството на VM, Xen присвои привилегировани виртуални
машини към всяко хардуерно I/O устройство. Тези специални виртуални машини се наричат драйвер
домейни. (Xen нарича своите виртуални машини „домейни“.) Домейните на драйверите управляват физическото устройство
драйвери, въпреки че прекъсванията все още се обработват от VMM, преди да бъдат изпратени до
подходящ домейн на драйвер. Редовните виртуални машини, наречени домейни за гости, изпълняват прости
драйвери за виртуални устройства, които трябва да комуникират с драйверите на физически устройства в
домейни на драйвери през канал за достъп до физически I/O хардуер. Данните се изпращат
между домейни на гости и драйвери чрез пренасочване на страници.

2.5 Междусекторни въпроси: Дизайнът на

Йерархии на паметта
Този раздел описва три теми, обсъждани в други глави, които са фундаментални за йерархиите на
паметта.
Архитектура на защита и набор от инструкции
Защитата е съвместно усилие на архитектурата и операционните системи, но архитектите трябваше да

променят някои неудобни детайли на съществуващите архитектури на набори от инструкции, когато
виртуалната памет стана популярна. Например, за да поддържат виртуална памет в IBM 370, архитектите
трябваше да променят успешната архитектура на набора от инструкции IBM 360, която беше обявена
само преди 6 години. Подобни корекции се правят днес, за да се приспособят виртуални машини.
Например инструкцията 80x86 POPF зарежда регистрите на флаговете от върха на стека в паметта.
Един от флаговете е флагът за разрешаване на прекъсване (IE).
До последните промени за поддържане на виртуализация, изпълнението на инструкцията POPF в
потребителски режим, вместо да я прихване, просто промени всички флагове, с изключение на IE. В
системен режим той променя флага на IE. Тъй като ОС за гости работи в потребителски режим във
виртуална машина, това беше проблем, тъй като би очаквало да види променен IE.
Разширенията на архитектурата 80x86 за поддръжка на виртуализация елиминираха този проблем.
Исторически хардуерът на IBM мейнфрейм и VMM предприеха три стъпки за подобряване на

производителността на виртуалните машини:
1. Намалете разходите за виртуализация на процесора.
2. Намалете режийните разходи за прекъсване поради виртуализацията.
3. Намалете разходите за прекъсване, като насочвате прекъсванията към правилната VM без извикване
ing VMM.
IBM все още е златният стандарт на технологията за виртуални машини. Например мейнфреймът на IBM
работи с хиляди Linux VM през 2000 г., докато Xen управлява 25 VM през 2004 г. [Clark et al. 2004].
Последните версии на чипсетите на Intel и AMD са добавили специални инструкции за поддръжка на

устройства във VM, за маскиране на прекъсвания на по-ниски нива от всяка VM и за насочване на
прекъсванията към подходящата VM.
Кохерентност на кешираните данни
Данните могат да бъдат намерени в паметта и в кеша. Докато процесорът е единственият компонент,
който променя или чете данните и кешът стои между процесора и паметта, няма голяма опасност
процесорът да види старото или остаряло копие. Както ще видим, множество процесори и I/O устройства
увеличават възможността копията да бъдат непоследователни и да четат грешното копие.
Честотата на проблема с кохерентността на кеша е различна за мултипроцесорите от I/O.

Множеството копия на данни са рядко събитие за I/O - едно трябва да бъде
2.6 Обединяване на всичко: йерархии на паметта в ARM Cortex-A8 и Intel Core i7 113
избягвайте, когато е възможно - но програма, работеща на множество процесори, ще иска да

има копия на едни и същи данни в няколко кеша. Производителността на многопроцесорна
програма зависи от производителността на системата при споделяне на данни.
Въпросът за кохерентността на I/O кеша е следният: Къде се извършва I/O в компютъра –

между I/O устройството и кеша или между I/O устройството и основната памет? Ако входът
поставя данни в кеша, а изходът чете данни от кеша, както I/O, така и процесорът виждат едни
и същи данни. Трудността при този подход е, че пречи на процесора и може да доведе до
спиране на процесора за I/O. Въведеното може също да попречи на кеша, като измести част от
информацията с нови данни, които е малко вероятно да бъдат достъпни скоро.
Целта на I/O системата в компютър с кеш е да предотврати проблема със застояли данни,
като същевременно се намесва възможно най-малко. Поради това много системи предпочитат
I/O да става директно в основната памет, като основната памет действа като I/O буфер. Ако се
използва кеш за запис, тогава паметта ще има актуално копие на информацията и няма да има
проблем с остарели данни за извеждане. (Това предимство е причината използваните процесори
да записват.) Уви, записът обикновено се среща днес само в кешове за данни от първо ниво,
поддържани от L2 кеш, който използва обратен запис.
Въвеждането изисква допълнителна работа. Софтуерното решение е да гарантира, че в

кеша няма блокове от входния буфер. Страница, съдържаща буфера, може да бъде маркирана
като некешируема и операционната система винаги може да въвежда данни в такава страница.
Алтернативно, операционната система може да изчисти адресите на буфера от кеша, преди да
се извърши въвеждането. Хардуерно решение е да се проверяват I/O адресите при въвеждане,
за да се види дали са в кеша. Ако има съвпадение на I/O адреси в кеша, записите в кеша се
анулират, за да се избегнат остарели данни. Всички тези подходи могат да се използват и за
извеждане с кешове за обратно записване.
Кохерентността на кеша на процесора е критична тема в ерата на многоядрените процеси.
sors и ще го разгледаме подробно в глава 5.
2.6 Събирайки всичко заедно: Йерахии на паметта в

ARM Cortex-A8 и Intel Core i7
Този раздел разкрива йерархиите на паметта на ARM Cortex-A8 (наричан по-долу Cortex-A8) и
Intel Core i7 (наричан по-нататък i7) и показва производителността на техните компоненти на
набор от еднонишкови бенчмаркове. Първо изследваме Cortex-A8, защото има по-проста
система за памет; навлизаме в повече подробности за i7, проследявайки подробно препратка
към паметта. Този раздел предполага, че читателите са запознати с организацията на
двустепенна кеш йерархия, използваща виртуално индексирани кешове. Основите на такава
система с памет са обяснени подробно в Приложение B и читателите, които не са сигурни в
организацията на такава система, силно се съветват да прегледат примера на Opteron в
Приложение B. След като разберат организацията на Opteron, краткото обяснението на
системата Cortex-A8, която е подобна, ще бъде лесно за следване.
ARM Cortex-A8
Cortex-A8 е конфигурируемо ядро, което поддържа набора от инструкции ARMv7
архитектура. Доставя се като IP (интелектуална собственост) ядро. IP ядрата са
доминираща форма на доставка на технологии на вградените, PMD и свързаните с тях пазари; милиарди
ARM и MIPS процесори са създадени от тези IP
ядра. Имайте предвид, че IP ядрата са различни от ядрата в многоядрените Intel i7 или AMD Ath-lon.
Едно IP ядро (което само по себе си може да бъде многоядрено) е проектирано да бъде
вграден с друга логика (следователно е ядрото на чип), включително специфични за приложението
процесори (като енкодер или декодер за видео), I/O интерфейси,
и интерфейси на паметта и след това произведени, за да се получи процесор, оптимизиран за a
специално приложение. Например, ядрото Cortex-A8 IP се използва в Apple
iPad и смартфони от няколко производителя, включително Motorola и Sam-sung. Въпреки че ядрото на
процесора е почти идентично, получените чипове имат
много разлики.
Обикновено IP ядрата се предлагат в два варианта. Твърдите ядра са оптимизирани за конкретен
производител на полупроводници и са черни кутии с външни (но все още в чип)
интерфейси. Твърдите ядра обикновено позволяват параметризация само на логиката извън
ядрото, като размерите на L2 кеша, и IP ядрото не могат да бъдат модифицирани. Меките ядра са
обикновено се доставя във форма, която използва стандартна библиотека от логически елементи. Мек
ядрото може да се компилира за различни доставчици на полупроводници и може също така да се
модифицира, въпреки че обширните модификации са много трудни поради сложността на
съвременни IP ядра. Като цяло твърдите ядра осигуряват по-висока производителност и
по-малка площ на матрицата, докато меките ядра позволяват пренасочване към други доставчици и могат да бъдат
по-лесно модифицирани.
Cortex-A8 може да издава две инструкции на такт при тактова честота до
1GHz. Може да поддържа кеш йерархия на две нива, като първото ниво е двойка
от кешове (за I & D), всеки 16 KB или 32 KB, организиран като четирипосочен набор асоциативен
и използване на предсказване на пътя и случайно заместване. Целта е да има латентност за достъп с
един цикъл за кеш паметта, което позволява на Cortex-A8 да поддържа забавяне при зареждане за
използване от един цикъл, по-просто извличане на инструкции и по-ниско наказание за извличане на
правилната инструкция, когато клон пропуска причинява грешна инструкция
предварително избрани. Допълнителният кеш от второ ниво, когато е наличен, е асоциативен с осем
начина и може да бъде конфигуриран от 128 KB до 1 MB; тя е организирана в едно към
четири банки, за да позволят няколко прехвърляния от паметта да се извършват едновременно. Ан
външната шина от 64 до 128 бита обработва заявки за памет. Кешът от първо ниво е
виртуално индексиран и физически маркиран, а кешът от второ ниво е физически
индексирани и маркирани; и двете нива използват 64-байтов размер на блока. За D-кеша от 32
KB и размер на страницата от 4 KB, всяка физическа страница може да се съпостави с два различни кеша
адреси; подобни псевдоними се избягват чрез хардуерно откриване при пропуск, както в Раздел
Б.3 от Приложение Б.
Управлението на паметта се управлява от чифт TLB (I и D), всеки от които
са напълно асоциативни с 32 записа и променлив размер на страницата (4 KB, 16 KB, 64
KB, 1 MB и 16 MB); подмяната в TLB се извършва чрез кръгов алгоритъм. TLB пропуските се обработват
в хардуер, който влиза в структурата на таблицата на страниците
памет. Фигура 2.16 показва как 32-битовият виртуален адрес се използва за

индексиране на TLB и кешовете, като се приема, че 32 KB първичен кеш и 512 KB
вторичен кеш с размер на страницата 16 KB.
Производителност на йерархията на паметта Cortex-A8
Йерархията на паметта на Cortex-A8 беше симулирана с 32 KB първични кешове и 1

MB осемпосочен асоциативен L2 кеш, използвайки целочислените показатели на
Minnespec (вижте KleinOsowski и Lilja [2002]). Minnespec е набор от бенчмаркове,
състоящ се от бенчмаркове SPEC2000, но с различни входове, които намаляват
времето за работа с няколко порядъка. Въпреки че използването на по-малки входове
не променя микса от инструкции, то засяга
Виртуална добавка <32>
Номер на виртуална страница <18> Отместване на страница <14>
L1 кеш индекс <7> Блоково отместване <6>

TLB етикет <19> TLB данни <19>
Към процесора
L1 кеш етикет <19> L1 данни <64>
=?
Физически адрес <32>
Адрес за сравнение на L2 етикет <15> Индекс на L2 кеш <11> Отместване на блок <6>
=?
Към L1 кеш или CPU
Фигура 2.16 Виртуалният адрес, физическият адрес, индексите, таговете и блоковете с данни за ARM Cortex-A8 кешове за
данни и TLB за данни. Тъй като йерархиите на инструкциите и данните са симетрични, ние показваме само един. TLB
(инструкция или данни) е напълно асоциативен с 32 записа. Кешът L1 е четирипосочен асоциативен с 64-байтови блокове и
32 KB капацитет. Кешът L2 е асоциативен с осемпосочен набор с 64-байтови блокове и 1 MB капацитет. Тази фигура не показва
валидните битове и битовете за защита за кешовете и TLB, нито използването на битовете за предсказване на пътя, които
биха диктували прогнозираната банка на L1 кеша.
поведение на кеша. Например при mcf, целочисленият бенчмарк SPEC2000 с най-

интензивна памет, Minnespec има процент на пропуски за 32 KB кеш, който е само 65% от
процента на пропуски за пълната версия на SPEC. За 1 MB кеш разликата е коефициент 6!
При много други бенчмаркове съотношенията са подобни на тези при mcf, но абсолютните
проценти на пропуски са много по-малки. Поради тази причина не може да се сравняват
бенчмарковете на Minnispec с бенчмарковете SPEC2000. Вместо това, данните са полезни
за разглеждане на относителното въздействие на пропуските на L1 и L2 и върху общия
CPI, както правим в следващата глава.
Процентите на пропуски в кеша на инструкции за тези показатели (а също и за
пълните версии на SPEC2000, на които е базиран Minnispec) са много малки дори само за
L1: близо до нула за повечето и под 1% за всички тях. Този нисък процент вероятно е
резултат от изчислително интензивния характер на SPEC програмите и четирипосочния
асоциативен кеш, който елиминира повечето конфликтни пропуски.
Фигура 2.17 показва резултатите от кеша на данни, които имат значителни нива на
пропуски на L1 и L2. Наказанието за пропуск на L1 за 1 GHz Cortex-A8 е 11 тактови цикъла, докато
25%
Процент на пропускане на L1 данни
L2 глобална честота на пропускане на данни
20%
15%
уп
о
енактси ро
н кн
нр
а С
п
д
10%
5%
0%
gzip vpr gcc mcf коварен парсер eon perlbmk празнина вихър bzip2
Фигура 2.17 Степента на пропускане на данни за ARM с 32 KB L1 и глобалния процент на пропускане на

данни за 1 MB L2, използвайки целочислените показатели на Minnespec, са значително повлияни от
приложенията. Приложенията с по-голям обем на паметта обикновено имат по-висок процент пропуски
както в L1, така и в L2. Имайте предвид, че коефициентът L2 е глобалният коефициент на пропуски, който
отчита всички препратки, включително тези, които са улучили L1. Mcf е известен като разбивач на кеша.
4.5 Средна памет за L2 данни

Средна памет за L1 данни
3.5
2.5
кн
ааи
оте сауи
тна ам
н
рзпп кр
н
ое ааП
ъ
р н
п
д
кз
1.5
0,5
0
gzip vpr gcc mcf коварен парсер eon perlbmk празнина вихър bzip2
Фигура 2.18 Средното наказание за достъп до паметта за препратка към памет за данни, идваща от L1 и
L2, е показана за ARM процесора, когато се изпълнява Minnispec.
Въпреки че процентите на пропуски за L1 са значително по-високи, наказанието за пропуски на L2,
което е повече от пет пъти по-високо, означава, че пропуските на L2 могат да допринесат значително.
Наказанието за пропуск на L2 е 60 тактови цикъла, като се използва DDR SDRAM за основна памет.
Използвайки тези пропуски, Фигура 2.18 показва средното наказание за достъп до данни. В
следващата глава ще разгледаме влиянието на пропуските в кеша върху общия CPI.
Intel Core i7
i7 поддържа архитектурата на набора от инструкции x86-64, 64-битово разширение на
архитектурата 80x86. i7 е процесор за изпълнение извън ред, който включва четири ядра. В тази
глава се фокусираме върху дизайна на системата с памет и производителността от гледна точка
на едно ядро. Системната производителност на многопроцесорните дизайни, включително
многоядрения i7, е разгледана подробно в Глава 5.
Всяко ядро в i7 може да изпълни до четири 80x86 инструкции на тактов цикъл, използвайки
динамично планиран 16-етапен тръбопровод с множество издания, който описваме подробно в
глава 3. i7 може също така да поддържа до две едновременни нишки на процесор , използвайки
техника, наречена едновременна многопоточност,
описано в глава 4. През 2010 г. най-бързият i7 имаше тактова честота от 3,3 GHz, което
дава пикова скорост на изпълнение на инструкции от 13,2 милиарда инструкции в секунда, или
над 50 милиарда инструкции в секунда за четириядрения дизайн.
i7 може да поддържа до три канала на паметта, всеки от които се състои от отделен набор
от DIMM модули и всеки от които може да прехвърля паралелно. Използване на DDR3-1066
(DIMM PC8500), i7 има пикова честотна лента на паметта от малко над 25 GB/sec.
i7 използва 48-битови виртуални адреси и 36-битови физически адреси, което дава
максимална физическа памет от 36 GB. Управлението на паметта се обработва с TLB на две
нива (вижте Приложение B, Раздел B.4), обобщено на Фигура 2.19.
Фигура 2.20 обобщава тристепенната йерархия на кеша на i7. Първото ниво
кешовете са виртуално индексирани и физически маркирани (вижте Приложение B, Раздел B.3),
докато L2 и L3 кешовете са физически индексирани. Фигура 2.21 е обозначена с
Характеристика Инструкция TLB Данни DLB TLB от второ ниво
Размер 128 64 512
Асоциативност 4-посочен 4-посочен 4-посочен
Замяна Псевдо-LRU Псевдо-LRU Псевдо-LRU
Забавяне на достъпа 1 цикъл 1 цикъл 6 цикъла
Мис 7 цикъла 7 цикъла Стотици цикли за достъп до таблицата

със страници
Фигура 2.19 Характеристики на TLB структурата на i7, която има отделно първо ниво
инструкции и данни TLB, и двете подкрепени от съвместно второ ниво TLB. Първото ниво
TLB поддържат стандартния размер на страницата от 4 KB, както и ограничен брой записи
на големи страници от 2 до 4 MB; само 4 KB страници се поддържат в TLB от второ ниво.
Характеристика L1 L2 L3
Размер 32 KB I/32 KB D 256 KB 2 MB на ядро
Асоциативност 4-посочен I/8-посочен D 8-посочен 16-пътен
Забавяне на достъпа 4 цикъла, конвейерно 10 цикъла 35 цикъла
Схема за подмяна Псевдо-LRU псевдо- Псевдо-LRU, но с подреден

LRU алгоритъм за избор
Фигура 2.20 Характеристики на тристепенната йерархия на кеша в i7. И трите

кешовете използват обратно записване и размер на блока от 64 байта. Кешовете L1 и L2 са отделни
за всяко ядро, докато кешът L3 се споделя между ядрата на чипа и е общо 2
MB на ядро. И трите кеша са неблокиращи и позволяват множество незавършени записи.
Обединяващ буфер за запис се използва за L1 кеша, който съхранява данни в случай, че
линия не присъства в L1, когато е написана. (Тоест пропуск на запис L1 не причинява
линия, която трябва да бъде разпределена.) L3 включва L1 и L2; ние проучваме този имот по-нататък
подробности, когато обясняваме многопроцесорни кешове. Замяната е с вариант на псевдо-LRU; в случай
на L3 заместеният блок винаги е най-ниско номерираният начин, чийто
битът за достъп е изключен. Това не е съвсем случайно, но е лесно за изчисляване.
Номер на Инструкция Номер на виртуална

виртуална страница <36> Отместване на страница <12> процесор <128> Данни <64> страница с данни <36> Отместване на страница <12>
Данни в <64>
настолен компютър
2
1
<4> <1> <31> <24> <4> <1> <31> <24>
Прот V Етикет Физически адрес Прот V Етикет Физически адрес
аз
д
T T
Л 3 Л
б б
(128 PTE в 4 банки) 4
(64 PTE в 4 банки) <28>
4:1 мултиплексор 4:1 мултиплексор
<24> <128> <64>
<4> <1> <29> <24>

Прот V Физически адрес
L2 Етикет
<7> <7>
T
Л
б
4 (512 PTE =? в 4:1 мултиплексор
банки)
<7> <6> <6> <6>

Индекс Блок офсет Индекс Блок офсет
аз
V D 16 д V D
°С <1> <1> <23> Данни <128x4> °С <1> <1> Етикет <21> Данни <128×4>
А 5 А
°С 5 °С
з з
д д
6
=? =?
4:1 мултиплексор 4:1 мултиплексор
7
(512 блока в 8 банки)
(512 блока в 4 банки)
2:1 мултиплексор
<30>
V д
8 <21> Данни <512>
<9> Маркирайте <1> <1> <21>
L2
Етикет Индекс
°С
9
А
°С
з
д 10 8:1 мултиплексор
=?
(4K блокове в 8 банки)
DIMM
<64>
14
М М
V D А д Интерфейс на паметта
11 <17> 16
<13> <1> <1> Етикет <17> Данни <512> М
L3 аз
Етикет Индекс н О <64> <64>

°С Р
12 15
А Y DIMM DIMM
°С
з
д 13 16:1 мултиплексор
=?
(128K блокове в 16 банки)
Фигура 2.21 Йерархията на паметта на Intel i7 и стъпките както в инструкциите, така и в достъпа до данни. Показваме само четения за
данни. Записите са подобни, тъй като започват с четене (тъй като кешовете се записват обратно). Пропуските се обработват чрез
просто поставяне на данните в буфер за запис, тъй като L1 кешът не е разпределен за запис.
стъпки за достъп до йерархията на паметта. Първо компютърът се изпраща в кеша на инструкциите.

Индексът на кеша на инструкциите е
Индекс Размер на кеша 32K

2 = -------------------------------------------------- -------------------- = ==-------------- 128 27
Размер на блока Задаване на асоциативност × 64 4 ×
или 7 бита. Страничната рамка на адреса на инструкцията (36 = 48 – 12 бита) се изпраща към TLB на
инструкцията (стъпка 1). В същото време 7-битовият индекс (плюс допълнителни 2 бита от отместването
на блока за избор на подходящите 16 байта, количеството за извличане на инструкцията) от виртуалния
адрес се изпраща към кеша на инструкциите (стъпка 2).
Забележете, че за четирипосочния асоциативен кеш с инструкции са необходими 13 бита за адреса на
кеша: 7 бита за индексиране на кеша плюс 6 бита блоково отместване за 64-байтовия блок, но размерът
на страницата е 4 KB = 212 , което означава, че 1 бит от
индексът на кеша трябва да идва от виртуалния адрес. Това използване на 1 бит виртуален адрес
означава, че съответният блок може действително да бъде на две различни места в кеша, тъй като
съответният физически адрес може да има 0 или 1 на това място. За инструкциите това не представлява
проблем, тъй като дори ако една инструкция се появи в кеша на две различни места, двете версии трябва
да са еднакви. Ако такова дублиране или псевдоним на данни е разрешено, кешът трябва да се
проверява, когато картата на страницата се променя, което е рядко събитие.
Обърнете внимание, че едно много просто използване на оцветяване на страници (вижте Приложение
B, Раздел B.3) може да елиминира възможността за тези псевдоними. Ако виртуални страници с четен
адрес се съпоставят с физически страници с четен адрес (и същото за нечетните страници), тогава тези
псевдоними никога не могат да възникнат, тъй като битът от нисък ред във виртуалния и физическия
номер на страница ще бъде идентичен.
Осъществява се достъп до инструкцията TLB, за да се намери съвпадение между адреса и валиден
запис в таблицата на страниците (PTE) (стъпки 3 и 4). В допълнение към превода на адреса, TLB проверява
дали PTE изисква този достъп да доведе до изключение поради нарушение на достъпа.
Пропуснат TLB на инструкция първо отива към L2 TLB, който съдържа 512 PTE с размер на страницата
4 KB и е четирипосочен асоциативен набор. Необходими са два тактови цикъла, за да се зареди L1 TLB
от L2 TLB. Ако L2 TLB пропусне, се използва хардуерен алгоритъм за обхождане на таблицата на
страниците и актуализиране на TLB записа. В най-лошия случай страницата не е в паметта и
операционната система получава страницата от диска. Тъй като милиони инструкции могат да се
изпълнят по време на грешка на страницата, операционната система ще замени друг процес, ако някой
чака да се изпълни. В противен случай, ако няма TLB изключение, достъпът до кеша на инструкции
продължава.
Индексното поле на адреса се изпраща до четирите банки на кеша за инструкции (стъпка 5). Тагът
за кеша на инструкциите е 36 – 7 бита (индекс) – 6 бита (отместване на блок) или 23 бита. Четирите
етикета и валидните битове се сравняват с рамката на физическата страница от инструкцията TLB (стъпка
6). Тъй като i7 очаква 16 байта за всяко извличане на инструкция, се използват допълнителни 2 бита от 6-
битовото отместване на блока, за да се изберат подходящите 16 байта. Следователно, 7 + 2 или 9 бита
се използват за изпращане на 16 байта инструкции към процесора. L1 кеш паметта е конвейерна и
латентността на попадението е 4 тактови цикъла (стъпка 7). Пропускът отива в кеша от второ ниво.
Както бе споменато по-рано, кешът на инструкциите е виртуално адресиран и физически маркиран.

Тъй като кешовете от второ ниво са адресирани физически,
физическият адрес на страница от TLB се съставя с отместването на страницата, за да се направи

адрес за достъп до L2 кеша. Индексът L2 е
Индекс Размер на кеша 256K

2 = -------------------------------------------------- -------------------- = ==-------------- 512 29
така че 30-битовият блоков адрес (36-битов физически адрес – 6-битово блоково отместване) е
разделен на 21-битов етикет и 9-битов индекс (стъпка 8). Още веднъж, индексът и етикетът
се изпращат до всичките осем банки на унифицирания L2 кеш (стъпка 9), които се сравняват в
паралелен. Ако едно съвпада и е валидно (стъпка 10), той връща блока последователно
ред след първоначалната латентност от 10 цикъла при скорост от 8 байта на тактов цикъл.
Ако L2 кеша пропусне, има достъп до L3 кеша. За четириядрен i7, който
има 8 MB L3, размерът на индекса е
Индекс Размер на кеша 8M

2 = -------------------------------------------------- --------------------
----------------- 8192 213
= ==
13-битовият индекс (стъпка 11) се изпраща до всичките 16 банки на L3 (стъпка 12). Етикетът L3,
което е 36 (13 + 6) = 17 бита, се сравнява с физическия адрес от
TLB (стъпка 13). Ако възникне попадение, блокът се връща след първоначално забавяне при a
скорост от 16 байта на часовник и поставени както в L1, така и в L3. Ако L3 пропусне, се инициира достъп
до паметта.
Ако инструкцията не е намерена в L3 кеша, контролерът на паметта в чипа
трябва да вземе блока от основната памет. i7 има три 64-битови канала на паметта
който може да действа като един 192-битов канал, тъй като има само един контролер на паметта и
един и същ адрес се изпраща и на двата канала (стъпка 14). Широките трансфери се случват, когато
и двата канала имат идентични DIMM модули. Всеки канал поддържа до четири DDR
DIMM модули (стъпка 15). Когато данните се върнат, те се поставят в L3 и L1 (стъпка 16)
тъй като L3 е включен.
Общото забавяне на пропуска на инструкцията, което се обслужва от основната памет, е

приблизително 35 цикъла на процесора, за да се определи, че е възникнала грешка L3,
плюс латентността на DRAM за критичните инструкции. За еднобанков DDR1600
SDRAM и 3,3 GHz CPU, латентността на DRAM е около 35 ns или 100 такта
цикли до първите 16 байта, което води до общо наказание за пропуск от 135 тактови цикъла.
Контролерът на паметта запълва остатъка от 64-байтовия кеш блок със скорост от
16 байта на тактов цикъл на паметта, което отнема още 15 ns или 45 тактови цикъла.
Тъй като кешът от второ ниво е кеш за обратно записване, всяко пропускане може да доведе до
старият блок се записва обратно в паметта. i7 има обединяващ запис с 10 записа
буфер, който записва обратно мръсни редове в кеша, когато е следващото ниво в кеша
неизползван за четене. Буферът за запис се подслушва от всяко пропускане, за да се види дали линията на кеша
съществува в буфера; ако е така, пропускът се запълва от буфера. Подобен буфер е
използвани между L1 и L2 кеш паметта.
Ако тази първоначална инструкция е зареждане, адресът на данните се изпраща до кеша за данни и
данни TLB, действащи много като достъп до кеша на инструкции с една ключова разлика. Кешът за
данни от първо ниво е асоциативен с осем начина, което означава, че индексът
е 6 бита (срещу 7 за кеша на инструкциите) и адресът, използван за достъп до кеша
е същото като отместването на страницата. Следователно псевдонимите в кеша за данни не са проблем.

Да предположим, че инструкцията е съхраняване вместо зареждане. Когато магазинът издаде

проблеми, той извършва търсене в кеша на данни точно като зареждане. Пропуск кара блока да
бъде поставен в буфер за запис, тъй като кешът L1 не разпределя блока при пропуск на запис. При
попадение магазинът не актуализира L1 (или L2) кеша до по-късно, след като е известно, че е
неспекулативен. През това време хранилището се намира в опашка за зареждане на хранилище,
част от механизма за управление на извънредния процес на процесора.
I7 също поддържа предварително извличане за L1 и L2 от следващото ниво в йерархията. В
повечето случаи предварително извлеченият ред е просто следващият блок в кеша. Чрез
предварително извличане само за L1 и L2 се избягват скъпи ненужни извличания в паметта.
Производителност на i7 Memory System
Ние оценяваме производителността на структурата на i7 кеша, използвайки 19 от показателите

SPECCPU2006 (12 цели числа и 7 с плаваща запетая), които бяха описани в глава 1. Данните в този
раздел бяха събрани от професор Lu Peng и Ph.D. студент Ying Zhang, и двамата от Луизианския
държавен университет.
Започваме с L1 кеша. 32 KB, четирипосочно зададен асоциативен кеш за инструкции води до
много нисък процент на пропускане на инструкции, особено защото предварителното извличане
на инструкции в i7 е доста ефективно. Разбира се, начинът, по който оценяваме процента на
пропуски, е малко труден, тъй като i7 не генерира отделни заявки за единични единици инструкции,
а вместо това извлича предварително 16 байта данни за инструкции (обикновено между четири и
пет инструкции). Ако, за простота, изследваме степента на пропускане на кеша на инструкциите,
сякаш се обработват единични препратки към инструкции, тогава процентът на пропускане на
кеша на инструкции L1 варира от 0,1% до 1,8%, средно малко над 0,4%. Тази скорост е в съответствие
с други проучвания на поведението на кеша на инструкциите за тестовете SPECCPU2006, които
показват ниски проценти на пропускане на кеша на инструкции.
Кешът за данни L1 е по-интересен и дори по-сложен за оценка за три
причини:
1. Тъй като L1 кешът за данни не е разпределен за запис, записите могат да улучат, но никога не
пропускат, в смисъл, че запис, който не уцелва, просто поставя данните си в буфера за запис и
не се записва като пропуск.
2. Тъй като спекулациите понякога може да са грешни (вижте Глава 3 за обширна дискусия), има
препратки към L1 кеша за данни, които не съответстват на зареждания или запаметявания,
които в крайна сметка завършват изпълнението. Как трябва да се третират такива пропуски?
3. И накрая, L1 кешът за данни извършва автоматично предварително извличане. Трябва ли предварителното
извличане на този пропуск да се брои и ако да, как?
За да се справят с тези проблеми, като същевременно се запази количеството данни в разумни

граници, Фигура 2.22 показва пропуски в L1 кеша за данни по два начина: спрямо броя на
действително завършените зареждания (често наричани дипломиране или пенсиониране) и
спрямо всички L1 данни достъп до кеша от всеки източник. Както виждаме, процентът на пропуски,
измерен само спрямо завършени зареждания, е 1,6 пъти по-висок (средно 9,5% срещу 5,9%). Фигура
2.23 показва същите данни под формата на таблица.
50%
L1 D пропуски/L1 D препратки към кеша
45% L1 D пропуски/градуирани натоварвания
40%
35%
30%
25%
20%
15%
10%
5%
0%
MILC NAMD DEALII SOPLEX POVRAYLBM SPHINX3
PERLBENCH BZIP2 GCC

MCF GOBMK HMMER SJENG LIBQUANTUM H264REF OMNETPP ASTAR XALANCBMK
Фигура 2.22 Показана е степента на пропуски в кеша за данни L1 за 17 теста за сравнение на SPECCPU2006
по два начина: спрямо действителните натоварвания, които завършват изпълнението успешно и
по отношение на всички препратки към L1, което също включва предварително извличане, спекулативни натоварвания
които не завършват и записват, които се считат за препратки, но не генерират
пропуски. Тези данни, както и останалите в този раздел, са събрани от професор Lu Peng и
Доцент доктор. студент Ying Zhang, и двамата от Луизианския държавен университет, въз основа на по-ранни проучвания на
Intel Core Duo и други процесори (вж. Peng et al. [2008]).
L1 данни пропуски/ L1 данни липсват/

Бенчмарк градуирани зареждания L1 препратки към кеша на данни
PERLBENCH 2% 1%
BZIP2 5% 3%
GCC 14% 6%
MCF 46% 24%
ГОБМК 3% 2%
ХММЪР 4% 3%
SJENG 2% 1%
LIBQUANTUM 18% 10%

H264REF 4% 3%
OMNETPP 13% 8%
ЗВЕЗДА 9% 6%
XALANCBMK 9% 7%
МЛЯКО 8% 5%
NAMD 4% 3%
СДЕЛКИ 6% 5%
СОПЛЕКС 13% 9%
ПОВРАЙ 7% 5%
LBM 7% 4%
СПИНКС3 10% 8%
Фигура 2.23 Пропуските на основния кеш данни са показани спрямо всички зареждания, които са завършили
и всички препратки (което включва спекулативни заявки и заявки за предварително извличане).

При нива на пропуски в L1 кеша за данни от 5% до 10%, а понякога и по-високи,

значението на L2 и L3 кешовете трябва да е очевидно. Фигура 2.24 показва процентите
на пропуски на L2 и L3 кешовете спрямо броя на L1 препратки (а Фигура 2.25 показва
данните в таблична форма). Тъй като цената за пропуск в паметта е над 100 цикъла и
средният процент на пропуски на данни в L2 е 4%, L3 очевидно е критичен. Без L3 и ако
приемем, че около половината инструкции са зареждания или съхранявания,
пропуските в L2 кеша могат да добавят два цикъла на инструкция към CPI! За сравнение,
средният процент на пропуски на L3 данни от 1% все още е значителен, но четири пъти
по-нисък от процента на пропуски на L2 и шест пъти по-малък от процента на пропуски
на L1. В следващата глава ще разгледаме връзката между i7 CPI и пропуските в кеша,
както и други ефекти на конвейера.
16%
L2 пропуска/всички препратки към D кеш
L3 пропуска/всички препратки към D кеш
14%
12%
10%
8%
6%
4%
2%
0%
GCC MCF МЛЯКО LBM
NAMD DEALII SOPLEX POVRAY СПИНКС3
PERLBENCH BZIP2 GOBMK HMMER SJENG LIBQUANTUM H264REF OMNETPP ASTAR XALANCBMK
Фигура 2.24 Процентите на пропуски в кеша на данни L2 и L3 за 17 бенчмарка SPECCPU2006 са

показани спрямо всички препратки към L1, което също включва предварително извличане,
спекулативни зареждания, които не завършват, и генерирани от програма зареждания и съхранявания.
Тези данни, както и останалите в този раздел, са събрани от професор Lu Peng и Ph.D. студент
Ying Zhang, и двамата от Луизианския държавен университет.
L2 пропуска/всички препратки към L3 пропуска/всички препратки към

кеша на данни кеша на данни
PERLBENCH 1% 0%
BZIP2 2% 0%
GCC 6% 1%
MCF 15% 5%
ГОБМК 1% 0%
ХММЪР 2% 0%
SJENG 0% 0%
LIBQUANTUM 3% 0%
H264REF 1% 0%
OMNETPP 7% 3%
ЗВЕЗДА 3% 1%
XALANCBMK 4% 1%
МЛЯКО 6% 1%
NAMD 0% 0%
СДЕЛКИ 4% 0%
СОПЛЕКС 9% 1%
ПОВРАЙ 0% 0%
LBM 4% 4%
СПИНКС3 7% 0%
Фигура 2.25 Процентите на пропуски L2 и L3, показани в таблична форма спрямо броя на данните
заявки.
Като най-естествената количествена от дисциплините на компютърната архитектура,

йерархията на паметта изглежда по-малко уязвима от грешки и клопки. И все пак ние
бяха ограничени тук не от липса на предупреждения, а от липса на място!
Грешка Предсказване на ефективността на кеша на една програма от друга.
Фигура 2.26 показва процентите на пропускане на инструкции и процента на пропускане на данни

за три програми от пакета за сравнение SPEC2000, тъй като размерът на кеша варира. В зависимост от
програмата, пропуските на данни на хиляда инструкции за 4096 KB кеш са 9,
2 или 90 и инструкцията пропуска на хиляда инструкции за 4 KB кеш са
55, 19 или 0,0004. Търговските програми като бази данни ще имат значителни
проценти на пропуски дори в големи кешове от второ ниво, което обикновено не е така
програмите SPEC. Ясно, обобщаване на производителността на кеша от една програма
за друг е неразумно. Както Фигура 2.24 ни напомня, има много вариации,
160
Д: Лукас D: gcc Аз: gcc
140 D: празнина Аз: празнина
Аз: Лукас
120
100
80
0П
а
н
тос0р
ииицкксуурп0 и
н
1
60
40
20
0
4 16 64 256 1024 4096
Размер на кеша (KB)
Фигура 2.26 Инструкции и пропуски на данни на 1000 инструкции, тъй като размерът на кеша варира
от 4 KB до 4096 KB. Пропуските на инструкции за gcc са 30 000 до 40 000 пъти по-големи от
lucas и, обратно, пропуските на данни за lucas са 2 до 60 пъти по-големи от gcc. Програмите gap, gcc
и lucas са от комплекта за сравнение SPEC2000.
и дори прогнозите за относителните проценти на пропуски на програми с интензивно използване на цели
числа и с плаваща запетая могат да бъдат погрешни, както ни напомнят mcf и sphnix3!
Клопка Симулиране на достатъчно инструкции за получаване на точни мерки за ефективност на
йерархия на паметта.
Тук наистина има три клопки. Човек се опитва да предвиди ефективността на голям
кеш с помощта на малка следа. Друг е, че локалното поведение на програмата не е така
постоянен за изпълнението на цялата програма. Третото е местоположението на програмата
поведението може да варира в зависимост от входа.
Фигура 2.27 показва кумулативните средни пропуски на хиляда инструкции
инструкции за пет входа към една програма SPEC2000. За тези входове,
средната скорост на паметта за първите 1,9 милиарда инструкции е много различна от
средният процент на пропуски за останалата част от изпълнението.
Клопка Не осигурява висока честотна лента на паметта в система, базирана на кеш памет.
Кешовете помагат при средна латентност на кеш паметта, но може да не осигурят висока честотна лента на
паметта на приложение, което трябва да отиде в основната памет. Архитектът трябва
проектирайте памет с висока честотна лента зад кеша за такива приложения. Ние ще
прегледайте отново този капан в глави 4 и 5.
Клопка Внедряване на монитор на виртуална машина върху архитектура на набор от инструкции, която
не е проектиран да бъде виртуализиран.
Много архитекти през 70-те и 80-те години на миналия век не бяха внимателни, за да се уверят, че всички
инструкции за четене или писане на информация, свързана с информация за хардуерни ресурси, бяха
привилегировани. Това отношение на laissez faire създава проблеми за VMM

6
1
5
2, 3, 4, 5
такцн
ии сууррпп0
тка 0П
р
а
н
с0р
тое и
н
п
1
4
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9
Инструкции (милиарди)
9
5
8
3
7
4 2
6
5
такцн
ии сууррпп0
тка 0П
р
а
н
с0р
тое и
н
п
1
3
1
2
0
0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42
Инструкции (милиарди)
Фигура 2.27 Пропуски на инструкции за 1000 препратки за пет входа към perl бенчмарк от
SPEC2000. Има малко вариации в пропуските и малка разлика между тях
петте входа за първите 1,9 милиарда инструкции. Изпълнението до завършване показва
как пропуските варират през живота на програмата и как зависят от входа. Горната графика
показва текущите средни пропуски за първите 1,9 милиарда инструкции, които започват
от около 2,5 и завършват с около 4,7 пропуска на 1000 препратки за всичките пет входа.
Долната графика показва текущите средни пропуски за изпълнение до завършване, което
отнема от 16 до 41 милиарда инструкции в зависимост от входа. След първите 1,9
милиарда инструкции, пропуските на 1000 препратки варират от 2,4 до 7,9 в зависимост от
входа. Симулациите бяха за процесора Alpha, използващ отделни L1 кешове за инструкции
и данни, всеки двупосочен 64 KB с LRU и унифициран 1 MB директно картографиран L2 кеш.
за всички тези архитектури, включително 80x86, която използваме тук като

пример.
Фигура 2.28 описва 18-те инструкции, които причиняват проблеми при виртуализацията
ция [Робин и Ървайн 2000]. Двата широки класа са инструкции, които
Четене на контролни регистри в потребителски режим, които разкриват, че гост

операционната система работи във виртуална машина (като POPF, споменат по-рано)
Проверете защитата, както се изисква от сегментираната архитектура, но приемете, че

операционната система работи на най-високото ниво на привилегия.
Виртуалната памет също е предизвикателство. Тъй като 80x86 TLB не поддържат

тагове за ID на процеса, както повечето RISC архитектури, е по-скъпо за
VMM и гост OS за споделяне на TLB; типична промяна на всяко адресно пространство
изисква TLB флъш.
Проблемна категория Проблем 80x86 инструкции
Достъп до чувствителни регистри без прихващане, Регистър на глобална дескрипторна таблица за съхранение (SGDT)
когато работи в потребителски режим Регистър на таблица на локален дескриптор (SLDT)
Регистър на таблицата с дескриптори на прекъсвания (SIDT)
Съхраняване на дума за състояние на машината (SMSW)
Флагове за натискане (PUSHF, PUSHFD)
Поп флагове (POPF, POPFD)
При достъп до механизми за виртуална памет в Зареждане на права за достъп от сегментен дескриптор (LAR)
потребителски режим инструкциите не Ограничение за зареждане на сегмент от дескриптор на сегмент (LSL)
успяват да преминат проверките за Проверете дали дескрипторът на сегмента е четим (VERR)
защита 80x86 Проверете дали дескрипторът на сегмента може да се записва (VERW)
Поп към сегментен регистър (POP CS, POP SS, ...)
Push сегментен регистър (PUSH CS, PUSH SS, ...)
Далечно повикване до различно ниво на привилегия (CALL)
Далечно връщане към различно ниво на привилегия (RET)
Далечен скок до различно ниво на привилегия (JMP)
Софтуерно прекъсване (INT)
Регистър за избор на сегмент на магазина (STR)
Преместване към/от сегментни регистри (MOVE)
Фигура 2.28 Резюме на 18 инструкции 80x86, които причиняват проблеми при виртуализацията [Robin and Irvine 2000]. Първите пет
инструкции от горната група позволяват на програма в потребителски режим да чете контролен регистър, като регистър на
дескрипторна таблица, без
причинявайки капан. Инструкцията за поп флагове модифицира контролен регистър с чувствителна информация, но се проваля
безшумно, когато е в потребителски режим. Проверката на защитата на сегментирания
архитектурата на 80x86 е провалът на долната група, тъй като всяка от тези инструкции проверява имплицитно нивото на привилегия
като част от изпълнението на инструкция при четене
контролен регистър. Проверката предполага, че ОС трябва да е с най-висока привилегия
ниво, което не е случаят с виртуалните машини за гости. Само регистърът MOVE to segment се опитва
модифицира състоянието на контрола и проверката на защитата също го фолира.

2.8 Заключителни бележки: Поглед напред 129
Виртуализирането на I/O също е предизвикателство за 80x86, отчасти защото той поддържа

картографиран I/O с памет и има отделни I/O инструкции, но по-важното е, че има много голям
брой и разнообразие от типове на устройства и драйвери на устройства на компютри, които VMM
да обработва. Доставчиците на трети страни предоставят свои собствени драйвери и те може да не
се виртуализират правилно. Едно решение за конвенционални VM реализации е да се заредят
истински драйвери на устройства директно във VMM.
За да опростят внедряването на VMM на 80x86, AMD и Intel предложиха разширения на
архитектурата. VT-x на Intel предоставя нов режим на изпълнение за стартиране на VM, архитектурна
дефиниция на състоянието на VM, инструкции за бърза смяна на VM и голям набор от параметри за
избор на обстоятелствата, при които трябва да се извика VMM. Като цяло VT-x добавя 11 нови
инструкции за 80x86. Сигурната виртуална машина (SVM) на AMD предоставя подобна функционалност.
След включване на режима, който позволява поддръжка на VT-x (чрез новата инструкция
VMXON), VT-x предлага четири нива на привилегия за OS за гости, които са с по-нисък приоритет от
първоначалните четири (и коригира проблеми като проблема с POPF инструкцията споменато по-
рано). VT-x улавя всички състояния на виртуална машина в състоянието на управление на виртуална
машина (VMCS) и след това предоставя атомарни инструкции за запазване и възстановяване на
VMCS. В допълнение към критичното състояние, VMCS включва конфигурационна информация, за
да определи кога да се извика VMM и след това конкретно какво е причинило извикването на VMM.
За да се намали броят на извикванията на VMM, този режим добавя сенчести версии на някои
чувствителни регистри и добавя маски, които проверяват дали критичните битове на чувствителен
регистър ще бъдат променени преди прихващане. За да се намалят разходите за виртуализиране
на виртуалната памет, SVM на AMD добавя допълнително ниво на индиректност, наречено вложени
таблици на страници. Това прави таблиците със сенчести страници ненужни.
2.8 Заключителни бележки: Поглед напред
През последните тридесет години имаше няколко прогнози за изтъкнато [sic] прекратяване на
скоростта на подобряване на компютърната производителност. Всяка такава прогноза беше
погрешна. Те грешаха, защото се основаваха на неизявени предположения, които бяха преобърнати
от последващи събития. Така например неуспехът да се предвиди преминаването от дискретни
компоненти към интегрални схеми доведе до предсказанието, че скоростта на светлината ще
ограничи скоростите на компютрите до няколко порядъка по-бавни от сегашните. Нашата прогноза
за стената на паметта вероятно също е погрешна, но предполага, че трябва да започнем да мислим
„извън кутията“.
Wm. A. Wulf и Sally A. McKee удрят

стената на паметта: Последици от очевидния отдел по
компютърни науки, Университет на Вирджиния (декември 1994 г.)
Този документ въвежда термина стена на паметта.
Възможността за използване на йерархия на паметта датира от най-ранните дни на цифровите

компютри с общо предназначение в края на 40-те и началото на 50-те години на миналия век. Виртуален
паметта е въведена в изследователските компютри в началото на 60-те години и в IBM

мейнфрейми през 70-те години. Кешовете се появиха приблизително по същото време. Основните
концепции бяха разширени и подобрени с течение на времето, за да помогнат за затваряне на времето за достъп
разликата между основната памет и процесорите, но основните концепции остават.
Една тенденция, която може да причини значителна промяна в дизайна на йерархиите на паметта,
е непрекъснатото забавяне както на плътността, така и на времето за достъп на DRAM. в
през последното десетилетие се наблюдават и двете тези тенденции. Докато някои увеличава в
DRAM честотната лента е постигната, времето за достъп е намалено
много по-бавно, отчасти защото за ограничаване на нивата на напрежение на потреблението на енергия

са се спускали. Една концепция, която се изследва за увеличаване на честотната лента, е да
имат множество припокриващи се достъпи на банка. Това предоставя алтернатива на
увеличаване на броя на банките, като същевременно позволява по-висока честотна лента. производство
предизвикателства пред конвенционалния дизайн на DRAM, който използва кондензатор във всяка клетка,
обикновено поставени в дълбок изкоп, също са довели до забавяне на скоростта на
увеличаване на плътността. Тъй като тази книга ще бъде отпечатана, един производител обяви
нова DRAM, която не изисква кондензатор, може би предоставяща възможност за непрекъснато
подобряване на DRAM технологията.
Независимо от подобренията в DRAM, Flash паметта вероятно ще играе a
по-голяма роля поради потенциалните предимства в мощността и плътността. Разбира се, в
PMDs, Flash вече замени дисковите устройства и предлага предимства като напр
„незабавно включване“, което много настолни компютри не предоставят. Потенциалът на Flash
предимство пред DRAM - липсата на битов транзистор за контрол на записа -
е и неговата ахилесова пета. Flash трябва да използва групови цикли на изтриване-пренаписване, които
са значително по-бавни. В резултат на това няколко PMD, като Apple iPad, използват относително
малка SDRAM основна памет, комбинирана с Flash, която действа и като файл
система и системата за съхранение на страници за работа с виртуална памет.
Освен това се създават няколко напълно нови подхода към паметта
проучени. Те включват MRAM, които използват магнитно съхранение на данни и фаза
сменете RAM (известни като PCRAM, PCME и PRAM), които използват стъкло, което
може да се променя между аморфно и кристално състояние. И двата вида на
паметите са енергонезависими и предлагат потенциално по-висока плътност от DRAM.
Това не са нови идеи; технологии с магниторезистивна памет и фаза
променящите се спомени съществуват от десетилетия. Всяка технология може да стане
алтернатива на текущия Flash; подмяната на DRAM е много по-трудна задача.
Въпреки че подобренията в DRAM са се забавили, възможността за a
клетка без кондензатор и други потенциални подобрения затрудняват залагането
DRAM поне за следващото десетилетие.
От няколко години се правят различни предсказания за идващото

стена на паметта (вижте цитата и статията, цитирани по-горе), което би довело до фундаментално
намаляване на производителността на процесора. Въпреки това, разширяването на кешовете до
множество нива, по-сложни схеми за презареждане и предварително извличане, по-добър компилатор и
осъзнаване на програмиста за важността на локалността и използването на паралелизъм за
скриване на оставащата латентност са помогнали да се запази стената на паметта. Въвеждането на
неправилни тръбопроводи с множество неизпълнени пропуски позволи наличен паралелизъм на ниво
инструкция, за да скрие латентността на паметта, оставаща в
кеш-базирана система. Въвеждането на многопоточност и по-нишково ниво
Казуси и упражнения от Norman P. Jouppi, Naveen Muralimanohar и Sheng Li 131
паралелизмът направи тази крачка напред, като предостави повече паралелизъм и следователно повече
възможности за скриване на латентност. Вероятно използването на паралелизъм на ниво инструкция и
нишка ще бъде основният инструмент за борба с всякакви забавяния на паметта
срещани в съвременните многостепенни кеш системи.
Една идея, която периодично възниква, е използването на управлявана от програмист скречпад или
други високоскоростни памети, които ще видим, че се използват в GPU. Такива
идеите никога не са станали мейнстрийм по няколко причини: Първо, те нарушават
модел на паметта чрез въвеждане на адресни пространства с различно поведение. Второ,
за разлика от оптимизациите на кеша, базирани на компилатор или програмист (като напр
предварително извличане), трансформациите на паметта със скречпадове трябва да се справят напълно
пренасочването от адресното пространство на основната памет към адресното пространство на scratchpad.
Това прави подобни трансформации по-трудни и ограничени като приложимост. в
GPU (вижте Глава 4), където локалните памети на scratchpad се използват силно, the
тежестта за тяхното управление в момента пада върху програмиста.
Въпреки че човек трябва да бъде предпазлив при прогнозирането на бъдещето на компютрите
технология, историята показва, че кеширането е мощен и силно разширяем
идея, която вероятно ще ни позволи да продължим да създаваме по-бързи компютри и да гарантираме това
йерархията на паметта може да достави инструкциите и данните, необходими за съхраняването на такива
системи работят добре.
2.9 Историческа перспектива и препратки
В раздел L.3 (достъпен онлайн) разглеждаме историята на кеш паметта, виртуалната памет и виртуалните
машини. IBM играе важна роля в историята и на трите.
Включени са препратки за допълнително четене.
Казуси и упражнения от Norman P. Jouppi, Naveen

Muralimanohar и Sheng Li
Казус 1: Оптимизиране на производителността на кеша чрез Advanced

Техники
Неблокиращи кешове
Оптимизации на компилатора за кешове
Предварително извличане на софтуер и хардуер
Изчисляване на въздействието на производителността на кеша върху по-сложни процесори

Транспонирането на матрица разменя нейните редове и колони; това е илюстрирано по-долу:
A11 A12 A13 A14 A11 A21 A31 A41

A21 A22 A23 A24 A12 A22 A32 A42
A31 A32 A33 A34 A13 A23 A33 A43
A41 A42 A43 A44 A14 A24 A34 A44
Ето един прост C цикъл за показване на транспонирането:
за (i = 0; i < 3; i++) {
за (j = 0; j < 3; j++) { изход[j][i] = вход[i]
[j]; }
Да приемем, че както входната, така и изходната матрица се съхраняват в основния ред на реда
(главният ред на реда означава, че индексът на реда се променя най-бързо). Да приемем, че
изпълнявате транспониране с двойна точност 256 × 256 на процесор с 16 KB напълно асоциативен
(не се притеснявайте за конфликти в кеша) най-скоро използван (LRU) заместващ L1 кеш за данни с
64 байтови блокове. Да приемем, че пропуските или предварителното извличане на L1 кеша изискват
16 цикъла и винаги попадат в L2 кеша и че L2 кешът може да обработва заявка на всеки два цикъла
на процесора. Да приемем, че всяка итерация на вътрешния цикъл по-горе изисква четири цикъла,
ако данните присъстват в L1 кеша.
Да приемем, че кешът има политика за извличане при запис за разпределяне на запис за пропуски при запис.
Нереалистично е да предположим, че записването обратно на мръсни кеш блокове изисква 0 цикъла.
2.1 [10/15/15/12/20] <2.2> За простото изпълнение, дадено по-горе, този ред на изпълнение би бил неидеален
за входната матрица; въпреки това, прилагането на оптимизация на обмен на цикъл би създало
неидеален ред за изходната матрица. Тъй като обменът на контури не е достатъчен за подобряване
на неговата производителност, вместо това той трябва да бъде блокиран.
а. [10] <2.2> Какъв трябва да бъде минималният размер на кеша, за да се възползвате от блокираното
изпълнение?
b. [15] <2.2> Как се сравнява относителният брой пропуски в блокираните и неблокираните версии в
кеша с минимален размер по-горе? ° С. [15] <2.2> Напишете код за извършване
на транспониране с параметър B за размер на блок

който използва B × B блокове.
д. [12] <2.2> Каква е минималната асоциативност, изисквана от L1 кеша за постоянна производителност,

независимо от позицията на двата масива в паметта?
д. [20] <2.2> Изпробвайте блокирани и неблокирани 256 × 256 матрични транспозиции на компютър. До каква
степен резултатите отговарят на вашите очаквания въз основа на това, което знаете за системата с памет
на компютъра? Обяснете всички несъответствия, ако е възможно.
2.2 [10] <2.2> Да приемем, че проектирате хардуерен инструмент за предварително извличане за деблокирания матричен
код за транспониране по-горе. Най-простият тип хардуерен инструмент за предварително извличане
предварително извлича само последователни кеш блокове след пропуск. По-сложните хардуерни програми за
предварително извличане на „non-unit stride“ могат да анализират пропуснат референтен поток и да откриват и
извличат предварително не-unit strides. За разлика от това, софтуерното предварително извличане може да
определи крачките, които не са единици, толкова лесно, колкото може да определи крачките на единиците. Да
приемем, че предварителното извличане записва директно в кеша и че няма „замърсяване“ (презаписване на
данни, които трябва да се използват преди данните, които се извличат предварително). За най-добро
представяне при предварително избиране на крачка без единица, в стабилно състояние на вътрешния цикъл
колко предварително избирания трябва да са неизпълнени в даден момент?
2.3 [15/20] <2.2> При софтуерното предварително извличане е важно да внимавате предварителното извличане да се
извършва навреме за използване, но също така да минимизирате броя на неизпълнените предварително
извличане, за да живеете в рамките на възможностите на микроархитектурата и да сведете до минимум
замърсяването на кеша. Това се усложнява от факта, че различните процесори имат различни възможности и
ограничения. а. [15] <2.2> Създаване на
блокирана версия на транспонирането на матрицата със софтуер
предварително извличане.
b. [20] <2.2> Оценете и сравнете производителността на блокираните и неблокираните кодове за транспониране
със и без софтуерно предварително извличане.
Казус 2: Обединяване на всичко: Силно паралелно

Системи за памет
Концепция, илюстрирана от този казус
Междусекторни въпроси: Дизайнът на йерархиите на паметта
Програмата на фигура 2.29 може да се използва за оценка на поведението на система с памет. Ключът е да
имате точно време и след това програмата да премине през паметта, за да извика различни нива на йерархията.
Фигура 2.29 показва кода в C. Първата част е процедура, която използва стандартна помощна програма, за да
получи точна мярка за процесорното време на потребителя; тази процедура може да се наложи да бъде
променена, за да работи на някои системи. Втората част е вложен цикъл за четене и запис на памет с различни
крачки и размери на кеша. За да получите точно време на кеша, този код се повтаря много пъти. Третата част
умножава само режийните разходи за вложен цикъл, за да може да се извади от общото измерено време, за да
се види колко дълги са били достъпите. Резултатите се извеждат във файлов формат .csv за улесняване на
импортирането в електронни таблици. Може да се наложи да промените CACHE_MAX в зависимост от въпроса,
на който отговаряте, и размера на паметта на системата, която измервате.
Изпълнението на програмата в режим за един потребител или поне без други активни приложения ще даде по-
последователни резултати. Кодът на фигура 2.29 е извлечен от програма, написана от Андреа Дюсо от
Калифорнийския университет в Бъркли

#include "stdafx.h"
#include <stdio.h>
#include <time.h>
#define ARRAY_MIN (1024) /* 1/4 най-малък кеш */ #define
ARRAY_MAX (4096*4096) /* 1/4 най-голям кеш */ int x[ARRAY_MAX]; /*
масивът ще премине през */
double get_seconds() { /* рутина за четене на времето в секунди */ __time64_t

ltime; _time64( &ltime);
връщане (двойно) ltime;
} int label(int i) {/* генерира текстови етикети */ if (i<1e3)

printf("%1dB,",i); else if (i<1e6)
printf("%1dK,",i/1024); else if (i<1e9) printf("%1dM,",i/
1048576); else printf("%1dG,",i/1073741824); връщане 0;
} int _tmain(int argc, _TCHAR* argv[]) { int регистър

следваща стъпка, i, индекс, крачка; int csize; двойни
стъпала,
стъпала; двойно време за
зареждане, lastsec, sec0, sec1, sec; /* времеви променливи */
/* Инициализиране на изхода
*/ printf(" ,"); за
(крачка=1; крачка <= ARRAY_MAX/2; крачка=крачка*2)
етикет (крачка*sizeof(int));
printf("\n");
/* Главен цикъл за всяка конфигурация */ for

(csize=ARRAY_MIN; csize <= ARRAY_MAX; csize=csize*2) {
етикет (csize*sizeof(int)); /* размер на кеша за печат този цикъл */ за
(stride=1; stride <= csize/2; stride=stride*2) {
/* Очертайте пътя на препратките към паметта в масив */ за

(index=0; index < csize; index=index+stride)
x[индекс] = индекс + крачка; /* указател към следващия */
x[индекс-крачка] = 0; /* връщане към началото */
/* Изчакайте таймера да се превърти */

lastsec = get_seconds(); sec0 =
get_seconds(); докато (sec0 == lastsec);
/* Преминаване през пътя в масива за двадесет секунди */ /* Това

дава 5% точност с втора резолюция */ стъпки = 0.0; /* брой
предприети стъпки */ nextstep = 0; /* начало в
началото на пътя */ sec0 = get_seconds(); /* стартиране на
таймера */
{ /* повторете, докато съберете 20 секунди */
(i=stride;i!=0;i=i-1) { /* запазете пробите същите */ nextstep =
0; направете
следваща стъпка = x[следваща стъпка]; /* зависимост
*/ докато (следваща стъпка != 0);
} стъпки = стъпки + 1.0; /* брои итерации на цикъл */ sec1 =

get_seconds(); /* край на таймера */ } while ((sec1
- sec0) < 20.0); /* събира 20 секунди */ сек = сек1 - сек0;
/* Повтаряне на празен цикъл към цикъл, изваждане на

допълнителни разходи */ tsteps = 0.0; /* използва се за съвпадение
на не. докато итерации */ sec0 = get_seconds(); /*
стартиране на таймера */ { /* повтаряне до същия номер.
итерации както по-горе */ (i=stride;i!=0;i=i-1) { /* запазване на
пробите
същите */ индекс = 0; направи
индекс = индекс + крачка; докато (индекс <csize);
} tsteps = tsteps + 1.0; sec1 =

get_seconds(); /* - режийни */ } докато
(tsteps<стъпки); /* до = не. итерации */ сек = сек - (сек1 - сек0);
време за зареждане = (сек*1e9)/
(стъпки*cразмер); /* извежда резултатите
във формат .csv за Excel */ printf("%4.1f,", (време за
зареждане<0.1) ? 0.1 : време за зареждане); }; /* край на
вътрешния for цикъл */ printf("\n"); }; /
* край на
външния for цикъл */ връща 0;
Фигура 2.29 C програма за оценка на системата памет.

1000
8K
16K
32K
64K
128K
256K
512K
100
1M
2M
4M
8M
ететечо)sрnП(
16M
32M
64M
128M
10
256M
512M
1
4B 16B 64B 256B 4K1K 16K 64K 256K 4M1M 16M 64M 256M
Крачка
Фигура 2.30 Примерни резултати от програмата на Фигура 2.29.
и се основава на подробно описание, намерено в Saavedra-Barrera [1992]. Той е

модифициран, за да коригира редица проблеми с по-модерни машини и да работи под
Microsoft Visual C++. Може да бъде изтеглен от www.hpl.hp.com/ Research/cacti/
aca_ch2_cs2.c.
Програмата по-горе предполага, че програмните адреси проследяват физическите
адреси, което е вярно за малкото машини, които използват виртуално адресирани
кешове, като Alpha 21264. По принцип виртуалните адреси са склонни да следват
физическите адреси малко след рестартиране, така че може да се наложи да рестартирате
машината, за да получите гладки линии във вашите резултати. За да отговорите на
въпросите по-долу, приемете, че размерите на всички компоненти на йерархията на
паметта са степени на 2. Да приемем, че размерът на страницата е много по-голям от
размера на блок в кеш от второ ниво (ако има такъв) , а размерът на кеш блок от второ
ниво е по-голям или равен на размера на блок в кеш от първо ниво. Пример за изхода
на програмата е изобразен на фигура 2.30; ключът показва размера на масива, който се упражняв
2.4 [12/12/12/10/12] <2.6> Използването на примерната програма води до резултати на Фигура 2.30:
а. [12] <2.6> Какъв е общият размер и размерът на блока на второто ниво

кеш?
b. [12] <2.6> Какво е наказанието за пропуск на кеша от второ ниво?

° С. [12] <2.6> Каква е асоциативността на кеша от второ ниво? д. [10] <2.6>
Какъв е размерът на основната памет? д. [12] <2.6> Какво е
времето за пейджинг, ако размерът на страницата е 4 KB?
2.5 [12/15/15/20] <2.6> Ако е необходимо, променете кода на Фигура 2.29 , за да измерите следните
характеристики на системата. Начертайте резултатите от експеримента с изминалото време по
оста y и стъпката на паметта по оста x. Използвайте логаритмични скали за двете оси и
начертайте линия за всеки размер на кеша.
а. [12] <2.6> Какъв е размерът на системната страница?
b. [15] <2.6> Колко записа има в страничния буфер за превод

(TLB)?
° С. [15] <2.6> Какво е наказанието за пропуск за TLB? д. [20]
<2.6> Каква е асоциативността на TLB?
2.6 [20/20] <2.6> В многопроцесорни системи с памет по-ниските нива на йерархията на паметта може
да не могат да бъдат наситени от един процесор, но трябва да могат да бъдат наситени от
множество процесори, работещи заедно. Променете кода на Фигура 2.29 и стартирайте няколко
копия едновременно. Можете ли да определите: а. [20] <2.6> Колко реални процесора
има във вашата компютърна система и колко системни процесора са само допълнителни
многонишкови контексти?
b. [20] <2.6> Колко контролера на паметта има вашата система?
2.7 [20] <2.6> Можете ли да измислите начин да тествате някои от характеристиките на кеша на
инструкции с помощта на програма? Съвет: Компилаторът може да генерира голям брой
неочевидни инструкции от част от кода. Опитайте се да използвате прости аритметични
инструкции с известна дължина във вашата архитектура на набор от инструкции (ISA).
2.8 [12/12/15] <2.2> Следните въпроси изследват въздействието на малки и прости кешове, използващи
CACTI и предполагат 65 nm (0,065 μm) технология.
(CACTI се предлага в онлайн формуляр на http://quid.hpl.hp.com:9081/cacti/.) а. [12] <2.2>
Сравнете времето за достъп на 64 KB кешове с 64 байтови блокове и една банка. Какви са

относителните времена за достъп на двупосочни и четирипосочни набори асоциативни
кешове в сравнение с директно картографирана организация?
b. [12] <2.2> Сравнете времето за достъп на асоциативни кешове с четирипосочен набор с 64

байтови блокове и единична банка. Какви са относителните времена за достъп на 32 KB и
64 KB кеш в сравнение с 16 KB кеш?
° С. [15] <2.2> За кеш от 64 KB намерете асоциативността на кеша между 1 и 8 с най-ниското

средно време за достъп до паметта, като се има предвид, че пропуските на инструкция за
определен набор от работни натоварвания са 0,00664 за директно картографиране, 0,00366
за асоциативен двупосочен набор , 0,000987 за асоциативен набор от четири посоки и 0,000266 за
асоциативен кеш с осемпосочен набор. Като цяло има 0,3 препратки към данни на инструкция. Да
приемем, че пропуските в кеша отнемат 10 ns във всички модели. За да изчислите времето за
попадение в цикли, приемете изходното време за цикъл с помощта на CACTI, което съответства
на максималната честота, която кешът може да работи без никакви мехурчета в конвейера.
2.9 [12/15/15/10] <2.2> Вие проучвате възможните ползи от L1 кеш с предсказване на пътя. Да приемем, че 64
KB четирипосочен асоциативен еднобанкиран L1 кеш за данни е ограничителят на времевия цикъл в
системата. Като алтернативна организация на кеша обмисляте кеш с прогнозиране на пътя, моделиран
като 64 KB директно картографиран кеш с 80% точност на прогнозиране. Освен ако не е посочено
друго, приемете, че погрешно предвиден достъп до кеша отнема още един цикъл. Да приемем
процентите на пропуски и наказанията за пропуски във въпрос 2.8 част (c). а. [12] <2.2> Какво е средното
време за достъп до паметта на текущия кеш (in
цикли) спрямо предвидения по начин кеш?
b. [15] <2.2> Ако всички останали компоненти можеха да работят с по-бързо предвиденото време на
цикъла на кеша (включително основната памет), какво би било въздействието върху
производителността от използването на предвидения по начин кеш?
° С. [15] <2.2> Предсказаните по пътя кешове обикновено се използват само за кешове на инструкции,
които захранват опашка с инструкции или буфер. Представете си, че искате да изпробвате
предсказване на пътя в кеш данни. Да приемем, че имате 80% точност на прогнозиране и че
последващите операции (напр. достъп до кеша на данни на други инструкции, зависими операции)
се издават при предположение за правилно прогнозиране на пътя. По този начин погрешното
предсказване налага необходимостта от промиване на канала и прихващане за повторно
възпроизвеждане, което изисква 15 цикъла. Положителна или отрицателна ли е промяната в
средното време за достъп до паметта на инструкция за зареждане с прогнозиране на пътя на кеша на данни и
д. [10] <2.2> Като алтернатива на предсказването на пътя, много големи асоциативни L2 кешове
сериализират етикети и достъп до данни, така че трябва да се активира само необходимият масив
от данни. Това спестява енергия, но увеличава времето за достъп. Използвайте подробния уеб
интерфейс на CACTI за 0,065 μm процес 1 MB четирипосочен асоциативен кеш с 64 байтови
блокове, 144 бита за четене, 1 банка, само 1 порт за четене/запис, 30 битови тагове и ITRS-HP
технология с глобални проводници . Какво е съотношението на времената за достъп за
сериализиране на етикет и достъп до данни в сравнение с паралелния достъп?
2.10 [10/12] <2.2> Бяхте помолени да проучите относителната производителност на банковия спрямо конвейерния
L1 кеш за данни за нов микропроцесор. Да приемем 64 KB двупосочен асоциативен кеш с 64 байтови
блокове. Конвейерният кеш ще се състои от три тръбопроводни етапа, подобни по капацитет на кеша
за данни Alpha 21264. Банкираното внедряване ще се състои от две асоциативни банки с двупосочен
набор от 32 KB. Използвайте CACTI и приемете 65 nm (0,065 μm) технология, за да отговорите на
следните въпроси. Изходното време на цикъла в уеб версията показва на каква честота кешът може да
работи без никакви мехурчета в конвейера. а. [10] <2.2> Какво е времето за цикъл на кеша в сравнение
с времето му за достъп и колко етапа на канала ще заеме кешът (до два знака след
десетичната запетая)?
b. [12] <2.2> Сравнете площта и общата динамична енергия на четене за достъп на

конвейерния дизайн спрямо груповия дизайн. Посочете кое заема по-малко площ и
кое изисква повече мощност и обяснете защо може да е така.
2.11 [12/15] <2.2> Помислете за използването на критична дума първа и ранно рестартиране при
пропуски в L2 кеша. Да приемем 1 MB L2 кеш с 64 байтови блокове и път за презареждане,
който е широк 16 байта. Да приемем, че L2 може да бъде записан с 16 байта на всеки 4
цикъла на процесора, времето за получаване на първия 16-байтов блок от контролера
на паметта е 120 цикъла, всеки допълнителен 16-байтов блок от основната памет изисква
16 цикъла и данните могат да бъдат прескочен директно в порта за четене на L2 кеша.
Игнорирайте всички цикли за прехвърляне на заявката за пропуск в L2 кеша и исканите
данни в L1 кеша.
а. [12] <2.2> Колко цикъла ще са необходими за обслужване на пропуск на L2 кеш с и без

първа критична дума и ранно рестартиране?
b. [15] <2.2> Смятате ли, че първата критична дума и ранното рестартиране биха били
по-важни за кеш L1 или L2 и какви фактори биха допринесли за относителната им
важност?
2.12 [12/12] <2.2> Вие проектирате буфер за запис между L1 кеш за запис и L2 кеш за обратно
записване. L2 кеш шината за запис на данни е широка 16 B и може да извършва запис
към независим кеш адрес на всеки 4 цикъла на процесора. а. [12] <2.2> Колко
байта трябва да е широк всеки запис в буфера за запис? b. [15] <2.2> Какво
ускоряване може да се очаква в стабилно състояние чрез използване на обединяващ

буфер за запис вместо необединяващ буфер при нулиране на памет чрез изпълнение
на 64-битови запаметявания, ако всички други инструкции могат да бъдат издадени
успоредно със запаметяванията и блоковете присъстват в L2 кеша? ° С.
[15] <2.2> Какъв би бил ефектът от възможни пропуски на L1 върху броя на необходимите
записи в буфер за запис за системи с блокиращи и неблокиращи кешове?
2.13 [10/10/10] <2.3> Помислете за настолна система с процесор, свързан към 2 GB DRAM с код за
коригиране на грешки (ECC). Да приемем, че има само един канал на паметта с ширина
от 72 бита до 64 бита за данни и 8 бита за ECC. а. [10] <2.3> Колко DRAM чипа
има на DIMM, ако се използват 1 GB DRAM чипове и колко I/O данни трябва да има всяка
DRAM, ако само една DRAM се свързва към всеки щифт за данни на DIMM?
b. [10] <2.3> Каква дължина на пакета е необходима за поддръжка на 32 B L2 кеш
блока? ° С. [10] <2.3> Изчислете пиковата честотна лента за DDR2-667 и DDR2-533 DIMM
модули за четене от активна страница, с изключение на ECC overhead.
2.14 [10/10] <2.3> Примерна времева диаграма на DDR2 SDRAM е показана на Фигура 2.31. tRCD е
времето, необходимо за активиране на ред в банка, а латентността (CL) на адрес на
колона (CAS) е броят цикли, необходими за прочитане на колона в ред. Да приемем, че
RAM е на стандартен DDR2 DIMM с ECC , като има 72 линии за данни. Също така приемете
дължини на пакет от 8, които четат 8 бита или общо 64 B от
Часовник
CMD/ ДЕЙСТВАЙ RD
ДОБАВЯНЕ B0, Rx B0, Cx
T
RCD CAS латентност Изход на данни Изход на данни
Данни
Фигура 2.31 DDR2 SDRAM времева диаграма.
DIMM модула. Да приемем, че tRCD = CAS (или CL) * clock_frequency и clock_frequency =

transfers_per_second/2. Латентността на чипа при пропуск на кеша през нива 1 и 2 и обратно,
без да се включва достъпът до DRAM, е 20 ns. а. [10] <2.3> Колко време е необходимо от
представянето на командата за активиране, докато последният поискан бит данни от DRAM

премине от валиден към невалиден за DDR2-667 1 GB CL = 5 DIMM? Да приемем, че за
всяка заявка ние автоматично извличаме предварително друга съседна кеш линия на
същата страница.
b. [10] <2.3> Каква е относителната латентност при използване на DDR2-667 DIMM на четене,
изискващо активиране на банка, спрямо едно към вече отворена страница, включително
времето, необходимо за обработка на пропуска вътре в процесора?
2.15 [15] <2.3> Да приемем, че DDR2-667 2 GB DIMM с CL = 5 е наличен за $130, а DDR2-533 2 GB DIMM с
CL = 4 е наличен за $100. Да приемем, че в една система се използват два DIMM модула, а
останалата част от системата струва $800.
Помислете за производителността на системата, използваща DDR2-667 и DDR2-533 DIMM
модули при работно натоварване с 3,33 L2 пропуска на 1K инструкции и приемете, че 80% от
всички четения на DRAM изискват активиране. Каква е производителността на разходите на
цялата система при използване на различните DIMM модули, ако приемем, че само един L2
пропуск е неизпълнен в даден момент и ядро в ред с CPI от 1,5, без да включва L2 кеш пропуск
време за достъп до паметта?
2.16 [12] <2.3> Осигурявате сървър с осемядрен 3 GHz CMP, който може да изпълни работно
натоварване с общ CPI от 2.0 (ако приемем, че не се забавят попълванията на L2 кеш паметта).
Размерът на L2 кеша е 32 байта. Ако приемем, че системата използва DDR2-667 DIMM, колко
независими канала за памет трябва да бъдат осигурени, така че системата да не е ограничена
от честотната лента на паметта, ако изискваната честотна лента понякога е два пъти по-
висока от средната? Работните натоварвания предизвикват средно 6,67 L2 пропуска на 1K
инструкции.
2.17 [12/12] <2.3> Голямо количество (повече от една трета) DRAM мощност може да се дължи на
активиране на страница (вижте http://download.micron.com/pdf/technotes/ddr2/TN4704.pdf и
www.micron.com/systemcalc). Да приемем, че изграждате система с 2 GB памет, като използвате
или 8-банкови 2 GB x8 DDR2 DRAM, или 8-банкови 1 GB x8 DRAM, и двете с еднаква скорост. И
двете използват размер на страницата от 1 KB, а
размерът на кеша на последното ниво е 64 байта. Да приемем, че DRAM, които не са активни, са

в предварително зареден режим на готовност и разсейват незначителна мощност. Да приемем,
че времето за преминаване от режим на готовност към
активно не е значително. а. [12] <2.3> Кой тип DRAM се очаква да осигури по-висока
производителност на системата? Обясни защо.
b. [12] <2.3> Как 2 GB DIMM, направен от 1 GB x8 DDR2 DRAM, се сравнява с DIMM с подобен
капацитет, направен от 1 Gb x4 DDR2 DRAM по отношение на мощност?
2.18 [20/15/12] <2.3> За достъп до данни от типична DRAM, първо трябва да активираме съответния ред.
Да приемем, че това носи цяла страница с размер 8 KB в буфера на реда. След това избираме
определена колона от буфера на редовете. Ако следващите достъпи до DRAM са към същата
страница, тогава можем да пропуснем стъпката за активиране; в противен случай трябва да
затворим текущата страница и да заредим предварително битовите линии за следващото
активиране. Друга популярна политика на DRAM е проактивно затваряне на страница и
предварително зареждане на битови линии веднага щом достъпът приключи. Да приемем, че
всяко четене или запис в DRAM е с размер 64 байта и латентността на DDR шината (данните на
Фигура 2.30) за изпращане
на 512 бита е Tddr. а. [20] <2.3> Ако приемем, че DDR2-667, ако са необходими пет цикъла за
предварително зареждане, пет цикъла за активиране и четири цикъла за четене на колона,
за каква стойност на скоростта на попадение на буфера на реда (r) ще изберете една политика
вместо друг, за да получите най-доброто време за достъп? Да приемем, че всеки достъп до
DRAM е разделен от достатъчно време, за да завърши произволен нов достъп.
b. [15] <2.3> Ако 10% от общите достъпи до DRAM се случват един след друг или непрекъснато без
никакво времево прекъсване, как ще се промени решението ви?
° С. [12] <2.3> Изчислете разликата в средната DRAM енергия за достъп между двете политики,
като използвате изчисления по-горе процент на попадения в буфера на редовете.
Да приемем, че предварителното зареждане изисква 2 nJ, а активирането изисква 4 nJ и че
са необходими 100 pJ/bit за четене или запис от буфера на реда.
2.19 [15] <2.3> Когато компютърът е неактивен, можем или да го поставим в режим на готовност (където
DRAM все още е активен), или можем да го оставим да хибернира. Да приемем, че за хибернация
трябва да копираме само съдържанието на DRAM на енергонезависима среда като Flash.
Ако четенето или записването на кеш линия с размер 64 байта във Flash изисква 2,56 μJ, а DRAM
изисква 0,5 nJ, и ако консумацията на енергия в неактивен режим за DRAM е 1,6 W (за 8 GB), колко
време трябва да е неактивна системата, за да се възползва от хибернация? Да предположим, че
основната памет е с размер 8 GB.
2.20 [10/10/10/10/10] <2.4> Виртуалните машини (VM) имат потенциала да добавят много полезни
възможности към компютърните системи, като например подобрена обща цена на притежание
(TCO) или наличност. Могат ли VM да се използват за предоставяне на следните възможности?
Ако е така, как биха могли да улеснят това? а. [10] <2.4>
Тествайте приложения в производствени среди с помощта на разработка

машини?
b. [10] <2.4> Бързо повторно разполагане на приложения в случай на бедствие или повреда?
° С. [10] <2.4> По-висока производителност в I/O-интензивни приложения?
д. [10] <2.4> Изолиране на грешки между различни приложения, което води до по-високи
наличност за услуги?
д. [10] <2.4> Извършване на софтуерна поддръжка на системи, докато приложения

работят без значителни прекъсвания?
2.21 [10/10/12/12] <2.4> Виртуалните машини могат да загубят производителност от редица

на събития, като изпълнение на привилегировани инструкции, пропуски на TLB, капани и
I/O. Тези събития обикновено се обработват в системен код. По този начин, един от начините за оценка
на забавянето при работа под VM е процентът на времето за изпълнение на приложението в системен
спрямо потребителски режим. Например разходи за приложение
10% от неговото изпълнение в системен режим може да се забави с 60%, когато работи
виртуална машина. Фигура 2.32 изброява ранната производителност на различни системни повиквания под
естествено изпълнение, чиста виртуализация и паравиртуализация за използване на LMbench

Xen на система Itanium с времена, измерени в микросекунди (с любезното съдействие на
Матю Чапман от Университета на Нов Южен Уелс). а. [10] <2.4> Какви типове
програми се очаква да имат по-малко забавяне, когато работят под виртуални машини?
b. [10] <2.4> Ако забавянията бяха линейни като функция на системното време, като се има предвид
забавяне по-горе, колко по-бавно би програма, изразходваща 20% от своите
изпълнение в системно време се очаква да се изпълнява?
° С. [12] <2.4> Какво е средното забавяне на системните извиквания в таблицата

по-горе под чиста виртуализация и паравиртуализация?
д. [12] <2.4> Кои функции в горната таблица имат най-голямо забавяне?

Каква според вас може да е причината за това?
Бенчмарк Местен Чисто ал
Нулево обаждане 0,04 0,96 0,50
Нулев вход/изход 0,27 6.32 2.91
статистика 1.10 10,69 4.14
Отворено затворено 1,99 20.43 7.71
Инсталирайте sighandler 0,33 7.34 2,89
Сигнал за дръжка 1,69 19.26 2.36
вилица 56,00 513,00 164,00
Изп 316,00 2084.00 578,00
Fork + exec sh 1451,00 7790,00 2360.00
Фигура 2.32 Ранна производителност на различни системни повиквания при естествено изпълнение, чисто
виртуализация и паравиртуализация.
2.22 [12] <2.4> Дефиницията на Попек и Голдбърг за виртуална машина казва, че тя няма да бъде разграничена
от реална машина, освен по нейната производителност. В този въпрос ще използваме тази
дефиниция, за да разберем дали имаме достъп до естествено изпълнение на процесор или работим
на виртуална машина. Технологията Intel VT-x ефективно осигурява втори набор от нива на
привилегии за използване на виртуалната машина. Какво би трябвало да прави виртуална машина,
работеща върху друга виртуална машина, ако приемем технологията VT-x?
2.23 [20/25] <2.4> С приемането на поддръжка за виртуализация на x86 архитектурата, виртуалните машини
активно се развиват и стават масови. Сравнете и контрастирайте технологиите за виртуализация
Intel VT-x и AMD-V на AMD. (Информация за AMD-V може да бъде намерена на http://sites.amd.com/
us/business/it-solutions/ virtualization/Pages/resources.aspx.) а. [20] <2.4> Кое от тях би могло да осигури
по-висока производителност за приложения,
изискващи интензивна памет с големи отпечатъци от паметта?
b. [25] <2.4> Информация за поддръжката на IOMMU на AMD за виртуализиран I/O може да бъде
намерена на http://developer.amd.com/documentation/articles/pages/892006101.aspx.
Какво правят технологията за виртуализация и модулът за управление на входно/изходната
памет (IOMMU) за подобряване на виртуализираната I/O производителност?
2.24 [30] <2.2, 2.3> Тъй като паралелизмът на ниво инструкция може също така да бъде ефективно използван
при суперскаларни процесори в ред и процесори с много дълги командни думи (VLIW) със спекулации,
една важна причина за изграждане на извънредно (OOO ) суперскаларният процесор е способността
да толерира непредвидима латентност на паметта, причинена от пропуски в кеша. Следователно
можете да мислите за хардуера, поддържащ проблема с OOO, като част от системата за памет!
Погледнете етажния план на Alpha 21264 на Фигура 2.33 , за да намерите относителната площ на
опашките за проблеми с цели числа и с плаваща запетая и съпоставителите спрямо кешовете.
Опашките планират инструкции за издаване, а съпоставителите преименуват спецификаторите на
регистъра. Следователно това са необходими допълнения в подкрепа на издаването на OOO. 21264
има само L1 кешове за данни и инструкции на чип и и двата са 64 KB двупосочен набор асоциативни.
Използвайте суперскаларен симулатор на OOO като SimpleScalar (www.cs.wisc.edu/~mscalar/
simplescalar.html) върху бенчмаркове с интензивно използване на паметта, за да разберете колко
производителност се губи, ако областта на опашките за проблеми и съпоставителите се използва за
допълнителна L1 област на кеша за данни в суперскаларен процесор в ред, вместо проблем с OOO
в модел на 21264 Уверете се, че другите аспекти на машината са възможно най-сходни, за да бъде
сравнението справедливо. Игнорирайте всяко увеличаване на достъпа или времето за цикъл от по-
големи кешове и ефектите от по-големия кеш на данни върху етажния план на чипа. (Имайте
предвид, че това сравнение няма да е напълно справедливо, тъй като кодът няма да е планиран за
процесора по ред от компилатора.)
2.25 [20/20/20] <2.6> Анализаторът на производителността на Intel VTune може да се използва за извършване
на много измервания на поведението на кеша. Безплатна пробна версия на VTune за Windows и
Linux може да бъде изтеглена от http://software.intel.com/en-us/articles/intel-vtune-amplifier-xe/ .
Програмата (aca_ch2_cs2.c), използвана в Казус 2, е модифицирана, така че да може да работи с VTune
от кутията на Microsoft Visual C++. Програмата може да бъде изтеглена от www.hpl.hp.com/
автобус
Поплавък Цяло число

интерфейс
картограф
карта мерна единица
ретсъл)к1(
ретсъл)к0(
дЦ
ч
е
дЦ
ч
е
и
и
ся
ся
лли
лли
н
н
аацвиоо
аацвиоо
опашка
памет
Цяло число
контролер
опашка
щ
ия
а цаиатн дап
апл
веи Езс
Шини за данни и управление
Контролер на паметта
мачилвзи
яицкуртснИ
Данни
Инструкция кеш памет
UIB
кеш памет
Фигура 2.33 Етажен план на Alpha 21264 [Kessler 1999].
research/cacti/aca_ch2_cs2_vtune.c. Специални функции на VTune са вмъкнати, за да се

изключи инициализацията и претоварването на цикъла по време на процеса на анализ на
производителността. Подробни указания за настройка на VTune са дадени в раздела README
в програмата. Програмата продължава да работи в цикъл за 20 секунди за всяка
конфигурация. В следващия експеримент можете да откриете ефектите от размера на
данните върху кеша и цялостната производителност на процесора. Стартирайте програмата
във VTune на процесор Intel с размери на входния набор от данни от 8 KB, 128 KB, 4 MB и 32
MB и поддържайте крачка от 64 байта (крачка с един ред в кеша при процесори Intel i7).
Събирайте статистически данни за цялостната производителност и ефективността на
кеша за данни L1, L2 и L3. а. [20] <2.6> Избройте броя пропуски на 1K инструкция на кеш
данни L1, L2 и L3 за всеки размер на набор от данни и модел и скорост на вашия
процесор. Въз основа на резултатите, какво можете да кажете за размерите на кеша за
данни L1, L2 и L3 на вашия процесор? Обяснете вашите наблюдения.
b. [20] <2.6> Избройте инструкциите за такт (IPC) за всеки размер на набора от данни и вашия
модел и скорост на процесора. Въз основа на резултатите, какво можете да кажете за
наказанията за пропуски на L1, L2 и L3 на вашия процесор? Обяснете вашите наблюдения.
° С. [20] <2.6> Стартирайте програмата във VTune с размер на входния набор от данни
от 8 KB и 128 KB на процесор Intel OOO. Посочете броя на пропуските на L1 кеш
данни и L2 кеш за 1K инструкции и CPI за двете конфигурации. Какво можете да
кажете за ефективността на техниките за скриване на латентността на паметта във
високопроизводителните OOO процесори? Подсказка: Трябва да намерите L1
латентността на кеша за данни за вашия процесор. За последните процесори Intel
i7 това е приблизително 11 цикъла.

3.1 Паралелизъм на ниво инструкция: Концепции и предизвикателства 148
3.2 Основни техники на компилатор за разкриване на ILP 156
3.3 Намаляване на разходите на клонове с разширено прогнозиране на клонове 162
3.4 Преодоляване на опасностите за данните с динамично планиране 167
3.5 Динамично планиране: примери и алгоритъм 176
3.6 Хардуерно базирани спекулации 183
3.7 Използване на ILP с помощта на множество проблеми и статично планиране 192
3.8 Използване на ILP чрез динамично планиране,

Множество проблеми и спекулации 197
3.9 Усъвършенствани техники за доставка на инструкции и спекулации 202
3.10 Проучвания на ограниченията на ILP 213
3.11 Междусекторни въпроси: подходи към ILP и системата за памет 221
3.12 Многопоточност: Използване на паралелизъм на ниво нишка за

Подобрете пропускателната способност на еднопроцесорния процесор
223
3.13 Събирайки всичко заедно: Intel Core i7 и ARM Cortex-A8 233
3.15 Заключителни бележки: Какво предстои? 245
3.16 Историческа перспектива и препратки Казуси 247
и упражнения от Джейсън Д. Бакос и Робърт П. Колуел 247

3
Ниво на инструкция
Паралелизъм и неговите
Експлоатация 1
„Кой е първи?“
"Америка."
„Кой е вторият?“
"Сър, няма втори."
Диалог между двама наблюдатели на
състезанието по ветроходство,
наречено по-късно „Купата на
Америка“ и провеждащо
се на всеки няколко години –
вдъхновението за именуването на
Джон Коке на изследователския
процесор на IBM като „Америка“. Този

процесор беше предшественик на
серията RS/6000 и първият суперскаларен микропроцесор.
Компютърна архитектура. DOI: 10.1016/B978-0-12-383872-8.00004-5 ©

2012 Elsevier, Inc. Всички права запазени.
148 Трета глава Паралелизъм на ниво инструкция и неговото използване
3.1 Паралелизъм на ниво инструкция: Концепции и предизвикателства
Всички процесори от около 1985 г. използват конвейерна обработка за припокриване на изпълнението на

инструкции и подобряване на производителността. Това потенциално припокриване между инструкциите
се нарича паралелизъм на ниво инструкция (ILP), тъй като инструкциите могат да бъдат оценени
паралелно. В тази глава и Приложение H разглеждаме широка гама от техники за разширяване на
основните концепции за тръбопроводи чрез увеличаване на количеството на
използван паралелизъм сред инструкциите.
Тази глава е на значително по-напреднало ниво от основния материал
конвейерна обработка в Приложение C. Ако не сте напълно запознати с идеите в
Приложение C, трябва да прегледате това приложение, преди да се впуснете в тази глава.
Започваме тази глава, като разгледаме ограничението, наложено от данните и контрола
опасности и след това се обърнете към темата за увеличаване на способността на компилатора и
процесор за използване на паралелизма. Тези раздели въвеждат голям брой понятия, върху които
надграждаме в тази и следващата глава. Докато някои от
по-основният материал в тази глава може да бъде разбран без всички идеи в нея
първите два раздела, този основен материал е важен за следващите раздели на това
глава.
Има два до голяма степен отделими подхода за използване на ILP: (1) подход
който разчита на хардуер, за да помогне за откриването и динамичното използване на паралелизма,
и (2) подход, който разчита на софтуерна технология за намиране на паралелизъм статически по време
на компилиране. Процесори, използващи динамичен, хардуерен подход,
включително серията Intel Core, доминират на пазарите за настолни компютри и сървъри. В
пазар на персонални мобилни устройства, където енергийната ефективност често е ключова цел,
дизайнерите използват по-ниски нива на паралелизъм на ниво инструкции. Така през 2011 г. повечето
процесорите за PMD пазара използват статични подходи, както ще видим в ARM
Cortex-A8; обаче бъдещите процесори (напр. новият ARM Cortex-A9) използват
динамични подходи. Опитани са агресивни подходи, базирани на компилатор
много пъти, започвайки през 80-те години на миналия век и най-скоро в Intel Itanium
серия. Въпреки огромните усилия, подобни подходи не са били успешни извън тесния кръг от научни
приложения.
През последните няколко години много от техниките са разработени за един подход
са били използвани в рамките на дизайн, разчитащ предимно на другия. Тази глава
въвежда основните понятия и двата подхода. Обсъждането на ограниченията на подходите на ILP е
включено в тази глава и именно такива ограничения
което директно доведе до движението към многоядрени. Разбиране на ограниченията
остава важен за балансирането на използването на ILP и паралелизъм на ниво нишка.
В този раздел обсъждаме характеристиките както на програмите, така и на процесорите, които ограничават
степента на паралелизъм, който може да се използва сред инструкциите, както и

критично съпоставяне между програмната структура и хардуерната структура, което е ключово
за разбиране дали дадено свойство на програмата действително ще ограничи производителността и
при какви обстоятелства.
Стойността на CPI (цикли на инструкция) за конвейерен процесор е

сбор от базовия CPI и всички вноски от сергиите:
= +
CPI на тръбопровода Идеален CPI на тръбопровода +
Структурни блокировки Опасност от данни + Контролни сергии
Техника Намалява Раздел
Препращане и байпас Потенциална опасност от данни спира В.2
Забавени разклонения и опростено планиране на разклонения Контролирайте опасността от спирания В.2
Основно планиране на конвейера на компилатора Опасността от данни спира В.2, 3.2
Основно динамично планиране (табло с резултати) Опасността от данни спира от истинските зависимости C.7
Развиване на примка Контролирайте опасността 3.2
Прогноза за разклонения Контролни сергии 3.3
Динамично планиране с преименуване Сергии от опасности за данни, изходни зависимости и 3.4
антизависимости
Хардуерни спекулации Опасност от данни и опасност от управление спира 3.6
Динамично разграничаване на паметта Опасността от данни спира с паметта 3.6
Издаване на множество инструкции на цикъл Идеален CPI 3.7, 3.8
Анализ на зависимостта на компилатора, конвейер Идеален CPI, опасност от данни спира З.2, З.3
на софтуера, планиране на трасиране
Хардуерна поддръжка за компилаторни спекулации Идеален CPI, опасност от данни спира, опасност от клон се спира З.4, З.5
Фигура 3.1 Основните техники, разгледани в Приложение C, Глава 3 и Приложение H, са показани заедно с
компонентът на уравнението на CPI, върху който техниката влияе.
Идеалният CPI на тръбопровода е мярка за максималната производителност, постижима от

прилагането. Чрез намаляване на всеки от членовете на дясната страна, ние
намалете общия CPI на тръбопровода или, алтернативно, увеличете IPC (инструкции
на часовник). Уравнението по-горе ни позволява да характеризираме различни техники чрез
какъв компонент от общия CPI намалява дадена техника. Фигура 3.1 показва
техники, които разглеждаме в тази глава и в Приложение H, както и темите
обхванати в уводния материал в Приложение C. В тази глава ще видим
че техниките, които въвеждаме за намаляване на идеалния CPI на тръбопровода, могат да се увеличат
значението на справянето с опасностите.
Какво е паралелизъм на ниво инструкция?
Всички техники в тази глава използват паралелизма между инструкциите. The

количество паралелизъм, наличен в рамките на основен блок - праволинеен код
последователност без разклонения навътре освен към входа и без разклонения навън освен при
изход - е доста малък. За типичните MIPS програми, средната динамична честота на разклоняване
често е между 15% и 25%, което означава, че между три и шест инструкции се изпълняват между
двойка разклонения. Тъй като тези инструкции вероятно ще
зависят един от друг, количеството припокриване, което можем да използваме в рамките на основния
блокът вероятно ще бъде по-малък от средния основен размер на блока. За получаване на значителни
подобрения на производителността, трябва да използваме ILP в множество основни блокове.
Най-простият и най-разпространеният начин за увеличаване на ILP е да се използва паралелността
между итерациите на цикъл. Този тип паралелизъм често се нарича ниво на цикъл
паралелизъм. Ето прост пример за цикъл, който добавя два 1000 елемента
масиви и е напълно успореден:
за (i=0; i<=999; i=i+1) x[i] = x[i] + y[i];
Всяка итерация на цикъла може да се припокрива с всяка друга итерация, въпреки че в рамките на
всяка итерация на цикъла има малка или никаква възможност за припокриване.
Ще разгледаме редица техники за преобразуване на такъв паралелизъм на ниво цикъл в
паралелизъм на ниво инструкция. По принцип такива техники работят чрез разгръщане на цикъла
или статично от компилатора (както в следващия раздел), или динамично от хардуера (както в раздели
3.5 и 3.6).
Важен алтернативен метод за използване на паралелизъм на ниво цикъл е използването на
SIMD както във векторни процесори, така и в графични процесори (GPU), като и двата са обхванати в
глава 4. Инструкцията SIMD използва паралелизъм на ниво данни, като работи върху малък до умерен
брой елементи от данни в паралел (обикновено два до осем). Векторната инструкция използва
паралелизма на ниво данни, като работи с много елементи от данни паралелно, като използва както
паралелни изпълнителни единици, така и дълбок конвейер. Например горната кодова
последователност, която в проста форма изисква седем инструкции на итерация (две зареждания,
добавяне, съхраняване, две актуализации на адреси и разклоняване) за общо 7000 инструкции, може
да се изпълни за една четвърт толкова много инструкции в някои SIMD архитектури, където четири
елемента данни се обработват на инструкция. При някои векторни процесори тази последователност
може да отнеме само четири инструкции: две инструкции за зареждане на векторите x и y от паметта,
една инструкция за добавяне на двата вектора и инструкция за съхраняване обратно на резултатния
вектор. Разбира се, тези инструкции ще бъдат конвейерни и ще имат относително дълги закъснения,
но тези закъснения може да се припокриват.
Зависимости от данни и опасности
Определянето как една инструкция зависи от друга е от решаващо значение за определяне колко
паралелизъм съществува в една програма и как този паралелизъм може да бъде използван. По-
специално, за да използваме паралелизма на ниво инструкция, трябва да определим кои инструкции
могат да се изпълняват паралелно. Ако две инструкции са паралелни, те могат да се изпълняват
едновременно в конвейер с произволна дълбочина, без да причиняват спирания, ако приемем, че
конвейерът разполага с достатъчно ресурси (и следователно не съществуват структурни опасности).
Ако две инструкции са зависими, те не са успоредни и трябва да се изпълняват в ред, въпреки че
често могат да бъдат частично припокриващи се. Ключът и в двата случая е да се определи дали
дадена инструкция зависи от друга инструкция.
Зависимости от данни
Има три различни типа зависимости: зависимости от данни (наричани още истински зависимости от
данни), зависимости от име и зависимости от управление. Инструкция j е данни, зависими от
инструкция i , ако е валидно някое от следните:
Инструкция i произвежда резултат, който може да се използва от инструкция j.
Инструкция j е данни, зависими от инструкция k, а инструкция k е данни

в зависимост от инструкцията i.
Второто условие просто гласи, че една инструкция зависи от друга if

между двете инструкции съществува верига от зависимости от първи тип.
Тази верига на зависимост може да бъде толкова дълга, колкото цялата програма. Имайте
предвид, че зависимост в рамките на една инструкция (като ADDD R1,R1,R1) не се счита за
зависимост.
Например, разгледайте следната MIPS кодова последователност, която увеличава a
вектор от стойности в паметта (започвайки от 0(R1) и с последния елемент от 8(R2))
чрез скалар в регистър F2. (За простота, в тази глава нашите примери
игнорирайте ефектите от забавените разклонения.)
цикъл: LD F0,0(R1) ;F0=елемент от масив

ADD.D F4,F0,F2 ;добавяне на скалар във F2
SD F4,0(R1);запаметяване на резултата
DADDUI R1,R1,#-8 ;указател за намаляване на 8 байта R1,R2,LOOP ;клон

BNE R1!=R2
Зависимостите на данните в тази кодова последователност включват както данни с плаваща запетая:
ДОБАВЯНЕ F4,F0,F2 ;добавете скалар във F2
SD F4,0(R1) ;запазете резултата
и цели данни:
DADDIU R1,R1,#-8 ;указател за намаляване ;8 байта (на
DW)
BNE R1,R2,Кръг ;клон R1!=R2
И в двете горни зависими последователности, както е показано със стрелките, всяка инструкция
зависи от предходната. Стрелките тук и в следващите примери
покажете реда, който трябва да се запази за правилно изпълнение. Стрелката сочи
от инструкция, която трябва да предшества инструкцията, към която сочи стрелката.
Ако две инструкции са зависими от данни, те трябва да се изпълнят в ред и не могат
да се изпълняват едновременно или да се припокриват напълно. Зависимостта предполага
че ще има верига от една или повече опасности за данни между двете
инструкции. (Вижте Приложение C за кратко описание на опасностите за данните, които ние

ще определи точно в няколко страници.) Изпълнение на инструкциите едновременно
ще доведе до процесор с блокировки на тръбопровода (и дълбочина на тръбопровода, по-голяма от
разстоянието между инструкциите в цикли) за откриване на опасност и спиране,
като по този начин се намалява или елиминира припокриването. В процесор без блокировки това
разчита на планиране на компилатора, компилаторът не може да планира зависими инструкции
по такъв начин, че те напълно да се припокриват, тъй като програмата няма да се изпълни
правилно. Наличие на зависимост от данни в последователност от инструкции
отразява зависимостта на данните в изходния код, от който идва последователността от инструкции
е генериран. Ефектът от първоначалната зависимост от данни трябва да бъде запазен.
Зависимостите са свойство на програмите. Дали дадена зависимост

води до откриване на действителна опасност и дали тази опасност действително причинява
сергия са свойства на тръбопроводната организация. Тази разлика е критична за
разбиране как може да се използва паралелизмът на ниво инструкция.
Зависимостта от данни предава три неща: (1) възможността за опасност, (2)
ред, в който резултатите трябва да бъдат изчислени, и (3) горна граница за това колко
евентуално може да се използва паралелизъм. Такива ограничения са разгледани в раздел 3.10 и
в Приложение H по-подробно.
Тъй като зависимостта от данни може да ограничи размера на паралелизма на ниво инструкция
можем да използваме, основен фокус на тази глава е преодоляването на тези ограничения.
Зависимостта може да бъде преодоляна по два различни начина: (1) поддържане на зависимостта,
но избягване на опасност, и (2) елиминиране на зависимост чрез трансформиране
кодът. Планирането на кода е основният метод, използван за избягване на опасност без промяна
на зависимост, и такова планиране може да се направи както от компилатора
и от хардуера.
Стойност на данните може да тече между инструкции или чрез регистри, или
чрез места в паметта. Когато потокът от данни се появи в регистър, откриването на
зависимостта е ясна, тъй като имената на регистрите са фиксирани в инструкциите, въпреки че
става по-сложно, когато се намесят клонове и опасенията за коректност принуждават компилатора
или хардуера да бъдат консервативни.
Зависимостите, които протичат през места в паметта, са по-трудни за откриване,
тъй като два адреса може да се отнасят за едно и също местоположение, но да изглеждат различно:
Например 100(R4) и 20(R6) може да са идентични адреси на паметта. В допълнение, на
ефективният адрес на зареждане или съхраняване може да се промени от едно изпълнение на
инструкцията към друго (така че 20(R4) и 20(R4) може да са различни), което допълнително усложнява
откриването на зависимост.
В тази глава разглеждаме хардуера за откриване на зависимости на данни, които
включват местоположения в паметта, но ще видим, че тези техники също имат ограничения.
Техниките на компилатора за откриване на такива зависимости са от решаващо значение
разкриване на паралелизъм на ниво цикъл.
Зависимости от имена
Вторият тип зависимост е зависимост от име. Зависимост от името

възниква, когато две инструкции използват един и същ регистър или място в паметта, наречено a
име, но няма поток от данни между инструкциите, свързани с това
име. Има два типа зависимости на името между една инструкция и това
предшества инструкция j в програмен ред:
1. Антизависимост между инструкция i и инструкция j възниква, когато

инструкция j записва регистър или място в паметта, която инструкцията i чете. The
оригиналната поръчка трябва да се запази, за да се гарантира, че чета правилната стойност. в
в примера на страница 151 има антизависимост между SD и
DADDIU в регистър R1.
2. Изходна зависимост възниква, когато инструкция i и инструкция j записват

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

инструкция j.
Както антизависимостите, така и зависимостите на изхода са зависимости от имена, като
за разлика от истинските зависимости на данните, тъй като няма предавана стойност
между инструкциите. Тъй като зависимостта от името не е истинска зависимост,
инструкциите, включени в зависимост от име, могат да се изпълняват едновременно или да бъдат
се пренарежда, ако името (регистров номер или място в паметта), използвано в инструкциите, се промени,
така че инструкциите да не са в конфликт.
Това преименуване може да се направи по-лесно за регистърни операнди, където е
наречено преименуване на регистър. Преименуването на регистър може да се извърши или статично чрез a
компилатор или динамично от хардуера. Преди да опишем възникващите зависимости
от клонове, нека разгледаме връзката между зависимостите и тръбопровода

опасности за данните.
Опасности за данни
Опасност съществува винаги, когато има зависимост между име или данни
инструкции и те са достатъчно близки, за да може припокриването по време на изпълнение
промяна на реда на достъп до операнда, включен в зависимостта. Защото
зависимостта, ние трябва да запазим това, което се нарича програмен ред - т.е
ред, в който инструкциите ще се изпълняват, ако се изпълняват последователно една по една
както е определено от оригиналната програма с изходен код. Целта както на нашия софтуер, така и на
хардуерните техники е да се използва паралелизма чрез запазване само на програмния ред
където се отразява на резултата от програмата. Откриване и избягване на опасности
гарантира запазването на необходимия програмен ред.
Опасностите за данни, които са неофициално описани в Приложение C, могат да бъдат класифицирани
като един от трите типа в зависимост от реда на достъпите за четене и запис в
инструкциите. По конвенция опасностите се наименуват според подредбата в програмата, която трябва да
бъде запазена от тръбопровода. Разгледайте две инструкции i и j,
с i предшестващо j в програмния ред. Възможните опасности за данните са
RAW (четене след запис)—j се опитва да прочете източник, преди i да го запише, така че j неправилно
получава старата стойност. Тази опасност е най-често срещаният вид и съответства на истинска
зависимост от данни. Програмният ред трябва да се запази, за да се гарантира

че j получава стойността от i.
WAW (запис след запис)—j се опитва да запише операнд, преди да бъде записан от i.
Записите в крайна сметка се извършват в грешен ред, оставяйки стойността, записана от i , вместо
стойността, записана от j в дестинацията. Тази опасност съответства на зависимост на продукцията.
Опасностите от WAW съществуват само в тръбопроводите
които пишат в повече от един етап на канал или позволяват на инструкция да продължи дори
когато предишна инструкция е спряна.
WAR (запис след четене)—j се опитва да запише дестинация, преди да бъде прочетена от i, така че i
неправилно получава новата стойност. Тази опасност възниква от антизависимост (или
зависимост от името). Опасностите от WAR не могат да възникнат в повечето статични тръбопроводи за проблеми—
още по-дълбоки тръбопроводи или тръбопроводи с плаваща запетая - защото всички четения са ранни
154 Трета глава Паралелизъм на ниво инструкции и неговото използване
(в ID в конвейера в Приложение C) и всички записи са закъснели (в WB в конвейера в

Приложение C). Опасност от ВОЙНА възниква или когато има някои инструкции, които
записват резултати рано в конвейера на инструкции и други инструкции
които четат източник късно в тръбопровода или когато инструкциите са пренаредени, както ние
ще видите в тази глава.
Обърнете внимание, че случайът RAR (четене след четене) не е опасен.
Контролни зависимости
Последният тип зависимост е контролна зависимост. Контролна зависимост

определя подреждането на инструкция, i, по отношение на инструкция за разклоняване
така че инструкцията i се изпълнява в правилния програмен ред и само когато трябва
бъда. Всяка инструкция, с изключение на тези в първия основен блок на програмата, е
управление, зависимо от някакъв набор от разклонения, и като цяло тези контролни
зависимости трябва да бъдат запазени, за да се запази програмният ред. Един от най-простите
примери за контролна зависимост е зависимостта на твърденията в „тогава“
част от оператор if на клона. Например в кодовия сегмент
if p1 {
S1;
};
if p2 {
S2;
}
S1 е контрол, зависим от p1, а S2 е контрол, зависим от p2, но не и от p1.

Като цяло, две ограничения се налагат от контролните зависимости:
1. Инструкция, която е контролно зависима от клон, не може да бъде преместена преди това
клона, така че неговото изпълнение вече не се контролира от клона. За
Например, не можем да вземем инструкция от then частта на оператор if и да я преместим
преди оператора if.
2. Инструкция, която не е контролно зависима от клон, не може да бъде преместена

след клона, така че изпълнението му да се контролира от клона. Например, не можем да
вземем оператор преди оператора if и да го преместим в
след това порция.
Когато процесорите поддържат строг програмен ред, те гарантират този контрол

зависимостите също се запазват. Може да сме готови да изпълним инструкции, които
не трябва да се изпълнява обаче, като по този начин се нарушават контролните зависимости,
ако можем да го направим, без да се засяга коректността на програмата. По този начин,
контролната зависимост не е критичното свойство, което трябва да се запази. Вместо,
двете свойства, критични за коректността на програмата - и обикновено се запазват от
поддържане както на данни, така и на контролни зависимости - са поведението на изключение
и потока от данни.
Запазването на поведението на изключението означава, че всички промени в подреждането на
изпълнението на инструкциите не трябва да променя начина, по който се предизвикват изключения в програмата.
Често това се облекчава, за да означава, че пренареждането на изпълнението на инструкциите не трябва

предизвика нови изключения в програмата. Прост пример показва как поддържането на контрола и
зависимостите от данни може да предотврати подобни ситуации. Обмисли
тази кодова последователност:
ДАДДУ R2, R3, R4

BEQZ R2, L1
LW R1,0(R2)
L1:
В този случай е лесно да се види, че ако не поддържаме зависимостта на данните

включвайки R2, можем да променим резултата от програмата. По-малко очевиден е фактът
че ако пренебрегнем контролната зависимост и преместим инструкцията за зареждане преди
клон, инструкцията за зареждане може да причини изключение за защита на паметта. Забележете
че никаква зависимост от данни не ни пречи да обменяме BEQZ и LW; то е
само контролната зависимост. За да ни позволите да пренаредим тези инструкции (и все още
запазване на зависимостта от данни), бихме искали просто да игнорираме изключението, когато
клонът е взет. В раздел 3.6 ще разгледаме хардуерна техника, спекулация, която ни позволява да
преодолеем този проблем с изключение. Приложение H разглежда
софтуерни техники за подпомагане на спекулации.
Второто свойство, запазено чрез поддържане на зависимости от данни и контролни зависимости,
е потокът от данни. Потокът от данни е действителният поток от стойности на данни
между инструкциите, които произвеждат резултати и тези, които ги консумират. Клонове
правят потока от данни динамичен, тъй като позволяват източника на данни за дадено
инструкцията да идва от много точки. Казано по друг начин, не е достатъчно просто
поддържайте зависимости от данни, тъй като дадена инструкция може да зависи от данни
повече от един предшественик. Програмният ред е това, което определя кой предшественик
всъщност ще достави стойност на данни към инструкция. Редът на програмата се осигурява от
поддържане на контролните зависимости.
Например, разгледайте следния кодов фрагмент:

BEQZ R4,L
ДСУБУ R1, R5, R6
Л: ...
ИЛИ R7, R1, R8
В този пример стойността на R1, използвана от инструкцията ИЛИ, зависи от това дали
клонът е взет или не. Само зависимостта от данни не е достатъчна за запазване
коректност. Инструкцията OR е данни, зависими както от DADDU, така и от
DSUBU инструкции, но само запазването на този ред е недостатъчно за правилно
екзекуция.
Вместо това, когато инструкциите се изпълняват, потокът от данни трябва да се запази: Ако
клонът не е взет, тогава стойността на R1, изчислена от DSUBU, трябва да бъде
използвана от OR, и, ако се вземе разклонението, стойността на R1, изчислена от
DADDU трябва да се използва от ИЛИ. При запазване на контролната зависимост на ОР
на клона, предотвратяваме незаконна промяна на потока от данни. По подобни причини,
инструкцията DSUBU не може да бъде преместена над клона. Спекулации, които
помага при проблема с изключенията, също така ще ни позволи да намалим въздействието на
контролна зависимост, като същевременно поддържа потока от данни, както ще видим в

Раздел 3.6.
Понякога можем да определим, че нарушаването на контролната зависимост не може
засягат или поведението на изключението, или потока от данни. Разгледайте следния код
последователност:
BEQZ R12, пропуснете
ДСУБУ R4, R5, R6

пропуснете: ИЛИ R7, R8, R9
Да предположим, че знаем, че местоназначението на регистъра на инструкцията DSUBU (R4) е
неизползван след инструкцията с етикет пропускане. (Свойството дали дадена стойност ще
да се използва от предстояща инструкция се нарича живост.) Ако R4 не е бил използван, тогава
промяната на стойността на R4 точно преди разклонението няма да повлияе на потока от данни
тъй като R4 ще бъде мъртъв (а не жив) в областта на кода след пропускане. По този начин, ако
R4 бяха мъртви и съществуващата DSUBU инструкция не можа да генерира изключение
(различни от тези, от които процесорът възобновява същия процес), бихме могли

преместете инструкцията DSUBU преди разклонението, тъй като потокът от данни не може да бъде
засегнати от тази промяна.

Ако разклонението бъде взето, инструкцията DSUBU ще се изпълни и ще бъде безполезна, но няма да
повлияе на резултатите от програмата. Този тип планиране на код е
също форма на спекулация, често наричана софтуерна спекулация, тъй като компилаторът залага на
резултата от разклонението; в този случай залогът е, че клонът е
обикновено не се приема. По-амбициозни механизми за спекулации на компилатора са
обсъдено в Приложение H. Обикновено ще бъде ясно, когато кажем спекулация
или спекулативно дали механизмът е хардуерен или софтуерен механизъм;
когато не е ясно, най-добре е да кажете „хардуерни спекулации“ или „софтуер“.
спекулации.”
Зависимостта от управление се запазва чрез прилагане на откриване на опасност от управление
което води до спиране на управлението. Контролните сергии могат да бъдат елиминирани или намалени чрез разнообразие
на хардуерни и софтуерни техники, които разглеждаме в раздел 3.3.
3.2 Основни техники на компилатор за разкриване на ILP
Този раздел разглежда използването на проста технология на компилатор за подобряване на способността
на процесора да използва ILP. Тези техники са от решаващо значение за процесорите, които
използвайте статичен проблем или статично планиране. Въоръжени с тази технология за компилиране, ние
скоро ще разгледа дизайна и производителността на процесори, използващи статично издаване.
Приложение H ще изследва по-сложен компилатор и свързаните с него
хардуерни схеми, предназначени да позволят на процесора да използва повече паралелизъм на ниво
3.2 Основни компилаторни техники за разкриване на ILP 157
Основно планиране на тръбопровода и разгръщане на цикъл
За да се поддържа конвейерът пълен, трябва да се използва паралелизмът между инструкциите

намиране на последователности от несвързани инструкции, които могат да се припокриват в
конвейера. За да се избегне спиране на конвейера, изпълнението на зависима инструкция трябва да бъде
разделени от изходната инструкция на разстояние в тактови цикли, равно на
латентност на конвейера на тази инструкция източник. Способността на компилатора да извърши това
планирането зависи както от количеството ILP, налично в програмата, така и от
закъсненията на функционалните единици в тръбопровода. Фигура 3.2 показва FP
латентности на единици, които приемаме в тази глава, освен ако изрично не са посочени различни латентности
заяви. Приемаме стандартния петстепенен конвейер с цели числа, така че се разклонява

имат закъснение от един тактов цикъл. Приемаме, че функционалните единици са напълно завършени
конвейерно или репликирано (толкова пъти, колкото е дълбочината на конвейера), така че операция
от всякакъв тип да може да бъде изпълнена на всеки такт и няма структурни
опасности.
В този подраздел разглеждаме как компилаторът може да увеличи сумата

на наличния ILP чрез трансформиране на цикли. Този пример служи както за илюстрация
важна техника, както и за мотивиране на по-мощната програма
трансформации, описани в Приложение H. Ще разчитаме на следния код
сегмент, който добавя скалар към вектор:
за (i=999; i>=0; i=i–1)

x[i] = x[i] + s;
Можем да видим, че този цикъл е паралелен, като забележим, че тялото на всяка итерация е такова
независима. Формализираме това понятие в Приложение H и описваме как можем
тествайте дали итерациите на цикъла са независими по време на компилиране. Първо, нека да разгледаме
производителността на този цикъл, показвайки как можем да използваме паралелизма за подобряване
неговата производителност за MIPS тръбопровод с показаните по-горе закъснения.
Първата стъпка е да преведете горния сегмент на MIPS асемблер.
В следващия кодов сегмент R1 първоначално е адресът на елемента в
масив с най-висок адрес, а F2 съдържа скаларната стойност s. Регистър R2 е
предварително изчислен, така че 8(R2) е адресът на последния елемент, върху който да се работи.
Инструкцията дава резултат Инструкция за използване на резултата Закъснение в тактови цикли
FP ALU оп Друг FP ALU оп 3
FP ALU оп Съхранявайте двойно 2
Заредете двойно FP ALU оп 1
Заредете двойно Съхранявайте двойно 0
Фигура 3.2 Закъснения на FP операции, използвани в тази глава. Последната колона е

брой междинни тактови цикли, необходими за избягване на спиране. Тези числа са подобни
към средните закъснения, които бихме видели на FP устройство. Закъснението на плаваща запетая
load to a store е 0, тъй като резултатът от натоварването може да бъде прескочен без спиране на
магазин. Ще продължим да приемаме цяло число закъснение при зареждане от 1 и цяло число закъснение на
операцията на ALU от 0.
Опростеният MIPS код, който не е планиран за тръбопровода, изглежда така

това:

ADD.D F4, F0, F2 ;добавете скалар във F2
SD F4,0(R1) ;запазете резултата
DADDUI R1,R1,#-8 ;указател за намаляване
;8 байта (на DW)
BNE R1, R2, цикъл ;клон R1!=R2
Нека започнем, като видим колко добре ще работи този цикъл, когато е планиран на a
прост тръбопровод за MIPS със закъсненията от Фигура 3.2.
Пример Покажете как ще изглежда цикълът на MIPS, както планиран, така и непланиран,
включително всякакви застой или неактивни часовникови цикли. График за закъснения от плаваща запетая
операции, но не забравяйте, че игнорираме забавени разклонения.
Отговор Без никакво планиране, цикълът ще се изпълни както следва, като ще отнеме девет цикъла:
Издаден часовников цикъл
цикъл: LD F0,0(R1) 1
сергия 2
ADD.D F4, F0, F2 3
сергия 4
сергия 5
SD F4,0(R1) 6
DADDUI R1,R1,#-8 7
сергия 8
BNE R1, R2, цикъл 9
Можем да планираме цикъла, за да получим само две сергии и да намалим времето до седем
цикли:
Цикъл: LD F0,0(R1)
DADDUI R1,R1,#-8
ДОБАВЯНЕ F4,F0,F2
сергия
сергия
SD F4,8(R1)
BNE R1, R2, цикъл
Сергиите след ADD.D са за използване от SD
В предишния пример завършваме една итерация на цикъл и съхраняваме обратно една

елемент от масив на всеки седем такта, но действителната работа на работата на
array element отнема само три (зареждането, добавянето и съхраняването) от тези седем часовника
3.2 Основни техники на компилатор за излагане на ILP 159
цикли. Останалите четири тактови цикъла се състоят от режийни цикли - DADDUI

и BNE—и две сергии. За да елиминираме тези четири тактови цикъла, които трябва да получим
повече операции спрямо броя на инструкциите за режийни разходи.
Проста схема за увеличаване на броя на инструкциите спрямо
инструкциите за клон и режийни са разгръщане на цикъл. Развиването просто се репликира
тялото на цикъла няколко пъти, коригирайки кода за прекратяване на цикъла.
Развиването на цикъла може също да се използва за подобряване на планирането. Защото елиминира
клона, позволява да се планират инструкции от различни итерации
заедно. В този случай можем да елиминираме сергиите за използване на данни, като създадем допълнителни
независими инструкции в тялото на цикъла. Ако просто възпроизведем

инструкции, когато развихме цикъла, произтичащото използване на същите регистри
може да ни попречи да планираме ефективно цикъла. По този начин ще искаме да използваме
различни регистри за всяка итерация, увеличавайки необходимия брой регистри.
Пример. Покажете нашия цикъл разгънат, така че да има четири копия на тялото на цикъла, ако приемем
R1 – R2 (т.е. размерът на масива) първоначално е кратно на 32, което означава
че броят на повторенията на цикъла е кратен на 4. Елиминирайте всички очевидно
излишни изчисления и не използвайте повторно нито един от регистрите.
Отговор Ето резултата след обединяването на инструкциите DADDUI и премахването на ненужните BNE
операции, които се дублират по време на разгръщане. Имайте предвид, че R2 трябва сега
бъде зададен така, че 32(R2) да е началният адрес на последните четири елемента.
цикъл: LD F0,0(R1)
ADD.D F4, F0, F2
SD F4,0(R1) ;пуснете DADDUI & BNE
LD F6,-8(R1)
ADD.D F8, F6, F2
SD F8,-8(R1) ;пуснете DADDUI & BNE
LD F10,-16(R1)
ADD.D F12, F10, F2
SD F12,-16(R1) ;пуснете DADDUI & BNE
LD F14,-24(R1)
ADD.D F16, F14, F2
SD F16,-24(R1)
DADDUI R1,R1,#-32
Премахнахме три разклонения и три декремента на R1. Адресите на

товарите и магазините са компенсирани, за да позволят инструкциите на DADDUI
R1 да бъде обединен. Тази оптимизация може да изглежда тривиална, но не е; то изисква
символично заместване и опростяване. Символно заместване и опростяване
ще пренареди изразите така, че да позволи свиването на константите, позволявайки an
израз като ((i + 1) + 1) да бъде пренаписан като (i + (1 + 1)) и след това опростен
до (i + 2). Ще видим по-общи форми на тези оптимизации, които елиминират
зависими изчисления в Приложение H.
Без планиране всяка операция в разгънатия цикъл е последвана от a

зависима работа и по този начин ще предизвика спиране. Този цикъл ще работи за 27 часовника
цикли—всеки LD има 1 срив, всеки ADDD 2, DADDUI 1, плюс 14 издаване на инструкции
цикъла—или 6,75 тактови цикъла за всеки от четирите елемента, но може да бъде планирано за
значително подобряване на производителността. Развиването на цикъла обикновено се извършва рано
в процеса на компилиране, така че излишните изчисления да могат да бъдат изложени и
елиминиран от оптимизатора.
В реалните програми обикновено не знаем горната граница на цикъла. Да предположим,

че е n и бихме искали да развием цикъла, за да направим k копия на тялото.
Вместо единична разгъната примка, ние генерираме двойка последователни примки. The
първо изпълнява (n mod k) пъти и има тяло, което е оригиналният цикъл. Секундата
е разточеното тяло, заобиколено от външен цикъл, който повтаря (n/k) пъти. (Тъй като ние
ще видите в Глава 4, тази техника е подобна на техника, наречена ивичен добив,
използвани в компилатори за векторни процесори.) За големи стойности на n по-голямата част от времето
за изпълнение ще бъде прекарано в тялото на разгънатия цикъл.
В предишния пример разгръщането подобрява производителността на този цикъл с

елиминиране на режийни инструкции, въпреки че увеличава значително размера на кода.
Как ще работи разгънатият цикъл, когато е планиран за тръбопровода
описано по-рано?
Пример Показване на разгънатия цикъл в предишния пример, след като е планиран за него
тръбопровода със закъсненията от Фигура 3.2.
Цикъл за отговор : LD F0,0(R1)

LD F6,-8(R1)
LD F10,-16(R1)
LD F14,-24(R1)
ADD.D F4, F0, F2
ADD.D F8, F6, F2
ADD.D F12, F10, F2
ADD.D F16, F14, F2
SD F4,0(R1)
SD F8,-8(R1)
DADDUI R1,R1,#-32
SD F12,16(R1)
SD F16,8(R1)
Времето за изпълнение на разгънатия цикъл е спаднало до общо 14 тактови цикъла,

или 3,5 тактови цикъла на елемент, в сравнение с 9 цикъла на елемент преди всеки
развиване или планиране и 7 цикъла, когато са планирани, но не са развити.
Печалбата от планирането на разгънатия цикъл е дори по-голяма, отколкото в оригиналния

цикъл. Това увеличение възниква, защото разгръщането на цикъла излага повече изчисления
3.2 Основни техники на компилатор за разкриване на ILP 161
които могат да бъдат планирани за минимизиране на сергиите; кодът по-горе няма сергии.
Планирането на цикъла по този начин налага осъзнаването, че товарите и магазините са независими

и могат да се разменят.
Обобщение на разгръщането и планирането на цикъла
В тази глава и Приложение H ще разгледаме разнообразие от хардуер

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

итерациите бяха независими, с изключение на кода за поддръжка на цикъла.
Използвайте различни регистри, за да избегнете ненужни ограничения, които биха били наложени
използване на едни и същи регистри за различни изчисления (напр. зависимости на имена).
Елиминирайте допълнителните инструкции за тестване и разклоняване и коригирайте кода за

прекратяване на цикъла и итерация.
Уверете се, че товарите и запасите в разгънатия контур могат да бъдат разменени

като се наблюдава, че зарежданията и запаметяванията от различни итерации са независими.
Тази трансформация изисква анализиране на адресите на паметта и установяване, че те не се
отнасят към един и същ адрес.
Планирайте кода, като запазите всички зависимости, необходими за получаването на същото

резултат като оригиналния код.
Ключовото изискване в основата на всички тези трансформации е разбирането

за това как една инструкция зависи от друга и какви могат да бъдат инструкциите
променени или пренаредени предвид зависимостите.
Три различни ефекта ограничават печалбите от разгръщането на цикъла: (1) намаляване на
сумата на режийните разходи, амортизирани с всяко развъртане, (2) ограничения за размера на кода,
и (3) ограничения на компилатора. Нека първо да разгледаме въпроса за цикъла.
Когато развихме цикъла четири пъти, той генерира достатъчен паралелизъм между
инструкциите, че цикълът може да бъде планиран без цикли на спиране. Всъщност в
14 тактови цикъла, само 2 цикъла бяха режийни: DADDUI, който поддържа
стойността на индекса и BNE, който прекратява цикъла. Ако примката се развие
осем пъти, режийните разходи се намаляват от 1/2 цикъл на оригинална итерация до 1/4.
Второ ограничение за разгръщането е увеличаването на размера на кода, което се получава. За по-големи
цикли, нарастването на размера на кода може да бъде проблем, особено ако причинява увеличение
в скоростта на пропуски в кеша на инструкциите.
Друг фактор, често по-важен от размера на кода, е потенциалният дефицит

регистри, които се създават чрез агресивно разгръщане и планиране. Това второстепенно
ефектът, който е резултат от планирането на инструкции в големи кодови сегменти, се нарича налягане
на регистъра. Това възниква, защото програмирането на код за увеличаване на ILP води до увеличаване
на броя на живите стойности. След агресивно планиране на инструкции може да не е възможно да се
разпределят всички живи стойности към регистрите. Трансформираният код, макар и теоретично по-
бърз, може да загуби част или цялото си предимство, защото генерира недостиг на регистри. Без
разгръщане, агресивното планиране е достатъчно ограничено от клонове, така че натискът върху
регистъра рядко е проблем. Комбинацията от разгръщане и агресивно планиране обаче може да
причини този проблем. Проблемът става особено предизвикателен при процесори с множество
издания, които изискват излагане на повече независими последователности от инструкции, чието
изпълнение може да се припокрива. Като цяло, използването на сложни трансформации на високо
ниво, чиито потенциални подобрения са трудни за измерване преди генерирането на подробен код,
доведе до значително увеличаване на сложността на съвременните компилатори.
Развиването на цикъл е прост, но полезен метод за увеличаване на размера на фрагменти с

праволинейни кодове, които могат да бъдат планирани ефективно. Тази трансформация е полезна в
различни процесори, от прости тръбопроводи като тези, които разгледахме досега, до многопроблемните
суперскалари и VLIW, разгледани по-късно в тази глава.
3.3 Намаляване на разходите на клонове с разширено прогнозиране

на клонове
Поради необходимостта от налагане на контролни зависимости чрез опасности от разклонения и

спирания, разклоненията ще навредят на производителността на тръбопровода. Развиването на
примката е един от начините за намаляване на броя на опасностите от разклонения; можем също така
да намалим загубите на производителност на клоновете, като предвидим как ще се държат. В
Приложение C разглеждаме прости предиктори на разклонения, които разчитат или на информация по
време на компилиране, или на наблюдаваното динамично поведение на разклонение в изолация. Тъй
като броят на инструкциите по време на полет се увеличи, значението на по-точното предсказване на
разклоненията нарасна. В този раздел разглеждаме техники за подобряване на точността на динамичното прогнозиране.
Корелиращи разклонителни предиктори
Схемите за 2-битови предиктори използват само скорошното поведение на един клон, за да предскажат
бъдещото поведение на този клон. Може да е възможно да подобрим точността на предсказването,
ако разгледаме и скорошното поведение на други клонове, а не само клона, който се опитваме да
предвидим. Помислете за малък кодов фрагмент от бенчмарка eqntott, член на ранните пакети за
бенчмаркове на SPEC, които показват особено лошо поведение при прогнозиране на разклонения:
ако (aa==2)
aa=0; ако
(bb==2) bb=0; if
(aa!=bb)
{
Ето MIPS кода, който обикновено генерираме за този кодов фрагмент-

като се приеме, че aa и bb са присвоени на регистри R1 и R2:
ДАДДИУ R3,R1,#–2
БНЕЗ R3, L1 ;клон b1 ;aa=0 (аа!=2)
ТАТО R1, R0, R0
L1: ДАДДИУ R3,R2,#–2
БНЕЗ R3, L2 ;клон b2 ;bb=0 (bb!=2)
ТАТО R2, R0, R0
L2: ДСУБУ R3, R1, R2 ;R3=aa-bb
BEQZ R3, L3 ;клон b3 (aa==bb)
Нека обозначим тези клонове с b1, b2 и b3. Ключовото наблюдение е, че поведението на клон
b3 е свързано с поведението на клонове b1 и b2. Очевидно, ако
клонове b1 и b2 не се вземат (т.е. ако и двете условия се оценяват като true
и на aa и bb са присвоени 0), тогава b3 ще бъде взето, тъй като aa и bb са
ясно равни. Предсказател, който използва само поведението на един клон за прогнозиране
резултатът от този клон никога не може да улови това поведение.
Предсказателите на клонове, които използват поведението на други клонове, за да
направят прогноза, се наричат корелиращи предиктори или предиктори на две нива.
Съществуващите корелиращи предиктори добавят информация за поведението на най-новите
клонове, за да решите как да предвидите даден клон. Например (1,2) предиктор използва
поведението на последния клон, за да избира измежду двойка 2-битови
предсказатели на клонове при прогнозиране на определен клон. В общия случай ан
(m,n) предикторът използва поведението на последните m клона, за да избира от 2m
предиктори на клонове, всеки от които е n-битов предиктор за един клон. The
привлекателността на този тип корелиращ предсказател на разклонения е, че може да дава по-високи резултати
скорости на прогнозиране от 2-битовата схема и изисква само тривиално количество

допълнителен хардуер.
Опростеността на хардуера идва от просто наблюдение: The

глобалната история на най-новите m разклонения може да бъде записана в m-битово отместване
регистър, където всеки бит записва дали разклонението е взето или не. The
буферът за предсказване на разклонения след това може да бъде индексиран с помощта на
конкатенация на битовете от нисък ред от адреса на разклонението с m-битовата глобална история. Например,
в (2,2) буфер с общо 64 записа, 4-те адресни бита от нисък ред на клона
(адрес на думата) и 2-та глобални бита, представящи поведението на двете най-много
наскоро изпълнените разклонения образуват 6-битов индекс, който може да се използва за индексиране на 64
броячи.
Колко по-добре работят корелиращите предиктори на клонове, когато се сравняват

със стандартната 2-битова схема? За да ги сравним справедливо, трябва да сравним
предиктори, които използват същия брой битове на състоянието. Броят битове в (m,n)
предиктор е
2m × n × Брой записи на прогнози, избрани от адреса на клона
2-битов предиктор без глобална история е просто (0,2) предиктор.

Пример Колко бита има в (0,2) предиктора на разклонения с 4K записи? Колко

записите са в (2,2) предиктор със същия брой битове?
Отговор Предсказателят с 4K записи има
20 × 2 × 4K = 8K бита
Колко избрани от клонове записи има в (2,2) предиктор, който има общо 8K
битове в буфера за прогнозиране? Ние знаем това
22 × 2 × Брой записи на прогнози, избрани от клона = 8K
Следователно броят на записите за прогнозиране, избран от клона, е 1K.
Фигура 3.3 сравнява процентите на грешни прогнози на по-ранния (0,2) предиктор с

4K записи и (2,2) предиктор с 1K записи. Както можете да видите, това корелира
предикторът не само превъзхожда прост 2-битов предиктор със същия общ брой битове на
състоянието, но също така често превъзхожда 2-битов предиктор с неограничен
брой на влизанията.
Турнирни прогнози: Адаптивно комбиниране на локални и

Глобални предсказатели
Основната мотивация за корелиране на предиктори за разклонения идва от наблюдението, че

стандартният 2-битов предиктор, използващ само локална информация, се провали на някои
важни клонове и че чрез добавяне на глобална информация ефективността
може да се подобри. Турнирните предсказатели извеждат това прозрение на следващото ниво, чрез
използване на множество предиктори, обикновено един базиран на глобална информация и един базиран
на местна информация и комбинирането им със селектор. Турнирни прогнози
може да постигне както по-добра точност при средни размери (8K–32K бита), така и направи
ефективно използване на много голям брой битове за прогнозиране. Съществуващите предиктори
на турнири използват 2-битов брояч за насищане на клон, за да избират между два различни
предиктори въз основа на това кой предиктор (локален, глобален или дори някакъв микс) е най-голям
ефективни в последните прогнози. Както при обикновен 2-битов предиктор, насищащият брояч
изисква две погрешни прогнози, преди да промени идентичността на предпочитания
предсказател.
Предимството на турнирния предиктор е способността му да избира правилното

предиктор за определен клон, което е особено важно за цялото число
бенчмаркове. Типичен турнирен предиктор ще избере глобалния предиктор
почти 40% от времето за целочислените бенчмаркове на SPEC и по-малко от 15% от
времето за бенчмарковете на SPEC FP. В допълнение към процесорите Alpha, които
пионери в турнирните прогнози, скорошни процесори на AMD, включително и двете
Opteron и Phenom са използвали предиктори в турнирен стил.
Фигура 3.4 разглежда производителността на три различни предиктора (локален 2-битов
предиктор, корелиращ предиктор и турнирен предиктор) за различни
1% 4096 записа: 2
nASA7 0% бита на запис
1%
Неограничени
0%
0% записи: 2 бита на запис
матрица300
0% 1024 записа:
1% (2,2)
tomcatv 0%
1%
5%
додук 5%
5%
9%
подправка 9%
5%
Eе
Cн Pб
S
9%
8ч
евокра9м 9%
fpppp
5%
12%
gcc 11%
11%
5%
еспресо 5%
4%
18%
eqntott 18%
6%
10%
ли 10%
5%
0% 2% 4% 6% 8% 10% 12% 14% 16% 18%
Честота на грешните прогнози
Фигура 3.3 Сравнение на 2-битови предиктори. Първо е некорелиращ предиктор за

4096 бита, следван от некорелиращ 2-битов предиктор с неограничен брой записи и
2-битов предиктор с 2 бита глобална история и общо 1024 записа. Въпреки че тези
данни са за по-стара версия на SPEC, данните за по-нови тестове на SPEC биха показали
подобни разлики в точността.
брой битове, използвайки SPEC89 като еталон. Както видяхме по-рано, способността за
прогнозиране на локалния предиктор не се подобрява отвъд определен размер. Корелиращият
предиктор показва значително подобрение, а предикторът на турнира генерира малко по-
добро представяне. За по-нови версии на SPEC, резултатите ще бъдат подобни, но
асимптотичното поведение няма да бъде достигнато до малко по-големи размери на
предиктора.
Локалният предиктор се състои от предиктор на две нива. Най-горното ниво е таблица с
местна история, състояща се от 1024 10-битови записи; всеки 10-битов запис съответства на
последните 10 резултата от разклонения за записа. Тоест, ако разклонението е взето 10 или
повече пъти подред, записът в таблицата с местна история ще бъде само 1. Ако клонът е
последователно взет и невзет, записът в историята се състои от редуващи се 0 и 1. Тази 10-
битова история позволява да се откриват и прогнозират модели от до 10 разклонения.
Избраният запис от таблицата с местна история се използва за
8%
7%
Локални 2-битови предиктори
6%
5%
4%
оиен
тнн
енадж д
еввц лр
е
нооео
ш сП
р
ал
р н
пк
уг
Корелиращи предиктори
3%
Турнирни прогнози
2%
1%
0%
2241921601289664320 288256 384352320 448416 480 512
Общ размер на предиктора
Фигура 3.4 Степента на неправилно предвиждане за три различни предиктора на SPEC89, тъй като общият брой битове се
увеличава. Предсказателите са локален 2-битов предиктор, корелиращ предиктор, който е оптимално структуриран при
използването на глобална и локална информация във всяка точка от графиката, и турнирен предиктор. Въпреки че тези данни
са за по-стара версия на SPEC, данните за по-нови сравнителни тестове на SPEC ще покажат подобно поведение, може би сходно
към асимптотичната граница при малко по-големи размери на предиктора.
индексира таблица от 1K записи, състоящи се от 3-битови насищащи броячи, които осигуряват

локалното предсказване. Тази комбинация, която използва общо 29K бита, води до висока
точност при прогнозиране на разклонения.
Intel Core i7 Branch Predictor

Intel пусна само ограничено количество информация за предиктора на клона на Core i7, който
се основава на по-ранни предиктори, използвани в чипа Core Duo. i7 използва предиктор на
две нива, който има по-малък предиктор от първо ниво, предназначен да отговори на
ограниченията на цикъла за предсказване на разклонение на всеки тактов цикъл, и по-голям
предиктор от второ ниво като резервно копие. Всеки предиктор комбинира три различни
предиктора: (1) простият двубитов предиктор, който беше въведен в Приложение C (и
използван в турнирния предиктор, обсъден по-горе); (2) предсказател на глобалната история,
като тези, които току-що видяхме; и (3) предсказател за излизане от цикъл. Предсказващият
изход от цикъла използва брояч, за да предвиди точния брой взети разклонения (което е
броят на повторенията на цикъла) за разклонение, което е открито като разклонение на
цикъл. За всеки клон се избира най-добрата прогноза измежду трите прогнози чрез
проследяване на точността на всяка прогноза, подобно на турнирен прогноз. В допълнение
към този многостепенен основен предиктор, отделна единица прогнозира целеви адреси за
непреки клонове и също се използва стек за прогнозиране на обратни адреси.
10%
9%
8%
7%
6%
5%
ш
тан
озн
енав аП
р
о
кесецдроегр н
п
4%
3%
2%
1%
0%
Gcc Mcf Milc Lbm
Bzip2 Sjeng
Gobmk Hmmer
Звезда Намд СделкаСоплекс
II Поврей
H264ref Сфинкс 3
Perlbench Omnetpp
Libquantum Xalancbmk
Фигура 3.5 Степента на погрешни прогнози за 19 от бенчмарковете SPECCPU2006 спрямо броя на успешно
оттеглените клонове е малко по-висока средно за целочислените бенчмаркове, отколкото за FP (4% срещу 3%).
По-важното е, че е много по-високо за няколко показателя.
Както в други случаи, спекулациите създават някои предизвикателства при оценката

на предиктора, тъй като неправилно предвиденото разклонение може лесно да доведе
до извличане и неправилно прогнозиране на друго разклонение. За да опростим
нещата, ние разглеждаме броя на грешните прогнози като процент от броя на успешно
завършените разклонения (тези, които не са резултат от грешни спекулации). Фигура 3.5
показва тези данни за 19 от тестовете на SPECCPU 2006. Тези референтни показатели са
значително по-големи от SPEC89 или SPEC2000, като резултатът е, че нивата на грешни
прогнози са малко по-високи от тези на Фигура 3.4 дори при по-сложна комбинация от
предиктори. Тъй като погрешното предвиждане на разклоненията води до неефективни
спекулации, то допринася за загубата на работа, както ще видим по-късно в тази глава.
3.4 Преодоляване на опасностите за данните с динамично планиране
Обикновен статично планиран конвейер извлича инструкция и я издава, освен ако няма
зависимост от данни между инструкция, която вече е в конвейера, и извлечената
инструкция, която не може да бъде скрита с прескачане или препращане. (Логиката за
пренасочване намалява ефективната латентност на конвейера, така че определени
зависимости да не водят до опасности.) Ако има зависимост от данни, която не може да бъде
скрит, тогава хардуерът за откриване на опасност спира тръбопровода, започвайки с

инструкция, която използва резултата. Никакви нови инструкции не се извличат или издават до
зависимостта се изчиства.
В този раздел изследваме динамичното планиране, при което хардуерът пренасочва изпълнението
на инструкциите, за да намали спиранията, като същевременно поддържа потока от данни
и поведение при изключение. Динамичното планиране предлага няколко предимства. Първо, то
позволява на код, който е компилиран с един тръбопровод, да работи ефективно на a
различен тръбопровод, елиминирайки необходимостта от множество двоични файлове и повторно компилиране
за различна микроархитектура. В днешната компютърна среда, където много

на софтуера е от трети страни и се разпространява в двоична форма, това предимство
е значително. Второ, позволява обработка на някои случаи, когато зависимостите са
неизвестен по време на компилация; например, те могат да включват препратка към паметта или
клон, зависим от данни, или могат да са резултат от модерна програмна среда, която използва
динамично свързване или изпращане. Трето и може би повечето
важното е, че позволява на процесора да толерира непредвидими забавяния, като напр
кеш пропуски, чрез изпълнение на друг код, докато чака пропускът да се разреши. в
В раздел 3.6 изследваме хардуерните спекулации, техника с допълнителни предимства в
производителността, която се основава на динамично планиране. Както ще видим,
предимствата на динамичното планиране се получават с цената на значително увеличение на
хардуерна сложност.
Въпреки че динамично планиран процесор не може да промени потока от данни, той
опитва се да избегне забавяне, когато са налице зависимости. За разлика от тях статичен тръбопровод
планирането от компилатора (обхванато в раздел 3.2) се опитва да минимизира спиранията чрез
разделяне на зависимите инструкции, така че да не водят до опасности. Разбира се,
планирането на конвейера на компилатора може също да се използва върху код, предназначен да
работи на процесор с динамично планиран конвейер.
Динамично планиране: Идеята
Основно ограничение на простите конвейерни техники е, че те използват in-order

издаване и изпълнение на инструкции: Инструкциите се издават в програмен ред и ако
инструкция е спряна в конвейера, по-късните инструкции не могат да продължат. По този начин, ако
има зависимост между две близко разположени инструкции в конвейера,
това ще доведе до опасност и ще доведе до срив. Ако има множество функционални
единици, тези единици биха могли да престоят. Ако инструкцията j зависи от дълго изпълняваща се
инструкция i, която в момента се изпълнява в конвейера, тогава всички инструкции след j трябва да бъдат
спря, докато i не приключи и j може да се изпълни. Например, разгледайте този код:
DIV.D F0, F2, F4

ДОБ.Г F10, F0, F8
ПОД.Г F12, F8, F14
Инструкцията SUB.D не може да се изпълни, защото зависимостта на ADD.D от

DIV.D причинява спиране на тръбопровода; все пак SUB.D не са данни, зависими от нищо в
тръбопроводът. Тази опасност създава ограничение на производителността, което може да бъде елиминирано
като не изисква инструкциите да се изпълняват в програмен ред.

В класическия петстепенен тръбопровод могат да съществуват както структурни, така и информационни опасности
проверено по време на декодиране на инструкции (ID): Когато дадена инструкция може да се изпълни
без опасности, тя е издадена от ID, като се знае, че всички опасности за данни са били
разрешено.
За да ни позволи да започнем да изпълняваме SUB.D в горния пример, трябва да разделим

процеса на издаване на две части: проверка за всякакви структурни опасности и
изчакване на липсата на опасност от данни. Така ние все още използваме инструкции по ред
проблем (т.е. инструкции, издадени в програмен ред), но ние искаме инструкция за
започне изпълнение веднага щом неговите операнди с данни са налични. Такъв тръбопровод прави
извънредно изпълнение, което предполага извънредно изпълнение.
Изпълнението извън реда въвежда възможността за WAR и WAW опасности,
които не съществуват в петстепенния целочислен конвейер и неговото логическо разширение до an
тръбопровод с плаваща запетая по ред. Помислете за следния MIPS с плаваща запетая
кодова последователност:
DIV.D F0, F2, F4

ДОБ.Г F6, F0, F8
ПОД.Г F8, F10, F14
МУЛ.Д F6, F10, F8
Има антизависимост между ADD.D и SUB.D и ако тръбопроводът

изпълни SUB.D преди ADD.D (който чака DIV.D), това ще наруши антизависимостта, създавайки
опасност от ВОЙНА. По същия начин, за да избегнете нарушаване
изходни зависимости, като например запис на F6 от MUL.D, трябва да има опасност от WAW
обработван. Както ще видим, и двете опасности се избягват чрез използването на register
преименуване.
Завършването извън ред също създава големи усложнения при обработката на изключения.
Динамичното планиране със завършване извън реда трябва да запази изключение
поведение в смисъл, че точно онези изключения, които биха възникнали, ако програмата се изпълни
в строг програмен ред, действително възникват. Динамично
планираните процесори запазват поведението на изключение, като забавят известяването на
свързано изключение, докато процесорът разбере, че инструкцията трябва да бъде
следващият завършен.
Въпреки че поведението при изключение трябва да се запази, динамично планираните
процесори могат да генерират неточни изключения. Изключение е неточно , ако
състоянието на процесора, когато е повдигнато изключение, не изглежда точно така, сякаш
инструкциите са били изпълнени последователно в строг програмен ред. Непрецизни изключения
може да възникне поради две възможности:
1. Тръбопроводът може вече да има изпълнени инструкции, които по-късно са в про-

грам ред от инструкцията, причиняваща изключение.
2. Тръбопроводът може все още да не е изпълнил някои инструкции, които са по-рано в

програмен ред от инструкцията, причиняваща изключението.
Непрецизните изключения затрудняват рестартирането на изпълнение след изключение.

Вместо да разглеждаме тези проблеми в този раздел, ние ще обсъдим решение, което
предоставя точни изключения в контекста на процесор със спекулации в раздел 3.6. За изключения с плаваща
запетая са използвани други решения, както е обсъдено в Приложение J.
За да позволим изпълнение извън реда, ние по същество разделяме етапа на ID тръба на нашия
прост петстепенен тръбопровод на два етапа:
1. Проблем—Декодирайте инструкциите, проверете за структурни опасности.
2. Четене на операнди—Изчакайте , докато няма опасност от данни, след което прочетете операндите.
Етапът на извличане на инструкции предшества етапа на издаване и може да извлече или в
регистър на инструкции или в опашка от чакащи инструкции; инструкциите са тогава
издадени от регистъра или опашката. Етапът на изпълнение следва операндите за четене
етап, точно както в петстепенния тръбопровод. Изпълнението може да отнеме няколко цикъла,
в зависимост от операцията.
Разграничаваме кога дадена инструкция започва да се изпълнява и кога завършва
екзекуция; между двете времена инструкцията е в изпълнение. Нашият тръбопровод
позволява множество инструкции да бъдат в изпълнение едновременно; без това
способност, основното предимство на динамичното планиране се губи. Имайки множество
инструкциите в изпълнение наведнъж изискват множество функционални единици, конвейерно обединени
функционални единици или и двете. Тъй като тези две възможности—тръбопроводни функционални единици
и множество функционални единици - по същество са еквивалентни за целите на
конвейерно управление, ще приемем, че процесорът има множество функционални единици.
В динамично планиран конвейер всички инструкции преминават през проблема
етап в ред (in-order issue); те обаче могат да бъдат блокирани или да се заобикалят взаимно
във втория етап (четене на операнди) и по този начин влиза в изпълнение извън ред. Score-boarding е
техника за позволяване на инструкциите да се изпълняват неправилно, когато
има достатъчно ресурси и няма зависимости от данни; той е кръстен на CDC
6600 табло, което разработи тази възможност. Тук се фокусираме върху още
сложна техника, наречена алгоритъм на Томасуло. Основната разлика е
че алгоритъмът на Томасуло обработва антизависимостите и изходните зависимости чрез
ефективно динамично преименуване на регистрите. Освен това, алгоритъмът на Tomasulo може да бъде
разширен, за да се справя със спекулации, техника за намаляване на ефекта от
контрол на зависимостите чрез прогнозиране на резултата от разклонение, изпълнение на инструкции на
предвидения адрес на местоназначение и предприемане на коригиращи действия, когато
прогнозата беше грешна. Докато използването на табло вероятно е достатъчно за
поддържат прост суперскалар с две издания като ARM A8, по-агресивен
процесор, подобно на Intel i7 с четири издания, се възползва от използването на извън поръчка

екзекуция.
Динамично планиране с помощта на подхода на Tomasulo
Устройството с плаваща запетая на IBM 360/91 използва усъвършенствана схема, за да позволи изпълнение
извън реда. Тази схема, изобретена от Робърт Томасуло, проследява кога са налични оператори и инструкции
за минимизиране на опасностите от RAW и въвежда
регистрирайте преименуването в хардуера, за да минимизирате опасностите от WAW и WAR. Има

3.4 Преодоляване на опасностите при данните с динамично планиране 171
много вариации на тази схема в съвременните процесори, въпреки че ключовите концепции

на зависимостите на инструкциите за проследяване, за да се позволи изпълнение веднага щом операндите са
налични и преименуването на регистри за избягване на WAR и WAW опасности са често срещани

характеристики.
Целта на IBM беше да постигне висока производителност с плаваща запетая от набор от

инструкции и от компилатори, предназначени за цялото семейство 360 компютри, по-скоро
отколкото от специализирани компилатори за процесори от висок клас. Архитектурата 360 имаше
само четири регистъра с плаваща запетая с двойна точност, което ограничава
ефективност на планирането на компилатора; този факт беше още една мотивация за
Подход Томасуло. В допълнение, IBM 360/91 имаше дълги достъпи до паметта и
дълги закъснения с плаваща запетая, които алгоритъмът на Tomasulo е проектиран да преодолее.
В края на раздела ще видим, че алгоритъмът на Tomasulo може също да поддържа
припокриващо се изпълнение на множество итерации на цикъл.
Ние обясняваме алгоритъма, който се фокусира върху модула с плаваща запетая и модула за
зареждане, в контекста на набора от инструкции MIPS. Основната разлика
между MIPS и 360 е наличието на инструкции за регистър-памет в
последна архитектура. Тъй като алгоритъмът на Tomasulo използва функционална единица за натоварване, не
необходими са значителни промени за добавяне на режими на адресиране на регистър-памет. The

IBM 360/91 също имаше конвейерни функционални единици, а не множество функционални
единици, но ние описваме алгоритъма, сякаш има множество функционални единици. То
е просто концептуално разширение за тръбопровод на тези функционални единици.
Както ще видим, опасностите от RAW се избягват чрез изпълнение само на инструкция
когато неговите операнди са налични, което е точно това, което е по-простото табло
подход предоставя. Опасностите от WAR и WAW, които възникват от зависимостите на имената,
се елиминират чрез преименуване на регистъра. Преименуването на регистъра ги елиминира
опасности чрез преименуване на всички целеви регистри, включително тези с чакащо четене
или пишете за по-ранна инструкция, така че записът извън реда да не се отразява
всякакви инструкции, които зависят от по-ранна стойност на операнд.
За да разберете по-добре как преименуването на регистър елиминира опасностите от WAR и
WAW, разгледайте следната примерна кодова последователност, която включва потенциална WAR
и WAW опасности:
DIV.D F0, F2, F4

ADD.D F6, F0, F8
SD F6,0(R1)
SUB.D F8, F10, F14
Има две антизависимости: между ADD.D и SUB.D и между

SD и MUL.D. Съществува и изходна зависимост между ADD.D
и MUL.D, което води до три възможни опасности: Опасности от ВОЙНА при използването на F8
от ADD.D и използването на F6 от SUB.D, както и опасност от WAW от
ADD.D може да завърши по-късно от MUL.D. Има и три истински зависимости на данните: между
DIV.D и ADD.D, между SUB.D и MUL.D и
между ADD.D и SD
Тези три зависимости на имена могат да бъдат елиминирани чрез преименуване на регистъра.
За простота приемете съществуването на два временни регистъра, S и T. Използвайки S
и T, последователността може да бъде пренаписана без никакви зависимости като:
DIV.D F0, F2, F4

ADD.D S,F0,F8
SD S,0(R1)
SUB.D T, F10, F14
MUL.D F6,F10,T
В допълнение, всички последващи употреби на F8 трябва да бъдат заменени с регистър T. В това
кодов сегмент, процесът на преименуване може да се извърши статично от компилатора. Намирането на
всякакви употреби на F8, които са по-късно в кода, изисква или сложен компилатор
анализ или хардуерна поддръжка, тъй като може да има междинни клонове между тях
горния кодов сегмент и по-късно използване на F8. Както ще видим, алгоритъмът на Tomasulo може да се
справи с преименуването между клоновете.
В схемата на Томасуло преименуването на регистъра се осигурява от резервационни станции,
които буферират операндите на инструкциите, чакащи за издаване. Основната идея е, че a
резервационната станция извлича и буферира операнд веднага щом е наличен, елиминирайки
необходимостта да се извлича операндът от регистър. В допълнение, очакващите инструкции определят
станцията за резервация, която ще предостави тяхното въвеждане. И накрая, кога
последователните записи в регистър се припокриват при изпълнение, само последното е действително
използвани за актуализиране на регистъра. Тъй като се издават инструкции, спецификаторите на регистъра за
чакащите операнди се преименуват на имената на резервационната станция, която осигурява преименуване
на регистъра.
Тъй като може да има повече резервационни станции, отколкото реални регистри, техниката
може дори да елиминира опасностите, произтичащи от зависимостите на имената, които не биха могли да бъдат
елиминиран от компилатор. Докато изследваме компонентите на схемата на Томасуло,
ще се върнем към темата за преименуването на регистъра и ще видим как точно става преименуването
възниква и как елиминира опасностите от WAR и WAW.
Използването на резервационни станции, а не централизиран регистрационен файл, води до
две други важни свойства. Първо, откриването на опасности и контролът на изпълнението са

разпределени: Информацията, съхранявана в резервационните станции на всяка функционална
единица определя кога дадена инструкция може да започне изпълнение в тази единица. Второ,
резултатите се предават директно на функционалните звена от резервационните станции, където
те са буферирани, вместо да минават през регистрите. Това байпасиране е направено
с обща шина за резултати, която позволява на всички единици, чакащи операнд, да бъдат
заредени едновременно (при 360/91 това се нарича обща шина за данни или
CDB). В конвейери с множество изпълнителни единици и издаване на множество инструкции на такт ще е
необходима повече от една шина за резултати.
Фигура 3.6 показва основната структура на процесор, базиран на Tomasulo, включващ модула с
плаваща запетая и модула за зареждане/съхранение; нито една от таблиците за контрол на изпълнението

не е показана. Всяка резервационна станция съдържа инструкция, която е била
е издаден и чака изпълнение във функционална единица и или стойностите на операнда
за тази инструкция, ако вече са изчислени, или имената на
резервационни станции, които ще предоставят стойностите на операндите.

От единица за обучение
Инструкция
FP регистри
опашка
Операции за
зареждане/съхраняване
Операции с Операнд
Адресна единица плаваща запетая автобуси
Буфери за съхранение
Заредете буфери
Операция автобус
3 2
2 Резервационни 1
1 станции
Данни Адрес
Единица памет FP суматори FP множители
Обща шина за данни (CDB)
Фигура 3.6 Основната структура на MIPS единица с плаваща запетая, използваща алгоритъма на Tomasulo. Инструкциите се изпращат
от модула за инструкции в опашката с инструкции, от която се издават в ред първи влязъл, първи излязъл (FIFO). Станциите за
резервиране включват операцията и действителните операнди, както и информация, използвана за откриване и разрешаване на
опасности. Буферите за зареждане имат три функции: (1) задържат компонентите на ефективния адрес, докато не бъде изчислен, (2)
проследяват неизпълнени зареждания, които чакат в паметта, и (3) задържат резултатите от завършени зареждания, които чакат за
CDB. По подобен начин буферите за съхранение имат три функции: (1) съхраняват компонентите на ефективния адрес, докато не
бъде изчислен, (2) съхраняват адресите на паметта на дестинацията на неизпълнени магазини, които чакат стойността на данните
за съхранение, и (3) съхраняват адрес и стойност за съхраняване, докато модулът за памет стане наличен. Всички резултати или от
FP единиците, или от единицата за зареждане се поставят в CDB, която отива във файла на FP регистъра, както и до резервационните
станции и буферите за съхранение. FP суматорите изпълняват събиране и изваждане, а FP умножителите извършват умножение и деление.
Буферите за зареждане и буферите за съхранение съхраняват данни или адреси, идващи

от и отиващи в паметта, и се държат почти точно като резервационни станции, така че ги
разграничаваме само когато е необходимо. Регистрите с плаваща запетая са свързани чрез
чифт шини към функционалните единици и чрез една шина към буферите на магазина.
Всички резултати от функционалните единици и от паметта се изпращат по общата шина за
данни, която отива навсякъде освен до буфера за зареждане. Всички резервационни станции
имат полета за етикети, използвани от контрола на конвейера.
Преди да опишем подробностите за резервационните станции и алгоритъма, нека да
разгледаме стъпките, през които преминава една инструкция. Има само три стъпки, въпреки
че всяка от тях вече може да отнеме произволен брой часовникови цикли:
1. Проблем – Вземете следващата инструкция от главата на опашката с инструкции, която

се поддържа в ред FIFO, за да се гарантира поддържането на правилен поток от данни. Ако
има съответстваща резервационна станция, която е празна, издайте инструкцията на
станцията със стойностите на операндите, ако в момента са в регистрите. Ако
няма празна резервационна станция, тогава има структурна опасност и
инструкцията спира, докато не се освободи станция или буфер. Ако операндите не са в
регистрите, следете функционалните единици, които ще произвеждат операндите.
Тази стъпка преименува регистрите, елиминирайки опасностите от WAR и WAW. (Този етап
понякога се нарича изпращане в динамично планиран процесор.)
2. Изпълнение—Ако един или повече от операндите все още не са налични, наблюдавайте
обща шина за данни, докато чака да бъде изчислена. Когато операнд
стане наличен, той се поставя във всяка резервационна станция, която го очаква. Кога
всички операнди са налични, операцията може да се изпълни в съответната функционална единица.
Чрез забавяне на изпълнението на инструкцията, докато оперите са налични, се избягват опасностите
от RAW. (Някои динамично планирани
процесорите наричат тази стъпка „проблем“, но ние използваме името „изпълни“, което беше
използвани в първия динамично планиран процесор, CDC 6600.)
Забележете, че няколко инструкции могат да станат готови в един и същ часовник
цикъл за същата функционална единица. Макар и независими функционални единици
може да започне изпълнение в същия тактов цикъл за различни инструкции, ако
повече от една инструкция е готова за една функционална единица, единицата ще
трябва да избирате между тях. За резервационните станции с плаваща запетая това
изборът може да бъде направен произволно; товарите и складовете обаче представляват допълнително
усложнение.
Зарежданията и съхраняванията изискват процес на изпълнение в две стъпки. Първата стъпка
изчислява ефективния адрес, когато основният регистър е наличен, и ефективния
след това адресът се поставя в буфера за зареждане или съхраняване. Зарежданията в буфера за
зареждане се изпълняват веднага щом паметта е налична. Магазини в буфера на магазина чакат
стойността, която трябва да бъде съхранена, преди да бъде изпратена към паметта. Зарежда и съхранява
се поддържат в програмен ред чрез изчисляване на ефективния адрес,
което ще помогне за предотвратяване на опасности чрез паметта, както ще видим скоро.
За да се запази поведението на изключение, не е позволено на нито една инструкция да започне
изпълнение, докато всички клонове, които предхождат инструкцията в програмния ред, не са
завършен. Това ограничение гарантира, че инструкция, която причинява an
изключение по време на изпълнение наистина щеше да бъде изпълнено. В процесор
използвайки предвиждане на разклонения (както правят всички динамично планирани процесори), това
означава, че процесорът трябва да знае, че прогнозата за разклоняване е правилна
преди да позволи на инструкция след разклонението да започне изпълнение. Ако процесорът запише
появата на изключение, но всъщност не го повдига,

дадена инструкция може да започне изпълнение, но не и да спре, докато не влезе в резултат от запис.
Както ще видим, спекулациите предоставят по-гъвкави и по-пълни
метод за обработка на изключения, така че ще отложим това подобрение и
покажете как спекулациите се справят с този проблем по-късно.

3. Запишете резултата—Когато резултатът е наличен, запишете го в CDB и от

там в регистрите и във всички резервационни станции (включително буфери на магазини),
чакайки този резултат. Магазините се буферират в буфера на магазина, докато и двете
стойността за съхраняване и адресът на магазина са налични, тогава резултатът е
записан веднага щом паметта се освободи.
Структурите от данни, които откриват и елиминират опасностите, са прикрепени към станциите
за резервиране, към регистрационния файл и към буферите за зареждане и съхраняване с леко

различна информация, прикрепена към различни обекти. Тези етикети са по същество
имена за разширен набор от виртуални регистри, използвани за преименуване. В нашия пример,
полето за етикет е 4-битова величина, която обозначава една от петте резервационни станции или
един от петте буфера за натоварване. Както ще видим, това произвежда еквивалента на 10
регистри, които могат да бъдат обозначени като регистри за резултати (за разлика от четирите
регистъра с двойна точност, които архитектурата 360 съдържа). В процесор с повече
реални регистри, бихме искали преименуването да осигури още по-голям набор от виртуални
регистри. Полето за етикет описва коя резервационна станция съдържа инструкцията, която ще
произведе резултат, необходим като операнд източник.
След като дадена инструкция е издадена и чака операнд източник, тя препраща към
операндът от номера на резервационната станция, където е инструкцията, която ще
запишете, че регистърът е назначен. Неизползваните стойности, като нула, показват това
операндът вече е наличен в регистрите. Тъй като има повече станции за резервация, отколкото
действителните номера на регистрите, опасностите от WAW и WAR се елиминират чрез преименуване
на резултатите с помощта на номера на станции за резервации. Въпреки че в
Схемата на Tomasulo резервационните станции се използват като разширени виртуални
регистри, други подходи биха могли да използват набор от регистри с допълнителни регистри или a
структура като буфера за пренареждане, който ще видим в раздел 3.6.
В схемата на Tomasulo, както и следващите методи, които търсим
в подкрепа на спекулациите, резултатите се излъчват в автобус (CDB), който е
наблюдавани от резервационните станции. Комбинацията от общия резултат
автобус и извличането на резултати от автобуса от станциите за резервации прилага механизмите
за препращане и заобикаляне, използвани в статично планиран
тръбопровод. При това обаче динамично планирана схема въвежда такъв
цикъл на латентност между източник и резултат, тъй като съвпадението на резултат и
използването му не може да се извърши до етапа на запис на резултата. По този начин, в динамично
планиран тръбопровод, ефективната латентност между генерираща инструкция и a
консумиращата инструкция е поне един цикъл по-дълъг от латентността на функционалната
единица, произвеждаща резултата.
Важно е да запомните, че етикетите в схемата Tomasulo се отнасят до
буфер или единица, която ще произведе резултат; имената на регистъра се отхвърлят, когато an
издаване на инструкции за резервационна станция. (Това е ключова разлика между
Схема на Томасуло и табло: При таблото операндите остават в
регистри и се четат само след като инструкцията за производство завърши и инструкцията за
потребление е готова за изпълнение.)
Всяка резервационна станция има седем полета:
Op—Операцията, която трябва да се извърши върху операндите източник S1 и S2.
Qj, Qk—Резервираните станции, които ще произвеждат съответния източник
операнд; стойност нула показва, че операндът източник вече е наличен

във Vj или Vk, или е ненужен.
Vj, Vk—Стойността на изходните операнди. Имайте предвид, че само един от V
полета или полето Q е валидно за всеки операнд. За товари се използва полето Vk

за задържане на офсетното поле.
A—Използва се за съхраняване на информация за изчисляване на адреса на паметта за натоварване
или магазин. Първоначално тук се съхранява непосредственото поле на инструкцията; след

изчисляването на адреса, ефективният адрес се съхранява тук.
Заето—Показва, че тази станция за резервации и придружаващите я функции
единица са заети.
Файлът на регистъра има поле Qi:
Qi—Номерът на резервационната станция, която съдържа операцията чийто
резултатът трябва да се съхранява в този регистър. Ако стойността на Qi е празна (или 0), не
текущо активната инструкция изчислява резултат, предназначен за този регистър,
което означава, че стойността е просто съдържанието на регистъра.
Всеки от буферите за зареждане и за съхранение има поле A, което съдържа резултата от
ефективен адрес след завършване на първата стъпка от изпълнението.

В следващия раздел първо ще разгледаме някои примери, които показват как тези
механизмите работят и след това разгледайте подробния алгоритъм.
3.5 Динамично планиране: Примери и алгоритъм
Преди да разгледаме подробно алгоритъма на Tomasulo, нека разгледаме няколко примера

което ще помогне да се илюстрира как работи алгоритъмът.
Пример Покажете как изглеждат информационните таблици за следната кодова последователност

когато само първото зареждане е завършило и е написал резултата си:
1. LD F6,32(R2)
2. LD F2,44(R3)
3. MUL.D F0, F2, F4
4. SUB.D F8, F2, F6
5. DIV.D F10, F0, F6
6. ADD.D F6, F8, F2
Отговор Фигура 3.7 показва резултата в три таблици. Числата, добавени към имената
Add, Mult и Load означават етикета за тази резервационна станция - Add1 е
етикет за резултата от първата добавена единица. Освен това сме включили
3.5 Динамично планиране: Примери и алгоритъм 177
Състояние на инструкцията
Инструкция Проблем Изпълни Напишете резултата
LD F6,32(R2)
LD F2,44(R3)
MUL.D F0,F2,F4
SUB.D F8,F2,F6
DIV.D F10,F0,F6
Резервационни станции
Име Зает оп Vj Вк Qj Qk А
Натоварване1 Не
Натоварване2 да Заредете 44 + Regs[R3]

Добавяне1 да ПОДП Mem[32 + Regs[R2]] Load2
Добавяне2 да ДОБАВЯНЕ Добавяне1 Натоварване2
Добавяне3 Не
Множество1 да MUL Правила[F4] Натоварване2
Мулт2 да DIV Mem[32 + Regs[R2]] Mult1
Статус на регистрация
Поле F0 F2 F4 F6 F8 F10 F12 . . . F30
Qi Множество1 Натоварване2 Добавяне2 Добавяне1 Мулт2
Фигура 3.7 Станции за резервация и регистрационни етикети, показани, когато всички инструкции са издадени, но само
първата инструкция за зареждане е завършила и е записала резултата си в CDB. Второто зареждане е ефективно
изчисление на адрес, но чака на паметта. Ние използваме масива Regs[], за да препращаме към регистрационния файл и
масив Mem[ ] за препратка към паметта. Не забравяйте, че операндът се определя или от Q поле, или от V поле по всяко време
време. Забележете, че инструкцията ADD.D, която има опасност от WAR на етап WB, е издадена и може да завърши
преди DIV.D да започне.
таблица за състоянието на инструкциите. Тази таблица е включена само за да ви помогне да разберете

алгоритъм; всъщност не е част от хардуера. Вместо това резервационната станция
запазва състоянието на всяка операция, която е издадена.
Схемата на Tomasulo предлага две основни предимства пред предишната и по-простата

схеми: (1) разпределението на логиката за откриване на опасност и (2) елиминирането
на сергии за WAW и WAR опасности.
Първото предимство произтича от разпределените станции за резервация и използването на

CDB. Ако множество инструкции чакат един резултат и всяка инструкция вече има свой друг
операнд, тогава инструкциите могат да бъдат освободени едновременно чрез излъчване на
резултата в CDB. Ако се използва централизиран регистрационен файл, единиците ще трябва да
прочетат своите резултати от регистрите, когато са налични регистрационни шини.
Второто предимство, елиминирането на опасностите от WAW и WAR, се постига чрез

преименуване на регистри с помощта на резервационните станции и чрез процеса на съхраняване
на операнди в резервационната станция веднага щом са налични.
Например кодовата последователност на Фигура 3.7 издава както DIV.D, така и ADD.D, въпреки
че има опасност от WAR, включваща F6. Опасността се елиминира по един от двата начина.
Първо, ако инструкцията, предоставяща стойността за DIV.D, е завършена, тогава Vk ще съхрани
резултата, позволявайки на DIV.D да се изпълни независимо от ADD.D (това е показаният случай).
От друга страна, ако LD не е завършен, тогава Qk ще сочи към резервационната станция Load1 и
инструкцията DIV.D ще бъде независима от ADD.D. Така и в двата случая ADD.D може да издаде и
да започне да се изпълнява. Всяко използване на резултата от DIV.D ще сочи към резервационната
станция, позволявайки на ADD.D да завърши и съхрани стойността си в регистрите, без да засяга
DIV.D.
Скоро ще видим пример за елиминиране на опасност от WAW. Но нека първо да разгледаме

как нашият предишен пример продължава изпълнението. В този пример и тези, които следват в
тази глава, приемете следните закъснения: натоварване е 1 тактов цикъл, събиране е 2 тактови
цикъла, умножение е 6 тактови цикъла и деление е 12 тактови цикъла.
Пример Използвайки същия кодов сегмент като в предишния пример (страница 176), покажете как изглеждат
таблиците за състояние, когато MUL.D е готов да запише своя резултат.
Отговор Резултатът е показан в трите таблици на Фигура 3.8. Забележете, че ADD.D е завършен, тъй като
операндите на DIV.D са копирани, като по този начин се преодолява опасността от WAR.
Забележете, че дори ако зареждането на F6 е било забавено, добавянето към F6 може да бъде
изпълнено, без да задейства опасност от WAW.
Алгоритъмът на Томасуло: Подробностите
Фигура 3.9 определя проверките и стъпките, през които трябва да премине всяка инструкция.
Както бе споменато по-рано, зарежданията и запаметяванията преминават през функционална
единица за ефективно изчисляване на адреса, преди да се пристъпи към независимо зареждане
или съхраняване на буфери. Зарежданията предприемат втора стъпка на изпълнение за достъп
до паметта и след това преминават към запис на резултата, за да изпратят стойността от паметта
към регистрационния файл и/или всички чакащи резервационни станции. Магазините завършват
своето изпълнение в етапа на запис на резултата, който записва резултата в паметта. Забележете,
че всички записи се случват в резултат от запис, независимо дали дестинацията е регистър или
памет. Това ограничение опростява алгоритъма на Tomasulo и е критично за разширяването му
със спекулации в раздел 3.6.
Инструкция Проблем Изпълни Напишете резултата
LD F6,32(R2)
LD F2,44(R3)
MUL.D F0,F2,F4
SUB.D F8,F2,F6
DIV.D F10,F0,F6
Име Busy Op Vj Вк Qj Qk A
Зареждане1 №
Зареждане 2 №
Add1 No
Add2 No
Add3 No
Mult1 Да MUL Mem[44 + Regs[R3]] Regs[F4]

Mult2 Да DIV Mem[32 + Regs[R2]] Mult1
Поле F0 F2 F4 F6 F8 F10 F12 ... F3 0
Qi Множество1 Мулт2
Фигура 3.8 Умножение и деление са единствените инструкции, които не са завършени.
Алгоритъмът на Томасуло: пример, базиран на цикъл
За да разберете пълната сила на елиминирането на опасностите от WAW и WAR

динамично преименуване на регистри, трябва да разгледаме цикъл. Помислете за следното
проста последователност за умножаване на елементите на масив по скалар във F2:
MUL.D F4, F0, F2
SD F4,0(R1)
DADDIU R1,R1,-8
BNE R1, R2, цикъл; разклонения, ако R1¦R2
Ако прогнозираме, че са взети разклонения, използването на резервационни станции ще

позволи множество изпълнения на този цикъл да продължат наведнъж. Това предимство се постига без
промяна на кода - всъщност цикълът се развива динамично от хардуера
използване на резервационните станции, получени чрез преименуване, за да действат като допълнителни регистри.
Състояние на инструкцията Изчакайте, докато Действие или счетоводство
Проблем Станцията r е празна ако (RegisterStat[rs].Qi¦0)

FP операция {RS[r].Qj RegisterStat[rs].Qi} else {RS[r].Vj
Regs[rs]; RS[r].Qj 0}; ако (RegisterStat[rt].Qi¦0)
{RS[r].Qk RegisterStat[rt].Qi else {RS[r].Vk

Regs[rt]; RS[r].Qk 0};
RS[r].Зает да; RegisterStat[rd].Q r;
Заредете или съхранете Буферът r е празен ако (RegisterStat[rs].Qi¦0)

{RS[r].Qj RegisterStat[rs].Qi} else {RS[r].Vj
Regs[rs]; RS[r].Qj 0}; RS[r].A imm; RS[r].Зает да;
RegisterStat[rt].Qi r;
Само натоварване
Само магазин ако (RegisterStat[rt].Qi¦0)

{RS[r].Qk RegisterStat[rs].Qi} else {RS[r].Vk
Regs[rt]; RS[r].Qk 0};
Изпълни (RS[r].Qj = 0) и (RS[r].Qk = 0) Резултат от изчислението: операндите са във Vj и Vk

FP операция
Зареждане/съхранение
RS[r].Qj = 0 & r е главата на опашката за RS[r].A RS[r].Vj + RS[r].A;
етап 1 зареждане-запаметяване
Заредете стъпка 2 Зареждане на стъпка 1 Прочетете от Mem[RS[r].A]
Напишете резултата завършено Изпълнение x(if (RegisterStat[x].Qi=r) {Regs[x] резултат;

FP операция завършено при r & CDB наличен RegisterStat[x].Qi 0});
или натоварване x(ако (RS[x].Qj=r) {RS[x].Vj резултат;RS[x].Qj
0});
x(ако (RS[x].Qk=r) {RS[x].Vk резултат;RS[x].Qk
0});
RS[r].Заето не;
Магазин Изпълнението е завършено при Mem[RS[r].A] RS[r].Vk;

r & RS[r].Qk = 0 RS[r].Заето не;
Фигура 3.9 Стъпки в алгоритъма и какво се изисква за всяка стъпка. За инструкцията за издаване rd е местоназначението, rs и rt са номерата на
регистъра източник, imm е разширеното със знак непосредствено поле и r е резервацията
станция или буфер, към който е присвоена инструкцията. RS е структурата на данните за резервационната станция. Стойността, върната от
FP единица или от товарната единица се нарича резултат. RegisterStat е структурата на данните за състоянието на регистъра (не регистърния файл,
което е Regs []). Когато е издадена инструкция, полето Qi на регистъра на местоназначението е зададено на номера на буфера или резервационната
станция, към която е издадена инструкцията. Ако операндите са налични в регистрите, те са
съхранявани в полетата V. В противен случай полетата Q са настроени да посочват резервационната станция, която ще генерира стойностите
необходими като изходни операнди. Инструкцията чака в резервационната станция, докато и двата й операнда са налични,
обозначени с нула в полетата Q. Полетата Q са зададени на нула или когато тази инструкция е издадена, или когато инструкция, от която зависи
тази инструкция, завърши и извърши обратния запис. Когато дадена инструкция приключи изпълнението и CDB е достъпна, тя може да извърши
обратно запис. Всички буфери, регистри и резервационни станции, чиито стойности
на Qj или Qk са същите като завършващата резервационна станция, актуализира своите стойности от CDB и маркира Q
полета, за да укажете, че са получени стойности. По този начин CDB може да излъчи резултата си до много дестинации в един тактов цикъл и ако
чакащите инструкции имат своите операнди, всички те могат да започнат изпълнение на следващия часовник
цикъл. Зарежданията преминават през две стъпки при изпълнение, а съхраняванията се представят малко по-различно по време на запис на резултата, където те
може да се наложи да изчака стойността да се съхрани. Не забравяйте, че за да запазите поведението на изключения, инструкциите не трябва да бъдат
разрешено за изпълнение, ако разклонение, което е по-рано в програмния ред, все още не е завършено. Тъй като каквато и да е концепция за
програмен ред не се поддържа след етапа на издаване, това ограничение обикновено се прилага чрез предотвратяване на напускане на каквато и
да е инструкция от етапа на издаване, ако вече има чакащо разклонение в конвейера. В раздел 3.6 ще видим как
поддръжката на спекулации премахва това ограничение.
Да приемем, че сме издали всички инструкции в две последователни итерации
на цикъла, но нито едно от зареждането/съхраняванията или операциите с плаваща запетая не е
завършило. Фигура 3.10 показва станции за резервация, таблици за състоянието на регистъра и натоварване и
съхранявайте буфери в този момент. (Цялочислената ALU операция се игнорира и е
предполага се, че клонът е предвиден като взет.) След като системата достигне това състояние,
две копия на цикъла могат да бъдат поддържани с CPI близо до 1.0, при условие че
умноженията могат да завършат за четири тактови цикъла. При латентност от шест цикъла ще трябва да
бъдат обработени допълнителни итерации, преди да може да се достигне стабилно състояние.
Това изисква повече станции за резервация, които да държат инструкции, които са в процес на изпълнение.
Инструкция От итерация Проблем Изпълни Напишете резултата
LD F0,0(R1) 1
MUL.D F4,F0,F2 1
SD F4,0(R1) 1
LD F0,0(R1) 2
MUL.D F4,F0,F2 2
SD F4,0(R1) 2
Име Зает оп Vj Вк Qj Qk А
Натоварване1 да Заредете Regs[R1] + 0

Натоварване2 да Заредете Правила [R1] – 8
Множество1 да MUL Правила[F2] Натоварване1
Мулт2 да MUL Правила[F2] Натоварване2
Магазин1 да Магазин Правила [R1] Множество1
Магазин2 да Магазин Правила [R1] – 8 Мулт2
Поле F0 F2 F4 F6 F8 F10 F12 ... F30
Qi Натоварване2 Мулт2
Фигура 3.10 Две активни итерации на цикъла без все още завършена инструкция. Записите в станциите за резервиране на
множителя показват, че неплатените товари са източниците. Станциите за резервация на магазина показват, че
multiply дестинацията е източникът на стойността за съхраняване.
Както ще видим по-късно в тази глава, когато се разшири с множество инструкции
проблем, подходът на Tomasulo може да поддържа повече от една инструкция на часовник.
Товарът и магазинът могат безопасно да бъдат направени извън ред, при условие че имат достъп до различни
различни адреси. Ако товар и магазин имат достъп до един и същи адрес, тогава и двете
Зареждането е преди съхраняването в програмен ред и резултатите от размяната им

при опасност от ВОЙНА, или
Съхранението е преди зареждането в програмен ред и резултатите от размяната им

в опасност от RAW.
По същия начин размяната на два магазина на един и същи адрес води до опасност от WAW.
Следователно, за да се определи дали даден товар може да бъде изпълнен в даден момент, процесорът
може да провери дали някой незавършен магазин, който предхожда зареждането в програмния ред
споделя същия адрес на паметта за данни като товара. По същия начин магазинът трябва да чака
докато няма неизпълнени зареждания или съхранява, които са по-ранни в реда на програмата и
споделят един и същ адрес на паметта за данни. Ние разглеждаме метод за премахване на това
ограничение в раздел 3.9.
За да открие такива опасности, процесорът трябва да е изчислил паметта на данните
адрес, свързан с всяка по-ранна операция с паметта. Просто, но не е задължително
оптималният начин да се гарантира, че процесорът има всички такива адреси, е да се изпълни
изчисления на ефективни адреси в програмен ред. (Ние наистина трябва само да запазим
относителен ред между магазини и други препратки към паметта; тоест натоварванията могат да бъдат
пренарежда се свободно.)
Нека първо разгледаме ситуацията с товар. Ако извършим изчисляване на ефективен адрес в програмен ред,
тогава, когато товарът е завършил изчисляването на ефективен адрес, можем да проверим дали има конфликт на
адреси, като проверим полето A
от всички активни буфери на магазина. Ако адресът за зареждане съвпада с адреса на всеки активен
записи в буфера за съхранение, тази инструкция за зареждане не се изпраща до буфера за зареждане, докато
противоречив магазин завършва. (Някои реализации заобикалят стойността директно към
зареждането от чакащ магазин, намалявайки забавянето за тази опасност от RAW.)
Магазините работят по подобен начин, с изключение на това, че процесорът трябва да проверява за конфликти
както буферите за зареждане, така и буферите за съхранение, тъй като конфликтните магазини не могат да бъдат
пренаредени по отношение нито на зареждане, нито на магазин.
Динамично планираният тръбопровод може да доведе до много висока производителност, при условие
разклоненията се предвиждат точно - проблем, който разгледахме в последния раздел. The
основен недостатък на този подход е сложността на схемата Tomasulo,
което изисква голямо количество хардуер. По-специално, всяка резервационна станция
трябва да съдържа асоциативен буфер, който трябва да работи с висока скорост, както и сложна контролна логика.
Производителността може също да бъде ограничена от единичния CDB.
Въпреки че могат да се добавят допълнителни CDB, всеки CDB трябва да взаимодейства с всяка станция за
резервации и хардуерът за съпоставяне на асоциативни тагове трябва да бъде
дублирани на всяка станция за всеки CDB.
В схемата на Томасуло са комбинирани две различни техники: преименуването на
архитектурните регистри към по-голям набор от регистри и буферирането на източника
операнди от регистърния файл. Буферирането на операнд източник разрешава опасностите от WAR
които възникват, когато операндът е наличен в регистрите. Както ще видим по-късно, така е
също е възможно да се премахнат опасностите от WAR чрез преименуване на регистър заедно с

буфериране на резултат, докато не останат неизвестни препратки към по-ранната версия на
регистъра. Този подход ще бъде използван, когато обсъждаме хардуерни спекулации.
Схемата на Томасуло беше неизползвана в продължение на много години след 360/91, но
беше широко възприета в процесорите с множество издания, започвайки през 1990 г. за няколко
причини:
1. Въпреки че алгоритъмът на Tomasulo е проектиран преди кешовете, наличието на кешове, с

присъщите непредвидими закъснения, се превърна в една от основните мотивации за
динамично планиране. Изпълнението извън реда позволява на процесорите да продължат
да изпълняват инструкции, докато чакат завършването на пропуск в кеша, като по този начин
скриват цялото или част от наказанието за пропуск в кеша.
2. Тъй като процесорите стават по-агресивни в способността си за издаване и дизайнерите са

загрижени за производителността на труден за планиране код (като повечето нечислови
кодове), техники като преименуване на регистър, динамично планиране и спекулации стават
по-важни.
3. Може да постигне висока производителност, без да изисква компилаторът да насочва кода към
специфична тръбопроводна структура, което е ценно свойство в ерата на масовия пазарен
софтуер.
3.6 Хардуерно базирани спекулации
Докато се опитваме да използваме повече паралелизъм на ниво инструкции, поддържането на

контролни зависимости става все по-голяма тежест. Предсказването на разклоненията намалява
директните спирания, дължащи се на разклоненията, но за процесор, изпълняващ множество
инструкции на такт, само точното предсказване на разклоненията може да не е достатъчно за
генериране на желаното количество паралелизъм на ниво инструкции. Процесорът с широк
проблем може да се наложи да изпълнява разклонение на всеки такт, за да поддържа максимална производит
Следователно, използването на повече паралелизъм изисква да преодолеем ограничението на
зависимостта от контрола.
Преодоляването на контролната зависимост се извършва чрез спекулиране на резултата от
разклоненията и изпълнение на програмата, сякаш нашите предположения са верни. Този
механизъм представлява фино, но важно разширение над прогнозирането на разклоненията с
динамично планиране. По-специално, със спекулации, ние извличаме, издаваме и изпълняваме
инструкции, сякаш нашите прогнози за разклонения винаги са правилни; динамичното планиране
само извлича и издава такива инструкции. Разбира се, имаме нужда от механизми за справяне със
ситуацията, в която спекулациите са неверни. Приложение H обсъжда различни механизми за
поддържане на спекулации от компилатора. В този раздел ние изследваме хардуерните
спекулации, които разширяват идеите за динамично планиране.
Хардуерно базираната спекулация съчетава три ключови идеи: (1) динамично предсказване
на разклоненията, за да се избере кои инструкции да се изпълнят, (2) спекулация, позволяваща
изпълнението на инструкции, преди контролните зависимости да бъдат разрешени (с възможност
за отмяна на ефектите от неправилно спекулирана последователност) и (3) динамично планиране
за справяне с планирането на различни комбинации от
основни блокове. (За сравнение, динамичното планиране без спекулации само частично припокрива
основни блокове, тъй като изисква разклонението да бъде разрешено преди
действително изпълнение на всякакви инструкции в основния блок наследник.)
Хардуерно базираните спекулации следват предвидения поток от стойности на данни към
изберете кога да изпълните инструкциите. Този метод за изпълнение на програми е
по същество изпълнение на поток от данни: Операциите се изпълняват веднага щом техните операнди
са налични.
За да разширим алгоритъма на Tomasulo, за да подкрепим спекулациите, трябва да разделим
заобикаляне на резултатите сред инструкциите, което е необходимо за спекулативно изпълнение на
инструкция от действителното завършване на инструкция. Правейки това
разделяне, можем да позволим на дадена инструкция да се изпълни и да заобиколи нейните резултати до
други инструкции, без да позволява на инструкцията да извършва актуализации, които
не може да бъде отменено, докато не разберем, че инструкцията вече не е спекулативна.
Използването на прескочена стойност е като извършване на спекулативно четене на регистър, тъй като
не знаем дали инструкцията, предоставяща стойността на регистъра източник, е
осигуряване на правилния резултат, докато инструкцията вече не е спекулативна. Кога
дадена инструкция вече не е спекулативна, позволяваме й да актуализира регистърния файл или
памет; ние наричаме тази допълнителна стъпка в последователността на изпълнение на инструкциите

ангажимент за инструкция.
Основната идея зад прилагането на спекулации е да се позволят инструкции за
изпълняват не по ред, но за да ги принудят да се ангажират по ред и да предотвратят всякакви
неотменимо действие (като актуализиране на състояние или предприемане на изключение), докато дадена
инструкция не се ангажира. Следователно, когато добавим спекулации, трябва да разделим процеса
на завършване на изпълнение от ангажимент на инструкция, тъй като инструкциите може да завършат
изпълнение значително преди да са готови да се ангажират. Добавяне на този ангажимент
фаза към последователността на изпълнение на инструкциите изисква допълнителен набор от хардуер

буфери, които съхраняват резултатите от инструкции, които са приключили изпълнението, но са
не е ангажиран. Този хардуерен буфер, който наричаме буфер за пренареждане, също е
използвани за предаване на резултати между инструкции, които могат да бъдат спекулирани.
Буферът за пренареждане (ROB) предоставя допълнителни регистри по същия начин като
резервационните станции в алгоритъма на Томасуло разширяват набора от регистри. ROB
съдържа резултата от инструкция между времето, свързано с операцията
инструкцията завършва и времето, което инструкцията ангажира. Следователно, ROB
е източник на операнди за инструкции, точно както резервационните станции предоставят
операнди в алгоритъма на Tomasulo. Ключовата разлика е, че в алгоритъма на Tomasulo, след като дадена
инструкция запише своя резултат, всички последващи инструкции
ще намери резултата в регистрационния файл. Със спекулации регистърният файл не е такъв
актуализирани, докато инструкцията се ангажира (и знаем окончателно, че инструкцията трябва да се
изпълни); по този начин ROB доставя операнди в интервала между
завършване на изпълнението на инструкцията и поемането на инструкцията. ROB е подобен
към буфера на магазина в алгоритъма на Томасуло и ние интегрираме функцията на
съхранявайте буфер в ROB за простота.
Всеки запис в ROB съдържа четири полета: тип инструкция, поле за дестинация, поле за стойност и
поле за готовност. Полето тип инструкция показва

дали инструкцията е разклонение (и няма резултат от дестинация), магазин (което
има местоназначение на адреса на паметта) или регистърна операция (ALU операция или
зареждане, която има местоназначения на регистър). Полето дестинация предоставя
номера на регистъра (за зареждания и ALU операции) или адреса на паметта (за магазини),
където трябва да бъде записан резултатът от инструкцията. Полето за стойност се използва
за задържане на стойността на резултата от инструкцията, докато инструкцията се ангажира.
Скоро ще видим пример за ROB записи. И накрая, полето за готовност показва, че
инструкцията е завършила изпълнението и стойността е готова.
Фигура 3.11 показва хардуерната структура на процесора, включително ROB. ROB
включва буферите за съхранение. Магазините все още се изпълняват на две стъпки, но
втората стъпка се извършва чрез ангажимент на инструкция. Въпреки че преименуването
Пренареждане на буфер
Рег. № Данни
опашка
FP регистри
Операнд
Адресна единица Операции с автобуси
плаваща запетая
Адрес 3 2
на магазина 2 Резервация 1
1 станции
Съхранявайте данни Адрес
Единица памет FP суматори FP множители
Заредете
данни
Фигура 3.11 Основната структура на FP единица, използваща алгоритъма на Tomasulo и разширена за справяне със спекулации.
Сравнявайки това с Фигура 3.6 на страница 173, която имплементира алгоритъма на Tomasulo, основната промяна е добавянето
на ROB и елиминирането на буфера за съхранение, чиято функция е интегрирана в ROB. Този механизъм може да бъде
разширен до множество издания, като направи CDB по-широк, за да позволи множество завършвания на такт.
функцията на резервационните станции е заменена от ROB, все още имаме нужда от място
за буфериране на операции (и операнди) между времето, когато издават, и времето, в което те
започнете изпълнението. Тази функция все още се предоставя от резервационните станции. От
всяка инструкция има позиция в ROB, докато не се ангажира, ние маркираме резултат с помощта на
входния номер на ROB, вместо да използвате номера на резервационната станция. Това
маркирането изисква ROB, зададен за дадена инструкция, да бъде проследен в
резервационна станция. По-късно в този раздел ще проучим алтернативна реализация, която
използва допълнителни регистри за преименуване и опашка, която замества
ROB, за да реши кога инструкциите могат да се ангажират.
Ето четирите стъпки, включени в изпълнението на инструкцията:
1. Проблем—Вземете инструкция от опашката с инструкции. Издайте инструкцията, ако

има празна резервационна станция и празен слот в ROB; изпрати
операнди към резервационната станция, ако са налични в регистрите
или ROB. Актуализирайте контролните записи, за да посочите, че буферите се използват. The
номерът на ROB записа, определен за резултата, също се изпраща до резервационната станция,
така че номерът да може да се използва за маркиране на резултата, когато бъде поставен
на ЦДБ. Ако или всички резервации са пълни, или ROB е пълен, тогава проблемът с инструкциите
се спира, докато и двете нямат налични записи.
2. Изпълнение—Ако един или повече от операндите все още не са налични, наблюдавайте

CDB, докато чака регистърът да бъде изчислен. Тази стъпка проверява за
Опасности от RAW. Когато и двата операнда са налични в резервационна станция, изпълнете
операцията. Инструкциите може да отнемат няколко такта на този етап,
и товарите все още изискват две стъпки в този етап. Магазините трябва да имат само основата
регистър, наличен на тази стъпка, тъй като изпълнението за магазин в този момент е само
изчисляване на ефективен адрес.
3. Запишете резултата—Когато резултатът е наличен, запишете го в CDB (с ROB

етикет, изпратен при издаване на инструкцията), както и от CDB в ROB
за всички резервирани станции, които чакат този резултат. Маркирайте станцията за резервация
като налична. За инструкциите на магазина са необходими специални действия. Ако стойността
за съхраняване е наличен, той се записва в полето Стойност на ROB записа за
магазина. Ако стойността, която трябва да бъде съхранена, все още не е налична, CDB трябва да
се наблюдава, докато тази стойност не бъде излъчена, след което полето Стойност на ROB
записът на магазина е актуализиран. За простота приемаме, че това се случва по време на

етапът на запис на резултатите от магазина; ще обсъдим облекчаването на това изискване по-късно.
4. Ангажиране—Това е последният етап от изпълнението на инструкция, след което само

резултатът от него остава. (Някои процесори наричат тази фаза на ангажимент „завършване“ или
„дипломиране.“) Има три различни последователности от действия при комит в зависимост от
това дали инструкцията за ангажимент е разклонение с неправилно предсказване, магазин или
друга инструкция (нормален комит). Нормалният случай на ангажиране
възниква, когато инструкция достигне главата на ROB и нейният резултат е налице
в буфера; в този момент процесорът актуализира регистъра с резултата и
премахва инструкцията от ROB. Ангажирането на магазин е подобно с изключение на
тази памет се актуализира, а не резултатен регистър. Когато клон с неправилна прогноза
достигне до главата на ROB, това показва, че спекулацията
беше грешно. ROB се промива и изпълнението се рестартира при правилния наследник на

клона. Ако разклонението е правилно предвидено, разклонението е завършено.
След като дадена инструкция се ангажира, нейният запис в ROB се възстановява и регистърът
или местоназначението на паметта се актуализират, елиминирайки необходимостта от ROB запис. Ако
ROB попълва, ние просто спираме да издаваме инструкции, докато входът не стане безплатен.
Сега нека разгледаме как ще работи тази схема със същия пример, който използвахме
за алгоритъма на Томасуло.
Пример Да приемем същите закъснения за функционалните единици с плаваща запетая, както в по-ранните
примери: събиране е 2 тактови цикъла, умножение е 6 тактови цикъла и деление е 12 тактови цикъла.
Използвайки кодовия сегмент по-долу, същият, който използвахме за генериране на Фигура 3.8, показва
как изглеждат таблиците за състоянието, когато MUL.D е готов да премине към ангажимент.
LD F6,32(R2)
LD F2,44(R3)
MUL.D F0, F2, F4
SUB.D F8, F2, F6
DIV.D F10, F0, F6
ADD.D F6, F8, F2
Отговор Фигура 3.12 показва резултата в трите таблици. Забележете, че въпреки че SUB.D
инструкцията е завършила изпълнението, тя не се ангажира, докато MUL.D не се ангажира.
Станциите за резервация и полето за статус на регистъра съдържат същата основна информация,
която направиха за алгоритъма на Tomasulo (вижте страница 176 за описание на
тези полета). Разликата е, че номерата на станциите за резервации се сменят
с ROB входни номера в полетата Qj и Qk, както и в статуса на регистъра
полета и добавихме полето Dest към резервационните станции. Полето Dest
обозначава ROB записа, който е дестинацията за резултата, получен от това
влизане в резервационна станция.
Горният пример илюстрира ключовата важна разлика между процесор със спекулация и
процесор с динамично планиране. Сравнете съдържанието на Фигура 3.12 с това на Фигура 3.8 на
страница 179, което показва същото
кодова последователност при работа на процесор с алгоритъма на Tomasulo. Ключът
разликата е, че в примера по-горе не е позволено да завърши нито една инструкция след най-
ранната незавършена инструкция (MUL.D по-горе). За разлика от това, на фигура 3.8
инструкциите SUB.D и ADD.D също са завършени.
Едно следствие от тази разлика е, че процесорът с ROB може
динамично изпълнение на код, като същевременно поддържа прецизен модел на прекъсване. За
например, ако инструкцията MUL.D предизвика прекъсване, можем просто да изчакаме, докато
той достигна до главата на ROB и взе прекъсването, изчиствайки всички останали чакащи
инструкции от ROB. Тъй като ангажиментът на инструкция се случва по ред, това
дава точно изключение.
За разлика от това, в примера, използващ алгоритъма на Tomasulo, SUB.D и
Инструкциите ADD.D можеха и двете да бъдат изпълнени, преди MUL.D да повдигне изключението.
Вход Зает Инструкция състояние Дестинация Стойност
1 Не LD F6,32(R2) Ангажирайте се F6 Mem[32 + Regs[R2]]

2 Не LD F2,44(R3) Ангажирайте се F2 Mem[44 + Regs[R3]]
3 да МУЛ.Д F0, F2, F4 Напишете резултата F0 #2 × Правила[F4]
4 да ПОДП.Д F8, F2, F6 Напишете резултата F8 #2 - #1
5 да DIV.D F10, F0, F6 Изпълни F10
6 да ДОБ.Д F6, F8, F2 Напишете резултата F6 #4 + #2
Име Зает оп Vj Вк Qj Qk Цел А
Зареждане1 №
Зареждане 2 №
Множество 1 № МУЛ.Д Mem[44 + Regs[R3]] Regs[F4] #3
Мулт2 да DIV.D Mem[32 + Regs[R2]] #3 #5
Състояние на FP регистър
Поле F0 F1 F2 F3 F4 F5 F6 F7 F8 F10
Пренареждане # 3 6 4 5
Зает да Не Не Не Не Не да ... да да
Фигура 3.12 По времето, когато MUL.D е готов за ангажиране, само двете LD инструкции са ангажирани, въпреки че
няколко други са завършили изпълнението. MUL.D е начело на ROB, а двете LD инструкции са
там само за улесняване на разбирането. Инструкциите SUB.D и ADD.D няма да се ангажират до инструкцията MUL.D
ангажира, въпреки че резултатите от инструкциите са налични и могат да се използват като източници за други инструкции.
DIV.D е в изпълнение, но не е завършен единствено поради по-голямото си забавяне от MUL.D. Колоната Стойност
показва държаната стойност; форматът #X се използва за препратка към поле със стойност на ROB запис X. Пренареждане на буфери 1 и
2 са действително завършени, но са показани с информационна цел. Не показваме записите за товар/склад
опашка, но тези записи се поддържат в ред.
Резултатът е, че регистрите F8 и F6 (дестинациите на SUB.D и ADD.D

инструкции) могат да бъдат презаписани и прекъсването би било неточно.
Някои потребители и архитекти са решили, че неточни изключения с плаваща запетая са
приемливи във високопроизводителни процесори, тъй като програмата ще
вероятно прекратяване; вижте Приложение J за по-нататъшно обсъждане на тази тема. Други видове
на изключения, като грешки в страницата, са много по-трудни за приспособяване, ако
те са неточни, тъй като програмата трябва прозрачно да възобнови изпълнението след това
обработка на такова изключение.
Използването на ROB с ангажиране на инструкции в ред осигурява точни изключения, в
допълнение към поддържането на спекулативно изпълнение, както показва следващият пример.
Пример Разгледайте примера на код, използван по-рано за алгоритъма на Tomasulo и показан в

Фигура 3.10 в изпълнение:
MUL.D F4, F0, F2
SD F4,0(R1)
DADDIU R1,R1,#-8
BNE R1, R2, цикъл ; разклонения, ако R1¦R2
Да приемем, че сме издали всички инструкции в цикъла два пъти. Нека също
приемем, че LD и MUL.D от първата итерация са ангажирани и всичко
други инструкции са изпълнени. Обикновено магазинът чакаше
ROB както за ефективния адресен операнд (R1 в този пример), така и за стойността
(F4 в този пример). Тъй като разглеждаме само тръбопровода с плаваща запетая,
приемете, че ефективният адрес за магазина е изчислен към момента на изпълнение на инструкцията
е издадена.
Отговор Фигура 3.13 показва резултата в две таблици.
Вход Зает Инструкция състояние Дестинация Стойност
1 Не LD F0,0(R1) Ангажирайте се F0 Mem [0 +

Правила [R1]]
2 Не MUL.D F4,F0,F2 Ангажирайте се F4 #1 × Правила[F2]

3 да SD F4,0(R1) Напишете резултата 0 + Regs [R1] #2
4 да DADDIU R1,R1,#-8 Напишете резултата R1 Правила [R1] – 8

5 да BNE R1,R2,Кръг Напишете резултата
6 да LD F0,0(R1) Напишете резултата F0 Mem [#4]

7 да MUL.D F4,F0,F2 Напишете резултата F4 #6 × Правила[F2]
8 да SD F4,0(R1) Напишете резултата 0 + #4 #7
9 да DADDIU R1,R1,#-8 Напишете резултата R1 #4 – 8
10 да BNE R1, R2, цикъл Напишете резултата
Състояние на FP регистър
Поле F0 F1 F2 F3 F4 F5 F6 F7 F8
Пренареждане # 6 7
Зает да Не Не Не да Не Не ... Н
о
Фигура 3.13 Само инструкциите LD и MUL.D са ангажирани, въпреки че всички останали са завършили
екзекуция. Следователно нито една станция за резервации не е заета и нито една не се показва. Останалите инструкции ще бъдат ангажирани
възможно най-бързо. Първите два буфера за пренареждане са празни, но са показани за пълнота.
Тъй като нито стойностите на регистъра, нито стойностите на паметта всъщност се записват,
докато дадена инструкция не се ангажира, процесорът може лесно да отмени своите спекулативни
действия, когато се установи, че разклонението е неправилно предвидено. Да предположим, че
клонът BNE не е взет за първи път на Фигура 3.13. Инструкциите преди разклонението просто ще
се ангажират, когато достигнат главата на ROB; когато клонът достигне главата на този буфер,
буферът просто се изчиства и процесорът започва да извлича инструкции от другия път.
На практика процесорите, които спекулират, се опитват да се възстановят възможно най-рано,

след като даден клон е погрешно предвиден. Това възстановяване може да бъде направено чрез
изчистване на ROB за всички записи, които се появяват след погрешно предвидения клон,
позволявайки на онези, които са преди клона в ROB, да продължат и рестартиране на извличането
при правилния наследник на клона. В спекулативните процесори производителността е по-
чувствителна към прогнозата за клона, тъй като въздействието на погрешно прогнозиране ще
бъде по-голямо. По този начин всички аспекти на обработката на разклоненията - точност на
прогнозиране, латентност на откриване на грешно прогнозиране и време за възстановяване на
грешно прогнозиране - нарастват по важност.
Изключенията се обработват, като изключението не се разпознава, докато не е готово за
ангажиране. Ако спекулирана инструкция предизвика изключение, изключението се записва в ROB.
Ако възникне погрешно предвиждане на разклоняване и инструкцията не е трябвало да бъде
изпълнена, изключението се изтрива заедно с инструкцията, когато ROB се изчисти. Ако
инструкцията достигне до ръководителя на ROB, тогава знаем, че вече не е спекулативна и
изключението наистина трябва да бъде прието. Можем също така да се опитаме да обработим
изключения веднага щом възникнат и всички по-ранни разклонения бъдат разрешени, но това е
по-голямо предизвикателство в случай на изключения, отколкото при неправилно предвиждане на
разклонения и, тъй като се случва по-рядко, не е толкова критично.
Фигура 3.14 показва стъпките на изпълнение на дадена инструкция, както и условията, които
трябва да бъдат изпълнени, за да се премине към стъпката и предприетите действия. Ние показваме
случая, при който погрешно предвидените разклонения не са разрешени, докато не се ангажират.
Въпреки че спекулацията изглежда като просто допълнение към динамичното планиране,
сравнението на Фигура 3.14 със сравнимата фигура за алгоритъма на Tomasulo на Фигура 3.9
показва, че спекулацията добавя значителни усложнения към контрола. Освен това не забравяйте,
че погрешните прогнози за клонове също са малко по-сложни.
Има важна разлика в начина, по който се обработват магазините в спекулативен процесор

спрямо алгоритъма на Tomasulo. В алгоритъма на Tomasulo хранилището може да актуализира
паметта, когато достигне резултат от запис (което гарантира, че ефективният адрес е изчислен) и
стойността на данните за съхраняване е налична. В спекулативен процесор магазинът актуализира
паметта само когато достигне главата на ROB. Тази разлика гарантира, че паметта не се актуализира,
докато дадена инструкция вече не е спекулативна.
Фигура 3.14 има едно значително опростяване за магазините, което не е необходимо на

практика. Фигура 3.14 изисква запаметяванията да изчакват в етапа на запис на резултата за
операнда източник на регистър, чиято стойност трябва да бъде съхранена; след това стойността се
премества от полето Vk на резервационната станция на магазина в полето Стойност на ROB записа
на магазина. В действителност обаче стойността, която трябва да се съхранява, не трябва да пристига

Статус Изчакай докато Действие или счетоводство
Проблем if (RegisterStat[rs].Busy)/*in-flight instr. пише rs*/

{h RegisterStat[rs].Reorder; if
всички инструкции (ROB[h].Ready)/* Instr вече е завършен */
{RS[r].Vj ROB[h].Стойност; RS[r].Qj 0;}
else {RS[r].Qj h;} /* изчакайте инструкция */
Резервация
} else {RS[r].Vj Regs[rs]; RS[r].Qj 0;}; RS[r].Зает да; RS[r].Dest
станция (r) b; ROB[b].Инструкция опкод; ROB[b].Dest
и
rd;ROB[b].Ready no;
ROB (б)
FP и двете налични if (RegisterStat[rt].Busy) /*in-flight instr записва rt*/
операции {h RegisterStat[rt].Reorder; if
и магазини (ROB[h].Ready)/* Instr вече е завършен */
{RS[r].Vk ROB[h].Стойност; RS[r].Qk 0;}
else {RS[r].Qk h;} /* изчакайте инструкция */
} else {RS[r].Vk Regs[rt]; RS[r].Qk 0;}; RegisterStat[rd].Reorder
FP операции b; RegisterStat[rd].Busy да;

ROB[b].Dest rd;
Натоварвания RS[r].A imm; RegisterStat[rt].Reorder b; RegisterStat[rt].Busy
да; ROB[b].Dest rt;
Магазини RS[r].A imm;
Изпълни (RS[r].Qj == 0) и FP оп Резултати от изчислението — операндите са във Vj и Vk
(RS[r].Qk == 0)
Заредете стъпка 1 (RS[r].Qj == 0) и няма RS[r].A RS[r].Vj + RS[r].A;

магазини по-рано в
опашката
Зареждане на стъпка 2 Зареждане на стъпка 1 е Прочетете от Mem[RS[r].A]
готово и всички магазини
по-рано в ROB имат
различен адрес
Магазин (RS[r].Qj == 0) и ROB[h].Адрес RS[r].Vj + RS[r].A;

съхранява в главата на опашката.
Напишете резултата Изпълнението е извършено в r b RS[r].Dest; RS[r].Заето не;

всички, освен съхраняване и CDB налични x(ако (RS[x].Qj==b) {RS[x].Vj резултат; RS[x].Qj 0}); x(ако (RS[x].Qk==b)
{RS[x].Vk резултат; RS[x].Qk 0}); ROB[b].Стойност резултат; ROB[b].Готов
да;
Магазин Изпълнението е ROB[h].Стойност RS[r].Vk;
извършено при r и (RS[r].Qk == 0)
Инструкцията за ангажиране е в d ROB[h].Dest; /* регистриране dest, ако съществува */
началото на ROB if (ROB[h].Instruction==Branch)
(запис h) и {if (разклонението е погрешно предвидено)
ROB[h].ready == да {изчистване на ROB[h], RegisterStat; извличане на цел на клон;};}
иначе ако (ROB[h].Instruction==Store)
{Mem[ROB[h].Destination] ROB[h].Value;}
else /* поставя резултата в дестинацията на регистъра */
{Regs[d] ROB[h].Value;};
ROB[h].Зает не; /* освобождаване на запис в ROB */
/* освобождаване на dest регистър, ако никой друг не го пише */
if (RegisterStat[d].Reorder==h) {RegisterStat[d].Busy no;};
Фигура 3.14 Стъпки в алгоритъма и какво се изисква за всяка стъпка. За инструкцията за издаване, rd е дестинацията, rs и rt са
източниците, r е резервираната станция, b е присвоеният ROB запис и h е главният запис
на РОБ. RS е структурата на данните на резервационната станция. Стойността, върната от резервационна станция, се нарича резултат.
RegisterStat е структурата на регистърните данни, Regs представлява действителните регистри, а ROB е данните за буфера за пренареждане
структура.
до точно преди магазинът да се ангажира и може да бъде поставен директно в магазина

Въвеждане на ROB от инструкцията за източник. Това се постига, като хардуерът проследява кога
стойността на източника, която трябва да се съхрани, е налична в ROB на магазина
влизане и търсене в ROB при всяко завършване на инструкция за търсене на зависими магазини.
Това добавяне не е сложно, но добавянето му има два ефекта: Ние бихме

трябва да добавите поле към ROB и Фигура 3.14, която вече е с малък шрифт,
ще бъде още по-дълго! Въпреки че Фигура 3.14 прави това опростяване, в нашата
примери, ние ще позволим на магазина да премине през етапа на запис на резултата и просто ще изчакаме
стойността да бъде готова, когато се ангажира.

Подобно на алгоритъма на Томасуло, ние трябва да избягваме опасностите чрез паметта. WAW
и опасностите от ВОЙНА чрез паметта се елиминират със спекулации, защото
действителното актуализиране на паметта се извършва по ред, когато магазинът е начело на
ROB и, следователно, не могат да бъдат чакащи по-ранни зареждания или съхранявания. Опасности от RAW
през паметта се поддържат от две ограничения:
1. Не позволява на натоварване да инициира втората стъпка от изпълнението си, ако има такова
Записът в ROB, зает от магазин, има поле Дестинация, което съответства на стойността
на полето А на товара.
2. Поддържане на програмния ред за изчисляване на ефективен адрес на

натоварване по отношение на всички по-ранни магазини.
Заедно тези две ограничения гарантират, че всяко зареждане, което има достъп до място в паметта,
записано от по-ранен магазин, не може да извърши достъп до паметта, докато
магазинът е написал данните. Някои спекулативни процесори всъщност ще заобиколят
стойност от магазина към зареждането директно, когато възникне такава опасност от RAW.
Друг подход е да се предвидят потенциални сблъсъци, като се използва форма на прогнозиране на
стойността; разглеждаме това в раздел 3.9.
Въпреки че това обяснение на спекулативното изпълнение се фокусира върху плаващите

точка, техниките лесно се разширяват до целочислените регистри и функционалните единици.
Всъщност спекулациите могат да бъдат по-полезни в целочислени програми, тъй като такива програми
са склонни да имат код, където поведението на клона е по-малко предвидимо. Освен това,
тези техники могат да бъдат разширени, за да работят в процесор с множество издания, като позволяват
множество инструкции за издаване и ангажиране на всеки часовник. Всъщност спекулациите са
вероятно най-интересното в такива процесори, тъй като по-малко амбициозните техники могат
вероятно използват достатъчно ILP в рамките на основните блокове, когато се подпомагат от компилатор.
3.7 Използване на ILP с помощта на множество проблеми и

Статично планиране
Техниките от предходните раздели могат да се използват за премахване на данни, контрол

спира и да постигнете идеален CPI от един. За да подобрим допълнително представянето, ние
иска да намали CPI до по-малко от единица, но CPI не може да бъде намален
под единица, ако издаваме само една инструкция на всеки такт.

3.7 Използване на ILP чрез използване на множество проблеми и статично планиране 193
Целта на многопроблемните процесори, обсъдени в следващите няколко раздела,

е да позволи издаване на множество инструкции в един тактов цикъл. Процесорите с множество издания
се предлагат в три основни разновидности:
1. Статично планирани суперскаларни процесори
2. Процесори VLIW (много дълга дума с инструкции).
3. Динамично планирани суперскаларни процесори
Двата типа суперскаларни процесори издават различен брой инструкции

на часовник и използвайте изпълнение в ред, ако са статично планирани, или изпълнение извън ред, ако
са динамично планирани.
VLIW процесорите, за разлика от тях, издават фиксиран брой форматирани инструкции
или като една голяма инструкция, или като фиксиран пакет инструкции с паралелност между инструкциите,
изрично посочени от инструкцията. VLIW процесори
са присъщо статично планирани от компилатора. Когато Intel и HP създадоха
IA-64 архитектурата, описана в Приложение H, те също въведоха името
EPIC—изрично паралелен компютър с инструкции—за този архитектурен стил.
Въпреки че статично планираните суперскалари издават по-скоро вариращи, отколкото фиксирани
брой инструкции на такт, те всъщност са по-близки по концепция до VLIW,
тъй като и двата подхода разчитат на компилатора да планира код за процесора.
Поради намаляващите предимства на статично планиран суперскалар като
ширината на проблема нараства, статично планираните суперскалари се използват предимно за тесни
издава ширини, обикновено само две инструкции. Отвъд тази ширина повечето дизайнери
изберете да внедрите VLIW или динамично планиран суперскалар.
Поради приликите в хардуера и необходимата компилаторна технология, ние
фокусирайте се върху VLIW в този раздел. Прозренията на този раздел лесно се екстраполират
към статично планиран суперскалар.
Фигура 3.15 обобщава основните подходи към множество проблеми и тяхното разграничаване.
изчезващи характеристики и показва процесори, които използват всеки подход.
Основният VLIW подход

VLIW използват множество независими функционални единици. Вместо да се опитвате
издава множество независими инструкции към единиците, VLIW пакетира множеството операции в една
много дълга инструкция или изисква инструкциите в
проблемният пакет отговаря на същите ограничения. Тъй като няма фундаментално
разлика в двата подхода, ние просто ще приемем, че множеството операции са
поставени в една инструкция, както в оригиналния VLIW подход.
Тъй като предимството на VLIW се увеличава с нарастването на максималния процент на издаване,
ние се фокусираме върху по-широк проблем процесор. Наистина, за обикновени двуемисионни процесори,
режийните разходи на суперскалар вероятно са минимални. Много дизайнери вероятно биха го направили
твърдят, че процесорът с четири издания има управляеми разходи, но както ще видим
по-късно в тази глава нарастването на режийните разходи е основен фактор, ограничаващ по-широк проблем
процесори.
Структура График Отличителна

Често срещано име на издаването за откриване на опасност характеристика Примери
Суперскаларен Динамичен Хардуер Статично Изпълнение по ред Предимно във

(статичен) вграденото пространство:
MIPS и ARM,
включително ARM
Cortex-A8
Суперскаларен Динамичен Динамичен хардуер Известно извънредно В момента няма

(динамичен) изпълнение, но без
спекулации
Суперскаларен Динамичен Хардуерна динамика със спекулации Извънредно изпълнение със Intel Core i3, i5, i7;
(спекулативен) спекулация AMD Phenom; IBM
Мощност 7
VLIW/LIW Статично Предимно Статично Всички опасности, определени Повечето примери са в

софтуер и посочени от компилатора обработката на
(често имплицитно) сигнали, като TI C6x
EPIC Предимно Предимно Предимно статични Всички опасности, определени Итаний

статичен софтуер и посочени изрично от
компилатора
Фигура 3.15 Петте основни подхода, използвани за многобройни процесори и основните характеристики
които ги отличават. Тази глава се фокусира върху хардуерно интензивните техники, които са някаква форма на
суперскаларен. Приложение H се фокусира върху подходи, базирани на компилатор. Подходът EPIC, въплътен в архитектурата IA-64, разширява много
от концепциите на ранните VLIW подходи, осигурявайки смес от статично и динамично
подходи.
Нека разгледаме VLIW процесор с инструкции, които съдържат пет операции, включително
една целочислена операция (която също може да бъде разклонение), две
операции с плаваща запетая и две препратки към паметта. Инструкцията би
имат набор от полета за всяка функционална единица - може би 16 до 24 бита на единица, което
води до дължина на инструкцията между 80 и 120 бита. За сравнение, Intel
Itanium 1 и 2 съдържат шест операции на пакет инструкции (т.е. те позволяват
едновременно издаване на два пакета с три инструкции, както е описано в Приложение H).
За да поддържате функционалните звена заети, трябва да има достатъчно паралелизъм в кода
последователност за запълване на наличните работни слотове. Този паралелизъм се разкрива от
развиване на цикли и планиране на кода в едно по-голямо тяло на цикъл. Ако
разгръщането генерира праволинеен код, след това техники за локално планиране , които
работят върху един основен блок, могат да се използват. Ако намирането и използването на
паралелизма изисква код за планиране между клонове, значително по-сложен глобален
трябва да се използва алгоритъм за планиране . Глобалните алгоритми за планиране не са само
по-сложни по структура, но те също трябва да се справят със значително по-сложни компромиси
при оптимизацията, тъй като преместването на код между клоновете е скъпо.
В Приложение H ще обсъдим планирането на проследяване, една от тези техники за глобално
планиране, разработена специално за VLIW; ние също ще проучим специални
хардуерна поддръжка, която позволява някои условни разклонения да бъдат елиминирани,
разширяване на полезността на локалното планиране и подобряване на производителността на
глобално планиране.
3.7 Използване на ILP чрез използване на множество проблеми и статично планиране 195
Засега ще разчитаме на разгръщане на цикъл, за да генерираме дълъг, прав код
последователности, така че да можем да използваме локално планиране за изграждане на VLIW инструкции и
съсредоточете се върху това колко добре работят тези процесори.
Пример Да предположим, че имаме VLIW, който може да издаде две препратки към паметта, две FP операции и една
целочислена операция или разклонение във всеки тактов цикъл. Покажи ан
разгъната версия на цикъла x[i] = x[i] + s (вижте страница 158 за MIPS кода)
за такъв процесор. Развийте толкова пъти, колкото е необходимо, за да премахнете всички сергии.
Игнорирайте забавените разклонения.
Отговор Фигура 3.16 показва кода. Примката е развита, за да се направят седем копия
тялото, което елиминира всички сергии (т.е. напълно празни цикли на издаване), и
протича в 9 цикъла. Този код дава скорост на движение от седем резултата в 9 цикъла, или
1,29 цикъла на резултат, почти два пъти по-бързо от двупроблемния суперскалар на Section
3.2 , който използва разгънат и планиран код.
За оригиналния модел VLIW имаше както технически, така и логистични проблеми, които правят
подхода по-малко ефективен. Техническите проблеми са
увеличаване на размера на кода и ограниченията на lockstep операцията. Две различни
елементите се комбинират, за да увеличат значително размера на кода за VLIW. Първо, генерирането на
достатъчно операции в кодов фрагмент с права линия изисква амбициозни усилия
развиване на цикли (както в по-ранните примери), като по този начин увеличава размера на кода. Второ,
когато инструкциите не са пълни, неизползваните функционални единици се превеждат като пропилени
битове в кодирането на инструкциите. В Приложение H разглеждаме софтуерното планиране
Препратка Препратка FP FP Цяло число

към паметта 1 към паметта 2 операция 1 операция 2 операция/клон
LD F0,0(R1) LD F6,-8(R1)
LD F10,-16(R1) LD F14,-24(R1)
LD F18,-32(R1) LD F22,-40(R1) ДОБАВ.D F4,F0,F2 ДОБАВ.D F8,F6,F2
LD F26,-48(R1) ADD.D F12,F10,F2 ADD.D F16,F14,F2
ADD.D F20,F18,F2 ADD.D F24,F22,F2
SD F4,0(R1) SD F8,-8(R1) ДОБАВЯНЕ F28,F26,F2
SD F12,-16(R1) SD F16,-24(R1) DADDUI R1,R1,#-56
SD F20,24(R1) SD F24,16(R1)
SD F28,8(R1) BNE R1, R2, контур
Фигура 3.16 VLIW инструкции, които заемат вътрешния цикъл и заместват разгънатата последователност. Този код отнема 9
цикли, при които се приема, че няма забавяне на разклонението; обикновено забавянето на клона също трябва да бъде планирано. Процентът
на издаване е 23 операции в 9 тактови цикъла или 2,5 операции на цикъл. Ефективността, процентът на наличните слотове, които съдържат
операция, е около 60%. За да се постигне този процент на издаване, са необходими по-голям брой регистри, отколкото MIPS би използвал обикновено
този цикъл. VLIW кодовата последователност по-горе изисква поне осем FP регистъра, докато същата кодова последователност е за основата
MIPS процесорът може да използва най-малко два FP регистъра или до пет, когато е разгънат и планиран.
подходи, като софтуерен конвейер, които могат да постигнат предимствата на разгръщането без толкова
много разширяване на кода.
За да се пребори с това увеличаване на размера на кода, понякога се използват умни кодировки. За
например, може да има само едно голямо непосредствено поле за използване от всяка функционалност
мерна единица. Друга техника е да компресирате инструкциите в основната памет и
разширете ги, когато се четат в кеша или се декодират. В допълнение H,
ние показваме други техники, както и документираме значителното разширение на кода

видян на IA-64.
Ранните VLIW работеха в синхрон; нямаше хардуер за откриване на опасност
всичко. Тази структура диктува, че трябва да причини спиране във всеки тръбопровод на функционална единица
целият процесор да спре, тъй като всички функционални единици трябва да се поддържат синхронизирани.
Въпреки че компилаторът може да е в състояние да планира детерминистичния функционал
единици за предотвратяване на спирания, предвиждайки при кои достъпи до данни ще се натъкне на спиране на кеша
и планирането им е много трудно. Следователно кешовете трябваше да бъдат блокирани и
да доведе до спиране на всички функционални единици. Като процент на издаване и брой памет
препратките стават големи, това ограничение за синхронизация става неприемливо.
В по-новите процесори функционалните единици работят по-независимо и
компилаторът се използва за избягване на опасности по време на проблем, докато хардуерните проверки позволяват
за несинхронизирано изпълнение след издаване на инструкции.
Съвместимостта с двоичен код също е основен логистичен проблем за
VLIWs. При строг VLIW подход кодовата последователност използва и двете
дефиниране на набор от инструкции и подробна структура на конвейера, включително както функционални

единици, така и техните закъснения. По този начин различен брой функционални единици и
закъсненията на единиците изискват различни версии на кода. Това изискване прави
мигриране между последователни реализации или между реализации
с различна ширина на издаване, по-трудно, отколкото е за суперскаларен дизайн. На
Разбира се, получаването на подобрена производителност от нов суперскаларен дизайн може
изискват прекомпилиране. Независимо от това, възможността за стартиране на стари двоични файлове е
практическо предимство за суперскаларния подход.
Подходът EPIC, от който архитектурата IA-64 е основният пример,
предоставя решения на много от проблемите, срещани в ранните проекти на VLIW,
включително разширения за по-агресивни софтуерни спекулации и методи за
преодолейте ограничението на хардуерната зависимост, като същевременно запазите двоичната
съвместимост.
Основното предизвикателство за всички многопроблемни процесори е да се опитат да използват големи
количества ILP. Когато паралелизмът идва от развиване на прости цикли във FP
програми, оригиналният цикъл вероятно е могъл да се изпълнява ефективно на вектор
процесор (описан в следващата глава). Не е ясно дали многоемисионният процесор е предпочитан пред
векторния процесор за такива приложения; разходите са
подобни и векторният процесор обикновено е със същата скорост или по-бърз. Потенциалните предимства
на многобройния процесор спрямо векторния процесор са техни
способността да извличат някакъв паралелизъм от по-малко структуриран код и способността им да
лесно кеширане на всички форми на данни. Поради тези причини подходите за множество проблеми имат
стане основният метод за възползване от паралелизма на ниво инструкции,
и векторите са се превърнали предимно в разширение на тези процесори.

3.8 Използване на ILP чрез динамично планиране, множество проблеми и спекулации 197
3.8 Използване на ILP чрез динамично планиране, множество

Въпрос и спекулации
Досега видяхме как отделните механизми на динамично планиране,
множество проблеми и спекулации. В този раздел събираме и трите заедно,
което води до микроархитектура, доста подобна на тази в съвременните микропроцесори. За простота, ние
разглеждаме само процент на издаване от две инструкции на часовник,
но концепциите не се различават от съвременните процесори, които издават три или повече
инструкции на часовник.
Да приемем, че искаме да разширим алгоритъма на Tomasulo, за да поддържа суперскаларен тръбопровод
с множество проблеми с отделно цяло число, зареждане/съхранение и плаваща запетая
единици (както FP умножение, така и FP добавяне), всяка от които може да инициира операция върху
всеки часовник. Не искаме да издаваме инструкции на резервационните станции извън
ред, тъй като това може да доведе до нарушаване на семантиката на програмата. За да спечелите
пълното предимство на динамичното планиране ще позволим на тръбопровода да издава всякакви
комбинация от две инструкции в часовник, използвайки хардуера за планиране
действително присвоява операции на целите числа и единиците с плаваща запетая. Тъй като
взаимодействието на целите числа и инструкциите с плаваща запетая е от решаващо значение, ние също разширяваме
Схемата на Томасуло за справяне както с целочисления, така и с плаващата запетая
единици и регистри, както и включване на спекулативно изпълнение. Както фигура 3.17
показва, че основната организация е подобна на тази на процесор със спекулации
с едно издаване на часовник, с изключение на това, че логиката за издаване и завършване трябва да бъде
подобрена, за да позволи множество инструкции да бъдат обработени на часовник.
Издаване на множество инструкции на такт в динамично планиран процесор
(със или без спекулации) е много сложно поради простата причина, че множеството инструкции могат да
зависят една от друга. Поради това таблиците трябва да бъдат
актуализиран за инструкциите паралелно; в противен случай таблиците ще бъдат неправилни или
зависимостта може да се загуби.
Използвани са два различни подхода за издаване на множество инструкции на
часовник в динамично планиран процесор и двете разчитат на наблюдението, че
ключът е присвояване на станция за резервация и актуализиране на таблиците за управление на тръбопровода.
Един подход е да изпълните тази стъпка на половин часовников цикъл, така че две инструкции да могат
да се обработват в един такт; този подход не може лесно да бъде разширен, за да обработва четири инструкции
на такт, за съжаление.
Втората алтернатива е да се изгради логиката, необходима за справяне с две или повече
инструкции наведнъж, включително всякакви възможни зависимости между инструкциите. Съвременните
суперскаларни процесори, които издават четири или повече инструкции на
clock може да включва и двата подхода: те едновременно конвейеризират и разширяват проблема
логика. Ключово наблюдение е, че не можем просто да отстраним проблема. от
проблемите с инструкциите отнемат няколко часовника, тъй като нови инструкции се издават на всеки такт,
трябва да можем да присвоим резервационната станция и да
актуализиране на тръбопроводните таблици, така че зависима инструкция да се издаде на следващия
часовникът може да използва актуализираната информация.
Тази стъпка на проблем е едно от най-фундаменталните тесни места в динамично
планирани суперскалари. За да илюстрира сложността на този процес, фигура 3.18

Рег. № Данни
опашка
Целочислени и FP регистри
Операнд
Адресна единица Операции с автобуси
плаваща запетая
Адрес 3 2 2
на магазина 2 Резервация 1 1
1 станции
Съхранявайте данни Адрес

:,7а
н
53а 8
нн 3уи
в
р
еръ сн
,гр
т8тн
т,ъ 3каев
тн ъм
ю
е
д2 ,м
ач
и 1
о
дсп
ти хN
ф
и
:гл рсм
1о
0 оъ
утеB
1
8
в
рд
нх
л кн
й
р
0
7
оа ;г,еI.©
S.ж
т,М е
п
К
Б
о
0
2
9
а П
Л
Д
А
Х
Единица памет FP суматори FP множители Цяло числова единица
Заредете
данни
Фигура 3.17 Основната организация на процесор с множество проблеми със спекулации. В този случай организацията може да позволи FP
умножение, FP добавяне, цяло число и зареждане/съхраняване за всички проблеми едновременно (приемайки, че един проблем на часовник на
функционална единица). Обърнете внимание, че няколко пътеки на данни трябва да бъдат разширени, за да поддържат множество проблеми:
CDB, операндните шини и, което е критично, логиката на издаване на инструкции, която не е показана на тази фигура. Последното е труден
проблем, както обсъждаме в текста.
показва логиката на проблема за един случай: издаване на зареждане, последвано от

зависима FP операция. Логиката се основава на тази от Фигура 3.14 на страница 191, но
представлява само един случай. В модерен суперскалар трябва да се вземе предвид всяка
възможна комбинация от зависими инструкции, която е позволена да издава в един и същ тактов цикъл.
Тъй като броят на възможностите нараства като квадрат на броя инструкции, които могат
да бъдат издадени в часовник, проблемната стъпка е вероятно тясно място за опити да се
надхвърли четири инструкции на часовник.
Можем да обобщим подробностите на Фигура 3.18 , за да опишем основната стратегия
за актуализиране на логиката на проблемите и таблиците за резервации в динамично
планиран суперскалар с до n проблеми на такт, както следва:
Действие или счетоводство Коментари
if (RegisterStat[rs1].Busy)/*in-flight instr. пише rs*/ Актуализиране на резервационните таблици за

{h RegisterStat[rs1].Reorder; if инструкцията за зареждане, която има един операнд източник.
(ROB[h].Ready)/* Instr вече е завършен */ Тъй като това е първата инструкция в този пакет с
{RS[r1].Vj ROB[h].Стойност; RS[r1].Qj 0;} проблеми, тя не изглежда по-различно от това, което
else {RS[r1].Qj h;} /* изчакване на инструкция */ обикновено се случва при зареждане.
} else {RS[r1].Vj Regs[rs]; RS[r1].Qj 0;}; RS[r1].Зает да;
RS[r1].Dest b1; ROB[b1].Инструкция Зареждане;
ROB[b1].Цел rd1;
ROB[b1].Готов не;
RS[r].A imm1; RegisterStat[rt1].Reorder b1; RegisterStat[rt1].Busy
да; ROB[b1].Dest rt1;
RS[r2].Qj b1;} /* изчакайте инструкция за зареждане */ Тъй като знаем, че първият операнд на FP операцията
е от натоварването, тази стъпка просто
актуализира резервационната станция, за да сочи
към товара. Забележете, че зависимостта
трябва да се анализира в движение и ROB записите
трябва да бъдат разпределени по време на тази
стъпка на проблем, така че таблиците за
Тъй като
резервации да могат да бъдат правилно актуализирани. if (RegisterStat[rt2].Busy) /*in-flight предположихме,
instr записва rt*/ че вторият операнд на
{h RegisterStat[rt2].Reorder; if (ROB[h].Ready)/ FP инструкцията е от пакет от предишни издания,
* Instr вече е завършен */ тази стъпка изглежда така, както би изглеждала в
{RS[r2].Vk ROB[h].Стойност; RS[r2].Qk 0;} случая с единичен проблем. Разбира се,
else {RS[r2].Qk h;} /* изчакайте инструкция */ ако тази инструкция зависи от нещо в същия
} else {RS[r2].Vk Regs[rt2]; RS[r2].Qk 0;}; RegisterStat[rd2].Reorder пакет от проблеми, таблиците ще трябва да се
b2; RegisterStat[rd2].Busy да; актуализират с помощта на присвоения резервен буфер.
ROB[b2].Dest rd2;
RS[r2].Зает да; RS[r2].Dest b2; ROB[b2].Инструкция Този раздел просто актуализира таблиците за FP
FP операция; ROB[b2].Dest rd2; операцията и е независим от натоварването.
ROB[b2].Готов не; Разбира се, ако по-нататъшните инструкции в
този пакет с проблеми зависят от FP операцията
(както може да се случи със суперскалар с
четири издания), актуализациите на таблиците
за резервации за тези инструкции ще бъдат повлияни от тази инс
Фигура 3.18 Проблемните стъпки за двойка зависими инструкции (наречени 1 и 2), където инструкция 1 е FP зареждане
и инструкция 2 е FP операция, чийто първи операнд е резултатът от инструкцията за зареждане; r1 и r2 са
определени резервационни станции за инструкциите; и b1 и b2 са присвоените записи в буфера за пренареждане. За
издаване на инструкции, rd1 и rd2 са дестинациите; rs1, rs2 и rt2 са източниците (зареждането има само един
източник); r1 и r2 са резервираните станции; и b1 и b2 са присвоените ROB записи. RS е структурата на данните за станцията за
резервации. RegisterStat е структурата на данните на регистъра, Regs представлява действителните регистри,
и ROB е структурата на данните на буфера за пренареждане. Забележете, че за това трябва да сме присвоили записи в буфера за пренареждане
логика за правилно функциониране и припомнете си, че всички тези актуализации се случват в един часовник паралелно, а не
последователно!
1. Задайте станция за резервация и буфер за пренареждане за всяка инструкция, която
може да бъде издаден в следващия пакет от издания. Тази задача може да бъде направена преди
типовете инструкции са известни чрез просто предварително разпределяне на буфера за пренареждане
записи последователно към инструкциите в пакета, като се използва n наличен пренареждане
буферни записи и като се уверите, че има достатъчно станции за резервация
да издаде целия пакет, независимо от това какво съдържа. Чрез ограничаване на
брой инструкции от даден клас (да речем, един FP, едно цяло число, едно зареждане,
един магазин), необходимите резервационни станции могат да бъдат предварително

разпределени. Ако достатъчно резервирани станции не са налични (като при следващите няколко
всички инструкции в програмата са от един тип инструкции), пакетът е повреден и само
подмножество от инструкциите в оригиналния ред на програмата е
издаден. Останалите инструкции в пакета могат да бъдат поставени в
следващ пакет за потенциален проблем.
2. Анализирайте всички зависимости между инструкциите в проблемния пакет.
3. Ако инструкция в пакета зависи от по-ранна инструкция в пакета,

използвайте присвоения номер на буфер за пренареждане, за да актуализирате таблицата за резервации за
зависима инструкция. В противен случай използвайте съществуващата таблица за резервации и
информация за буфера за пренареждане, за да актуализирате записите в таблицата за резервации за издаването

инструкция.
Разбира се, това, което прави горното много сложно, е, че всичко се прави паралелно
в един такт!
В задния край на тръбопровода трябва да можем да завършим и да се ангажираме
множество инструкции на часовник. Тези стъпки са малко по-лесни от проблема
проблеми, тъй като множество инструкции, които всъщност могат да се ангажират в един и същи часовник
цикъл трябва вече да е разгледал и разрешил всякакви зависимости. Както щем
Вижте, дизайнерите са измислили как да се справят с тази сложност: Intel i7,
който разглеждаме в раздел 3.13, използва по същество схемата, която имаме
описан за спекулативна множествена емисия, включително голям брой резервации
станции, буфер за пренареждане и буфер за зареждане и съхраняване, който също се използва за обработка
пропуски на неблокиращ кеш.

От гледна точка на ефективността можем да покажем как концепциите си пасват
с пример.
Пример Да разгледаме изпълнението на следния цикъл, който увеличава всеки елемент от

масив с цели числа, на процесор с два броя, веднъж без спекулации и веднъж
със спекулации:
цикъл: LD R2,0(R1) ;R2=елемент от масив

DADDIU R2,R2,#1 ;увеличете R2
SD R2,0(R1) ;запазете резултата
DADDIU R1,R1,#8 ;указател за
BNE R2, R3, LOOP увеличаване ;клон, ако не е последният елемент
Да приемем, че има отделни целочислени функционални единици за ефективен адрес

изчисление, за ALU операции и за оценка на състоянието на клона. Създавам
таблица за първите три итерации на този цикъл за двата процесора. Приеми това
до две инструкции от всякакъв тип могат да се ангажират на часовник.
Отговор Фигури 3.19 и 3.20 показват производителността за двуемисионен процесор с динамично планиране,
без и със спекулации. В този случай, където може да бъде клон
критичен ограничител на производителността, спекулациите помагат значително. Третият клон в
Достъп до
Проблеми при Изпълнява се паметта при Запишете CDB на
Повторение номер на при номер на номер на номер на
номер Инструкции тактовия цикъл тактовия цикъл тактовия цикъл часовников цикъл Коментирайте
1 LD R2,0(R1) 1 2 3 4 Първи проблем
1 DADDIU R2,R2,#1 1 5 6 Изчакайте LW
1 SD R2,0(R1) 2 3 7 Изчакайте DADDIU
1 DADDIU R1,R1,#8 2 3 4 Изпълнете директно
1 BNE R2, R3, LOOP 3 7 Изчакайте DADDIU
2 LD R2,0(R1) 4 8 9 10 Изчакайте BNE
2 DADDIU R1,R1,#8 5 8 9 Изчакайте BNE
3 LD R2,0(R1) 7 14 15 16 Изчакайте BNE
3 DADDIU R1,R1,#8 8 14 15 Изчакайте BNE
Фигура 3.19 Времето на издаване, изпълнение и резултатът от писане за двойна версия на нашия конвейер без
спекулация. Имайте предвид, че LD след BNE не може да започне изпълнение по-рано, защото трябва да изчака до разклонението
резултатът се определя. Този тип програма, със зависещи от данни разклонения, които не могат да бъдат разрешени по-рано, показва
силата на спекулацията. Отделни функционални единици за изчисляване на адреси, ALU операции и разклонение
оценката позволява множество инструкции за изпълнение в един и същи цикъл. Фигура 3.20 показва този пример със спекулации.
спекулативният процесор се изпълнява в тактов цикъл 13, докато се изпълнява в часовник

цикъл 19 на неспекулативния тръбопровод. Тъй като процентът на завършване на неспекулативния
тръбопровод изостава бързо от процента на издаване, неспекулативният
тръбопроводът ще спре, когато бъдат издадени още няколко итерации. Изпълнението на
неспекулативният процесор може да бъде подобрен чрез разрешаване на инструкции за зареждане
завършете изчислението на ефективния адрес, преди да бъде взето решение за клон, но освен ако
спекулативните достъпи до паметта са разрешени, това подобрение ще спечели само 1
часовник на итерация.
Този пример ясно показва как спекулациите могат да бъдат изгодни, когато са налице
са зависими от данни клонове, които иначе биха ограничили производителността. Това
предимството обаче зависи от точното прогнозиране на клона. Неправилната спекулация не
подобрява производителността; всъщност това обикновено вреди на производителността и,
както ще видим, драматично намалява енергийната ефективност.
Пишете
Проблеми Изпълнява Достъп за четене CDB на
Номер на с номера на се на на
итерация Инструкции часовника часовников номер часовников номерчасовник номер
Ангажименти на часовник номер Коментар
1 LD R2,0(R1) 1 2 3 4 5 Първи проблем
1 DADDIU R2,R2,#1 1 5 6 7 Изчакайте LW
1 DADDIU R1,R1,#8 2 3 4 8 Ангажирайте се по ред
1 BNE R2, R3, LOOP 3 7 8 Изчакайте DADDIU
2 LD R2,0(R1) 4 5 6 7 9 Без забавяне на изпълнението
2 DADDIU R1,R1,#8 5 6 7 11 Ангажирайте се по ред
3 LD R2,0(R1) 7 8 9 10 12 Възможно най-рано
3 DADDIU R1,R1,#8 8 9 10 14 Изпълнява се по-рано
Фигура 3.20 Времето на издаване, изпълнение и резултат от писане за двойна версия на нашия конвейер със спекулация. Обърнете
внимание, че LD след BNE може да започне изпълнение по-рано, защото е спекулативен.
3.9 Разширени техники за доставка на инструкции и

спекулации
В конвейер с висока производителност, особено такъв с множество проблеми, предвиждане

клони добре не е достатъчно; ние всъщност трябва да можем да доставим поток от инструкции с
висока честотна лента. В последните многобройни процесори това означаваше
предоставяне на 4 до 8 инструкции на всеки такт. Първо разглеждаме методите за увеличаване на
честотната лента за доставка на инструкции. След това се обръщаме към набор от ключови въпроси
прилагане на усъвършенствани спекулативни техники, включително използването на регистър
преименуване срещу пренареждане на буфери, агресивността на спекулациите и техника, наречена
прогнозиране на стойността, която се опитва да предскаже резултата от изчисление и която може
допълнително да подобри ILP.
Увеличаване на честотната лента за извличане на инструкции
Процесорът с няколко издания ще изисква средния брой инструкции

извличането на всеки тактов цикъл да бъде поне толкова голямо, колкото средната пропускателна способност. На
Разбира се, извличането на тези инструкции изисква достатъчно широки пътища до инструкцията
кеш, но най-трудният аспект е обработката на клонове. В този раздел разглеждаме
два метода за работа с разклонения и след това обсъдете как съвременните процесори
интегрират функциите за предсказване на инструкции и предварително извличане.
Разклонение-целеви буфери
За да намалим наказанието за разклоняване за нашия прост конвейер с пет етапа, както и за по-
дълбоки конвейери, трябва да знаем дали все още недекодираната инструкция е разклонение и
ако е така, какъв трябва да бъде следващият програмен брояч (PC). Ако инструкцията е
разклонение и знаем какъв трябва да бъде следващият компютър, можем да имаме наказание за
разклоняване от нула. Кеш за предвиждане на разклонения, който съхранява предвидения адрес
за следващата инструкция след разклонение, се нарича буфер за цел за разклоняване или кеш за
цел за разклоняване. Фигура 3.21 показва буфер за разклонение-цель.
Тъй като буферът за цел на разклонение предвижда адреса на следващата инструкция и ще
го изпрати преди декодирането на инструкцията, трябва да знаем дали изтеглената инструкция
е предвидена като взето разклонение. Ако компютърът на извлечената инструкция съответства
на адрес в буфера за прогнозиране, тогава съответният прогнозиран компютър се използва като
следващ компютър. Хардуерът за този буфер за разклоняване е по същество идентичен с
хардуера за кеш.
PC с инструкции за извличане
Погледни нагоре
Предвиден компютър
Брой записи
в буфера
за целта
на
клона
Не: инструкцията е
= не се предвижда да Клон,
бъде клон; продължете нормално предвиден

взет или
невзет
Да: тогава инструкцията се разклонява и се предвижда
Компютърът трябва да се използва като следващ компютър
Фигура 3.21 Буфер за цел на клон. PC на извличаната инструкция се съпоставя с набор от адреси на инструкции, съхранени
в първата колона; те представляват адресите на известни клонове. Ако PC съответства на един от тези записи, тогава
извличаната инструкция е взето разклонение, а второто поле, прогнозиран PC, съдържа прогнозата за следващия PC след
разклонението. Извличането започва веднага на този адрес. Третото поле, което не е задължително, може да се използва
за допълнителни битове на състояние на прогнозиране.
Ако съвпадащ запис бъде намерен в буфера за цел на клон, извличането започва незабавно
на предвидения компютър. Обърнете внимание, че за разлика от буфера за предвиждане на
разклонения, предсказуемият запис трябва да бъде съпоставен с тази инструкция, тъй като
прогнозираният компютър ще бъде изпратен, преди да се знае дали тази инструкция е дори
разклонение. Ако процесорът не провери дали записът съответства на този компютър, тогава
грешният компютър ще бъде изпратен за инструкции, които не са разклонения, което води до
по-лоша производителност. Трябва само да съхраним предвидените взети разклонения в
целевия буфер за разклонения, тъй като непоетият разклонение трябва просто да извлече
следващата последователна инструкция, сякаш не е разклонение.
Фигура 3.22 показва стъпките при използване на клон-целеви буфер за обикновен
петстепенен конвейер. От тази фигура можем да видим, че няма да има забавяне на клона
Изпращане на компютър към
паметта и буфера за целта на клона
АКО
Не Намерен е запис да
в буфера за цел
на клон?
Изпратете
предвидено
Не Инструкцията да
взет клон
ли е?
документ за самоличност
Не Взет да
Нормално
клон?
изпълнение на
инструкциите
Неправилно разклоняване, Правилно предвиден

Въведете адреса на унищожаване на извлечена клон;
EX инструкциите за клон и след това
инструкция; рестартирайте продължете
PC в буфера за цел извличането при друга цел; изпълнението без забавяне
на клон изтриване на запис от целевия буфер
Фигура 3.22 Стъпките, включени в обработката на инструкция с буфер за разклоняване.

Инструкция в буфера Прогноза Действителен клон Наказателни цикли
да Взета Взета 0
да Взета Не е взето 2
Не Взета 2
Не Не е взето 0
Фигура 3.23 Наказания за всички възможни комбинации дали клонът е в

буфер и какво всъщност прави, ако приемем, че съхраняваме само взети клонове в
буфер. Няма наказание за клон, ако всичко е правилно предвидено и клонът е такъв
намерени в целевия буфер. Ако разклонението не е правилно предвидено, наказанието е равно
до един тактов цикъл, за да актуализирате буфера с правилната информация (по време на който ан
инструкцията не може да бъде извлечена) и един тактов цикъл, ако е необходимо, за рестартиране на извличането на
следващата правилна инструкция за клона. Ако клонът не бъде намерен и взет, два цикъла
се среща наказание, през което време буферът се актуализира.
ако в буфера е намерен запис за предсказване на разклонения и предсказанието е правилно.
В противен случай ще има наказание от поне два тактови цикъла. Справяне с
грешни прогнози и пропуски е значително предизвикателство, тъй като обикновено ще имаме
за спиране на извличането на инструкции, докато пренаписваме записа в буфера. По този начин бихме искали да
направете този процес бърз, за да сведете до минимум наказанието.
За да оценим колко добре работи буферът за целта на клона, първо трябва да определим
наказанията във всички възможни случаи. Фигура 3.23 съдържа тази информация за прост петстепенен
тръбопровод.
Пример Определете общото наказание за разклоняване за буфер за цел на разклонение, като приемете циклите на наказание
за отделни грешни прогнози от Фигура 3.23. Направете следното
предположения относно точността на прогнозата и процента на попадение:
Точността на прогнозата е 90% (за инструкции в буфера).
Процентът на попадение в буфера е 90% (за клонове, предвидени заети).
Отговор Изчисляваме наказанието, като разглеждаме вероятността от две събития: разклонението е
предвидено взето, но в крайна сметка не е взето, и клонът е взет, но не е
намерени в буфера. И двете носят наказание от два цикъла.
=
Вероятност (разклонение в буфера, но всъщност не е заето) Процент × Процент неправилни прогнози
на попадение в буфера
= 90% 10% × = 0,09
Вероятност (клон не е в буфера, но действително е взет) 10% =

+ ×2
Наказание за клон = (0,09 0,10)
Наказание за клон 0,38 =
Това наказание се сравнява с наказанието за клонове за забавени клонове, което ние
оценете в Приложение C, от около 0,5 тактови цикъла на клон. Помня,
въпреки това, че подобрението от динамичното предсказване на разклоненията ще нараства с нарастването

дължината на тръбопровода и следователно забавянето на клона нараства; в допълнение, по-добри предсказатели
ще донесе по-голямо предимство в производителността. Модерни високопроизводителни процесори
имат закъснения при погрешно предвиждане на разклонения от порядъка на 15 тактови цикъла; ясно е, че
точното прогнозиране е критично!
Една вариация на буфера за разклонение-цель е да съхранява една или повече цели
инструкции вместо или в допълнение към предвидения целеви адрес. Тази вариация има две потенциални
предимства. Първо, той позволява достъп до буфера на целта на клона
да отнеме повече от времето между последователните извличания на инструкции, вероятно
позволявайки по-голям буфер за разклонение. Второ, буферирането на действителните целеви инструкции
ни позволява да извършим оптимизация, наречена сгъване на разклонения. Сгъване на клон
може да се използва за получаване на безусловни разклонения с 0 цикъла и понякога условни разклонения

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

инструкцията, която се връща от кеша (която е безусловната
клон). Ако процесорът издава множество инструкции на цикъл, тогава буферът
ще трябва да предостави множество инструкции, за да получи максимална полза. В някои
случаи може да е възможно да се елиминират разходите за условен клон.
Предсказатели на адрес за връщане
Докато се опитваме да увеличим възможността и точността на спекулациите, ние се сблъскваме с
предизвикателство за предвиждане на косвени скокове, т.е. скокове, чийто целеви адрес
варира по време на изпълнение. Въпреки че езиковите програми на високо ниво ще генерират такива
скокове за индиректни извиквания на процедури, оператори select или case и изчислени с FORTRAN gotos,
по-голямата част от индиректните скокове идват от процедура
се завръща. Например за показателите SPEC95 връщанията на процедурата отчитат
повече от 15% от клоновете и по-голямата част от индиректните скача
средно аритметично. За обектно-ориентирани езици като C++ и Java процедурата се връща
са още по-чести. Следователно фокусирането върху процедурата за връщане изглежда подходящо.
Въпреки че връщанията на процедурата могат да бъдат предвидени с буфер за цел на разклонение, the
точността на такава техника за прогнозиране може да бъде ниска, ако процедурата се извика от
множество сайтове и обажданията от един сайт не са групирани във времето. Например в
SPEC CPU95, агресивен предсказващ разклонения постига точност по-малка от
60% за такива клонове за връщане. За да преодолеят този проблем, някои дизайни използват малък
буфер от адреси за връщане, работещи като стек. Тази структура кешира най-много
скорошни адреси за връщане: натискане на адрес за връщане в стека при повикване и изскачане
еднократно при връщане. Ако кешът е достатъчно голям (т.е. толкова голям, колкото максимумът
дълбочина на повикване), той ще предвиди перфектно възвръщаемостта. Фигура 3.24 показва производителността
на такъв буфер за връщане с 0 до 16 елемента за номер на SPEC CPU95
бенчмаркове. Ще използваме подобен предиктор на възвращаемостта, когато разглеждаме проучванията на

70%
Отивам
m88ksim
cc1
60%
Компресирайте
Xlisp
Ijpeg
50% Perl
Вихър
40%
ктсе
ознаш
енав аЧ
р
о
сге
те
одр н
п
30%
20%
10%
0%
0 124 8 16
Записи в буфера на адреса за връщане
Фигура 3.24 Точност на предсказване за буфер на адрес за връщане, работещ като стек на редица
тестове за сравнение на SPEC CPU95. Точността е частта от адресите за връщане, предвидени
правилно. Буфер от 0 записа означава, че се използва стандартното предсказване на разклоненията.
Тъй като дълбочините на повикванията обикновено не са големи, с някои изключения, скромният
буфер работи добре. Тези данни идват от Skadron et al. [1999] и използвайте механизъм за
коригиране, за да предотвратите повреда на кешираните адреси за връщане.
ILP в раздел 3.10. Както процесорите Intel Core, така и процесорите AMD Phenom имат предсказващи
адреси за връщане.
Интегрирани единици за извличане на инструкции
За да отговорят на изискванията на многобройните процесори, много скорошни дизайнери избраха да

внедрят интегрирана единица за извличане на инструкции като отделна автономна единица, която
подава инструкции към останалата част от конвейера. По същество това се равнява на признаването, че
характеризирането на извличането на инструкции като обикновен етап с една тръба, като се има предвид
сложността на множество проблеми, вече не е валидно.
Вместо това, последните проекти използват интегриран блок за извличане на инструкции, който
интегрира няколко функции:
1. Интегрирано предсказване на разклоненията – Прогнозиращият разклонения става част от единицата

за извличане на инструкции и непрекъснато предсказва разклоненията, така че да управлява
конвейера за извличане.
2. Предварително извличане на инструкции – За да достави множество инструкции на такт, модулът за извличане
на инструкции вероятно ще трябва да извлича предварително. Устройството управлява автономно
предварителното извличане на инструкции (вижте глава 2 за обсъждане на
техники за извършване на това), интегрирайки го с прогнозиране на разклонения.
3. Достъп до паметта на инструкциите и буфериране – При извличане на множество инструкции на цикъл се срещат
различни усложнения, включително трудността, че извличането на множество инструкции може да изисква
достъп до множество кеша
линии. Модулът за извличане на инструкции капсулира тази сложност, използвайки предварително извличане
за да се опитате да скриете разходите за пресичане на кеш блокове. Модулът за извличане на инструкции също
осигурява буфериране, като по същество действа като единица при поискване за предоставяне
инструкции към етапа на издаване при необходимост и в необходимото количество.
На практика всички процесори от висок клас сега използват отделен модул за извличане на инструкции, свързан с
останалата част от конвейера чрез буфер, съдържащ чакащи инструкции.
Спекулации: Проблеми с внедряването и разширения
В този раздел ние изследваме четири въпроса, които включват компромисите на дизайна в спекулациите,
започвайки с използването на преименуване на регистър, подходът, който често се използва
вместо буфер за пренареждане. След това обсъждаме едно важно възможно разширение на
спекулации върху контролния поток: идея, наречена прогнозиране на стойността.
Поддръжка на спекулации: Преименуване на регистър срещу пренареждане на буфери
Една алтернатива на използването на буфер за пренареждане (ROB) е изричното използване на по-голям
физически набор от регистри, комбиниран с преименуване на регистър. Този подход изгражда
върху концепцията за преименуване, използвана в алгоритъма на Tomasulo и я разширява. в
Алгоритъмът на Tomasulo, стойностите на архитектурно видимите регистри (R0, …,
R31 и F0, …, F31) се съдържат във всяка точка на изпълнение в някаква комбинация от регистрационен набор и
станции за резервация. С добавянето на спекулации стойностите на регистъра също могат временно да пребивават
в ROB. И в двата случая, ако
процесорът не издава нови инструкции за определен период от време, всички съществуващи
инструкциите ще се ангажират и стойностите на регистъра ще се появят в регистърния файл,
което пряко кореспондира с архитектурно видимите регистри.
При подхода за преименуване на регистъра се използва разширен набор от физически регистри
използвани за съхраняване както на архитектурно видимите регистри, така и на временни стойности.
По този начин разширените регистри заместват по-голямата част от функцията на ROB и станциите за резервации;
само опашка, за да се гарантира, че инструкциите са изпълнени в ред
необходими. По време на издаване на инструкции процесът на преименуване картографира имената на
архитектурните регистри към номерата на физическите регистри в разширения набор от регистри, разпределяйки
нов неизползван регистър за дестинацията. Опасностите от WAW и WAR се избягват
чрез преименуване на целевия регистър и възстановяването на спекулациите се обработва
тъй като физически регистър, съдържащ дестинация на инструкция, не става
архитектурния регистър до ангажимента на инструкцията. Картата за преименуване е a
проста структура от данни, която предоставя номера на физическия регистър на регистъра

3.9 Разширени техники за доставка на инструкции и спекулации 209
който в момента съответства на посочения архитектурен регистър, функция, изпълнявана от

таблицата за състояние на регистъра в алгоритъма на Tomasulo. Когато инструкция
извършва, таблицата за преименуване се актуализира постоянно, за да покаже, че физически
регистърът съответства на действителния архитектурен регистър, като по този начин ефективно се финализира
актуализация на състоянието на процесора. Въпреки че ROB не е необходим с регистър

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

инструкцията commit е леко опростена, тъй като изисква само две прости
действия: (1) запишете, че съпоставянето между номер на архитектурен регистър и
номерът на физическия регистър вече не е спекулативен и (2) освобождаване на всички физически
регистри, използвани за съхраняване на „по-старата“ стойност на архитектурния регистър. В
дизайн с резервирани станции, станция се освобождава, когато инструкцията я използва
завършва изпълнението и ROB запис се освобождава, когато съответният
инструкция ангажименти.
С преименуването на регистъра освобождаването на регистрите е по-сложно от преди

освободим физически регистър, трябва да знаем, че той вече не съответства на
архитектурен регистър и че не остават допълнителни употреби на физическия регистър. Физическият
регистър съответства на архитектурен регистър, докато архитектурният регистър не бъде
пренаписан, което кара таблицата за преименуване да сочи другаде. Това е,
ако нито един вход за преименуване не сочи към определен физически регистър, тогава той вече не
отговаря на архитектурен регистър. Възможно е обаче все още да има употреби на
физически регистър неизпълнен. Процесорът може да определи дали това е
случай чрез изследване на спецификаторите на регистъра източник на всички инструкции в
опашките на функционалните единици. Ако даден физически регистър не фигурира като източник и то
не е определен като архитектурен регистър, той може да бъде възстановен и преразпределен.
Като алтернатива, процесорът може просто да изчака друга инструкция, която
пише същия архитектурен регистър ангажименти. В този момент не може да има по-нататъшно
използване на остарялата по-стара стойност. Въпреки че този метод може да свърже физически
регистър малко по-дълго от необходимото, той е лесен за изпълнение и се използва в
най-новите суперскалари.
Един въпрос, който може би задавате, е как изобщо да разберем кои са регистрите
архитектурните регистри, ако постоянно се променят? През повечето време, когато
програмата се изпълнява, няма значение. Явно обаче има случаи,
където друг процес, като например операционната система, трябва да може да знае
точно където се намира съдържанието на определен архитектурен регистър. За да разберете как се
предоставя тази възможност, приемете, че процесорът не издава
инструкции за известен период от време. В крайна сметка всички инструкции са в ход
ще се ангажира и съпоставянето между архитектурно видимите регистри и
физическите регистри ще станат стабилни. В този момент подмножество от физическите регистри
съдържа архитектурно видимите регистри и стойността на всеки физически
регистър, който не е свързан с архитектурен регистър, не е необходим. Тогава е лесно да
преместете архитектурните регистри към фиксирано подмножество от физически регистри, така че
стойностите могат да бъдат предадени на друг процес.
Както преименуването на регистъра, така и буферите за пренареждане продължават да се използват

в процесори от висок клас, които сега разполагат с възможността да имат до 40 или 50 инструкции
(включително зареждания и съхранявания, чакащи в кеша) в полет. Независимо дали се използва
преименуване или буфер за пренареждане, ключовото тясно място на сложността за суперскаларно
управление с динамично планиране остава издаването на пакети от инструкции със зависимости в
рамките на пакета. По-специално, зависимите инструкции в пакет от издания трябва да бъдат издадени с
присвоените виртуални регистри на инструкциите, от които те зависят.
Стратегия за проблем с инструкции с преименуване на регистър, подобна на тази, използвана за
множество проблеми с буфери за пренареждане (вижте страница 198), може да бъде разгърната, както следва:
1. Логиката на издаване предварително резервира достатъчно физически регистри за целия пакет от

издания (да речем, четири регистъра за пакет от четири инструкции с най-много един резултат от
регистър на инструкция).
2. Логиката на проблема определя какви зависимости съществуват в пакета. Ако в пакета не съществува
зависимост, структурата за преименуване на регистър се използва за определяне на физическия
регистър, който съдържа или ще съдържа резултата, от чиято инструкция зависи. Когато в пакета не
съществува зависимост, резултатът е от по-ранен пакет с проблеми и таблицата за преименуване на
регистър ще има правилния номер на регистъра.
3. Ако дадена инструкция зависи от инструкция, която е по-ранна в пакета, тогава предварително
запазеният физически регистър, в който ще бъде поставен резултатът, се използва за актуализиране
на информацията за издаващата инструкция.
Обърнете внимание, че точно както в случая на буфера за пренареждане, логиката на проблема трябва
както да определя зависимости в рамките на пакета, така и да актуализира таблиците за преименуване в
един часовник и, както преди, сложността на това за по-голям брой инструкции на часовник става главно
ограничение в ширината на проблема.
Колко да спекулираме
Едно от значителните предимства на спекулациите е способността им да разкрива събития, които иначе

биха спрели конвейера рано, като пропуски в кеша. Това потенциално предимство обаче идва със
значителен потенциален недостатък. Спекулацията не е безплатна. Отнема време и енергия, а
възстановяването на неправилни спекулации допълнително намалява производителността. Освен това,
за да поддържа по-високата скорост на изпълнение на инструкциите, необходима за извличане на полза
от спекулациите, процесорът трябва да има допълнителни ресурси, които отнемат силициева площ и
мощност. И накрая, ако спекулациите предизвикат извънредно събитие, като пропуск на кеш или
транслационен буфер (TLB), потенциалът за значителна загуба на производителност се увеличава, ако
това събитие не би се случило без спекулации.
За да запазят по-голямата част от предимствата, като минимизират недостатъците, повечето

конвейери със спекулации ще позволят само евтини извънредни събития (като пропуск на кеш от първо
ниво) да бъдат обработвани в спекулативен режим. Ако възникне скъпо извънредно събитие, като
например пропуск на кеш от второ ниво или пропуск на TLB, процесорът ще изчака, докато инструкцията,
причиняваща събитието, вече не изчезне
спекулативен преди обработка на събитието. Въпреки че това може леко да влоши
производителността на някои програми, избягва значителни загуби на производителност в
други, особено тези, които страдат от висока честота на такива съчетани събития
с по-малко от отлично прогнозиране на клона.
През 90-те години потенциалните недостатъци на спекулациите бяха по-малко очевидни. Като
процесорите се развиха, реалните разходи за спекулациите станаха по-очевидни и ограниченията на по-
широкия проблем и спекулациите бяха очевидни. Ние
върнете се към този въпрос скоро.
Спекулиране чрез множество клонове
В примерите, които разгледахме в тази глава, беше възможно да се
разрешаване на клон, преди да се наложи да спекулирате с друг. Три различни ситуации
могат да се възползват от спекулирането на няколко клона едновременно: (1) много
висока честота на разклоненията, (2) значително групиране на разклонения и (3) големи закъснения
във функционални единици. В първите два случая постигането на висока производителност може да означава
че се спекулира с множество клонове и може дори да означава обработка на повече от
един клон на часовник. Програми за бази данни и други по-малко структурирани цели числа
изчисления, често проявяват тези свойства, правейки спекулации с множество
клонове важни. По същия начин, дългите закъснения във функционалните единици могат да повишат
важността на спекулирането с множество клонове като начин да се избегнат задръстванията от по-дългите
закъснения на тръбопровода.
Спекулирането с множество клонове леко усложнява процеса на възстановяване на спекулациите, но
иначе е лесно. Към 2011 г. все още няма процесор
комбинирани пълни спекулации с разрешаване на множество разклонения на цикъл и това е така
малко вероятно е разходите за това да бъдат оправдани от гледна точка на производителност спрямо
сложност и мощност.
Спекулациите и предизвикателството на енергийната ефективност
Какво е въздействието на спекулациите върху енергийната ефективност? На пръв поглед един
може да се твърди, че използването на спекулации винаги намалява енергийната ефективност, тъй като
когато спекулацията е погрешна, тя консумира излишна енергия по два начина:
1. Инструкциите, с които се спекулираше и чиито резултати не бяха необходими ген.
натрупана излишна работа за процесора, загуба на енергия.
2. Отменяне на спекулациите и възстановяване на състоянието на процесора, за да продължите
изпълнението на съответния адрес изразходва допълнителна енергия, която би
не са необходими без спекулации.
Разбира се, спекулациите ще повишат консумацията на енергия и, ако можем да контролираме
спекулации, би било възможно да се измери цената (или поне динамиката
цена на мощността). Но ако спекулациите намаляват времето за изпълнение с повече от него
увеличава средната консумация на енергия, тогава общата консумирана енергия може

бъдете по-малко.
45%
40%
35%
30%
25%
пГс
нушкер
яицал
20%
15%
10%
5%
0%
181.mcf
168.wupwise 171.swim 173.applu 177.mesa172.mgrid 164.gzip 175.vpr 176.gcc 186.crafty
Фигура 3.25 Делът на инструкциите, които се изпълняват в резултат на грешна спекулация, обикновено е много по-висок за
целочислени програми (първите пет) в сравнение с FP програми (последните пет).
Следователно, за да разберем въздействието на спекулациите върху енергийната ефективност,

трябва да разгледаме колко често спекулациите водят до ненужна работа. Ако се изпълнят значителен
брой ненужни инструкции, малко вероятно е спекулацията да подобри времето за изпълнение със
сравнима сума! Фигура 3.25 показва частта от инструкциите, които се изпълняват от грешна спекулация.
Както виждаме, тази фракция е малка в научен код и значителна (средно около 30%) в целочислен код.
По този начин е малко вероятно спекулациите да са енергийно ефективни за целочислени приложения.

Дизайнерите биха могли да избегнат спекулациите, да се опитат да намалят погрешните спекулации
или да помислят за нови подходи, като например да спекулират само с клонове, за които е известно, че
са силно предвидими.
Прогноза за стойността
Една техника за увеличаване на количеството ILP, налично в дадена програма, е прогнозирането на

стойността. Предсказването на стойност се опитва да предвиди стойността, която ще бъде произведена
от дадена инструкция. Очевидно, тъй като повечето инструкции произвеждат различна стойност всеки
път, когато се изпълняват (или поне различна стойност от набор от стойности), прогнозирането на
стойност може да има само ограничен успех. Има обаче определени инструкции, за които е по-лесно да
се предвиди получената стойност - например зареждания, които се зареждат от постоянен пул или
които зареждат стойност, която се променя рядко. В допълнение,
3.10 Изследвания на ограниченията на ILP 213
когато една инструкция произвежда стойност, избрана от малък набор от потенциални стойности,
може да е възможно да се предскаже получената стойност чрез корелиране с поведението на друга
програма.
Прогнозата на стойността е полезна, ако значително увеличава наличното количество
ILP. Тази възможност е най-вероятна, когато дадена стойност се използва като източник на верига
на зависими изчисления, като натоварване. Тъй като прогнозирането на стойността е свикнало
засилват спекулациите и неправилните спекулации имат вредно представяне
въздействие, точността на прогнозата е критична.
Въпреки че много изследователи са се фокусирали върху прогнозирането на стойността през последните десет
години, резултатите никога не са били достатъчно привлекателни, за да оправдаят включването им в
реални процесори. Вместо това е използвана по-проста и по-стара идея, свързана с предсказване на
стойност: предсказание за псевдоним на адрес. Прогнозата за псевдоним на адрес е a
проста техника, която предвижда дали два магазина или товар и магазин се отнасят за
същия адрес на паметта. Ако две такива препратки не се отнасят за един и същи адрес,
тогава те могат да бъдат безопасно разменени. В противен случай трябва да изчакаме паметта
адресите, достъпни от инструкциите, са известни. Защото всъщност не ни трябва
предвидете стойностите на адреса, само ако тези стойности са в конфликт, прогнозата е
едновременно по-стабилни и по-прости. Тази ограничена форма на спекулация на стойността на адреса има
вече се използва в няколко процесора и може да стане универсален в бъдеще.
3.10 Изследвания на ограниченията на ILP
Използването на ILP за увеличаване на производителността започна с първите конвейерни процесори
през 60-те години. През 80-те и 90-те години на миналия век тези техники бяха ключови за постигането
бързи подобрения на производителността. Въпросът колко ILP съществува беше
от решаващо значение за нашата дългосрочна способност да подобряваме производителността със скорост, която надвишава
увеличаване на скоростта на технологията на базовата интегрална схема. В по-кратък мащаб,
критичният въпрос какво е необходимо, за да се използва повече ILP, е от решаващо значение както за
компютърните дизайнери, така и за авторите на компилатори. Данните в този раздел също ни предоставят
начин за изследване на стойността на идеите, които въведохме в тази глава,
включително разграничаване на паметта, преименуване на регистри и спекулации.
В този раздел разглеждаме част от едно от изследванията, направени по тези въпроси (въз основа на
изследването на Wall от 1993 г.). Всички тези изследвания на наличния паралелизъм
оперирайте, като правите набор от предположения и виждате колко паралелизъм има
налични при тези предположения. Данните, които разглеждаме тук, са от проучване
това прави най-малко предположения; всъщност крайният хардуерен модел е вероятно неосъществим.
Независимо от това, всички подобни изследвания предполагат определено ниво на компилатор
технология и някои от тези предположения могат да повлияят на резултатите, въпреки
използване на невероятно амбициозен хардуер.
Както ще видим, за хардуерни модели, които имат разумна цена, това е малко вероятно
че разходите за много агресивни спекулации могат да бъдат оправдани: неефективността в
мощността и употребата на силиций са просто твърде високи. Докато мнозина в изследователската общност
и големите производители на процесори залагаха в полза на много
по-голяма експлоатируема ILP и първоначално не бяха склонни да приемат тази възможност, от
2005 г. бяха принудени да променят мнението си.

Моделът на хардуера
За да видим какви могат да бъдат границите на ILP, първо трябва да дефинираме идеален процесор.
Идеален процесор е този, при който всички ограничения на ILP са премахнати. Единственият
ограниченията на ILP в такъв процесор са тези, наложени от действителните потоци от данни
чрез регистри или памет.
Предположенията, направени за идеален или перфектен процесор, са следните:
1. Безкрайно преименуване на регистър – Има безкраен брой виртуални регистри

на разположение и следователно всички опасности от WAW и WAR се избягват и ан
неограничен брой инструкции могат да започнат да се изпълняват едновременно.
2. Перфектно предсказване на разклоненията— Предвиждането на разклонения е перфектно. Всички условни
разклоненията са предвидени точно.
3. Идеално предвиждане на скокове—Всички скокове (включително регистър на скокове, използван за връщане
и изчислени скокове) са перфектно предвидени. Когато се съчетае с перфектно
предсказване на разклонения, това е еквивалентно на наличието на процесор с перфектна спекулация

и неограничен буфер от инструкции, налични за изпълнение.
4. Перфектен анализ на псевдонима на адреса на паметта—Всички адреси на паметта са известни
точно и товарът може да бъде преместен преди магазин, при условие че адресите
не са идентични. Обърнете внимание, че това прилага перфектен анализ на псевдоним на адрес.
5. Перфектни кешове – всички достъпи до паметта отнемат един такт. На практика,
суперскаларните процесори обикновено консумират големи количества скриване на ILP
пропуски в кеша, което прави тези резултати много оптимистични.
Предположения 2 и 3 елиминират всички контролни зависимости. По същия начин предположения 1 и
4 елиминират всички зависимости на данните освен истинските . Заедно тези четирима
предположенията означават, че всяка инструкция в изпълнението на програмата може да бъде планирана
в цикъла непосредствено след изпълнението на предшественика на
което зависи. Дори е възможно, при тези предположения, за последно
динамично изпълнената инструкция в програмата да бъде планирана на първата
цикъл! По този начин този набор от предположения включва както контрола, така и спекулациите с адреси
и ги прилага така, сякаш са перфектни.
Първоначално разглеждаме процесор, който може да издава неограничен брой
инструкции наведнъж, гледайки произволно далеч напред в изчислението. За всички
модели процесори, които изследваме, няма ограничения за това какви типове инструкции могат да се
изпълняват в цикъл. За случая с неограничени емисии това означава, че може да има
да бъде неограничен брой зареждания или съхранява, издавани в един тактов цикъл. В допълнение,
всички закъснения на функционалните единици се приемат за един цикъл, така че всяка последователност от
зависимите инструкции могат да се издават при последователни цикли. Латенции, по-дълги от едно
цикъл ще намали броя на проблемите на цикъл, но не и броя на
инструкции в процес на изпълнение във всяка точка. (Инструкциите в изпълнение по всяко време
точка често се наричат в полет.)
Разбира се, този идеален процесор вероятно е неосъществим. Например IBM
Power7 (вижте Wendell et. al. [2010]) е най-модерният суперскаларен процесор

обявени до момента. Power7 издава до шест инструкции на такт и инициира изпълнение на

до 8 от 12 изпълнителни единици (само две от които са единици за зареждане/съхраняване),
поддържа голям набор от регистри за преименуване (позволявайки стотици инструкции да
бъдат в движение), използва голям агресивен предсказател на разклонения и използва
динамична памет. Power7 продължи движението към използване на повече паралелизъм
на ниво нишка чрез увеличаване на ширината на поддръжката на едновременна
многонишкова обработка (SMT) (до четири нишки на ядро) и броя на ядрата на чип до осем.
След като разгледахме наличния паралелизъм за перфектния процесор, ще разгледаме
какво може да бъде постижимо във всеки процесор, който вероятно ще бъде проектиран в близко бъд
За измерване на наличния паралелизъм беше компилиран и оптимизиран набор от
програми със стандартните MIPS оптимизиращи компилатори. Програмите бяха
инструментирани и изпълнени, за да създадат следа от инструкциите и препратките към
данни. След това всяка инструкция в проследяването се планира възможно най-рано,
ограничена само от зависимостите на данните. Тъй като се използва следа, перфектното
предсказване на разклоненията и перфектният анализ на псевдоними са лесни за
извършване. С тези механизми инструкциите могат да бъдат планирани много по-рано,
отколкото биха били иначе, преминавайки през голям брой инструкции, от които не зависят
от данни, включително разклонения, тъй като разклоненията са перфектно предвидени.
Фигура 3.26 показва средната степен на паралелизъм, наличен за шест от тестовете
SPEC92. В целия този раздел паралелизмът се измерва чрез средната честота на издаване
на инструкции. Не забравяйте, че всички инструкции имат латентност от един цикъл; по-
дългото забавяне би намалило средния брой инструкции на часовник. Три от тези
бенчмаркове (fpppp, doduc и tomcatv) са интензивни с плаваща запетая, а другите три са
цели програми. Два от бенчмарковете с плаваща запетая (fpppp и tomcatv) имат широк
паралелизъм, който може да се използва от векторен компютър или от мултипроцесор
(структурата във fpppp обаче е доста объркана, тъй като в кода са направени някои ръчни
трансформации) . Програмата doduc има обширен паралелизъм, но паралелизмът не се
среща в прости паралелни цикли, както се случва в fpppp и tomcatv. Програмата li е LISP
интерпретатор, който има много кратки зависимости.
gcc 55
еспресо 63
ли 18
Cн Pб
Eе S
75
евокрамч
fpppp
додук 119
tomcatv 150
0 20 40 60 80 100 120 140 160

Проблеми с инструкции за цикъл
Фигура 3.26 ILP, наличен в перфектен процесор за шест от тестовете SPEC92.

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

поддръжка, равни или по-добри от наличните през 2011 г. или, предвид събитията и уроците от
последното десетилетие, които вероятно ще бъдат налични в близко бъдеще. По-специално, ние
приемаме следните фиксирани атрибути:
1. До 64 издания на инструкции на часовник без ограничения на издаването или повече от 10 пъти

общата широчина на издаването на най-широкия процесор през 2011 г. Както ще обсъдим по-
късно, практическите последици от много широки издания на широчина върху тактовата честота,
логиката сложността и мощността може да са най-важните ограничения при използването на ILP.
2. Турнирен предиктор с 1K влизания и 16 входа за връщане. Този предиктор е сравним с най-добрите

предиктори през 2011 г.; предикторът не е основно тясно място.
3. Перфектно разграничаване на препратките към паметта, направено динамично - това е амбициозно,

но може би постижимо за малки размери на прозореца (и следователно малки нива на проблеми
и буфери за зареждане/съхраняване) или чрез предсказване на псевдоним на адрес.
4. Преименуване на регистър с 64 допълнителни цели числа и 64 допълнителни FP регистъра, което е

малко по-малко от най-агресивния процесор през 2011 г. Intel Core i7 има 128 записа в своя буфер
за пренареждане, въпреки че те не са разделени между цяло число и FP, докато IBM Power7 има
почти 200. Обърнете внимание, че приемаме латентност на конвейера от един цикъл, което
значително намалява необходимостта от записи в буфера за пренареждане. Както Power7, така и
i7 имат закъснения от 10 цикъла или повече.
Фигура 3.27 показва резултата за тази конфигурация, докато променяме размера на прозореца.
Тази конфигурация е по-сложна и скъпа от всички съществуващи реализации, особено по отношение
на броя проблеми с инструкциите, който е повече от 10 пъти по-голям от най-големия брой проблеми,
налични на който и да е процесор през 2011 г. Въпреки това, тя дава полезна обвързани с това какво
могат да доведат до бъдещи внедрявания. Данните в тези цифри вероятно са много оптимистични по
друга причина. Няма ограничения за проблеми сред 64-те инструкции: всички те могат да бъдат
препратки към паметта. Никой дори не би обмислял тази възможност в процесор в близко бъдеще. За
съжаление е доста трудно да се обвърже производителността на процесор с разумни ограничения за
проблеми; не само че пространството от възможности е доста голямо, но съществуването на
ограничения на проблемите изисква паралелността да бъде оценена с точен планировчик на
инструкции, което прави разходите за изучаване на процесори с голям брой проблеми много скъпи.
Освен това не забравяйте, че при тълкуването на тези резултати пропуските в кеша и закъсненията,
различни от модулите, не са взети под внимание и тези два ефекта ще имат значително въздействие!
Размер на прозореца
10
10 Безкрайно
gcc 10 256
9 128
8 64
32
15
15
еспресо 13
10
8
12
12
ли 11
11
9
евокрамчнеБ
52
47
fpppp 35
22
14
17
16
додук 15
12
9
56
45
tomcatv 34
22
14
0 10 20 30 40 50 60
Проблеми с инструкции за цикъл
Фигура 3.27 Размерът на наличния паралелизъм спрямо размера на прозореца за различни цели
числа и програми с плаваща запетая с до 64 произволни инструкции за такт. Въпреки че има по-
малко регистри за преименуване от размера на прозореца, фактът, че всички операции имат
латентност от един цикъл и броят на регистрите за преименуване е равен на ширината на
проблема, позволява на процесора да използва паралелизма в рамките на целия прозорец. В
реална реализация размерът на прозореца и броят на регистрите за преименуване трябва да бъдат
балансирани, за да се предотврати прекомерното ограничаване на броя на проблемите на един от тези фактор
Най-удивителното наблюдение от Фигура 3.27 е, че с реалистичните ограничения

на процесора, изброени по-горе, ефектът от размера на прозореца за целочислените
програми не е толкова сериозен, колкото за FP програмите. Този резултат сочи
ключовата разлика между тези два типа програми. Наличието на паралелизъм на ниво
цикъл в две от FP програмите означава, че количеството ILP, което може да се използва,
е по-високо, но за целочислени програми други фактори - като предсказване на
разклонения, преименуване на регистър и по-малко паралелизъм, като начало - са
всички важни ограничения. Това наблюдение е критично поради увеличения акцент върху цялот
производителност след експлозията на световната мрежа и облачните изчисления

като се започне от средата на 90-те години. Всъщност по-голямата част от растежа на пазара през последното десетилетие—
обработка на транзакции, уеб сървъри и други подобни - зависят от целочислена производителност, а не

от плаваща запетая. Както ще видим в следващия раздел, за реалистично
процесор през 2011 г., действителните нива на производителност са много по-ниски от тези
показано на фигура 3.27.
Като се има предвид трудността при увеличаване на скоростите на инструкции с реалистичен хардуер
дизайни, дизайнерите са изправени пред предизвикателство да решат как най-добре да използват ограниченото
ресурси, налични на интегрална схема. Един от най-интересните компромиси

е между по-прости процесори с по-големи кешове и по-високи тактови честоти срещу
по-голям акцент върху паралелизма на ниво инструкции с по-бавен часовник и по-малък
тайници. Следващият пример илюстрира предизвикателствата и в следващата глава
ще видим алтернативен подход за използване на финия паралелизъм в
форма на GPU.
Пример Разгледайте следните три хипотетични, но не нетипични процесора, които ние

стартирайте с SPEC gcc бенчмарк:
1. Прост MIPS двуемисионен статичен канал, работещ на тактова честота от 4 GHz и

постигане на тръбопроводен CPI от 0,8. Този процесор има кеш система, която дава
0,005 пропуска на инструкция.
2. Дълбоко конвейерна версия на двуемисионен MIPS процесор с малко

по-малки кешове и тактова честота от 5 GHz. Конвейерният CPI на процесора е
1.0, а по-малките кешове дават средно 0,0055 пропуска на инструкция.
3. Спекулативен суперскалар с прозорец от 64 входа. Постига половината от

идеален процент на проблеми, измерен за този размер на прозореца. (Използвайте данните от Фигура 3.27.)
Този процесор има най-малкия кеш, което води до 0,01 пропуска на инструкция, но скрива 25% от
наказанието за пропуск при всяко пропуск чрез динамично планиране. Този процесор има тактова
честота от 2,5 GHz.
Да приемем, че времето на основната памет (което определя наказанието за пропуск) е 50 ns. Определете
относителната производителност на тези три процесора.
Отговор Първо, ние използваме информацията за наказанието за пропуски и процента на пропуски, за да изчислим
приноса към CPI от пропуските в кеша за всяка конфигурация. Правим това със следната формула:
= ×
Кеширане на пропуски на CPI на инструкция Наказание за пропуски
Трябва да изчислим наказанията за пропуски за всяка система:
Време за достъп до паметта

= --------------------------------------------------
Пропусната дузпа
Цикъл на часовника
Времената на тактовия цикъл за процесорите са съответно 250 ps, 200 ps и 400 ps. Следователно
наказанията за пропуски са
50 ns
=
Пропусната дузпа1 = --------------- 200 цикъла 250
ps
50 ns
=
Пропусната дузпа 2 = --------------- 250 цикъла 200
ps 0,75
5 × 0 ns
Пропусната дузпа3 = ----------------------------- 94 цикъла =
400 к.с
Прилагайки това за всеки кеш:
Кеш CPI1 = 0,005 × 200 = 1,0
Кеш CPI2 = 0,0055 × 250 = 1,4
Кеш CPI3 = 0,01 × 94 = 0,94
Знаем приноса на конвейера за CPI за всичко, освен за процесор 3; неговият конвейерен CPI се дава от:
1 1 1
= ---------------------- = ---------------- = ------- 0,22 =
Тръбопровод CPI3
Процент на издаване 9 0,5 × 4,5
Сега можем да намерим CPI за всеки процесор, като добавим конвейера и кеша
Принос на CPI:
CPI1 = 0,8 + 1,0 = 1,8
CPI2 = 1,0 + 1,4 = 2,4
CPI3 = 0,22 + 0,94 = 1,16
Тъй като това е една и съща архитектура, можем да сравним скоростите на изпълнение на инструкциите
милиони инструкции в секунда (MIPS) за определяне на относителната производителност:
CR
Скорост на изпълнение на инструкциите = --------
CPI
4000 MHz
= = ------------------------ 2222 MIPS
Скорост на изпълнение на инструкциите1
1.8
5000 MHz
= = ------------------------ 2083 MIPS
2.4
2500 MHz
= = ------------------------ 2155 MIPS
1.16
В този пример простият статичен суперскалар с две издания изглежда най-добре. На практика,
производителността зависи както от предположенията за CPI, така и от тактовата честота.
Отвъд границите на това изследване
Като всяко изследване на границите, изследването, което разгледахме в този раздел, има свои собствени
ограничения. Ние ги разделяме на два класа: ограничения, които възникват дори за
перфектен спекулативен процесор и ограничения, които възникват за един или повече

реалистични модели. Разбира се, всички ограничения в първия клас важат и за втория. Най-
важните ограничения, които важат дори за перфектния модел са
1. Опасности от WAW и WAR чрез паметта – Проучването елиминира опасностите от WAW и

WAR чрез преименуване на регистър, но не и при използване на паметта. Въпреки че на
пръв поглед може да изглежда, че подобни обстоятелства са редки (особено опасности
от WAW), те възникват поради разпределението на стековите рамки. Извиканата
процедура използва повторно местоположенията на паметта на предишна процедура в
стека и това може да доведе до опасности от WAW и WAR, които са ненужно ограничаващи.
Aus-tin и Sohi [1992] изследват този въпрос.
2. Ненужни зависимости – При безкраен брой регистри се премахват всички зависимости от

регистрови данни, освен истинските. Съществуват обаче зависимости, произтичащи или
от повторения, или от конвенции за генериране на код, които въвеждат ненужни истински
зависимости на данните. Един пример за това е зависимостта от контролната променлива
в прост for цикъл. Тъй като контролната променлива се увеличава при всяка итерация на
цикъла, цикълът съдържа поне една зависимост. Както показваме в Приложение H,
разгръщането на цикъла и агресивната алгебрична оптимизация могат да премахнат
такова зависимо изчисление. Проучването на Уол включва ограничено количество
такива оптимизации, но по-агресивното им прилагане може да доведе до увеличени
количества ILP. В допълнение, определени конвенции за генериране на код въвеждат
ненужни зависимости, по-специално използването на регистри на адрес за връщане и
регистър за указателя на стека (който се увеличава и намалява в последователността за
извикване/връщане). Стената премахва ефекта от регистъра на адреса за връщане, но
използването на указател на стека в конвенцията за свързване може да причини
„ненужни“ зависимости. Постиф и др. [1999] изследва предимствата от премахването на
това ограничение.
3. Преодоляване на лимита на потока от данни – Ако прогнозирането на стойността работи с

висока точност, то може да преодолее лимита на потока от данни. Досега нито една от
над 100-те статии по темата не е постигнала значително подобрение в ILP при използване
на реалистична схема за прогнозиране. Очевидно перфектното предвиждане на
стойността на данните би довело до ефективно безкраен паралелизъм, тъй като всяка
стойност на всяка инструкция може да бъде предвидена a priori.
За не толкова перфектен процесор бяха предложени няколко идеи, които биха могли да
разкрият повече ILP. Един пример е да се спекулира по множество пътища. Тази идея беше
обсъдена от Lam и Wilson [1992] и изследвана в изследването, обхванато в този раздел. Чрез
спекулиране на множество пътища цената на неправилното възстановяване се намалява и
може да се разкрие повече паралелизъм. Има смисъл да се оценява тази схема само за
ограничен брой клонове, тъй като необходимите хардуерни ресурси нарастват експоненциално.
Wall [1993] предоставя данни за спекулации в двете посоки на до осем клона. Като се имат
предвид разходите за преследване на двата пътя, знаейки, че единият ще бъде изхвърлен (и
нарастващото количество безполезни изчисления, тъй като такъв процес се следва през
множество клонове), всеки търговски дизайн вместо това е отделил допълнителен хардуер за
по-добро спекулиране на правилния път.
3.11 Междусекторни въпроси: Подходи на ILP и системата за памет 221
Важно е да разберете, че нито едно от ограниченията в този раздел не е фундаментално
в смисъл, че преодоляването им изисква промяна в законите на физиката!

Вместо това те са практически ограничения, които предполагат съществуването на някакво страхотно
бариери пред използването на допълнителни ILP. Тези ограничения – независимо дали са прозорец
размер, откриване на псевдоним или предвиждане на разклонения – представляват предизвикателства за дизайнерите
и изследователите да преодолеят.
Опитите за пробиване на тези граници през първите пет години на този век
срещнах разочарование. Някои техники водят до малки подобрения, но често при
значително увеличаване на сложността, увеличаване на тактовия цикъл и непропорционално увеличаване
на мощността. В обобщение, дизайнерите откриха, че се опитват да

извличане на повече ILP просто беше твърде неефективно. Ще се върнем към тази дискусия в
нашите заключителни бележки.
3.11 Междусекторни въпроси: Подходи на ILP и

Система за памет
Хардуер срещу софтуерни спекулации
Хардуерно интензивните подходи към спекулациите в тази глава и софтуерните подходи в Приложение H
предоставят алтернативни подходи за използване
ILP. Изброени са някои от компромисите и ограниченията за тези подходи
По-долу:
За да спекулираме широко, трябва да можем да разграничим препратките към паметта. Тази възможност
е трудна за изпълнение по време на компилиране за цели програми
които съдържат указатели. В хардуерно базирана схема, динамичното раздвояване на адресите на
паметта по време на изпълнение се извършва с помощта на техниките, които видяхме по-рано
за алгоритъма на Томасуло. Тази недвусмисленост ни позволява да преместваме товари
минали магазини по време на изпълнение. Поддръжката на спекулативни препратки към паметта може да помогне
преодоляване на консерватизма на компилатора, но освен ако такива подходи не са

ако се използва внимателно, режийните разходи на механизмите за възстановяване могат да затрупат
предимства.
Хардуерно базираните спекулации работят по-добре, когато контролният поток е непредвидим

и когато хардуерно базираното предвиждане на разклонения е по-добро от софтуерно базираното
предвиждане на разклонения, направено по време на компилиране. Тези свойства са валидни за
много цели програми. Например, добър статичен предиктор има процент на грешно прогнозиране от
около 16% за четири основни цели SPEC92 програми, а хардуерен предиктор има процент на грешни
прогнози под 10%. Защото спекулирани инструкции
може да забави изчислението, когато прогнозата е неправилна, тази разлика е значителна. Един
резултат от тази разлика е, че дори статично планираните процесори обикновено включват
динамични предсказатели на разклонения.
Хардуерно базираните спекулации поддържат напълно прецизен модел на изключение

дори за спекулирани инструкции. Последните базирани на софтуер подходи имат
добави специална поддръжка, за да позволи и това.
Хардуерно базираните спекулации не изискват компенсация или счетоводство

код, който е необходим на амбициозни софтуерни спекулативни механизми.
Базираните на компилатор подходи могат да се възползват от способността да виждат по-нататък в

кодова последователност, което води до по-добро планиране на кода, отколкото чисто хардуерно
управляван подход.
Хардуерно базираните спекулации с динамично планиране не изискват различни кодови

последователности за постигане на добра производителност за различни реализации на дадена
архитектура. Въпреки че това предимство е най-трудното за количествено определяне, то
може да бъде най-важното в дългосрочен план. Интересното е, че това беше един от
мотивации за IBM 360/91. От друга страна, по-скорошни изрично
паралелните архитектури, като IA-64, имат добавена гъвкавост, която намалява
хардуерна зависимост, присъща на кодовата последователност.
Основният недостатък на поддържането на хардуерни спекулации е сложността и необходимите

допълнителни хардуерни ресурси. Тази цена на хардуера трябва да бъде
оценени както спрямо сложността на компилатор за базиран на софтуер
подход и количеството и полезността на опростяванията в процесора, който
разчита на такъв компилатор.
Някои дизайнери са се опитали да комбинират динамичното и базираното на компилатора
подходи за постигане на най-доброто от всеки. Такава комбинация може да генерира интересни и
неясни взаимодействия. Например, ако се комбинират условни ходове
с преименуването на регистъра се появява фин страничен ефект. Това е условен ход
anulled все още трябва да копира стойност в целевия регистър, тъй като е преименуван
по-рано в тръбопровода с инструкции. Тези фини взаимодействия усложняват дизайна
и процес на проверка и също може да намали производителността.
Процесорът Intel Itanium беше най-амбициозният компютър, създаван някога
въз основа на софтуерната поддръжка за ILP и спекулации. Не се доставя на
надеждите на дизайнерите, особено за код с общо предназначение, ненаучен. Като
Амбициите на дизайнерите за използване на ILP бяха намалени в светлината на трудностите
обсъдено в раздел 3.10, повечето архитектури се спират на хардуерно базирани механизми с честота
на издаване от три до четири инструкции на часовник.
Спекулативно изпълнение и системата на паметта
Присъща на процесорите, които поддържат спекулативно изпълнение или условни инструкции, е

възможността за генериране на невалидни адреси, които не биха възникнали без спекулативно
изпълнение. Това не само би било неправилно поведение, ако защитата
бяха направени изключения, но ползите от спекулативното изпълнение ще бъдат
затрупани от фалшиви изключения. Следователно системата за памет трябва да идентифицира
спекулативно изпълнени инструкции и условно изпълнени инструкции и
потиснете съответното изключение.
По подобни разсъждения не можем да позволим такива инструкции да предизвикат кеша
щанд при пропуск, защото отново ненужните щандове биха могли да надделеят над ползите от
спекулация. Следователно тези процесори трябва да бъдат съпоставени с неблокиращи кешове.
3.12 Многопоточност: Използване на паралелизъм на ниво нишка за подобряване на пропускателната способност на еднопроцесор 223
В действителност наказанието за пропуск на L2 е толкова голямо, че компилаторите обикновено

спекулират само с пропуски на L1. Фигура 2.5 на страница 84 показва, че за някои научни програми,
които се държат добре, компилаторът може да поддържа множество неизпълнени пропуски на L2, за
да намали ефективно наказанието за пропуски на L2. Още веднъж, за да работи това, системата с
памет зад кеша трябва да отговаря на целите на компилатора по отношение на броя на едновременните
достъпи до паметта.
3.12 Многопоточност: Използване на ниво нишка

Паралелизъм за подобряване на пропускателната способност на еднопроцесор
Темата, която разглеждаме в този раздел, многонишковостта, е наистина междусекторна тема, тъй като
има отношение към конвейерната обработка и суперскаларите, към графичните процесори (Глава 4) и
мултипроцесорите (Глава 5). Представяме темата тук и изследваме използването на многопоточност за
увеличаване на пропускателната способност на еднопроцесор чрез използване на множество нишки за
скриване на закъсненията на конвейера и паметта. В следващата глава ще видим как многонишковостта
предоставя същите предимства в графичните процесори и накрая, глава 5 ще изследва комбинацията
от многонишковост и многопроцесорност.
Тези теми са тясно преплетени, тъй като многонишковостта е основна техника за излагане на повече
паралелизъм на хардуера. В тесен смисъл, многонишковостта използва паралелизъм на ниво нишка и
следователно е правилно предмет на Глава 5, но ролята му както в подобряването на използването на
конвейера, така и в графичните процесори ни мотивира да представим концепцията тук.
Въпреки че увеличаването на производителността чрез използване на ILP има голямото

предимство, че е сравнително прозрачно за програмиста, както видяхме, ILP може да бъде доста
ограничено или трудно за използване в някои приложения. По-специално, при разумни нива на
издаване на инструкции, пропуските в кеша, които отиват в паметта или кешовете извън чипа, е малко
вероятно да бъдат скрити от наличния ILP. Разбира се, когато процесорът е в застой в очакване на
пропуск в кеша, използването на функционалните единици пада драстично.
Тъй като опитите да се покрият дълги застой на паметта с повече ILP имат ограничена ефективност,
естествено е да се запитаме дали други форми на паралелизъм в приложение могат да се използват за
скриване на закъсненията на паметта. Например, онлайн система за обработка на транзакции има
естествен паралелизъм между множество заявки и актуализации, които се представят от заявки. Разбира
се, много научни приложения съдържат естествен паралелизъм, тъй като те често моделират
триизмерната паралелна структура на природата и тази структура може да се използва чрез използване
на отделни нишки. Дори приложенията за настолни компютри, които използват съвременни базирани
на Windows операционни системи, често имат множество работещи активни приложения, осигурявайки
източник на паралелизъм.
Многонишковостта позволява на множество нишки да споделят функционалните единици на един
процесор по припокриващ се начин. За разлика от това, по-общ метод за използване на паралелизъм
на ниво нишка (TLP) е с мултипроцесор, който има множество независими нишки, работещи наведнъж
и паралелно. Многонишковостта обаче не дублира целия процесор, както прави многопроцесорът.
Вместо това, многонишковостта споделя по-голямата част от ядрото на процесора сред набор от
нишки, дублирайки само частно състояние, като например регистрите и програмния брояч. Както ще
видим в
Глава 5, много нови процесори включват както няколко процесорни ядра на a
един чип и осигуряват многопоточност във всяко ядро.
Дублирането на състоянието на нишка на процесорно ядро означава създаване на отделно
регистрационен файл, отделен компютър и отделна таблица на страниците за всяка нишка. Самата памет
може да се споделя чрез механизмите за виртуална памет, които вече
поддържа мултипрограмиране. Освен това хардуерът трябва да поддържа способността за
сменете към друга нишка сравнително бързо; по-специално превключвател на нишка
трябва да бъде много по-ефективен от превключване на процес, което обикновено се изисква
стотици до хиляди процесорни цикли. Разбира се, за да може многонишковият хардуер да постигне
подобрения в производителността, програмата трябва да съдържа множество
нишки (понякога казваме, че приложението е многонишково), които могат да се изпълняват едновременно.
Тези нишки се идентифицират или от компилатор (обикновено от език с паралелни конструкции), или от
програмист.
Има три основни хардуерни подхода към многопоточността. Дребнозърнеста
multithreading превключва между нишки на всеки часовник, причинявайки изпълнението на
инструкции от множество нишки, които да бъдат преплитани. Това преплитане е често
направено по кръгов ред, като се пропускат всички нишки, които са спрени по това време.
Едно ключово предимство на фино-зърнестата многонишковост е, че може да скрие пропускателните загуби,
които възникват както от къси, така и от дълги спирания, тъй като инструкциите от други
нишките могат да бъдат изпълнени, когато една нишка спре, дори ако сривът е само за няколко
цикли. Основният недостатък на фината многонишковост е, че забавя
надолу изпълнението на отделна нишка, тъй като нишка, която е готова за изпълнение
без сергии ще се забави поради инструкции от други теми. Той търгува с
увеличаване на многопоточната пропускателна способност за загуба на производителност (както е измерено
чрез латентност) на една нишка. Процесорът Sun Niagara, който разглеждаме
накратко, използва проста фина многопоточност, както и графичните процесори на Nvidia, които
разглеждаме в следващата глава.
Едрозърнестата многонишковост е измислена като алтернатива на финозърнестата
многопоточност. Грубозърнестата многопоточност превключва нишките само на скъпи
закъснения, като пропуски на кеш ниво две или три. Тази промяна облекчава необходимостта от
накарайте превключването на нишки да бъде по същество безплатно и е много по-малко вероятно да се забави
изпълнението на която и да е нишка, тъй като инструкциите от други нишки ще бъдат само
се издава, когато нишката се сблъска със скъпоструващ застой.
Грубозърнестата многонишковост обаче страда от основен недостатък: така е
ограничена в способността си да преодолява загубите на производителност, особено от по-къси
сергии. Това ограничение произтича от началните разходи на тръбопровода за едрозърнести
многопоточност. Тъй като CPU с едрозърнеста многонишковост издава инструкции от една нишка, когато
възникне застой, конвейерът ще види балон
преди новата нишка да започне да се изпълнява. Поради тези начални разходи,
грубозърнестата многонишковост е много по-полезна за намаляване на наказанието на
сергии с много висока цена, където презареждането на тръбопровода е незначително в сравнение със сергиите
време. Няколко изследователски проекта са изследвали грубо зърнеста многонишковост, но
нито един основен настоящ процесор не използва тази техника.
Най-често срещаната реализация на многопоточност се нарича едновременна
многопоточност (SMT). Едновременната многонишковост е вариант на финозърнеста многонишковост, която
възниква естествено, когато финозърнестата многонишковост е
имплементиран върху динамично планиран процесор с множество проблеми. Като

с други форми на многопоточност, SMT използва паралелизъм на ниво нишка, за да се скрие
събития с дълга латентност в процесор, като по този начин се увеличава използването на функционалността
единици. Ключовото прозрение в SMT е преименуването на регистъра и динамичното планиране
позволява множество инструкции от независими нишки да бъдат изпълнени без
отношение към зависимостите между тях; разрешаването на зависимостите може да бъде
управлявани от възможността за динамично планиране.
Фигура 3.28 концептуално илюстрира разликите в способността на процесора да
използва ресурсите на суперскалар за следните процесорни конфигурации:
Суперскалар без поддръжка на многопоточност
Суперскалар с грубо-зърнеста многонишковост Суперскалар с
фино-зърнеста многопоточност
Суперскалар с едновременна многонишковост
В суперскалара без многонишкова поддръжка, използването на проблемни слотове е
ограничен от липсата на ILP, включително ILP за скриване на латентността на паметта. Поради на
дължина на L2 и L3 кеш пропуски, голяма част от процесора може да остане неактивен.
Слотове за изпълнение
Суперскаларен Груб МТ Фин MT SMT

емерв
Фигура 3.28 Как четири различни подхода използват слотовете за изпълнение на функционални единици на суперскаларен процесор.
Хоризонталното измерение представлява способността за изпълнение на инструкцията във всеки тактов цикъл. Вертикалното измерение
представлява последователност от тактови цикли. Празно (бяло) поле показва, че съответният слот за изпълнение е
неизползван в този тактов цикъл. Нюансите на сивото и черното съответстват на четири различни нишки в многопоточността
процесори. Черното също се използва за обозначаване на заетите проблемни слотове в случай на суперскалар без многонишкова
поддръжка. Процесорите Sun T1 и T2 (известни още като Niagara) са фини многонишкови процесори, докато Intel
Процесорите Core i7 и IBM Power7 използват SMT. T2 има осем нишки, Power7 има четири, а Intel i7 има две.
Във всички съществуващи SMT инструкциите се издават само от една нишка наведнъж. Разликата при SMT е, че последващите
решението за изпълнение на инструкция е отделено и може да изпълни операциите, идващи от няколко различни
инструкции в същия тактов цикъл.
В грубо-зърнестия многонишков суперскалар, дългите застоявания са частично скрити чрез

превключване към друга нишка, която използва ресурсите на процесора.
Това превключване намалява броя на напълно неактивните часовникови цикли. В грубо-
зърнестия многонишков процесор обаче превключването на нишки се случва само когато има
застой. Тъй като новата нишка има период на стартиране, има вероятност да останат някои
напълно неактивни цикли.
В финозърнестия случай преплитането на нишки може да елиминира напълно празните
слотове. В допълнение, тъй като издаващата нишка се променя на всеки такт, операциите с по-
голяма латентност могат да бъдат скрити. Тъй като издаването и изпълнението на инструкциите
са свързани, една нишка може да издава само толкова инструкции, колкото са готови. При тясна
ширина на издаване това не е проблем (цикълът или е зает, или не), поради което фината
многопоточност работи перфектно за един процесор на издаване и SMT няма смисъл. Наистина,
в Sun T2 има два проблема на часовник, но те са от различни нишки. Това елиминира
необходимостта от прилагане на сложния подход за динамично планиране и вместо това
разчита на скриване на латентността с повече нишки.
Ако някой внедри фино-зърнеста нишка върху процесор с динамичен график с множество
проблеми, резултатът е SMT. Във всички съществуващи реализации на SMT всички проблеми
идват от една нишка, въпреки че инструкциите от различни нишки могат да инициират
изпълнение в един и същ цикъл, като използват хардуера за динамично планиране, за да
определят какви инструкции са готови. Въпреки че Фигура 3.28 значително опростява реалната
работа на тези процесори, тя илюстрира потенциалните предимства в производителността на
многонишковостта като цяло и SMT в по-широкообхватни, динамично планирани процесори.
Едновременната многопоточност използва прозрението, че динамично планираният

процесор вече има много от хардуерните механизми, необходими за поддържане на механизма,
включително голям набор от виртуални регистри. Многонишковостта може да бъде изградена
върху неправилен процесор чрез добавяне на таблица за преименуване на нишка, запазване на
отделни компютри и предоставяне на възможност за извършване на инструкции от множество
нишки.
Ефективност на фино-зърнеста многонишковост на Sun T1
В този раздел използваме процесора Sun T1, за да изследваме способността на многопоточността

да скрие латентността. T1 е прецизен многонишков многоядрен микропроцесор, представен от
Sun през 2005 г. Това, което прави T1 особено интересен е, че той е почти изцяло фокусиран
върху използването на паралелизъм на ниво нишка (TLP), а не паралелизъм на ниво инструкция
(ILP). T1 изостави интензивния фокус върху ILP (малко след представянето на най-агресивните
ILP процесори някога), върна се към проста конвейерна стратегия и се фокусира върху
използването на TLP, използвайки както множество ядра, така и многонишковост, за да се
постигне пропускателна способност.
Всеки T1 процесор съдържа осем процесорни ядра, всяко от които поддържа четири нишки.
Всяко процесорно ядро се състои от прост шестстепенен конвейер с един проблем (стандартен
петстепенен RISC конвейер като този в Приложение C, с добавен един етап за превключване на
нишки). T1 използва фина многопоточност (но не и SMT), превключване към нова нишка на
всеки такт и нишки, които са неактивни, защото чакат поради
Характеристика Слънце Т1
Многопроцесорна и Осем ядра на чип; четири нишки на ядро. Фино планиране на нишки. Една споделена
многонишкова единица с плаваща запетая за осем ядра.
поддръжка Поддържа само многопроцесорна обработка на чип.
Структура на тръбопровода Опростен тръбопровод с шест дълбочини в ред с три цикъла на забавяне за товари
и разклонения.
L1 кешове 16 KB инструкции; 8 KB данни. 64-байтов размер на блока. Пропускането до L2 е 23

цикъла, ако се приеме, че няма конкуренция.
L2 кешове Четири отделни L2 кеша, всеки по 750 KB и свързан с банка памет. 64-байтов
размер на блока. Липсата на основната памет е 110 тактови цикъла, ако се приеме,
че няма конкуренция.
Първоначално внедряване 90 nm процес; максимална тактова честота от 1,2 GHz; мощност 79 W;

300 M транзистори; 379 mm2 матрица.
Фигура 3.29 Резюме на процесора T1.
забавяне на тръбопровода или пропуск в кеша са заобиколени в планирането. Процесорът не работи

само когато и четирите нишки са неактивни или в застой. Както зарежданията, така и разклоненията
предизвикват забавяне от три цикъла, което може да бъде скрито само от други нишки. Единичен набор от плаваща запетая
функционалните единици се споделят от всичките осем ядра, тъй като производителността с плаваща запетая не беше a
фокус за Т1. Фигура 3.29 обобщава процесора T1.
T1 Multithreading Unicore Performance
T1 прави TLP своя фокус, както чрез многонишковостта върху индивида

ядро и чрез използването на много прости ядра на една матрица. В този раздел ние
ще разгледа ефективността на T1 за увеличаване на производителността на единичен
ядро чрез фина многопоточност. В Глава 5 ще се върнем, за да разгледаме
ефективността на комбинирането на многопоточност с множество ядра.
За да изследваме производителността на T1, ние използваме три сървърно ориентирани
бенчмарка: TPC-C, SPECJBB (SPEC Java Business Benchmark) и SPECWeb99.
Тъй като множеството нишки увеличават изискванията за памет от един процесор, те
може да претовари системата на паметта, което води до намаляване на потенциалната печалба от
многопоточност. Фигура 3.30 показва относителното увеличение на процента на пропуски и на
наблюдавано забавяне на пропускане при изпълнение с една нишка на ядро спрямо изпълнение
четири нишки на ядро за TPC-C. И процентът на пропуски, и латентностите на пропуски се увеличават,
поради увеличеното съревнование в системата на паметта. Сравнително малкото увеличение на
miss latency показва, че системата с памет все още има неизползван капацитет.
Разглеждайки поведението на средна нишка, можем да разберем взаимодействието между
нишките и способността им да поддържат ядрото заето. Фигура 3.31 показва
процент на циклите, за които дадена нишка се изпълнява, готова е, но не се изпълнява и
не е готов. Не забравяйте, че не е готово не означава, че ядрото с тази нишка е
в застой; само когато и четирите нишки не са готови, ядрото ще спре.
Нишките може да не са готови поради пропуски в кеша, закъснения на конвейера (произтичащи от
дълги инструкции за латентност като разклонения, зареждания, плаваща запетая или цяло число
умножение/деление) и разнообразие от по-малки ефекти. Фигура 3.32 показва относителната
1.7
1.6
1.5
1.4
1.3
нти
оте
а отте
и
лсан
е ч
кнаи н
стсуи е
пл
оо евО
ттр
осе
и
тн а
л и
н
п
ч
л
у
1.2
1.1
1
L1 Липсва L1 D процент Степен на L1 Липсва ми L1 D пропуск L2 пропускане
ми курс пропуски пропуск L2 латентност латентност на латентност
Фигура 3.30 Относителната промяна в процентите на пропуски и латентностите на пропуски при

изпълнение с една нишка на ядро спрямо четири нишки на ядро при бенчмарка TPC-C.
Закъсненията са действителното време за връщане на исканите данни след пропуск. В случая с
четири нишки, изпълнението на други нишки може потенциално да скрие голяма част от това забавяне.
100%
90%
80%
70%
60%
аП
и
тентеицлокр н
ц
Не е готов
50% Готов, не избран
Изпълнява се
40%
30%
20%
10%
0%
TPC-C-подобен SPECJBB00 SPECWeb99
Фигура 3.31 Разбивка на състоянието на средна нишка. „Изпълнение“ показва, че нишката издава
инструкция в този цикъл. „Готово, но неизбрано“ означава, че може да издаде, но е избрана друга
нишка, а „не е готова“ показва, че нишката чака завършване на събитие (например забавяне на
конвейера или пропуск в кеша).
честотата на тези различни причини. Ефектите на кеша са отговорни за това, че нишката не е

готова от 50% до 75% от времето, с пропуски на L1 инструкции, L1 пропуски на данни и L2
пропуски, които допринасят приблизително еднакво. Потенциалните закъснения от
тръбопровода (наречени „закъснение на тръбопровода“) са най-тежки в SPECJBB и могат да
възникнат от по-високата му честота на разклонения.
3.12 Многопоточност: Използване на паралелизма на ниво нишка за подобряване на пропускателната способност на еднопроцесорния 229
100%
90%
80%
70%
други
60%
Забавяне на тръбопровода
50% L2 пропуск
аП
и
тентеицлокр н
ц
L1 D пропуск
40% L1 Липсва ми
30%
20%
10%
0%
TPC-C-подобен SPECJBB SPECWeb99
Фигура 3.32 Разбивка на причините за това, че нишката не е готова. Приносът

към категорията „други“ варира. В TPC-C буферът на магазина е пълен с най-голям принос; в
SPEC-JBB, атомарните инструкции имат най-голям принос; и в SPECWeb99 и двата фактора допринасят.
Бенчмарк CPI за нишка CPI на ядро
TPC-C 7.2 1,80
SPECJBB 5.6 1.40
SPECWeb99 6.6 1,65
Фигура 3.33 CPI за нишка, CPI за ядро, ефективният CPI за осем ядра и
ефективният IPC (обратен на CPI) за осемядрения процесор T1.
Фигура 3.33 показва CPI за нишка и за ядро. Тъй като T1 е прецизен многонишков
процесор с четири нишки на ядро, при достатъчен паралелизъм идеалният ефективен CPI
на нишка би бил четири, тъй като това би означавало
че всяка нишка е консумирала един цикъл от всеки четири. Идеалният CPI на
ядрото ще бъде едно. През 2005 г. IPC за тези показатели работи агресивно
ILP ядрата биха били подобни на тези, наблюдавани при ядрото T1. T1 ядрото обаче беше
много скромно по размер в сравнение с агресивните ILP ядра от 2005 г.
поради което T1 имаше осем ядра в сравнение с две до четири, предлагани на други
процесори от същата реколта. В резултат на това през 2005 г., когато беше въведен,
Процесорът Sun T1 имаше най-добрата производителност при целочислени приложения с
обширен TLP и взискателна производителност на паметта, като SPECJBB и работни
натоварвания за обработка на транзакции.
Ефективност на едновременната многопоточност

на суперскаларни процесори
Ключов въпрос е колко производителност може да се постигне чрез прилагане на SMT? Когато този
въпрос беше изследван през 2000-2001 г., изследователите предположиха, че динамичните
суперскалари ще станат много по-широки през следващите пет години, поддържайки шест до осем
въпроса на часовник със спекулативно динамично планиране, много едновременни зареждания и
съхранявания, големи първични кешове и четири до осем контекста с едновременно издаване и
оттегляне от множество контексти. Никой процесор не се е доближавал до това ниво.
В резултат на това резултатите от симулационни изследвания, които показват печалби за

многопрограмирани работни натоварвания от два или повече пъти, са нереалистични. На практика
съществуващите реализации на SMT предлагат само два до четири контекста с извличане и издаване
само от един и до четири издания на часовник. Резултатът е, че печалбата от SMT също е по-скромна.
Например, в Pentium 4 Extreme, както е внедрено в сървърите на HP-Compaq, използването на

SMT дава подобрение на производителността от 1,01 при изпълнение на бенчмарка SPECintRate и
около 1,07 при изпълнение на бенчмарка SPECfpRate. Tuck и Tullsen [2003] съобщават, че при
паралелните бенчмаркове SPLASH са открили едноядрени многонишкови ускорявания, вариращи
от 1,02 до 1,67, със средно ускоряване от около 1,22.
С наличието на скорошни обширни и проницателни измервания, направени от Esmaeilzadeh et

al. [2011], можем да разгледаме производителността и енергийните ползи от използването на SMT в
едно i7 ядро, използвайки набор от многонишкови приложения. Бенчмарковете, които използваме,
се състоят от колекция от паралелни научни приложения и набор от многонишкови Java програми
от пакета DaCapo и SPEC Java, както е обобщено на Фигура 3.34. Intel i7 поддържа SMT с две нишки.
Фигура 3.35 показва коефициента на производителност и коефициента на енергийна ефективност

на тези тестове, работещи на едно ядро на i7 с изключен и включен SMT. (Начертаваме коефициента
на енергийна ефективност, който е обратен на потреблението на енергия, така че, подобно на
ускоряването, по-високият коефициент е по-добър.)
Хармоничната средна стойност на ускорението за тестовете на Java е 1,28, въпреки двата
показателя, които отбелязват малки печалби. Тези два бенчмарка, pjbb2005 и trade-beans, макар и
многонишкови, имат ограничен паралелизъм. Те са включени, защото са типични за многонишков
бенчмарк, който може да се изпълнява на SMT процесор с надеждата да се извлече известна
производителност, която те намират в ограничени количества. Бенчмарковете PARSEC постигат
малко по-добри ускорения от пълния набор от тестове на Java (хармонична средна стойност от 1,31).
Ако tradebeans и pjbb2005 бяха пропуснати, работното натоварване на Java всъщност щеше да има
значително по-добро ускоряване (1.39) от показателите на PARSEC. (Вижте обсъждането на
значението на използването на хармонична средна стойност, за да обобщите резултатите в
заглавието на Фигура 3.36.)
Консумацията на енергия се определя от комбинацията от ускоряване и увеличаване на
консумацията на енергия. За сравнителните тестове на Java средно SMT осигурява същата енергийна
ефективност като не-SMT (средно 1,0), но тя е намалена от двата сравнителни показателя с лошо
представяне; без tradebeans и pjbb2005, средното
3.12 Многопоточност: Използване на паралелизма на ниво нишка за подобряване на пропускателната способност на еднопроцесорния 231
чернокожи Цени портфолио от опции с Black-Scholes PDE

bodytrack Проследява човешко тяло без маркер
канал Минимизира разходите за маршрутизиране на чип със симулирано отгряване, съобразено с кеша
facesim Симулира движения на човешко лице за целите на визуализацията
пор Търсачка, която намира набор от изображения, подобни на изображение на заявка
fluidanimate Симулира физика на движение на течности за анимация с SPH алгоритъм
raytrace Използва физическа симулация за визуализация
streamcluster Изчислява приближение за оптимално групиране на точки от данни
swaptions Оценява портфолио от суапови опции с рамката Heath–Jarrow–Morton
vips Прилага серия от трансформации към изображение
x264 MPG-4 AVC/H.264 видео енкодер
eclipse Интегрирана среда за разработка

lusearch Инструмент за търсене на текст
слънчоглед Фотореалистична система за изобразяване

котка Контейнер за сервлети Tomcat
търговски боб Tradebeans Daytrader бенчмарк

ксалан XSLT процесор за трансформиране на XML документи
pjbb2005 Версия на SPEC JBB2005 (но коригирана по-скоро в размера на проблема, отколкото във времето)
Фигура 3.34 Паралелните бенчмаркове, използвани тук за изследване на многонишковостта, както и в глава 5 за изследване
многопроцесорна обработка с i7. Горната половина на диаграмата се състои от показатели PARSEC, събрани от Biena et al. [2008].
Бенчмарковете PARSEC са предназначени да бъдат показателни за паралелни приложения с интензивни изчисления, които биха
били подходящи за многоядрени процесори. Долната половина се състои от многонишкови тестове на Java от колекцията DaCapo
(вижте Blackburn et al. [2006]) и pjbb2005 от SPEC. Всички тези бенчмаркове съдържат известен паралелизъм; друго
Тестовете за сравнение на Java в работните натоварвания DaCapo и SPEC на Java използват множество нишки, но имат малък или никакъв истински паралелизъм
и следователно не се използват тук. Вижте Esmaeilzadeh et al. [2011] за допълнителна информация относно характеристиките на
тези показатели спрямо измерванията тук и в Глава 5.
енергийната ефективност за тестовете на Java е 1,06, което е почти толкова добро, колкото
бенчмарковете PARSEC. В показателите на PARSEC SMT намалява енергията с
1 (1/1,08) = 7%. Такива подобрения на ефективността, намаляващи енергията, са много
трудни за намиране. Разбира се, статичната мощност, свързана със SMT, се заплаща и в двете
случаи, така че резултатите вероятно леко надценяват енергийните печалби.
Тези резултати ясно показват, че SMT в агресивен спекулативен процесор
с обширна поддръжка за SMT може да подобри производителността в енергийно ефективен
мода, което по-агресивните подходи на ILP не успяха. През 2011,
балансът между предлагането на множество по-прости ядра и по-малко по-сложни ядра се е
променил в полза на повече ядра, като всяко ядро обикновено е
суперскаларен с три до четири издания със SMT, поддържащ два до четири нишки. Наистина,
Esmaeilzadeh и др. [2011] показват, че енергийните подобрения от SMT са
дори по-голям при Intel i5 (процесор, подобен на i7, но с по-малки кеши
и по-ниска тактова честота) и Intel Atom (процесор 80×86, предназначен за
пазар на нетбуци и описан в раздел 3.14).
Архитектурен
2.00
Ускори Енергийна ефективност
1,75
1.50
регистър
1.25
1,00
нш
аед
о
тсонлеетитсни ой тги
озн
и
вв к оM
ртTе ъ7и
ф
н
р
а н
п
е
Sсi
0,75
Ксалан
Vips ×264
Затъмнение
Sunflow Tomcat Facesim
Lusearch Bodytrack Canneal Суапции
Tradebeans Pjbb2005
Блекскоулс
файл
Фигура 3.35 Ускоряването от използването на многопоточност на едно ядро на i7 процесор е средно 1,28 за показателите на Java и 1,31 за
показателите PARSEC (използвайки непретеглена хармонична средна стойност, което предполага работно натоварване, където общото време,
Ferret Fluidanimate Raytrace Streamcluster
прекарано за изпълнение на всеки показател в единичен -резбовият базов комплект беше същият). Енергийната ефективност е средно 0,99 и 1,07,
съответно (използвайки средната хармонична стойност). Спомнете си, че всичко над 1,0 за енергийна ефективност показва, че функцията намалява
времето за изпълнение с повече, отколкото увеличава средната мощност. Два от тестовете на Java изпитват слабо ускоряване и имат значителна
отрицателна енергийна ефективност поради това.
Turbo Boost е изключен във всички случаи. Тези данни са събрани и анализирани от Esmaeilzadeh et al. [2011] с помощта на Oracle (Sun) HotSpot
компилация 16.3-b01 Java 1.6.0 виртуална машина и собствен компилатор gcc v4.4.1.
F0 F1 F2 D0 D1 D2 D3 D4 E0 E1 E2 E3 E4 E5
Наказание за неправилно
предвиждане на клон =13 цикъла Изпълнение на инструкцията и зареждане/съхранение
Извличане на
ALU/MUL тръба 0
инструкции Актуализация на BP
RAM Извличане на
AGU + 12 входа Декодиране на инструкции
TLB опашка ALU тръба 1
Актуализация на BP
BTB
GHB
RS LS тръба 0 или 1
Актуализация на BP
Фигура 3.36 Основната структура на тръбопровода A8 е 13 етапа. Три цикъла се използват за извличане на
инструкции и четири за декодиране на инструкции, в допълнение към конвейера с цели числа от пет цикъла.
Това води до 13-цикълна санкция за погрешно предвиждане на разклонения. Модулът за извличане на
инструкции се опитва да поддържа опашката от 12 инструкции запълнена.
3.13 Обединяване на всичко: Intel Core i7 и ARM Cortex-A8 233
3.13 Обединяване на всичко: Intel Core i7 и ARM

Cortex-A8
В този раздел изследваме дизайна на два процесора с множество проблеми: ARM

Cortex-A8 ядро, което се използва като основа за процесора Apple A9 в
iPad, както и процесорът в Motorola Droid и iPhone 3GS и 4,
и Intel Core i7, висок клас, динамично планиран, спекулативен процесор,
предназначен за настолни компютри от висок клас и сървърни приложения. Започваме с по-простия
процесор.
ARM Cortex-A8
A8 е двоен проблем, статично планиран суперскалар с динамичен проблем
откриване, което позволява на процесора да издава една или две инструкции на такт.
Фигура 3.36 показва основната тръбопроводна структура на 13-степенния тръбопровод.
A8 използва динамичен предсказател на разклонения с 512-вписвания двупосочен набор от
асоциативни целеви буфери на разклонения и 4K-входен буфер за глобална история, който е
индексирани от историята на клоновете и текущия компютър. В случай, че клонът tar-get буфер
пропусне, се получава прогноза от буфера за глобална история, който
след това може да се използва за изчисляване на адреса на клона. В допълнение, връщане с осем входа
стекът се съхранява за проследяване на адресите за връщане. Неправилна прогноза води до 13-
наказание за цикъл, тъй като тръбопроводът се промива.
Фигура 3.37 показва конвейера за декодиране на инструкции. До две инструкции на

часовник може да бъде издаден с помощта на механизъм за издаване в ред. Просто табло с резултати
структура се използва за проследяване кога може да бъде издадена инструкция. Двойка зависими
инструкциите могат да бъдат обработени чрез логиката на издаване, но, разбира се, те ще бъдат
сериализирани на таблото, освен ако не могат да бъдат издадени така, че препращането
пътищата могат да разрешат зависимостта.
Фигура 3.38 показва конвейера за изпълнение на процесора A8. Или инструкция 1, или инструкция
2 може да отиде до тръбопровода за зареждане/съхранение. Поддържа се пълно заобикаляне между
тръбопроводите. Тръбопроводът ARM Cortex-A8 използва прост двуемисионен статично планиран
суперскалар, за да позволи разумно висока тактова честота с
по-ниска мощност. За разлика от това, i7 използва сравнително агресивна, динамично планирана
спекулативна тръбопроводна структура с четири издания.
Производителност на тръбопровода A8
A8 има идеален CPI от 0,5 поради своята двойна структура. Тръбопроводните сергии могат
възникват от три източника:
1. Функционални опасности, които възникват поради избрани две съседни инструкции

за издаване едновременно използвайте същия функционален конвейер. Тъй като A8 е
статично планиран, задачата на компилатора е да се опита да избегне подобни конфликти.
Когато не могат да бъдат избегнати, A8 може да издаде най-много една инструкция в това
цикъл.
Архитекту
регистър
D0 D1 D2 D3 D4
Декодиране на инструкции
Рано Дек./послед
дек
Табло с резултати
Дек опашка + RegFile
чети пиши ID remap
проблемна логика
Рано
дек дек
файл Фигура 3.37 Петстепенно декодиране на инструкции на A8. В първия етап PC, произведен от модула за
извличане (или от целевия буфер на клона, или от PC инкремента), се
използва се за извличане на 8-байтов блок от кеша. Декодират се до две инструкции
и поставен в опашката за декодиране; ако нито една инструкция не е разклонение, компютърът се
увеличава за следващото извличане. Веднъж в опашката за декодиране, логиката на таблото решава
когато инструкциите могат да издават. В издаването операндите на регистъра се четат; припомни си това
в просто табло операндите винаги идват от регистрите. Оперите на регистъра и кодът на операцията се
изпращат към частта за изпълнение на инструкции на конвейера.
E0 E1 E2 E3 E4 E5
Изпълнение на инструкцията
Регистър на цели числа записва обратно
ALU
BP
Shft + сб WB
актуализация ALU
знамена
умножават се
MUL MUL MUL тръба 0

ACC WB
INST 0 1 2 3
ALU
INST 1 BP
Shft + сб WB ALU тръба 1
актуализация
знамена
Зареждане/съхранение
ALU LS тръбопровод WB
тръба 0 или 1
Фигура 3.38 Петстепенно декодиране на инструкции на A8. Операциите за умножение са

винаги се изпълнява в ALU конвейер 0.
2. Опасности за данни, които се откриват рано в процеса на обработка и могат да спрат

двете инструкции (ако първата не може да издаде, втората винаги е в застой) или
втори от чифт. Компилаторът е отговорен за предотвратяването на подобни застоявания, когато
възможен.
3. Контролирайте опасностите, които възникват само когато разклоненията са неправилно предвидени.
В допълнение към спиранията на тръбопровода, L1 и L2 пропускат и двете причини.

Фигура 3.39 показва оценка на факторите, които допринасят за действителния CPI
за бенчмарковете на Minnespec, които видяхме в Глава 2. Както можем да видим, закъсненията в
конвейера, а не забавянето на паметта, са основният фактор за CPI. Това
резултатът отчасти се дължи на ефекта, че Minnespec има по-малък кеш отпечатък
отколкото пълен SPEC или други големи програми.
6
L2 сергии/инструкция
L1 сергии/инструкция
Тръбопроводът спира/инструкция
5 Идеален CPI
3
аЦ
н
яицкуирлткси и
н
0
gzip vpr gcc mcf хитър парсер eon perlbmk gap vortex bzip2
Фигура 3.39 Прогнозният състав на CPI на ARM A8 показва, че спиранията на тръбопровода са основните
допълнение към основния CPI. eon заслужава специално споменаване, тъй като прави базирани на цели числа графични изчисления (ray
проследяване) и има много малко пропуски в кеша. Това е изчислително интензивно с интензивно използване на множествени и единични
многократният тръбопровод се превръща в основно тясно място. Тази оценка се получава чрез използване на нивата на пропуски и наказания за L1 и L2
за изчисляване на генерираните забавяния на L1 и L2 за инструкция. Те се изваждат от CPI, измерен чрез a
подробен симулатор за получаване на сергии на тръбопровода. Сергиите на тръбопровода включват и трите опасности плюс незначителни ефекти, като път
погрешно предвиждане.
2.25
1,75
9A
1.5
1.25
gzip vpr gcc mcf хитър парсер eon perlbmk gap vortex bzip2 twolf
0,75
Фигура 3.40 Съотношението на производителност за A9 в сравнение с A8, като и двата използват тактова честота от 1 GHz
и кешове със същия размер за L1 и L2, показва, че A9 е около 1,28 пъти по-бърз. И двете изпълнения използват 32 KB
първичен кеш и 1 MB вторичен кеш, който е 8-посочен асоциативен за A8 и 16-посочен за A9. Размерите на блоковете в
кеш паметта са 64 байта за A8 и 32 байта за A9. Както е споменато в надписа на Фигура 3.39, eon използва интензивно
целочислено умножение, а комбинацията от динамично планиране и по-бърз конвейер за умножение значително
подобрява производителността на A9. twolf изпитва малко забавяне, вероятно поради факта, че поведението на кеша му
е по-лошо с по-малкия L1 размер на блока на A9.
Прозрението, че спирането на тръбопровода създава значителни загуби на

производителност, вероятно е изиграло ключова роля в решението да се направи ARM
Cortex-A9 динамично планиран суперскалар. A9, подобно на A8, издава до две инструкции
на такт, но използва динамично планиране и спекулации. До четири чакащи инструкции
(две ALU, едно зареждане/съхранение или FP/мултимедия и едно разклонение) могат да
започнат изпълнение в един тактов цикъл. A9 използва по-мощен предсказател на
разклонения, предварително извличане на кеша на инструкции и неблокиращ L1 кеш
на данни. Фигура 3.40 показва, че A9 превъзхожда A8 с коефициент средно 1,28, като се
приеме същата тактова честота и почти идентични конфигурации на кеша.
Intel Core i7
i7 използва агресивна извънредна спекулативна микроархитектура с разумно дълбоки
тръбопроводи с цел постигане на висока производителност на инструкции чрез
комбиниране на множество проблеми и високи тактови честоти. Фигура 3.41 показва
цялостната структура на конвейера i7. Ще разгледаме тръбопровода, като започнем с
32 KB Inst. кеш (четирипосочен асоциативен)

128-Вх.инст.
TLB
(четирипосочен) 16-байтово предварително декодиране + сливане на
макро операции, буфер за извличане
Хардуер за
18-Опашка с инструкции за влизане
извличане на инструкции
Комплексен Прост Прост Прост

декодер за декодер за декодер за
макро операции
макрооперационен декодер макро операции макро операции
Микрокод
Буфер за откриване на поток от микрооперационен цикъл с 28 входа
Регистрирайте таблица с псевдоними и разпределител

Регистър файл
за пенсиониране 128-Вписване на буфер за пренареждане
36-Входна резервационна станция
ALU ALU Адрес ALU

смяна смяна Заредете адрес на магазина Съхранявайте данни смяна
SSE SSE SSE
разбъркване разбъркване разбъркване

Буфер за ред на паметта
ALU ALU ALU
128-битов 128-битов 128-битов

Съхранявайте
FMUL FMUL FMUL
и зареждайте
FDIV FDIV FDIV
512-Вписване унифицирано 64-Entry данни TLB (4- 32-KB двойно портиран кеш за 256 KB унифициран l2
L2 TLB (4-лентов) посочен асоциативен) данни (8-посочен асоциативен) кеш (осемпосочен)
8 MB всички ядра, споделен и включен L3 кеш (16- Uncore арбитър (обработва графика и разликите в
посочен асоциативен) часовника/състоянието на захранване)
Фигура 3.41 Конвейерната структура на Intel Core i7, показана с компонентите на системата с памет.
Общата дълбочина на тръбопровода е 14 етапа, като грешните прогнози на разклоненията струват 17
цикъла. Има 48 буфера за зареждане и 32 буфера за съхранение. Всяка от шестте независими
функционални единици може да започне изпълнението на готова микрооперация в същия цикъл.
извличане на инструкции и продължаване към предаване на инструкции, следвайки стъпките,

обозначени на фигурата.
1. Извличане на инструкции—процесорът използва целеви буфер за разклоняване на много нива, за

да постигне баланс между скорост и точност на прогнозиране. Има и стек с адреси за връщане, за
да се ускори връщането на функцията. Грешните прогнози причиняват наказание от около 15
цикъла. Използвайки предвидения адрес, модулът за извличане на инструкции извлича 16 байта
от кеша на инструкциите.
2. 16-те байта се поставят в буфера с инструкции за предварително декодиране – В тази стъпка се

изпълнява процес, наречен макрооперационно сливане. Сливането на макрооперации взема
комбинации от инструкции като сравнение, последвано от разклонение, и ги слива в една
операция. Етапът на предварително декодиране също разбива 16-те байта на индивидуални x86
инструкции. Този преддекод е нетривиален, тъй като дължината на x86
Инструкцията може да бъде от 1 до 17 байта и преддекодерът трябва да прегледа определен брой

байтове, преди да разбере дължината на инструкцията. Индивидуалните x86 инструкции
(включително някои слети инструкции) се поставят в опашката с инструкции от 18 записа.
3. Декодиране на микрооперации—индивидуалните x86 инструкции се превеждат в микрооперации.

Микрооперациите са прости MIPS-подобни инструкции, които могат да бъдат изпълнени директно
от тръбопровода; този подход за преобразуване на набора от инструкции x86 в прости операции,
които са по-лесно конвейерни, беше въведен в Pentium Pro през 1997 г. и се използва оттогава. Три
от декодерите обработват x86 инструкции, които се превеждат директно в една микрооперация.
За x86 инструкции, които имат по-сложна семантика, има микрокодова машина, която се използва
за създаване на микрооперационна последователност; той може да произведе до четири
микрооперации на всеки цикъл и продължава, докато се генерира необходимата последователност
от микрооперации. Микрооперациите се поставят според реда на x86 инструкциите в буфера за
микрооперации с 28 входа.
4. Буферът за микрооперации предварително формира откриване на поток от цикъл и микросливане –

Ако има малка последователност от инструкции (по-малко от 28 инструкции или 256 байта дължина),
която включва цикъл, детекторът на поток от цикъл ще намери цикъла и директно ще издаде
микрооперации от буфера, елиминирайки необходимостта етапите на извличане на инструкции и
декодиране на инструкции да бъдат активирани. Microfu-sion комбинира двойки инструкции като
зареждане/ALU операция и ALU операция/запаметяване и ги изпраща към една резервационна
станция (където те все още могат да издават независимо), като по този начин увеличава
използването на буфера. В проучване на архитектурата Intel Core, което също включва микрофузия
и макрофузия, Bird et al. [2007] откриват, че микросливането има малко влияние върху
производителността, докато макросливането изглежда има скромно положително въздействие
върху целочислената производителност и малко върху производителността с плаваща запетая.
5. Изпълнете въпроса с основната инструкция — Търсене на местоположението на регистъра в

регистрационните таблици, преименуване на регистрите, разпределяне на запис в буфера за
пренареждане и извличане на всички резултати от регистрите или буфера за пренареждане, преди
да изпратите микрооперациите към резервационните станции.
6. i7 използва централизирана резервационна станция с 36 входа, споделена от шест функционални

единици. До шест микрооперации могат да бъдат изпратени към функционалните единици на всеки
такт.
7. Микрооперациите се изпълняват от отделните функционални единици и след това резултатите се

изпращат обратно до всяка чакаща резервационна станция, както и до единицата за пенсиониране
на регистъра, където те ще актуализират състоянието на регистъра, след като стане известно, че
инструкцията е вече не е спекулативно. Записът, съответстващ на инструкцията в буфера за
пренареждане, се маркира като завършен.
8. Когато една или повече инструкции в началото на буфера за пренареждане са маркирани като
завършени, чакащите записи в модула за оттегляне на регистъра се изпълняват и инструкциите се

премахват от буфера за пренареждане.
Производителност на i7
В по-ранните раздели разгледахме производителността на предиктора на разклонения на i7,

както и производителността на SMT. В този раздел разглеждаме производителността на
конвейера с една нишка. Поради наличието на агресивни спекулации, както и неблокиращи
кешове, е трудно да се припише точно разликата между идеализираната производителност
и действителната производителност. Както ще видим, възникват относително малко
забавяния, защото инструкциите не могат да се издават. Например, само около 3% от
товарите се забавят, защото няма резервирана станция. Повечето загуби идват или от грешни
прогнози на клонове, или от пропуски в кеша. Цената на грешно предвиждане на разклонение
е 15 цикъла, докато цената на пропуск на L1 е около 10 цикъла; Пропускането на L2 е малко
повече от три пъти по-скъпо от пропускането на L1, а пропуските на L3 струват около 13 пъти
повече от това, което струва пропускът на L1 (130–135 цикъла)! Въпреки че процесорът ще
се опита да намери алтернативни инструкции за изпълнение за L3 пропуски и някои L2
пропуски, вероятно е някои от буферите да се запълнят преди пропускът да завърши, което
ще накара процесора да спре да издава инструкции.
За да се проучи цената на погрешните прогнози и неправилните спекулации, Фигура
3.42 показва частта от работата (измерена чрез броя на микрооперациите, изпратени в
процеса), които не се оттеглят (т.е. техните резултати се анулират),
40%
35%
30%
25%
20%
ап
/аеатбноулбгъ
ан р
З
15%
10%
5%
0%
Bzip2
Gcc Mcf Milc Lbm
Намд Деалии
Soplex Povray
Gobmk Hmmer Сфинкс 3
Perlbench
Astar Xalancbmk
Sjeng Libquantum H264ref Omnetpp
Фигура 3.42 Количеството „загубена работа“ се изобразява чрез съотношението на изпратените микрооперации, които не
преминават към всички изпратени микрооперации. Например съотношението е 25% за sjeng, което означава, че 25% от
изпратените и изпълнени микрооперации се изхвърлят. Данните в този раздел са събрани от професор Lu Peng и Ph.D.
студент Ying Zhang, и двамата от Луизианския държавен университет.
спрямо всички изпращания на микрооперации. За sjeng, например, 25% от работата се губи,

тъй като 25% от изпратените микрооперации никога не се пенсионират.
Забележете, че загубата на работа в някои случаи съвпада много с нивата на грешно
предвиждане на разклоненията, показани на Фигура 3.5 на страница 167, но в няколко случая,
като например mcf, загубата на работа изглежда относително по-голяма от процента на грешно
прогнозиране. В такива случаи вероятното обяснение възниква от поведението на паметта. С
много високите проценти на пропускане на кеша за данни, mcf ще изпрати много инструкции
по време на неправилна спекулация, стига да има достатъчно резервирани станции за
препратките към блокираната памет. Когато бъде открито погрешно предвиждане на
разклонението, микрооперациите, съответстващи на тези инструкции, ще бъдат изчистени,
но ще има задръстване около кешовете, тъй като спекулираните препратки към паметта се опитват да завършат.
Няма прост начин за процесора да спре такива заявки за кеширане, след като бъдат
инициирани.
Фигура 3.43 показва общия CPI за 19-те теста SPECCPU2006.

Целочислените бенчмаркове имат CPI от 1,06 с много голяма дисперсия (0,67 стандартно
отклонение). MCF и OMNETPP са основните отклонения, като и двата имат CPI над 2,0, докато
повечето други показатели са близки до или по-малко от 1,0 (gcc, следващият най-висок, е
1,23). Това отклонение произтича от разликите в точността на разклонението
2.5
1.5
IPC
0,5
0
Bzip2
Gcc Mcf Milc Lbm
Намд Деалии
Soplex Povray
Gobmk Hmmer Сфинкс 3
Perlbench
Astar Xalancbmk
Sjeng Libquantum H264ref Omnetpp
Фигура 3.43 CPI за 19 бенчмарка SPECCPU2006 показва среден CPI за 0,83 както за FP, така и за целочислен бенчмарк,
въпреки че поведението е доста различно. В случая на цяло число стойностите на CPI варират от 0,44 до 2,66 със
стандартно отклонение от 0,77, докато вариацията в случая с FP е от 0,62 до 1,38 със стандартно отклонение от 0,25.
Данните в този раздел са събрани от професор Lu Peng и Ph.D. студент Ying Zhang, и двамата от Луизианския
държавен университет.
прогнозиране и проценти на пропуски в кеша. За целочислените сравнителни показатели процентът на

пропуски L2 е най-добрият предиктор на CPI, а процентът на пропуски L3 (който е много малък) няма почти
никакъв ефект.
FP бенчмарковете постигат по-висока производителност с по-нисък среден CPI (0,89) и по-ниско

стандартно отклонение (0,25). За показателите на FP L1 и L2 са еднакво важни при определянето на CPI,
докато L3 играе по-малка, но значителна роля. Въпреки че възможностите за динамично планиране и

неблокиране на i7 могат да скрият известна латентност на пропуските, поведението на кеш паметта все
още е основен фактор.
Това засилва ролята на многопоточността като друг начин за скриване на латентността на паметта.
Нашите няколко заблуди се фокусират върху трудността при прогнозиране на производителността и

енергийната ефективност и екстраполиране от единични мерки като тактова честота или CPI. Ние също
така показваме, че различните архитектурни подходи могат да имат радикално различно поведение за
различни бенчмаркове.
Заблуда Лесно е да се предвиди производителността и енергийната ефективност на две различни версии

на една и съща архитектура на набор от инструкции, ако поддържаме технологията постоянна.
Intel произвежда процесор за нетбуците от нисък клас и PMD пространството, който е доста подобен в
своята микроархитектура на ARM A8, наречен Atom 230. Интересното е, че Atom 230 и Core i7 920 са
произведени в едно и също 45 nm Intel технология. Фигура 3.44 обобщава Intel Core i7, ARM Cortex-A8 и Intel
Atom 230. Тези прилики предоставят рядка възможност за директно сравняване на две коренно различни
микроархитектури за един и същ набор от инструкции, като същевременно се поддържа постоянна
основната производствена технология. Преди да направим сравнението, трябва да кажем малко повече
за Atom 230.
Процесорите Atom реализират x86 архитектурата, като използват стандартната техника за

преобразуване на x86 инструкции в RISC-подобни инструкции (както всяка x86 реализация от средата на 90-
те години насам). Atom използва малко по-мощна микрооперация, която позволява аритметична операция
да бъде съчетана със зареждане или съхраняване. Това означава, че средно за типичен микс от инструкции
само 4% от инструкциите изискват повече от една микрооперация. След това микрооперациите се
изпълняват в конвейер с дълбочина 16, способен да издава две инструкции на часовник, в ред, както в ARM
A8. Има ALU с двойно цяло число, отделни тръбопроводи за добавяне на FP и други FP операции и два
тръбопровода за операции на паметта, поддържащи по-общо двойно изпълнение от ARM A8, но все още
ограничени от възможността за издаване в ред. Atom 230 има 32 KB кеш за инструкции и 24 KB кеш за
данни, и двата поддържани от споделен 512 KB L2 на една и съща матрица. (Atom 230 също поддържа
многопоточност с две нишки, но ние ще разгледаме сравнения само с една нишка.) Фигура 3.46 обобщава
процесорите i7, A8 и Atom и техните ключови характеристики.
Можем да очакваме, че тези два процесора, реализирани в една и съща технология и със същия
набор от инструкции, ще проявят предвидимо поведение, в
Intel i7 920 ARM A8 Intel Atom 230
Четири ядра, едно ядро, едно ядро,

Специфична характеристика всяко с FP няма FP с FP
площ
Физически Тактова честота 2,66 GHz 1 GHz 1,66 GHz

свойства на чипа
Топлинна проектна мощност 130 W 2W 4W
Пакет 1366-пинов BGA 522-пинов BGA 437-пинов BGA
Система за памет Двустепенна Двустепенна
Всички четирипосочни Всички четирипосочни

набори асоциативни Едно ниво набори асоциативни
128 I/64 D напълно асоциативен 16 I/16 D

TLB 512 L2 32 I/32 D 64 L2
Три нива
32 KB/32 KB Двустепенна Двустепенна
256 KB 16/16 или 32/32 KB 32/24 KB
Кешове 2–8 MB 128 KB–1MB 512 KB
Пикова памет BW 17 GB/сек 12 GB/сек 8 GB/сек
Структура на тръбопровода Пиков процент на издаване 4 операции/тактовник със сливане 2 операции/тактовник 2 операции/часовник
График на Спекулиране Динамичен Динамичен
тръбопровода без ред проблем по поръчка проблем по поръчка
Двустепенна
512-вписване BTB
4K глобална история
Стек за връщане с
Прогноза за разклонения Двустепенна 8 входа Двустепенна
Фигура 3.44 Общ преглед на четириядрения Intel i7 920, пример за типичен процесорен чип Arm A8 (с 256
MB L2, 32K L1s и без плаваща запетая) и Intel ARM 230, ясно показващи разликата във философията на дизайна между процесор, предназначен за
PMD (в случая на ARM) или нетбук пространство (в случая на Atom) и а
процесор за използване в сървъри и настолни компютри от висок клас. Не забравяйте, че i7 включва четири ядра, всяко от които е няколко
пъти по-висока производителност от едноядрения A8 или Atom. Всички тези процесори са реализирани по сравним начин
45 nm технология.
по отношение на относителната производителност и консумация на енергия, което означава, че мощността и
производителността ще се мащабира близо до линейно. Разглеждаме тази хипотеза, използвайки

три комплекта бенчмаркове. Първите комплекти са група от Java, еднонишкови
бенчмаркове, които идват от бенчмарковете DaCapo и SPEC JVM98
бенчмаркове (вж. Esmaeilzadeh et al. [2011] за обсъждане на бенчмарковете
и измервания). Вторият и третият набор от показатели са от SPEC
CPU2006 и се състоят съответно от целочислени и FP показатели.
Както можем да видим на фигура 3.45, i7 значително превъзхожда Atom. всичко
бенчмарковете са поне четири пъти по-бързи на i7, два SPECFP бенчмарка са
над десет пъти по-бързо, а един SPECINT бенчмарк работи над осем пъти по-бързо!
11
10 Ускори Енергийна ефективност
2
m0o2t7и
A
9i
0
poF
rltna
енавудоП
скедниуЛ
fcm.924
mbi.074
3134
bd_902_
g.6
cliam
374
otnot.564
ssem
lllaed.744
104
54
a.0
86
dman.444
tso
mutnagunqebjisl.2
b.0
ppternam
ssej_202_
каж_822_
lriezp
054
bp
kmbog.544
hcne2
apcs.4
3
remmh.654
cavaj_312_
leurlcvploo
fer462h.464
d3eilsel.734
3скнифс.284
434
xyxia
oe
cammsu
sp rgz.5
kmbcnalax.384
яисерпмок_102_
3A4
54
D.T9D F
.6D
суткакM
smag
oiduagepm_212_
Фигура 3.45 Относителната производителност и енергийна ефективност за набор от еднонишкови бенчмаркове показва, че
i7 920 е 4 до над 10 пъти по-бърз от Atom 230, но е около 2 пъти по-малко енергийно ефективен средно! Производителността
е показана в колоните като i7 спрямо Atom, което е време за изпълнение (i7)/време за изпълнение (Atom). Енергията се
показва с линията като Енергия (Атом)/Енергия (i7). i7 никога не бие Atom по отношение на енергийната ефективност,
въпреки че по същество е толкова добър при четири показателя, три от които са с плаваща запетая. Показаните тук данни
са събрани от Esmaeilzadeh et al. [2011]. Сравнителните тестове на SPEC бяха компилирани с оптимизация при използване
на стандартния компилатор на Intel, докато сравнителните тестове на Java използват Sun (Oracle) Hotspot Java VM. Само едно
ядро е активно на i7, а останалите са в дълбок енергоспестяващ режим. Turbo Boost се използва при i7, което увеличава
предимството му в производителността, но леко намалява относителната му енергийна ефективност.
Тъй като съотношението на тактовите честоти на тези два процесора е 1,6, по-голямата
част от предимството идва от много по-нисък CPI за i7: фактор 2,8 за тестовете на Java,
фактор 3,1 за показателите SPECINT и фактор 4,3 за бенчмарковете SPECFP.
Но средната консумация на енергия за i7 е малко под 43 W, докато средната

консумация на енергия на Atom е 4,2 W, или около една десета от мощността!
Комбинирането на производителност и мощност води до предимство на енергийната
ефективност за Atom, което обикновено е повече от 1,5 пъти по-добро и често 2 пъти по-
добро! Това сравнение на два процесора, използващи една и съща основна технология,
изяснява, че предимствата на производителността на агресивен суперскалар с динамично
планиране и спекулации идват със значителен недостатък в енергийната ефективност.
Fallacy процесорите с по-ниски CPI винаги ще бъдат по-бързи.
Fallacy процесорите с по-високи тактови честоти винаги ще бъдат по-бързи.
Ключът е, че резултатът от CPI и тактовата честота определя производителността. Високата

тактова честота, получена чрез дълбоко конвейеризиране на процесора, трябва да поддържа a
нисък CPI, за да се възползвате напълно от по-бързия часовник. По същия начин прост процесор
с висока тактова честота, но нисък CPI може да бъде по-бавен.
Както видяхме в предишната заблуда, производителността и енергийната ефективност могат
се различават значително сред процесорите, проектирани дори за различни среди
когато имат една и съща ISA. Всъщност могат да се покажат големи разлики в производителността
дори в рамките на семейство процесори от една и съща компания, всички предназначени за
приложения от висок клас. Фигура 3.46 показва целочислената и FP производителност на две
различни реализации на x86 архитектурата от Intel, както и версия
на архитектурата Itanium, също от Intel.
Pentium 4 беше най-агресивно конвейерният процесор, създаван някога от
Intel. Той използва тръбопровод с над 20 етапа, има седем функционални звена и
кеширани микрооперации, а не x86 инструкции. Неговата относително по-ниска производителност
като се има предвид агресивното изпълнение, беше ясна индикация, че опитът за
използване на повече ILP (лесно може да има 50 инструкции в полет) се провали. The
Консумацията на енергия на Pentium беше подобна на i7, въпреки броя на транзисторите
беше по-нисък, тъй като неговите първични кешове бяха наполовина по-големи от i7 и включваше само
2 MB вторичен кеш без третичен кеш.
Intel Itanium е архитектура в стил VLIW, която въпреки потенциала
намаляване на сложността в сравнение с динамично планираните суперскалари, никога
постигна конкурентни тактови честоти с основните x86 процесори (въпреки че
изглежда, че постига общ CPI, подобен на този на i7). При разглеждането на тези
Резултати, читателят трябва да е наясно, че те използват различни технологии за изпълнение,
давайки предимство на i7 по отношение на скоростта на транзистора и следователно часовника
скорост за еквивалентен конвейерен процесор. Въпреки това широката вариация в
производителността - повече от три пъти между Pentium и i7 - е удивителна. Следващата клопка
обяснява къде се намира значително количество от това предимство
идва от.
SPECCInt2006 SPECCFP2006
Процесор Тактова честота база базова линия
Intel Pentium 4 670 3,8 GHz 11.5 12.2
Intel Itanium -2 1,66 GHz 14.5 17.3
Intel i7 3,3 GHz 35.5 38.4
Фигура 3.46 Три различни процесора на Intel се различават значително. Въпреки че Itanium
процесорът има две ядра, а i7 четири, само едно ядро се използва в бенчмарковете.
3.15 Заключителни бележки: Какво предстои? 245
Клопка Понякога по-голямото и по-глупавото е по-добро.
Голяма част от вниманието в началото на 2000-те беше насочено към създаването на агресивни процесори
за използване на ILP, включително архитектурата Pentium 4, която използва най-дълбоката конвейерна
линия, виждана някога в микропроцесор, и Intel Itanium, който имаше най-високата
пиков процент на издаване на часовник, виждан някога. Това, което бързо стана ясно, беше, че основният
ограничението при използването на ILP често се оказва системата с памет. Макар че
спекулативните тръбопроводи извън ред бяха доста добри в скриването на значителна част
от наказанията за пропуск от 10 до 15 цикъла за пропуск от първо ниво, те биха могли да направят много
малко, за да скрият наказанията за пропуск от второ ниво, които, когато отиват в основната памет,
вероятно ще бъдат от 50 до 100 тактови цикъла.
Резултатът беше, че тези проекти никога не се доближиха до постигането на върха
пропускателна способност на инструкции въпреки големия брой транзистори и изключително сложни и
умни техники. Следващият раздел обсъжда тази дилема и
завръщане от по-агресивни ILP схеми към многоядрени, но имаше
още една промяна, която илюстрира този капан. Вместо да се опитват да скрият още повече
латентност на паметта с ILP, дизайнерите просто са използвали транзисторите, за да изградят много
по-големи кешове. Както Itanium 2, така и i7 използват кешове на три нива в сравнение с
двустепенният кеш на Pentium 4, а кешовете от трето ниво са 9 MB и 8
MB в сравнение с 2 MB кеша от второ ниво на Pentium 4. Излишно е да казвам,
изграждането на по-големи кешове е много по-лесно от проектирането на Pentium 4 с 20+ етапа
тръбопровод и от данните на Фигура 3.46 изглежда по-ефективен.
3.15 Заключителни бележки: Какво предстои?
В началото на 2000 г. фокусът върху използването на паралелизма на ниво инструкции беше на мястото си
връх. Intel беше на път да представи Itanium, статично планиран висок процент на проблеми
процесор, който разчита на VLIW-подобен подход с интензивна поддръжка на компилатор.
Процесорите MIPS, Alpha и IBM с динамично планирано спекулативно изпълнение бяха във второто си
поколение и бяха станали по-широки и по-бързи. Pen-tium 4, който използва спекулативно планиране,
също беше обявен през същата година
със седем функционални звена и тръбопровод с дълбочина над 20 етапа. Но там

бяха буреносни облаци на хоризонта.
Изследвания като тези, обхванати в раздел 3.10 , показват, че натискането на ILP
много по-нататък би било изключително трудно и докато пиковите скорости на пропускане на инструкции
са се повишили от първите спекулативни процесори около 3 до 5 години по-рано,
устойчивите нива на изпълнение на инструкции нарастват много по-бавно.
Следващите пет години бяха показателни. Itanium се оказа добър FP процесор, но само посредствен
целочислен процесор. Intel все още произвежда линията, но
няма много потребители, тактовата честота изостава от основните процесори на Intel и
Microsoft вече не поддържа набора от инструкции. Intel Pentium 4, докато
постигането на добра производителност се оказа неефективно по отношение на производителност/ват (т.е.
потребление на енергия), а сложността на процесора го направи
Малко вероятно е по-нататъшен напредък да бъде възможен чрез увеличаване на емисионния процент. The
настъпи краят на 20-годишен път за постигане на нови нива на производителност в

микропроцесорите чрез използване на ILP. Pentium 4 беше широко признат, че е надхвърлил
точката на намаляваща възвръщаемост и агресивната и усъвършенствана микроархитектура
Netburst беше изоставена.
До 2005 г. Intel и всички други големи производители на процесори преработиха своя

подход, за да се съсредоточат върху многоядрените процесори. По-висока производителност
ще бъде постигната чрез паралелизъм на ниво нишка, а не паралелизъм на ниво инструкция,
а отговорността за ефективното използване на процесора до голяма степен ще се прехвърли
от хардуера към софтуера и програмиста. Тази промяна беше най-значимата промяна в
процесорната архитектура от първите дни на конвейерната обработка и паралелизма на ниво
инструкции преди около 25 години.
През същия период дизайнерите започнаха да изследват използването на повече
паралелизъм на ниво данни като друг подход за постигане на производителност. Разширенията
на SIMD позволиха на настолните и сървърните микропроцесори да постигнат умерено
увеличение на производителността за графики и подобни функции. По-важното е, че
графичните процесори (GPU) преследваха агресивно използване на SIMD, постигайки
значителни предимства в производителността за приложения с екстензивен паралелизъм на
ниво данни. За научни приложения такива подходи представляват жизнеспособна алтернатива
на по-общия, но по-малко ефективен паралелизъм на ниво нишка, използван в многоядрени
процесори. Следващата глава изследва тези развития в използването на паралелизъм на ниво данни.
Много изследователи прогнозираха голямо намаляване на използването на ILP, като
прогнозираха, че бъдещето ще бъде два суперскаларни процесора и по-голям брой ядра.
Предимствата обаче на малко по-високите нива на издаване и способността на спекулативното
динамично планиране да се справя с непредсказуеми събития, като пропуски в кеша от ниво
едно, доведоха до това, че умереният ILP е основният градивен елемент в многоядрените
дизайни. Добавянето на SMT и неговата ефективност (както за производителност, така и за
енергийна ефективност) допълнително циментира позицията на умерения проблем, извън
реда, спекулативни подходи. Наистина, дори на пазара на вградени устройства, най-новите
процесори (напр. ARM Cortex-A9) въведоха динамично планиране, спекулации и по-широки
проценти на проблеми.
Много малко вероятно е бъдещите процесори да се опитат значително да увеличат
ширината на проблема. Той просто е твърде неефективен както от гледна точка на използване
на силиций, така и от енергийна ефективност. Разгледайте данните на Фигура 3.47 , които
показват най-новите четири процесора от серията IBM Power. През последното десетилетие
имаше скромно подобрение в поддръжката на ILP в процесорите Power, но доминиращата част
от увеличението на броя на транзисторите (коефициент почти 7 от Power 4 до Power7) отиде в
увеличаване на кеш паметта и броя на ядрата на матрица. Дори разширяването на поддръжката
на SMT изглежда е по-скоро фокус, отколкото увеличаване на пропускателната способност на
ILP: ILP структурата от Power4 към Power7 премина от 5 въпроса на 6, от 8 функционални
единици на 12 (но не се увеличава от първоначалното 2 натоварване/ складови единици),
докато поддръжката на SMT премина от несъществуваща до 4 нишки/процесор. Изглежда ясно,
че дори за най-модерния ILP процесор през 2011 г. (Power7), фокусът се е преместил отвъд
паралелизма на ниво инструкции.
Следващите две глави се фокусират върху подходи, които използват паралелизма на ниво
данни и на ниво нишка.
Мощност4 Мощност5 Мощност6 Мощност7
Въведено 2001 г 2004 г 2007 г 2010 г
Първоначална тактова честота (GHz) 1.3 1.9 4.7 3.6
Брой транзистори (M) 174 276 790 1200
Проблеми на часовник 5 5 7 6
Функционални единици 8 8 9 12
Ядра/чип 2 2 2 8
SMT резби 0 2 2 4
Общ кеш в чипа (MB) 1.5 2 4.1 32.3
Фигура 3.47 Характеристики на четири IBM Power процесора. Всички с изключение на Power6 бяха динамично планирани,
който е статичен и в ред, и всички процесори поддържат два конвейера за зареждане/съхранение. Power6 има същите функционални единици
като Power5, с изключение на десетичната единица. Power7 използва DRAM за L3 кеша.

Раздел L.5 (достъпен онлайн) включва дискусия относно разработването на паралелизъм на
ниво конвейер и инструкции. Предоставяме множество препратки за по-нататъшно четене и
изследване на тези теми. Раздел L.5 обхваща и Глава 3
и Приложение З.
Казуси и упражнения от Джейсън Д. Бакос и

Робърт П. Колуел
Казус от практиката: Изследване на въздействието на микроархитектурата

Техники
Планиране на основни инструкции, пренареждане, изпращане
Множество проблеми и опасности
Преименуване на регистър
Неправилно и спекулативно изпълнение
Къде да изразходвате ресурсите, които не са в ред
Имате задачата да проектирате нова процесорна микроархитектура и вие сте

опитвайки се да разберете как най-добре да разпределите хардуерните си ресурси. Кой от
хардуерни и софтуерни техники, които научихте в глава 3, трябва да приложите?
Имате списък със закъснения за функционалните единици и за паметта, както и
някакъв представителен код. Вашият шеф е бил малко неясен относно
изискванията за производителност на вашия нов дизайн, но знаете от опит
че при равни други условия по-бързото обикновено е по-добро. Започнете с основите. Фигура 3.48
предоставя последователност от инструкции и списък със закъснения.
3.1 [10] <1.8, 3.1, 3.2> Каква би била базовата производителност (в цикли, на
итерация на цикъл) на кодовата последователност на Фигура 3.48 , ако няма нови инструкции
изпълнението може да бъде инициирано, докато не приключи изпълнението на предишната инструкция
завършено? Игнорирайте предния извличане и декодиране. Да приемем засега това изпълнение
не спира поради липса на следваща инструкция, а само една инструкция/цикъл
могат да бъдат издадени. Да приемем, че клонът е взет и че има клон с един цикъл
слот за забавяне.
3.2 [10] <1.8, 3.1, 3.2> Помислете какво всъщност означават числата за латентност - те показват броя на циклите,
които дадена функция изисква, за да произведе изхода си, нищо
Повече . Ако общият тръбопровод спре за циклите на латентност на всяка функционална единица,
тогава най-малкото сте гарантирани, че всяка двойка последователни инструкции („продуцент“,
последван от „консуматор“) ще се изпълни правилно. Но не всички инструкции
двойките имат връзка производител/потребител. Понякога две съседни инструкции нямат нищо общо
една с друга. Колко цикъла ще бъде тялото на цикъла
в кодовата последователност на фигура 3.48 изискват, ако тръбопроводът е открил верни данни
зависимости и се спираше само върху тях, вместо сляпо да спира всичко просто
защото една функционална единица е заета? Покажете кода с вмъкнат <stall> където
необходими за приспособяване на заявените закъснения. (Съвет: Инструкция със закъснение +2
изисква два цикъла <stall> да бъдат вмъкнати в кодовата последователност. Помисли си
по този начин: Инструкция с един цикъл има латентност 1 + 0, което означава нула допълнително чакане
държави. И така, латентност 1 + 1 предполага един цикъл на спиране; латентност 1 + N има N допълнително забавяне
цикли.
3.3 [15] <3.6, 3.7> Помислете за дизайн с няколко издания. Да предположим, че имате два конвейера за
изпълнение, всеки от които може да започне изпълнение на една инструкция на цикъл,
и достатъчно честотна лента за извличане/декодиране в предния край, така че да не ви спре
Латенции над единичен цикъл
Цикъл: LD F2,0(RX) Памет LD +4

IO: DIVD F8, F2, F0 Памет SD +1
I1: MULTD F2, F6, F2 Цяло число ADD, SUB +0

I2: LD F4,0(Ry) Клонове +1
I3: ДОБАВЯНЕ F4, F0, F4 ДОБАВЯНЕ +1
I4: ДОБАВЯНЕ F10, F8, F2 MULTD +5

I5: ДОБАВИ Rx, Rx, #8 DIVD +12
I6: ДОБАВИ Рай, Рай, №8
I7: SD F4,0(Ry)
I8: ПОДП R20, R4, Rx
I9: БНЗ R20, контур
Фигура 3.48 Код и закъснения за упражнения 3.1 до 3.6.

екзекуция. Да приемем, че резултатите могат да бъдат незабавно препратени от едно изпълнение
единица към друга или към себе си. Освен това приемете, че единствената причина е екзекуция
тръбопроводът ще спре е да се наблюдава истинска зависимост от данни. Сега колко цикъла
изисква ли цикълът?
3.4 [10] <3.6, 3.7> В дизайна с множество проблеми на упражнение 3.3 може да сте разпознали някои фини проблеми.
Въпреки че двата тръбопровода са абсолютно еднакви
репертоар от инструкции, те не са нито идентични, нито взаимозаменяеми, т.к
има имплицитно подреждане между тях, което трябва да отразява подреждането на
инструкции в оригиналната програма. Ако инструкция N + 1 започне да се изпълнява в Execution Pipe 1 по
същото време, когато инструкция N започва в Pipe 0, и N + 1 се случи да изискват по-кратко забавяне на
изпълнението от N, тогава N + 1 ще завърши
преди N (въпреки че програмното подреждане би предполагало друго). Рецитирайте
поне две причини, поради които това може да бъде опасно и ще изисква специални съображения в
микроархитектурата. Дайте пример за две инструкции от
код на Фигура 3.48 , който демонстрира тази опасност.
3.5 [20] <3.7> Пренаредете инструкциите, за да подобрите производителността на кода на фигура
3.48. Да приемем, че двутръбната машина в упражнение 3.3 е неработеща
Проблемите със завършването на Упражнение 3.4 са решени успешно. Просто се притеснявай
относно наблюдаването на истинските зависимости на данните и закъсненията на функционалните единици засега.
Колко цикъла отнема вашият пренареден код?
3.6 [10/10/10] <3.1, 3.2> Всеки цикъл, който не инициира нова операция в канал
е загубена възможност, в смисъл, че вашият хардуер не отговаря на своя потенциал.
а. [10] <3.1, 3.2> Във вашия пренареден код от Упражнение 3.5 каква част от всички
цикли, като се броят и двете тръби, са били пропилени (не е инициирал нова операция)?
b. [10] <3.1, 3.2> Развиването на цикъл е една стандартна техника на компилатор за намиране
повече паралелизъм в кода, за да се сведат до минимум загубените възможности за изпълнение.
Развийте ръчно две итерации на цикъла във вашия пренареден код от

Упражнение 3.5.
° С. [10] <3.1, 3.2> Какво ускоряване постигнахте? (За това упражнение просто оцветете
инструкциите на N + 1 итерация са зелени, за да се разграничат от инструкциите на N-тата итерация;
ако всъщност развивате цикъла, ще трябва да го направите
преназначете регистри, за да предотвратите сблъсъци между повторенията.)
3.7 [15] <2.1> Компютрите прекарват по-голямата част от времето си в цикли, така че многократните итерации на
цикъла са страхотни места за спекулативно намиране на повече работа, за да запазите ресурсите на процесора
зает. Все пак нищо не е лесно; компилаторът издаде само едно копие от това
код на цикъл, така че въпреки че множество итерации обработват различни данни, те
изглежда, че използва същите регистри. За да запазите употребата на регистъра на множество итерации
от сблъсък, ние преименуваме техните регистри. Фигура 3.49 показва примерен код, който
бихме искали нашият хардуер да се преименува. Компилаторът може просто да се развие
цикъла и използва различни регистри, за да избегне конфликти, но ако очакваме нашият хардуер да развие
цикъла, той също трябва да извърши преименуването на регистъра. как? Приемете вашето
хардуерът има набор от временни регистри (наречете ги T регистри и приемете, че

Цикъл: LD F4,0(Rx)
I0: МНОГО F2, F0, F2
I1: DIVD F8, F4, F2
I2: LD F4,0(Ry)
I3: ДОБАВЯНЕ F6, F0, F4
I4: СУБД F8, F8, F6
I5: SD F8,0(Ry)
Фигура 3.49 Примерен код за практика за преименуване на регистър.
I0: LD T9,0(Rx)
I1: MULTD T10,F0,T9
...
Фигура 3.50 Подсказка: Очакван изход от преименуване на регистър.
има 64 от тях, T0 до T63), които може да замени тези регистри, определени от компилатора. Този хардуер за
преименуване е индексиран от src (източник)
обозначение на регистъра и стойността в таблицата е T регистъра на последната дестинация, която е
насочена към този регистър. (Мислете за тези таблични стойности като производители и
src регистрите са потребителите; няма голямо значение къде слага производителя
неговият резултат, стига потребителите му да могат да го намерят.) Разгледайте кодовата последователност
на фигура 3.49. Всеки път, когато видите дестинационен регистър в кода, заменете следващия
наличен T, започващ с T9. След това актуализирайте съответно всички src регистри, така че
че се поддържат истинските зависимости на данните. Покажете получения код. (Съвет: Вижте
Фигура 3.50.)
3.8 [20] <3.4> Упражнение 3.7 изследва простото преименуване на регистъра: когато хардуерът
преименуващото устройство на регистър вижда изходен регистър, замества целевия T регистър на
последната инструкция, насочена към този източник източник. Когато преименувате таблицата
вижда дестинационен регистър, той замества следващия наличен T за него, но суперскаларен
проектите трябва да обработват множество инструкции за тактов цикъл на всеки етап от
машина, включително преименуването на регистъра. Един прост скаларен процесор следователно би
потърсил съпоставянията на src регистъра за всяка инструкция и ще разпредели нова
дест картографиране на часовников цикъл. Суперскаларните процесори трябва да могат да правят това като
добре, но те също така трябва да гарантират, че всички връзки dest-to-src между
две едновременни инструкции се обработват правилно. Разгледайте примерния код
последователност на фигура 3.51. Да приемем, че бихме искали едновременно да преименуваме
първите две инструкции. Освен това приемете, че следващите два налични T регистрират към
които се използват, са известни в началото на тактовия цикъл, в който тези две инструкции се преименуват.
Концептуално това, което искаме, е първата инструкция да
направете справки в таблицата за преименуване и след това актуализирайте таблицата според нейната дестинация
T регистър. След това втората инструкция ще направи точно същото нещо, както и всяко
I0: СУБД F1, F2, F3

I1: ДОБАВЯНЕ F4, F1, F2
I2: МНОГО F6, F4, F1
I3: DIVD F0, F2, F6
Фигура 3.51 Примерен код за преименуване на суперскаларен регистър.
Следващият наличен T регистър Преименуване на таблицата
. . . 10 9 0
1 21
Това 9 се появява в 2 19
таблицата за
3 38
преименуване в
4 29
следващия часовников цикъл
5
...
8
9
dst = F1 dst = T9
I1
src1 =F2 ... src1 =T19
src2 =F3 src2 =T38
62
63
(Съгласно инстр. 1)
Y н
I1 dst = I2 src? dst = T10
dst = F4 src1 =T9
I2
src1 =F1 (Подобен mux src2 = T19
src2 =F2 за src2)
Фигура 3.52 Преименуване на таблица и логика за заместване на регистри в движение за

суперскаларни машини. (Имайте предвид, че src е източник, а dest е дестинация.)
по този начин зависимостта между инструкциите ще бъде обработена правилно. Но няма

достатъчно време, за да запише това обозначение на T регистър в таблицата за преименуване и
след това да го потърси отново за втората инструкция, всичко в същия тактов цикъл. Това
заместване на регистър трябва вместо това да се извърши на живо (успоредно с актуализацията
на таблицата за преименуване на регистъра). Фигура 3.52 показва електрическа диаграма,
използваща мултиплексори и компаратори, които ще извършат необходимото преименуване на
регистъра в движение. Вашата задача е да покажете състоянието цикъл по цикъл на таблицата
за преименуване за всяка инструкция от кода, показан на Фигура 3.51. Да приемем, че таблицата
започва с всеки запис, равен на нейния индекс (T0 = 0; T1 = 1, …).
3.9 [5] <3.4> Ако някога се объркате какво трябва да прави преименуващият регистър, върнете се към
асемблерния код, който изпълнявате, и се запитайте какво трябва да се случи
за да се получи правилният резултат. Например, разгледайте тристранен суперскалар

машинно преименуване на тези три инструкции едновременно:
ДОБАВЯНЕ R1, R1, R1

Ако стойността на R1 започва като 5, каква трябва да бъде стойността му, когато тази последователност има
изпълнен?
3.10 [20] <3.4, 3.9> Дизайнерите на много дълги командни думи (VLIW) имат няколко основни
избори, които да направите по отношение на архитектурните правила за използване на регистъра. Да предположим, че VLIW е
проектирани със самоотводняващи се тръбопроводи за изпълнение: след като се започне операция, тя

резултатите ще се появят в целевия регистър най-много L цикъла по-късно (където L е
латентност на операцията). Никога няма достатъчно регистри, така че има изкушение да се извлече
максимална полза от съществуващите регистри. Разгледайте фигура 3.53.
Ако товарите имат латентност от 1 + 2 цикъла, развийте този цикъл веднъж и покажете как VLIW
способен на две зареждания и две добавяния на цикъл, може да използва минималния брой регистри,
при липса на каквито и да е прекъсвания на тръбопровода или спирания. Дайте пример за
събитие, което при наличието на самооттичащи се тръбопроводи може да наруши тази облицовка на
тръбопровода и да доведе до грешни резултати.
3.11 [10/10/10] <3.3> Да приемем петстепенна еднотръбна микроархитектура (извличане,

декодиране, изпълнение, памет, обратно запис) и кода на Фигура 3.54. Всички операции са
един цикъл с изключение на LW и SW, които са 1 + 2 цикъла, и клонове, които са 1 + 1
цикли. Няма препращане. Показване на фазите на всяка инструкция за часовник
цикъл за една итерация на цикъла.
а. [10] <3.3> Колко тактови цикъла на итерация на цикъл се губят в разклонението

отгоре?
b. [10] <3.3> Да приемем статичен предсказател на разклонения, способен да разпознава разклонение

назад в етапа на декодиране. Сега колко тактови цикъла са загубени
на режийни клонове?
° С. [10] <3.3> Да приемем динамичен предиктор на разклонения. Колко цикъла са загубени на

правилна прогноза?
Цикъл: LW R4,0(R0); ДОБАВИ R11, R3, #1
LW R5,8(R1); ДОБАВИ R20, R0, #1
<сергия>
ДОБАВИ R10,R4,#1;
SW R7,0(R6); SW R9,8(R8)
ДОБАВИ R2, R2, #8
ПОДП R4, R3, R2
БНЗ R4, Цикъл
Фигура 3.53 Примерен VLIW код с две добавяния, две зареждания и две спирания.
Цикъл: LW R3,0(R0)
LW R1,0(R3)
ДОБАВИ R1, R1, #1
ПОДП R4, R3, R2
SW R1,0(R3)
БНЗ R4, контур
Фигура 3.54 Цикъл на код за упражнение 3.11.
ALU 0
Инструкции
от декодера
1
ALU 1
Резервация
станция
2
LD/ST Мем
Фигура 3.55 Неправилна микроархитекура.
3.12 [15/20/20/10/20] <3.4, 3.7, 3.14> Нека помислим какво може да представлява динамичното планиране
постигнете тук. Да приемем микроархитектура, както е показано на фигура 3.55. Предполагам че
аритметично-логическите единици (ALU) могат да извършват всички аритметични операции (MULTD, DIVD, ADDD,
ADDI, SUB) и клонове, и на които станцията за резервации (RS) може да изпрати

най-много една операция към всяка функционална единица на цикъл (една операция към всяко ALU плюс
една памет към LD/ST).
а. [15] <3.4> Да предположим, че всички инструкции от последователността на Фигура 3.48

присъстват в RS, без да е извършено преименуване. Маркирайте всеки
инструкции в кода, където преименуването на регистър би подобрило производителността. (Съвет:
Потърсете опасности от четене след запис и запис след запис.
Да приемем същите закъснения на функционалните единици като на Фигура 3.48.)
b. [20] <3.4> Да предположим, че преименуваната в регистър версия на кода от част (a) е

резидентен в RS в тактов цикъл N, със закъснения, както е дадено на Фигура 3.48.
Покажете как RS трябва да изпрати тези инструкции извън ред, часовник по
часовник, за да получите оптимална производителност на този код. (Предполагаме същия RS
ограничения, както в част (а). Също така приемете, че резултатите трябва да бъдат записани в RS
преди да са достъпни за използване—без прескачане.) Колко тактови цикъла отнема

кодовата последователност?
° С. [20] <3.4> Част (b) позволява на RS да се опита да планира оптимално тези инструкции.
Но в действителност цялата интересна последователност от инструкции обикновено не
присъства в RS. Вместо това различни събития изчистват RS и тъй като нова кодова
последователност постъпва от декодера, RS трябва да избере да изпрати това, което има.
Да предположим, че RS е празен. В цикъл 0, първите две преименувани в регистър
инструкции от тази последователност се появяват в RS. Да приемем, че е необходим един
тактов цикъл за изпращане на всяка операция и приемете, че закъсненията на
функционалните единици са такива, каквито бяха за упражнение 3.2. Освен това
приемете, че предният край (декодер/регистър-пренамерител) ще продължи да
предоставя две нови инструкции на тактов цикъл. Покажете реда на изпращане на RS
цикъл по цикъл. Колко тактови
цикъла изисква тази кодова последователност сега? д. [10] <3.14> Ако искахте да подобрите
резултатите от част (c), кое би помогнало най-много: (1) Друго ALU? (2) Друго устройство
LD/ST? (3) Пълно заобикаляне на резултатите от ALU към следващите операции? или (4)
намаляване наполовина на най-дългата
латентност? Какво е ускорението? д. [20] <3.7> Сега нека разгледаме спекулацията, акта на
извличане, декодиране и изпълнение отвъд едно или повече условни разклонения.
Нашата мотивация да направим това е двойна: графикът за изпращане, който измислихме
в част (c), имаше много неуспехи и знаем, че компютрите прекарват по-голямата част от
времето си в изпълнение на цикли (което означава, че клонът обратно към върха на цикъла е доста предсказ
Loops ни казват къде да намерим повече работа; нашият оскъден график за изпращане
предполага, че имаме възможности да свършим част от тази работа по-рано от преди. В
част (d) намерихте критичния път през цикъла. Представете си, че сгъвате второ копие
на този път върху графика, който сте получили в част (b). Колко повече тактови цикъла
ще са необходими, за да се извърши работата на два цикъла (ако приемем, че всички
инструкции са резидентни в RS)? (Да приемем, че всички функционални единици са
напълно конвейерни.)
3.13 [25] <3.13> В това упражнение ще изследвате компромисите в производителността между три
процесора, всеки от които използва различни видове многопоточност. Всеки от тези
процесори е суперскаларен, използва тръбопроводи в ред, изисква фиксиран три цикъл на
спиране след всички натоварвания и разклонения и има идентични L1 кешове. Инструкциите
от една и съща нишка, издадени в същия цикъл, се четат в програмен ред и не трябва да
съдържат данни или контролни зависимости. Процесор
A е суперскаларна SMT архитектура, способна да издава до две

инструкции на цикъл от две нишки.
Процесор B е добра MT архитектура, способна да издава до четири

инструкции на цикъл от една нишка и да превключва нишки на всеки конвейер.
Процесор C е груба MT архитектура, способна да издава до осем инструкции на цикъл от

една нишка и превключва нишките при пропуск на L1 кеш.
Нашето приложение е търсач в списък, който сканира област от паметта за конкретна

стойност, съхранена в R9 между адресния диапазон, посочен в R16 и R17. Той е паралелен
чрез равномерно разделяне на пространството за търсене на четири съседни блока с
еднакъв размер и присвояване на една нишка за търсене на всеки блок (получавайки четири нишки).
По-голямата част от времето за изпълнение на всяка нишка се изразходва в следното разгърнато тяло на цикъл:
контур: LD R1,0(R16)
LD R2,8(R16)
LD R3,16(R16)
LD R4,24(R16)
LD R5,32(R16)
LD R6,40(R16)
LD R7,48(R16)
LD R8,56(R16)
BEQAL R9,R1,съвпадение0
DADDIU R16 ,R16,#64 BLT
R16,R17,loop Приемете
следното: Използва се
бариера, за да се гарантира, че всички нишки започват едновременно.
Първата грешка в L1 кеша възниква след две итерации на цикъла. Нито
един от клоновете на BEQAL не е взет. BLT
винаги се взема. И трите
процесора планират нишки по кръгов начин.
Определете колко цикъла са необходими за всеки процесор, за да завърши първите две

итерации на цикъла.
3.14 [25/25/25] <3.2, 3.7> В това упражнение разглеждаме как софтуерните техники могат да извлекат
паралелизъм на ниво инструкция (ILP) в общ векторен цикъл. The
следващият цикъл е така нареченият DAXPY цикъл ( aX плюс Y с двойна точност) и

е централната операция в елиминирането на Гаус. Следният код имплементира операцията
DAXPY, Y = aX + Y, за вектор с дължина 100. Първоначално R1 е
зададен на основния адрес на масива X и R2 е зададен на основния адрес на Y:
ДАДДИУ R4,R1,#800; R1 = горна граница за X
foo: LD F2,0(R1) ; (F2) = X(i)
МУЛ.Д F4, F2, F0 ; (F4) = a*X(i)
LD F6,0(R2) ; (F6) = Y(i)
ДОБ.Д F6, F4, F6 ; (F6) = a*X(i) + Y(i)
SD F6,0(R2) ; Y(i) = a*X(i) + Y(i)
ДАДДИУ R1, R1, #8 ; увеличаване на индекса X
ДАДДИУ R2, R2, #8 ; увеличаване на индекса Y
DSLTU R3, R1, R4 ; тест: продължаване на цикъла?
БНЕЗ R3,фу ; цикъл, ако е необходимо
Приемете закъсненията на функционалните единици, както е показано в таблицата по-долу. Да приемем
едно забавено разклонение с един цикъл, което се разрешава в етапа на ИД. Да приемем, че резултатите са пълни
заобиколен.
Инструкцията дава резултат

Инструкция за използване на резултата Закъснение в тактови цикли
FP умножение FP ALU оп 6
FP доп FP ALU оп 4
FP умножение FP магазин 5
FP доп FP магазин 4
Целочислени операции и всички Всякакви

2
зареждания
а. [25] <3.2> Да приемем конвейер с един проблем. Покажете как ще изглежда цикълът
както непланирани от компилатора, така и след планиране на компилатора и за двете
работа с плаваща запетая и закъснения на разклоненията, включително всякакви закъснения или празен часовник
цикли. Какво е времето за изпълнение (в цикли) на елемент от вектора на резултата,

Y, непланирано и планирано? Колко по-бърз трябва да бъде часовникът, за да може само
хардуерът на процесора да достигне подобрението на производителността, постигнато от
компилаторът на график? (Пренебрегвайте всички възможни ефекти от увеличения часовник
скорост върху производителността на системата с памет.)
b. [25] <3.2> Да приемем конвейер с един проблем. Развийте примката толкова пъти, колкото
необходимо, за да го планирате без никакви сергии, свивайки цикъла отгоре
инструкции. Колко пъти трябва да се развие примката? Покажете графика на обучението.
Какво е времето за изпълнение на елемент от резултата?
° С. [25] <3.7> Да приемем VLIW процесор с инструкции, които съдържат пет

операции, както е показано на фигура 3.16. Ще сравним две степени на цикъл
развиване. Първо, развийте цикъла 6 пъти, за да извлечете ILP и го планирайте без
всякакви застоявания (т.е. напълно празни цикли на издаване), свивайки режийните цикли
инструкции и след това повторете процеса, но развийте примката 10 пъти. Игнорирайте
слота за забавяне на разклонението. Покажете двата графика. Какво е времето за изпълнение по
елемент от вектора на резултата за всеки график? Какъв процент от операцията
слотовете се използват във всеки график? Колко се различава размерът на кода
между двата графика? Какво е общото търсене на регистъра за двете

графици?
3.15 [20/20] <3.4, 3.5, 3.7, 3.8> В това упражнение ще разгледаме как вариантите на
Алгоритъмът на Tomasulo се изпълнява при изпълнение на цикъла от упражнение 3.14. The
функционалните единици (FU) са описани в таблицата по-долу.
Брой резервационни
Тип FU Цикли в EX Брой FU станции
Цяло число 1 1 5
FP суматор 10 1 3
FP множител 15 1 2
Да приемем следното:
Функционалните единици не са конвейеризирани.
Няма препращане между функционални единици; резултатите се съобщават

чрез общата шина за данни (CDB).
Етапът на изпълнение (EX) извършва както изчисляването на ефективния адрес, така и

достъп до паметта за зареждания и съхранявания. Така тръбопроводът е IF/ID/IS/EX/WB.
Натоварванията изискват един тактов цикъл.
Всеки от етапите на издаване (IS) и обратно записване (WB) изисква по един тактов цикъл.
Има пет слота за буфер за зареждане и пет слота за буфер за съхранение.
Да приемем, че инструкцията за разклоняване при неравно на нула (BNEZ) изисква

един тактов цикъл.
а. [20] <3.4–3.5> За този проблем използвайте конвейерната линия Tomasulo MIPS с единичен
проблем от Фигура 3.6 със закъсненията на конвейера от таблицата по-горе. Покажете на
брой цикли на спиране за всяка инструкция и кой тактов цикъл всяка инструкция започва да се
изпълнява (т.е. влиза в своя първи EX цикъл) за три итерации на
цикъл. Колко цикъла отнема всяка итерация на цикъл? Докладвайте отговора си в
формата на таблица със следните заглавия на колони:
Итерация (номер на итерация на цикъл)
Проблеми (цикъл при проблеми с инструкции)
Изпълнява (цикли, когато инструкцията се изпълнява)

Достъп до паметта (цикъл при достъп до паметта)
Запис на CDB (цикъл, когато резултатът се запише в CDB)
Коментар (описание на всяко събитие, за което инструкцията чака)
Покажете три повторения на цикъла във вашата таблица. Можете да пренебрегнете първото
b. [20] <3.7, 3.8> Повторете част (a), но този път приемете Tomasulo от два броя
алгоритъм и напълно конвейерна единица с плаваща запетая (FPU).
3.16 [10] <3.4> Алгоритъмът на Tomasulo има недостатък: Само един резултат може да се изчисли на часовник на CDB.
Използвайте хардуерната конфигурация и закъсненията от
предишен въпрос и намерете кодова последователност от не повече от 10 инструкции
където алгоритъмът на Tomasulo трябва да спре поради спор за CDB. Посочете къде
това се случва във вашата последователност.
3.17 [20] <3.3> (m,n) корелиращ предиктор на разклонения използва поведението на най-много
скорошни m изпълнени разклонения за избор от 2m предиктори, всеки от които е n- битов предиктор.
Местният предиктор на две нива работи по подобен начин, но само
следи миналото поведение на всеки отделен клон, за да предвиди бъдещето

поведение.
Съществува компромис в дизайна, свързан с такива предиктори: Корелиращи предиктори
изискват малко памет за история, което им позволява да поддържат 2-битови предиктори
за голям брой отделни разклонения (намаляване на вероятността от разклоняване
инструкции, използващи повторно същия предсказател), докато локалните предсказатели изискват
значително повече памет за запазване на историята и по този начин са ограничени до проследяване на относително
малък брой инструкции за клонове. За това упражнение помислете за (1,2) корелиращ предиктор, който
може да проследи четири разклонения (изискващи 16 бита) срещу (1,2) локален
предиктор, който може да проследява два клона, използвайки едно и също количество памет. За
следните резултати от разклонения, осигурете всяка прогноза, използвания запис в таблицата
прогнозата, всички актуализации на таблицата в резултат на прогнозата и финала
степен на погрешно прогнозиране на всеки предиктор. Да приемем, че всички клонове до тази точка
са взети. Инициализирайте всеки предиктор към следното:
Корелиращ предиктор
Вход Клон Последен резултат Прогноза
0 0 T T с една грешна прогноза

1 0 NT NT
2 1 T NT
3 1 NT T
42 Т T
5 2 NT T
6 3 T NT с една грешна прогноза

7 3 NT NT
Локален предсказател
Входящ клон Последни 2 изхода (вдясно е най-новият) Прогноза
0 0 Т, Т T с една грешна прогноза

1 0 T,NT NT
2 0 NT,T NT
3 0 NT T
4 1 Т, Т T
5 1 T,NT T с една грешна прогноза
6 1 NT,T NT
7 1 NT, NT NT
Клон PC (адрес на думата) Резултат
454 T
543 NT
777 NT
543 NT
777 NT
454 T
777 NT
454 T
543 T
3.18 [10] <3.9> Да предположим, че имаме дълбоко конвейеризиран процесор, за който внедряваме
целеви буфер само за условните разклонения. Да приемем, че
наказанието за погрешно предвиждане винаги е четири цикъла, а наказанието за пропуск на буфера е винаги
три цикъла. Приемете 90% процент на попадение, 90% точност и 15% честота на разклонения.
Колко по-бърз е процесорът с целевия буфер в сравнение с процесора
който има фиксирано наказание за разклоняване на два цикъла? Да приемем основен тактов цикъл за
инструкция (CPI) без забавяне на разклонения от един.
3.19 [10/5] <3.9> Помислете за целеви буфер за разклонения, който има наказания от нула, две и
два тактови цикъла за правилна условна прогноза за разклоняване, неправилна прогноза,
и буферна грешка, съответно. Помислете за дизайн на буферен буфер за разклонение, който
разграничава условни и безусловни разклонения, съхранявайки целевия адрес за
условно разклоняване и целевата инструкция за безусловно разклоняване.
а. [10] <3.9> Какво е наказанието в часовниковите цикли при безусловно разклонение

се намира в буфера?
b. [10] <3.9> Определете подобрението от сгъване на клони за безусловни клони. Приемете

90% честота на попадение, безусловна честота на разклоняване от
5% и наказание от два цикъла за пропуск на буфер. Колко подобрение е
получени от това подобрение? Колко висок трябва да бъде процентът на попадение, за да може това
подобрение да осигури печалба в производителността?

4.2 Векторна архитектура 264
4.3 Разширения на SIMD набор от инструкции за мултимедия 282
4.4 Графични процесори 288
4.5 Откриване и подобряване на паралелизма на ниво цикъл 315
4.6 Междусекторни въпроси 322
4.7 Обединяване на всичко: мобилни срещу сървърни графични процесори

и Tesla срещу Core i7 323
4.10 Историческа перспектива и препратки Казус 334
и упражнения от Джейсън Д. Бакос 334

4
Паралелизъм на ниво данни в
Vector, SIMD и GPU

Архитектури 1
Наричаме тези алгоритми паралелни алгоритми за данни, тъй като техният

паралелизъм идва от едновременни операции в големи набори от данни, а не
от множество нишки за управление.
У. Даниел Хилис и Гай Л. Стийл

„Паралелни алгоритми за данни“, Comm. ACM (1986)
Ако орете нива, кое бихте предпочели: два силни вола или 1024 кокошки?
Сиймор Крей, бащата на суперкомпютъра

(спори за два мощни векторни процесора
срещу много прости процесори)

262 Четвърта глава Паралелизъм на ниво данни във векторни, SIMD и GPU архитектури
Въпрос за архитектурата с единична инструкция, множество данни (SIMD), която

Глава 1 , въведена, винаги е била колко широк е наборът от приложения
значителен паралелизъм на ниво данни (DLP). Петдесет години по-късно отговорът е не само
матрично-ориентираните изчисления на научните изчисления, но също така и медийно-ориентираната
обработка на изображения и звук. Освен това, тъй като една единствена инструкция може
стартира много операции с данни, SIMD е потенциално по-енергийно ефективен от
множество инструкции множество данни (MIMD), които трябва да извлекат и изпълнят
една инструкция за операция с данни. Тези два отговора правят SIMD привлекателен за
Лични мобилни устройства. И накрая, може би най-голямото предимство на SIMD срещу MIMD е, че
програмистът продължава да мисли последователно, но постига
паралелно ускоряване чрез паралелни операции с данни.
Тази глава обхваща три варианта на SIMD: векторни архитектури, мултиме-
dia SIMD разширения за набор от инструкции и графични процесори (GPU).1
Първата вариация, която предхожда другите две с повече от 30 години,
означава по същество конвейерно изпълнение на много операции с данни. Тези векторни
архитектурите са по-лесни за разбиране и компилиране в сравнение с други варианти на SIMD, но
доскоро се смятаха за твърде скъпи за микропроцесори.
Част от този разход беше в транзистори, а част беше в цената на достатъчно
Ширина на честотната лента на DRAM, като се има предвид широко разпространеното разчитане на кеш паметта
изисквания за производителност на конвенционалните микропроцесори.

Вторият вариант на SIMD заимства името SIMD, за да означава основно едновременни паралелни
операции с данни и се намира в повечето архитектури на набори от инструкции
днес, които поддържат мултимедийни приложения. За x86 архитектури, SIMD
разширенията на инструкциите започнаха с MMX (мултимедийни разширения) през 1996 г.,
които бяха последвани от няколко версии на SSE (поточно предаване на SIMD разширения).
следващото десетилетие и те продължават и до днес с AVX (Advanced Vector
Разширения). За да получите най-високата скорост на изчисление от x86 компютър, вие често
трябва да използвате тези SIMD инструкции, особено за програми с плаваща запетая.
Третият вариант на SIMD идва от общността на GPU, предлагайки
по-висока потенциална производителност, отколкото при традиционните многоядрени компютри
днес. Докато графичните процесори споделят функции с векторни архитектури, те имат свои собствени
отличителни характеристики, отчасти дължащи се на екосистемата, в която са се развили.
Тази среда има системен процесор и системна памет в допълнение към
GPU и неговата графична памет. Всъщност, за да разпознае тези различия, GPU
общността нарича този тип архитектура хетерогенна.
1
Тази глава се основава на материал в Приложение F, „Векторни процесори“, от Крсте Асанович, и Приложение G, „Хардуер
и софтуер за VLIW и EPIC” от 4-то издание на тази книга; върху материал в Приложение А, „Графични и компютърни графични
процесори“, от Джон Никълс и Дейвид Кърк, от 4-то издание на Компютърна организация и дизайн; и на а
по-малка степен върху материала в „Вземане и разширяване на архитектурите на набор от инструкции от 20-ти век“, от Джо Гебис и
Дейвид Патерсън, IEEE Computer, април 2007 г.
1000
MIMD*SIMD (32 b)
MIMD*SIMD (64 b)
SIMD (32 b)
SIMD (64 b)
MIMD
100
аотркоасП
лре
онелонанаилвцеян п
у
10
1
2003 г 2007 г 2011 г 2015 г 2019 г 2023 г
Фигура 4.1 Потенциално ускоряване чрез паралелизъм от MIMD, SIMD и двете MIMD и
SIMD във времето за x86 компютри. Тази цифра предполага, че две ядра на чип за
MIMD ще се добавя на всеки две години и броят на операциите за SIMD ще се удвои
на всеки четири години.
За проблеми с много паралелизъм на данни и трите варианта на SIMD споделят

предимството, че е по-лесен за програмиста от класическия паралелен MIMD
програмиране. За да поставим в перспектива важността на SIMD срещу MIMD,
Фигура 4.1 показва броя на ядрата за MIMD спрямо броя на 32-битовите и
64-битови операции на такт в режим SIMD за x86 компютри във времето.
За x86 компютри очакваме да видим две допълнителни ядра на чип на всеки две
години и ширината на SIMD да се удвоява на всеки четири години. Предвид тези предположения,
през следващото десетилетие потенциалното ускоряване от паралелизма на SIMD е два пъти по-голямо от
MIMD паралелизъм. Следователно е също толкова важно да се разбере SIMD паралелизма, колкото
и MIMD паралелизма, въпреки че последният получи много повече фанфари
наскоро. За приложения както с паралелизъм на ниво данни, така и с паралелизъм на ниво нишка,
потенциалното ускоряване през 2020 г. ще бъде с порядък по-голямо от днешното.
Целта на тази глава е архитектите да разберат защо векторът е повече
общ от мултимедийния SIMD, както и приликите и разликите
между векторни и GPU архитектури. Тъй като векторните архитектури са супермножества
на мултимедийните SIMD инструкции, включително по-добър модел за компилация,
и тъй като графичните процесори споделят няколко прилики с векторните архитектури, започваме с
векторни архитектури, за да поставите основата за следващите два раздела. Следващият
раздел въвежда векторни архитектури, докато Приложение G навлиза много по-дълбоко
предметът.
4.2 Векторна архитектура
Най-ефективният начин за изпълнение на векторизиращо приложение е векторен процесор.
Джим Смит
Международен симпозиум по компютърна архитектура (1994 г.)
Векторните архитектури грабват набори от елементи от данни, разпръснати в паметта, място
ги в големи, последователни регистърни файлове, оперира с данни в тези регистрационни файлове,
и след това разпръснете резултатите обратно в паметта. Действа една единствена инструкция
вектори на данни, което води до десетки операции регистър–регистър върху независими елементи от данни.
Тези големи регистрови файлове действат като буфери, контролирани от компилатора, и двете за скриване
латентност на паметта и за използване на честотната лента на паметта. Тъй като векторните натоварвания и
магазините са дълбоко конвейеризирани, програмата плаща дългото забавяне на паметта само веднъж
на векторно зареждане или съхраняване спрямо веднъж на елемент, като по този начин се амортизира латентността
над, да кажем, 64 елемента. Наистина векторните програми се стремят да заемат паметта.
VMIPS
Започваме с векторен процесор, състоящ се от основните компоненти, които
Фигура 4.2 показва. Този процесор, който е базиран на Cray-1, е
основа за дискусия в този раздел. Ще наречем тази инструкция
зададена архитектура VMIPS; неговата скаларна част е MIPS, а векторната му част е
логическо векторно разширение на MIPS. Останалата част от този подраздел разглежда как
основната архитектура на VMIPS е свързана с други процесори.
Основните компоненти на архитектурата на набора от инструкции на VMIPS са
следното:
Векторни регистри—Всеки векторен регистър е банка с фиксирана дължина, съдържаща единична
вектор. VMIPS има осем векторни регистъра и всеки векторен регистър съдържа 64 елемента, всеки с
ширина 64 бита. Векторният регистрационен файл трябва да осигури достатъчно портове
за захранване на всички векторни функционални единици. Тези портове ще позволят висока степен на
припокриване между векторни операции към различни векторни регистри. Прочетеното и
са свързани портове за запис, които общо най-малко 16 порта за четене и 8 порта за запис
входовете или изходите на функционалната единица се извършват чрез чифт напречни
превключватели. Векторни функционални единици—всяка единица е напълно конвейерна и може да започне нова
работа на всеки такт. Необходим е контролен блок за откриване на опасности,
както структурни опасности за функционални единици, така и опасности за данните в регистъра
достъпи. Фигура 4.2 показва, че VMIPS има пет функционални единици. За простота ние се фокусираме
изключително върху функционалните единици с плаваща запетая.

Главна памет
Векторно FP добавяне/изваждане
зареждане/съхранение
FP умножение
FP разделение
Векторни
Цяло число
регистри
Логично
Скаларни
регистри
Фигура 4.2 Основната структура на векторна архитектура, VMIPS. Този процесор има скаларна
архитектура точно като MIPS. Има и осем 64-елементни векторни регистъра и всички
функционални единици са векторни функционални единици. Тази глава дефинира специални
векторни инструкции за достъп както до аритметика, така и до памет. Фигурата показва векторни
единици за логически и цели операции, така че VMIPS изглежда като стандартен векторен
процесор, който обикновено включва тези единици; обаче няма да обсъждаме тези единици.
Векторните и скаларните регистри имат значителен брой портове за четене и запис, за да
позволят множество едновременни векторни операции. Набор от кръстосани превключватели
(дебели сиви линии) свързва тези портове към входовете и изходите на векторните функционални единици
Единица за зареждане/запаметяване на вектор —Векторната единица памет зарежда или съхранява

вектор към или от паметта. Векторните зареждания и съхранявания на VMIPS са напълно
конвейерни, така че думите да могат да се преместват между векторните регистри и паметта с
честотна лента от една дума на тактов цикъл след първоначално забавяне. Това устройство също
така нормално би обработвало скаларни натоварвания и запаметявания.
Набор от скаларни регистри—Скаларните регистри могат също така да осигурят данни като вход към
векторните функционални единици, както и изчислителни адреси за предаване към векторната
единица за зареждане/съхранение. Това са нормалните 32 регистъра с общо предназначение и 32
регистъра с плаваща запетая на MIPS. Един вход на векторните функционални единици заключва
скаларни стойности, докато те се четат от файла на скаларния регистър.
Операнди с инструкции функция
ADDVV.D V1,V2,V3 Добавете елементи от V2 и V3, след което поставете всеки резултат във V1.
ADDVS.D V1,V2,F0 Добавете F0 към всеки елемент от V2, след което поставете всеки резултат във V1.
СУБВВ.Д V1,V2,V3 Извадете елементи от V3 от V2, след което поставете всеки резултат във V1.
ПОДП.С.Д V1,V2,F0 Извадете F0 от елементите на V2, след което поставете всеки резултат във V1.
СУБСВ.Д V1,F0,V2 Извадете елементи от V2 от F0, след което поставете всеки резултат във V1.
МУЛВВ.Д V1,V2,V3 Умножете елементи от V2 и V3, след което поставете всеки резултат във V1.
MULVS.D V1,V2,F0 Умножете всеки елемент от V2 по F0, след което поставете всеки резултат във V1.
DIVVV.D V1,V2,V3 Разделете елементи от V2 на V3, след което поставете всеки резултат във V1.
ДИВВС.Д V1,V2,F0 Разделете елементи от V2 на F0, след което поставете всеки резултат във V1.
ДИВСВ.Д V1,F0,V2 Разделете F0 на елементи от V2, след което поставете всеки резултат във V1.
LV V1,R1 Заредете векторен регистър V1 от паметта, започвайки от адрес R1.
СВ R1, V1 Съхранявайте векторен регистър V1 в паметта, започвайки от адрес R1.
LVWS V1, (R1, R2) Заредете V1 от адрес в R1 с крачка в R2 (т.е. R1 + i × R2).
SVWS (R1,R2),V1 Съхранявайте V1 на адрес в R1 с крачка в R2 (т.е. R1 + i × R2).
LVI V1, (R1+V2) Заредете V1 с вектор, чиито елементи са в R1 + V2(i) (т.е. V2 е индекс).
SVI (R1+V2),V1 Съхранявайте V1 във вектор, чиито елементи са в R1 + V2(i) (т.е. V2 е индекс).
CVI V1,R1 Създайте индексен вектор, като съхраните стойностите 0, 1 × R1, 2 × R1,...,63 × R1 във V1.
S--VV.D V1,V2 Сравнете елементите (EQ, NE, GT, LT, GE, LE) във V1 и V2. Ако условието е вярно, поставете 1 в
S--VS.D V1,F0 съответния битов вектор; в противен случай поставете 0. Поставете получения битов вектор в
регистъра на векторната маска (VM). Инструкцията S--VS.D извършва същото сравнение, но използва
скаларна стойност като един операнд.
POP R1,VM Пребройте 1s във VM регистър на векторна маска и запазете броя в R1.
CVM Задайте регистъра на векторната маска на всички 1s.
MTC1 VLR, R1 Преместване на съдържанието на R1 към регистър с дължина на вектор VL.

MFC1 R1, VLR Преместете съдържанието на регистъра VL с векторна дължина в R1.
MVTM VM,F0 Преместете съдържанието на F0 към регистъра на векторната маска VM.

MVFM F0,VM Преместете съдържанието на регистъра на векторната маска VM към F0.
Фигура 4.3 Векторните инструкции на VMIPS, показващи само операциите с плаваща запетая с двойна точност. в
в допълнение към векторните регистри, има два специални регистъра, VLR и VM, обсъдени по-долу. Тези специални регистри
се предполага, че живеят в пространството на MIPS копроцесор 1 заедно с FPU регистрите. Операциите с крачка и
употребите на създаването на индекс и операциите за индексирано зареждане/съхранение са обяснени по-късно.
Фигура 4.3 изброява векторните инструкции на VMIPS. Във VMIPS, векторни операции
използвайте същите имена като скаларните MIPS инструкции, но с буквите „VV“
добавен. Така ADDVV.D е добавяне на два вектора с двойна точност. The
векторните инструкции приемат като вход или двойка векторни регистри (ADDVV.D)
или векторен регистър и скаларен регистър, обозначени чрез добавяне на „VS“
(ADDVS.D). В последния случай всички операции използват една и съща стойност в скаларния регистър като
един вход: Операцията ADDVS.D ще добави съдържанието на скаларния регистър
към всеки елемент във векторен регистър. Векторната функционална единица получава копие на
скаларна стойност към момента на издаване. Повечето векторни операции имат векторен дестинационен
регистър, въпреки че някои (като броя на населението) произвеждат скаларна стойност, която е
съхранявани в скаларен регистър.

Имената LV и SV обозначават векторно натоварване и векторно съхранение и те зареждат или

съхранява цял вектор от данни с двойна точност. Единият операнд е векторният регистър, който трябва
да бъде зареден или съхранен; другият операнд, който е MIPS с общо предназначение
регистър, е началният адрес на вектора в паметта. Както ще видим, в допълнение към векторните
регистри, имаме нужда от два допълнителни регистъра със специално предназначение:
регистри на векторна дължина и векторна маска. Първият се използва, когато естественият
дължината на вектора не е 64 и последното се използва, когато циклите включват оператори IF.
Силовата стена води архитектите към стойностни архитектури, които могат да доставят високи резултати
производителност без разходите за енергия и сложност на дизайна на суперскаларните процесори със

силно отклонение от реда. Векторните инструкции са естествено съвпадение с това
тенденция, тъй като архитектите могат да ги използват, за да увеличат производителността на обикновените ин-орд
скаларни процесори без значително увеличаване на енергийните изисквания и сложността на дизайна.

На практика разработчиците могат да изразят много от програмите, които работят добре
на сложни дизайни извън реда по-ефективно като паралелизъм на ниво данни в
форма на векторни инструкции, както показват Козиракис и Патерсън [2002].
С векторна инструкция системата може да изпълнява операциите върху вектора
елементи от данни по много начини, включително работа върху много елементи едновременно. Тази
гъвкавост позволява на векторните дизайни да използват бавни, но широки изпълнителни единици, за да
постигане на висока производителност при ниска мощност. Освен това, независимостта на елементите
в рамките на набор от векторни инструкции позволява мащабиране на функционални единици без
извършване на допълнителни скъпи проверки на зависимости, както изискват суперскаларните процесори.
Векторите естествено побират различни размери на данни. Следователно един изглед на a

размерът на векторния регистър е 64 64-битови елемента от данни, но 128 32-битови елемента, 256 16-битови
елементи и дори 512 8-битови елемента са еднакво валидни изгледи. Такъв хардуер
множествеността е причината векторната архитектура да бъде полезна за мултимедийни приложения,
както и за научни приложения.
Как работят векторните процесори: Пример
Най-добре можем да разберем векторен процесор, като разгледаме векторен цикъл за VMIPS.
Нека вземем типичен векторен проблем, който използваме в този раздел:
Y=a×X+Y
X и Y са вектори, първоначално резидентни в паметта, а a е скалар. Този проблем

е така нареченият SAXPY или DAXPY цикъл, който образува вътрешния цикъл на Linpack
бенчмарк. (SAXPY означава единична точност a × X плюс Y; DAXPY за двойна точност a × X плюс Y.) Linpack
е колекция от процедури за линейна алгебра и
бенчмаркът на Linpack се състои от процедури за извършване на елиминиране на Гаус.
Засега нека приемем, че броят на елементите или дължината на вектор
регистър (64) съответства на дължината на векторната операция, която ни интересува. (Това
ограничението ще бъде премахнато скоро.)
Пример Покажете кода за MIPS и VMIPS за DAXPY цикъла. Да приемем, че началото-

ing адресите на X и Y са съответно в Rx и Ry.
Отговор Ето MIPS кода.

LD F0,a ;зареди скалар a

DADDIU R4, Rx, #512 ;последен адрес за
Loop: LD MUL.D F2,0(Rx) зареждане ;зареждане на X[i]

LD F2, F2, F0 ;a × X[i]
F4,0(Ry) ;зареди Y[i]
ADD.D F4, F4, F2 ;a × X[i] + Y[i]
SD F4,9(Ry) ;съхранение в Y[i]
DADDIU Rx, Rx, #8 ;увеличаване на индекса до X
DADDIU Рай, Рай, №8 ;увеличаване на индекса до Y
DSUBU R20, R4, Rx ;изчисляване обвързано
БНЕЗ R20, контур ;проверете дали е готово
Ето VMIPS кода за DAXPY.

LV V1,Rx ;зареди вектор X
MULVS.D V2,V1,F0 ;векторно-скаларно умножение
LV V3, Ry ;зарежда вектор Y
ADDVV.D V4, V2, V3 ;добавете
SV V4, Ry ;запазете резултата
Най-драматичната разлика е, че векторният процесор значително намалява

динамична честотна лента на инструкции, изпълнявайки само 6 инструкции срещу почти
600 за MIPS. Това намаление се получава, защото векторните операции работят върху 64
елементи и горните инструкции, които представляват почти половината от цикъла
MIPS не присъстват в кода на VMIPS. Когато компилаторът произвежда вектор
инструкции за такава последователност и полученият код прекарва голяма част от времето си
работещ във векторен режим, се казва, че кодът е векторизиран или векторизиран. Примки
могат да бъдат векторизирани, когато нямат зависимости между итерациите на a
цикъл, които се наричат пренасяни от цикъл зависимости (вижте раздел 4.5).
Друга важна разлика между MIPS и VMIPS е честотата на
тръбопроводни блокировки. В простия MIPS код всеки ADD.D трябва да изчака
MUL.D и всеки SD трябва да изчака ADD.D. На векторния процесор, всеки
векторната инструкция ще спре само за първия елемент във всеки вектор, а след това
следващите елементи ще текат плавно по конвейера. По този начин има тръбопроводни сергии
изисква се само веднъж за векторна инструкция, а не веднъж за векторен елемент.
Векторните архитекти извикват препращане на вериги на зависими от елемент операции, в
че зависимите операции са „оковани“ заедно. В този пример,
честотата на спиране на тръбопровода на MIPS ще бъде около 64 пъти по-висока, отколкото е на VMIPS.
Софтуерната конвейерна обработка или разгръщането на цикъл (Приложение H) може да намали спиранията на конвейера
на MIPS; обаче голямата разлика в честотната лента на инструкциите не може да бъде

намалена значително.
Векторно време за изпълнение
Времето за изпълнение на последователност от векторни операции зависи основно от три

фактори: (1) дължината на операндните вектори, (2) структурни опасности сред
операции и (3) зависимостите от данни. Като се има предвид дължината на вектора и скоростта на
иницииране, която е скоростта, с която векторна единица консумира нови операнди и произвежда
нови резултати, можем да изчислим времето за една векторна инструкция. Всички съвременни
векторни компютри имат векторни функционални единици с множество паралелни конвейери (или
ленти) , които могат да произведат два или повече резултата на часовников цикъл, но те също могат
да имат някои функционални единици, които не са напълно конвейерни. За простота, нашата
реализация на VMIPS има една лента със скорост на иницииране от един елемент на тактов цикъл за
отделни операции. По този начин времето за изпълнение в тактови цикли за единична векторна
инструкция е приблизително дължината на вектора.
За да опростим обсъждането на векторното изпълнение и векторната производителност, ние
използваме понятието конвой , което е набор от векторни инструкции, които потенциално биха могли
да се изпълняват заедно. Както скоро ще видим, можете да оцените ефективността на част от кода, като
преброите броя на конвоите. Инструкциите в конвой не трябва да съдържат никакви структурни
опасности; ако такива опасности са налице, инструкциите ще трябва да бъдат серийни и инициирани
в различни конвои. За да запазим анализа прост, приемаме, че конвой от инструкции трябва да
завърши изпълнението, преди други инструкции (скаларни или векторни) да могат да започнат
изпълнението.
Може да изглежда, че в допълнение към последователностите на векторни инструкции със
структурни опасности, последователностите с опасности от зависимостта четене след запис също
трябва да бъдат в отделни конвои, но верижното им позволява да бъдат в един и същ конвой.
Верижното свързване позволява векторна операция да започне веднага щом отделните елементи
на нейния векторен операнд източник станат достъпни: Резултатите от първата функционална
единица във веригата се „препращат“ към втората функционална единица. На практика често
прилагаме верижно свързване, като позволяваме на процесора да чете и записва конкретен векторен
регистър едновременно, макар и в различни елементи. Ранните реализации на верижното свързване
работеха точно като препращане в скаларна конвейерна обработка, но това ограничаваше времето на
инструкциите на източника и местоназначението във веригата.
Последните реализации използват гъвкаво верижно свързване, което позволява на векторна
инструкция да се свърже във верига по същество с всяка друга активна векторна инструкция, като се
предполага, че не генерираме структурна опасност. Всички съвременни векторни архитектури
поддържат гъвкаво верижно свързване, което предполагаме в тази глава.
За да превърнем конвоите във време за изпълнение, се нуждаем от времева метрика, за да
оценим времето за конвой. Нарича се звънец, което е просто единицата време, необходимо за
изпълнение на един конвой. По този начин векторна последователност, която се състои от m конвоя,
се изпълнява в m камбанки; за дължина на вектор от n, за VMIPS това е приблизително m × n тактови
цикъла. Приближението на камбанката игнорира някои специфични за процесора допълнителни
разходи, много от които зависят от дължината на вектора. Следователно измерването на времето в
камбанки е по-добро приближение за дълги вектори, отколкото за къси. Ще използваме измерването
на звъненето, а не часовниковите цикли за резултат, за да посочим изрично, че пренебрегваме
определени режийни разходи.
Ако знаем броя на конвоите във векторна последователност, знаем времето за изпълнение в
камбанки. Един източник на режийни разходи, игнорирани при измерване на камбанки, е всяко
ограничение за иницииране на множество векторни инструкции в един тактов цикъл. Ако само една
векторна инструкция може да бъде инициирана в тактов цикъл (реалността в повечето векторни
процесори), броят на звънците ще подцени действителното време за изпълнение на
конвой. Тъй като дължината на векторите обикновено е много по-голяма от броя

на инструкциите в конвоя, ние просто ще приемем, че конвоят изпълнява в
един звън.
Пример Покажете как следната кодова последователност се разполага в конвои, като се приеме, че е единична
копие на всяка векторна функционална единица:
LV V1,Rx ;зареди вектор X

MULVS.D V2,V1,F0 ;векторно-скаларно умножение
ADDVV.D V4, V2, V3 ;добавете два вектора
SV V4, Ry ;запазете сумата
Колко камбанки ще отнеме тази векторна последователност? Колко цикъла на FLOP

(операция с плаваща запетая) са необходими, като се игнорира проблемът с векторните инструкции?
Отговор Първият конвой започва с първата LV инструкция. MULVS.D зависи от

първият LV, но верижното му свързване позволява да бъде в същия конвой.
Втората инструкция за LV трябва да бъде в отделен конвой, тъй като има структурна опасност
за единицата за товарене/съхранение за предишната инструкция LV. ADDVV.D е
зависи от второто LV, но може отново да бъде в същия конвой чрез верижно свързване.
И накрая, SV има структурна опасност за LV във втория конвой, така че трябва
отидете в третия конвой. Този анализ води до следното оформление на вектора
инструкции в конвои:
1. ЛВ MULVS.D
2. ЛВ ADDVV.D
3. СВ
Последователността изисква три конвоя. Тъй като последователността отнема три звъна и
има две операции с плаваща запетая за резултат, броят цикли на FLOP
е 1,5 (пренебрегвайки всички проблеми с векторни инструкции). Имайте предвид, че въпреки че ние
позволи на LV и MULVS.D да се изпълняват в първия конвой, повечето векторни
машините ще отнемат два тактови цикъла, за да започнат инструкциите.
Този пример показва, че приближението на звънеца е сравнително точно за
дълги вектори. Например, за 64-елементни вектори, времето в камбанките е 3, така че
последователността ще отнеме около 64 × 3 или 192 тактови цикъла. Разходите за издаване
конвоите в два отделни тактови цикъла биха били малки.
Друг източник на режийни разходи е много по-важен от ограничението на проблема.

Най-важният източник на режийни разходи, игнориран от модела на камбанката, е векторът
време за стартиране. Времето за стартиране се определя основно от тръбопровода
латентност на векторната функционална единица. За VMIPS ще използваме същия тръбопровод
дълбочини като Cray-1, въпреки че закъсненията в по-модерните процесори са в тенденция
да се увеличи, особено за векторни натоварвания. Всички функционални единици са напълно конвейеризирани.
Дълбочините на конвейера са 6 тактови цикъла за събиране с плаваща запетая, 7 за умножение с

плаваща запетая, 20 за разделяне с плаваща запетая и 12 за векторно натоварване.
Предвид тези векторни основи, следващите няколко подсекции ще дадат оптимизации, които или
подобряват производителността, или увеличават видовете програми, които могат да работят добре на
векторни архитектури. По-специално те ще отговорят на въпросите:
Как векторен процесор може да изпълни един вектор по-бързо от един елемент за тактов цикъл?
Няколко елемента на тактов цикъл подобряват производителността. Как един векторен
процесор обработва програми, при които дължините на вектора не са същите като дължината на
векторния регистър (64 за VMIPS)? Тъй като повечето вектори на приложения не съвпадат с
дължината на вектора на архитектурата, имаме нужда от ефективно решение за този общ случай.
Какво се случва, когато в кода, който трябва да бъде векторизиран, има оператор IF?
Повече код може да векторизира, ако можем ефективно да обработваме условни изрази. Какво
се нуждае един векторен процесор от системата с памет? Без достатъчна честотна лента на паметта
векторното изпълнение може да бъде безполезно.
Как един векторен процесор обработва многомерни матрици? Тази популярна структура от данни
трябва да се векторизира, за да се справят добре векторните архитектури.
Как векторният процесор обработва разредени матрици? Тази популярна структура на данни
ture също трябва да векторизира.
Как се програмира векторен компютър? Архитектурните иновации, които не съответстват на

технологията на компилатора, може да не получат широко приложение.
Останалата част от този раздел представя всяка от тези оптимизации на векторната архитектура, а
Приложение G навлиза в по-голяма дълбочина.
Множество ленти: Отвъд един елемент на тактов цикъл
Критично предимство на векторния набор от инструкции е, че той позволява на софтуера да предава

голямо количество паралелна работа към хардуера, като използва само една кратка инструкция.
Една векторна инструкция може да включва множество независими операции, но да бъде кодирана в
същия брой битове като конвенционалната скаларна инструкция. Паралелната семантика на векторна
инструкция позволява изпълнението да изпълни тези елементарни операции, използвайки дълбоко
конвейерна функционална единица, както в изпълнението на VMIPS, което сме изучавали досега; масив
от паралелни функционални единици; или комбинация от паралелни и конвейерни функционални
единици. Фигура 4.4 илюстрира как да се подобри векторната производителност чрез използване на
паралелни конвейери за изпълнение на инструкция за добавяне на вектор.
Наборът от инструкции VMIPS има свойството, че всички векторни аритметични инструкции

позволяват само на елемент N от един векторен регистър да участва в операции с елемент N от други
векторни регистри. Това драстично опростява конструирането на силно успоредна векторна единица,
която може да бъде структурирана като множество успоредни ленти. Както при магистрала за движение,
можем да увеличим пиковата пропускателна способност на векторна единица чрез добавяне на повече
ленти. Фигура 4.5 показва структурата на четирилентов вектор
Група елементи
(а) б)
Фигура 4.4 Използване на множество функционални единици за подобряване на производителността на единична векторна
инструкция за добавяне, C = A + B. Векторният процесор (a) отляво има един конвейер за добавяне и може да завърши едно
добавяне на цикъл. Векторният процесор (b) вдясно има четири конвейера за добавяне и може да завърши четири добавяния
на цикъл. Елементите в една инструкция за добавяне на вектор се вплитат в четирите конвейера. Наборът от елементи,
които се движат през тръбопроводите заедно, се нарича група елементи. (Възпроизведено с разрешение от Asanovic [1998].)
мерна единица. По този начин преминаването към четири ленти от една лента намалява броя на
часовниците за звънец от 64 на 16. За да бъдат много ленти изгодни, както приложенията, така и
архитектурата трябва да поддържат дълги вектори; в противен случай те ще се изпълнят толкова
бързо, че ще изчерпите честотната лента на инструкциите, изисквайки ILP техники (вижте Глава
3), за да предоставите достатъчно векторни инструкции.
Всяка лента съдържа една част от файла на векторния регистър и един конвейер за
изпълнение от всяка векторна функционална единица. Всяка векторна функционална единица
изпълнява векторни инструкции със скорост на една група елементи на цикъл, използвайки
множество конвейерни линии, по една на лента. Първата лента съдържа първия елемент
(елемент 0) за всички векторни регистри и така първият елемент във всяка векторна инструкция ще има своя източник
Пътека 0 Пътека 1 пътека 2 пътека 3
FP добавете FP добавяне FP добавяне FP добавяне
тръба 0 на тръба 1 на тръба 2 на тръба 3
Векторни Векторни Векторни Векторни
регистри: регистри: регистри: регистри:

елементи 0, елементи 1, елементи 2, елементи 3,
4, 8, . . . 5, 9, . .. 6, 10, . . . 7, 11, . . .
FP мул. FP мул. FP мул. FP мул.
тръба 0 тръба 1 тръба 2 тръба 3
Векторна товарно-складова единица
Фигура 4.5 Структура на векторна единица, съдържаща четири ленти. Съхранението на векторния регистър
е разделено между лентите, като всяка лента съдържа всеки четвърти елемент от всеки векторен регистър.
Фигурата показва три векторни функционални единици: FP add, FP multi-ply и load-store единица. Всяка от
векторните аритметични единици съдържа четири конвейера за изпълнение, по един на лента, които
действат съвместно, за да изпълнят една векторна инструкция.
Обърнете внимание, че всяка секция на векторния регистрационен файл трябва да осигури само достатъчно
портове за тръбопроводи, локални спрямо нейната лента. Тази фигура не показва пътя за предоставяне на
скаларния операнд за векторно-скаларни инструкции, но скаларният процесор (или контролният процесор)
излъчва скаларна стойност към всички ленти.
и дестинационни операнди, разположени в първата лента. Това разпределение позволява на аритметичния

тръбопровод, локален за лентата, да завърши операцията, без да комуникира с други ленти. Достъпът до
основната памет също изисква само интралентово окабеляване.
Избягването на междулентова комуникация намалява разходите за окабеляване и регистрационни файлови
портове, необходими за изграждане на високо паралелна изпълнителна единица, и помага да се обясни
защо векторните компютри могат да изпълнят до 64 операции на часовников цикъл (2 аритметични
единици и 2 единици за зареждане/съхранение в 16 ленти).
Добавянето на множество ленти е популярна техника за подобряване на векторната производителност,

тъй като изисква малко увеличаване на сложността на управлението и не изисква промени в съществуващия
машинен код. Той също така позволява на дизайнерите да компромисират площта на матрицата, тактовата
честота, напрежението и енергията, без да жертват върховата производителност. Ако тактовата честота на
векторен процесор се намали наполовина, удвояването на броя на лентите ще запази същата потенциална
Регистри с дължина на вектор: Обработка на цикли, които не са равни на 64
Процесорът на векторен регистър има естествена дължина на вектора, определена от броя

на елементите във всеки векторен регистър. Тази дължина, която е 64 за VMIPS, е малко
вероятно да съответства на реалната дължина на вектора в програмата. Освен това в реална
програма дължината на конкретна векторна операция често е неизвестна по време на
компилиране. Всъщност едно парче код може да изисква различни дължини на вектора.
Например, разгледайте този код:
за (i=0; i <n; i=i+1)

Y[i] = a X[i] + Y[i];
Размерът на всички векторни операции зависи от n, което може дори да не е известно до

момента на изпълнение! Стойността на n може също да бъде параметър на процедура,
съдържаща горния цикъл и следователно подлежи на промяна по време на изпълнение.
Решението на тези проблеми е да се създаде регистър с дължина на вектор (VLR).
VLR контролира дължината на всяка векторна операция, включително векторно зареждане
или съхраняване. Стойността във VLR обаче не може да бъде по-голяма от дължината на
векторните регистри. Това решава нашия проблем, докато реалната дължина е по-малка или
равна на максималната дължина на вектора (MVL). MVL определя броя на елементите от данни
във вектор на дадена архитектура. Този параметър означава, че дължината на векторните
регистри може да нараства в следващите компютърни поколения, без да се променя наборът
от инструкции; както ще видим в следващия раздел, мултимедийните SIMD разширения нямат
еквивалент на MVL, така че те променят набора от инструкции всеки път, когато увеличат
дължината на своя вектор.
Какво става, ако стойността на n не е известна по време на компилиране и следователно
може да е по-голяма от MVL? За справяне с втория проблем, при който векторът е по-дълъг от
максималната дължина, се използва техника, наречена strip mining . Strip mining е генериране
на код, така че всяка векторна операция да се извършва за размер, по-малък или равен на
MVL. Създаваме един цикъл, който обработва произволен брой итерации, който е кратен на
MVL, и друг цикъл, който обработва всички оставащи итерации и трябва да бъде по-малък от
MVL. На практика компилаторите обикновено създават единичен цикъл, който се копае, който
е параметризиран да обработва и двете части чрез промяна на дължината. Показваме стрип-
минираната версия на DAXPY цикъла в C:
ниско = 0;
VL = (n % MVL); /*намиране на парче с нечетен размер, използвайки модул op % */
за (j = 0; j <= (n/MVL); j=j+1) { /*външен цикъл*/
for (i = low; i < (low+VL); i=i+1) /*работи за дължина VL*/
Y[i] = a * X[i] + Y[i] ; /*основна операция*/
ниско = ниско + VL; /*начало на следващия вектор*/
VL = MVL; /*нулиране на дължината до максимална дължина на вектора*/
}
Терминът n/MVL представлява съкращаващо целочислено деление. Ефектът от този цикъл е

да блокира вектора в сегменти, които след това се обработват от вътрешния цикъл. The
Стойността на j 0 123 . . . ... n/MVL
Обхват на i 0 м (m + MVL) (m + 2 × MVL) ... ... (n MVL)

.. .. .. .. ..
(m 1) (m 1) (m 1) (m 1) (n 1)
+ MVL + 2 × MVL + 3 × MVL
Фигура 4.6 Вектор с произволна дължина, обработен с лентово копаене. Всички блокове, но
първите са с дължина MVL, използвайки пълната мощност на векторния процесор. В тази фигура,
използваме променливата m за израза (n % MVL). (Операторът C % е по модул.)
дължината на първия сегмент е (n % MVL), а всички следващи сегменти са от

дължина MVL. Фигура 4.6 показва как да разделим дългия вектор на сегменти.
Вътрешният цикъл на предходния код може да се векторизира с дължина VL, което е
равно на (n % MVL) или MVL. VLR регистърът трябва да бъде зададен два пъти в
код, веднъж на всяко място, където е присвоена променливата VL в кода.
Регистри на векторни маски: Работа с оператори IF във векторни цикли
От закона на Амдал знаем, че ускоряването на програми с ниски до умерени нива на векторизация

ще бъде много ограничено. Наличието на условни изрази (АКО
оператори) вътре в цикли и използването на редки матрици са две основни причини за
по-ниски нива на векторизация. Програми, които съдържат оператори IF в цикли, не могат
се изпълняват във векторен режим, като се използват техниките, които обсъждахме досега, защото
IF операторите въвеждат контролни зависимости в цикъл. По същия начин ние не можем
прилагане на разредени матрици ефективно, използвайки всяка от възможностите, които сме виждали
до тук. Обсъждаме стратегии за справяне с условно изпълнение тук, напускайки
обсъждането на разредените матрици за по-късно.
Помислете за следния цикъл, написан на C:
за (i = 0; i < 64; i=i+1) ако (X[i] != 0)
X[i] = X[i] – Y[i];
Този цикъл обикновено не може да бъде векторизиран поради условното изпълнение на

тялото; обаче, ако вътрешният цикъл може да се изпълнява за итерациите, за които
X[i] 0, тогава изваждането може да бъде векторизирано.
Общото разширение за тази възможност е управление на векторна маска. Регистрите на
маската по същество осигуряват условно изпълнение на всяка елементна операция във векторна
инструкция. Контролът на векторната маска използва булев вектор за управление на
изпълнение на векторна инструкция, точно както условно изпълнените инструкции използват a

Булево условие за определяне дали да се изпълни скаларна инструкция. Когато
регистърът на векторната маска е активиран, всички изпълнени векторни инструкции работят само върху
векторните елементи, чиито съответстващи записи в регистъра на векторната маска са

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

като приемем, че началните адреси на X и Y са съответно в Rx и Ry:
LV V1,Rx ;зареди вектор X във V1

LD F0,#0 ;заредете FP нула във F0
СНЕВС.Д V1,F0 ;задава VM(i) на 1, ако V1(i)!=F0 ;изваждане под
СУБВВ.Д СВ V1,V1,V2 векторна маска ;съхранява резултата в X
V1,Rx
Писателите на компилаторите извикват трансформацията, за да променят оператор IF в праволинейна

кодова последователност, използвайки условно изпълнение ако преобразуване.
Използването на регистър на векторна маска обаче има допълнителни разходи. При скаларните
архитектури условно изпълнените инструкции все още изискват време за изпълнение, когато
условието не е изпълнено. Независимо от това, елиминирането на разклонение и свързаните контролни
зависимости може да направи условната инструкция по-бърза, дори ако понякога върши безполезна
работа. По същия начин, векторни инструкции, изпълнявани с векторна маска
все още отнемат същото време за изпълнение, дори за елементите, където маската е нула.
По същия начин, дори и със значителен брой нули в маската, използвайки векторна маска
управлението все още може да бъде значително по-бързо от използването на скаларен режим.
Както ще видим в раздел 4.4, една разлика между векторните процесори и

Графичните процесори са начинът, по който те обработват условни изрази. Векторните процесори правят
mask регистрира част от архитектурното състояние и разчита на компилатори за манипулиране
маската се регистрира изрично. За разлика от това, графичните процесори получават същия ефект, като използват хардуер
манипулирайте вътрешни регистри на маски, които са невидими за софтуера на GPU. И в двете

случаи хардуерът изразходва времето за изпълнение на векторен елемент, независимо дали
mask е нула или едно, така че скоростта на GFLOPS пада, когато се използват маски.
Банки памет: Предоставяне на честотна лента за

Векторни единици за зареждане/съхранение
Поведението на векторната единица за зареждане/запаметяване е значително по-сложно от

тази на аритметичните функционални единици. Времето за стартиране на натоварване е времето за
вземете първата дума от паметта в регистър. Ако останалата част от вектора може да бъде доставена без
спиране, тогава скоростта на иницииране на вектора е равна на скоростта, при която
нови думи се извличат или съхраняват. За разлика от по-простите функционални единици иници
скоростта може да не е непременно един такт, защото банката памет може да блокира
намаляване на ефективната производителност.
Обикновено санкциите за стартиране на единици за зареждане/съхранение са по-високи от тези за

аритметични единици - над 100 тактови цикъла на много процесори. За VMIPS ние
приемете време за стартиране от 12 тактови цикъла, същото като Cray-1. (По-скорошен
векторните компютри използват кешове, за да намалят латентността на векторните зареждания и съхранявания.)
За да поддържа скорост на иницииране от една изтеглена или съхранена дума на часовник,

системата с памет трябва да може да произвежда или приема толкова много данни.
Разпределянето на достъпа в множество независими банки памет обикновено осигурява желаната
скорост. Както скоро ще видим, наличието на значителен брой банки е полезно за работа с векторни
натоварвания или хранилища, които имат достъп до редове или колони с данни.
Повечето векторни процесори използват банки памет, които позволяват множество независими
dent достъпи, а не просто преплитане на паметта поради три причини:
1. Много векторни компютри поддържат множество зареждания или запаметявания на часовник и

времето за цикъл на паметта обикновено е няколко пъти по-голямо от времето за цикъл на
процесора. За да поддържа едновременен достъп от множество зареждания или магазини,
системата с памет се нуждае от множество банки и за да може да контролира адресите към
банките независимо.
2. Повечето векторни процесори поддържат способността да зареждат или съхраняват думи с данни,
които не са последователни. В такива случаи се изисква независимо банково адресиране, а не
взаимно оставяне.
3. Повечето векторни компютри поддържат множество процесори, споделящи една и съща система с
памет, така че всеки процесор ще генерира свой собствен независим поток от адреси.
В комбинация тези характеристики водят до голям брой независими банки памет, както показва
следният пример.
Пример Най-голямата конфигурация на Cray T90 (Cray T932) има 32 процесора, всеки от които може да генерира 4
зареждания и 2 запаметявания на тактов цикъл. Тактовият цикъл на процесора е 2,167 ns, докато
времето за цикъл на SRAM, използвани в системата с памет, е 15 ns. Изчислете минималния брой
банки памет, необходими, за да позволи на всички процесори да работят при пълна честотна лента
на паметта.
Отговор Максималният брой препратки към паметта за всеки цикъл е 192: 32 процесора по 6 препратки на
процесор. Всяка SRAM банка е заета за 15/2,167 = 6,92 тактови цикъла, които закръгляме до 7 тактови
цикъла на процесора. Следователно ние изискваме минимум 192 × 7 = 1344 банки памет!
Cray T932 всъщност има 1024 банки памет, така че ранните модели не можеха да поддържат пълна
честотна лента към всички процесори едновременно. Последващото надграждане на паметта замени
15 ns асинхронните SRAM с конвейерни синхронни SRAM, които намалиха наполовина времето на
цикъла на паметта, като по този начин осигуряват достатъчна честотна лента.
От гледна точка на по-високо ниво, единиците за векторно зареждане/съхранение играят подобна роля на
единиците за предварително извличане в скаларните процесори, тъй като и двете се опитват да осигурят честотна
лента на данни, като доставят на процесорите потоци от данни.

Stride: Работа с многомерни масиви във вектор

Архитектури
Позицията в паметта на съседни елементи във вектор може да не е последователна.

Разгледайте този прост код за умножение на матрици в C:
за (i = 0; i < 100; i=i+1)

за (j = 0; j < 100; j=j+1) { A[i][j] = 0.0; за (k
= 0; k < 100; k=k+1)
A[i][j] = A[i][j] + B[i][k] * D[k][j];

}
Можем да векторизираме умножението на всеки ред от B с всяка колона от D и да

изчистим вътрешния цикъл с k като индексна променлива.
За да направим това, трябва да обмислим как да адресираме съседни елементи в B и
съседни елементи в D. Когато на масив е разпределена памет, той е линеаризиран и трябва
да бъде разположен или в главния ред (както в C), или в колона основен (както във Fortran) ред.
Тази линеаризация означава, че или елементите в реда, или елементите в колоната
не са съседни в паметта. Например кодът C по-горе разпределя в реда на главния
ред, така че елементите на D, до които се осъществява достъп чрез итерации във
вътрешния цикъл, са разделени от размера на реда, умножен по 8 (броя байтове на
запис) за общо 800 байта . В глава 2 видяхме, че блокирането може да подобри
локалността в базирани на кеш системи. За векторни процесори без кешове се
нуждаем от друга техника за извличане на елементи от вектор, които не са съседни в паметта.
Това разстояние, разделящо елементите, които трябва да бъдат събрани в един
регистър, се нарича стъпка. В този пример матрица D има стъпка от 100 двойни думи
(800 байта), а матрица B ще има стъпка от 1 двойна дума (8 байта). За големия ред на
колони, който се използва от Fortran, крачките ще бъдат обърнати. Матрица D ще
има стъпка от 1 или 1 двойна дума (8 байта), разделяща последователни елементи,
докато матрица B ще има стъпка от 100 или 100 двойни думи (800 байта). По този
начин, без пренареждане на циклите, компилаторът не може да скрие дългите
разстояния между последователни елементи за B и D.
След като векторът бъде зареден във векторен регистър, той действа така, сякаш има логически
съседни елементи. По този начин векторният процесор може да обработва крачки, по-големи от
една, наречени неединични крачки, като използва само операции за векторно зареждане и
съхраняване на вектори с възможност за крачка. Тази способност за достъп до непоследователни
места в паметта и преформатирането им в плътна структура е едно от основните предимства на
векторния процесор. Кешовете по своята същност се занимават с данни за крачка на единица;
увеличаването на размера на блока може да помогне за намаляване на процентите на пропуски за
големи научни набори от данни с единична стъпка, но увеличаването на размера на блока може
дори да има отрицателен ефект за данни, до които се осъществява достъп с неединична стъпка.
Докато техниките за блокиране могат да разрешат някои от тези проблеми (вижте глава 2),
способността за ефективен достъп до данни, които не са съседни, остава предимство за векторните
процесори при определени проблеми, както ще видим в раздел 4.7.
При VMIPS, където адресируемата единица е байт, стъпката за нашия пример ще

бъде 800. Стойността трябва да се изчисли динамично, тъй като размерът на
матрицата може да не е известна по време на компилиране или - точно като дължината на вектора - може да се промени
за различни изпълнения на едно и също изявление. Векторът крачи, като вектора
начален адрес, може да се впише в регистър с общо предназначение. След това VMIPS инструкцията
LVWS (зареждане на вектор със стъпка) извлича вектора във векторен регистър. По същия начин,
когато съхранявате вектор на крачка без единица, използвайте инструкцията SVWS (вектор за съхраняване
с крачка).
Поддържането на крачки, по-големи от една, усложнява системата за памет. След като ние
въвеждане на крачки без единици, става възможно да се изискват достъпи от същото
банка често. Когато множество достъпи се борят за банка, банка памет
възниква конфликт, като по този начин спира един достъп. Конфликт в банката и оттам застой
ще възникне, ако
Брой банки
-------------------------------------------------- -------------------------------------------------- ---------------------
< Банката е натоварено време
Най-малко общо кратно (крачка, брой банки)
Пример Да предположим, че имаме 8 банки памет с време на заетост на банката от 6 часовника и общо
латентност на паметта от 12 цикъла. Колко време ще отнеме завършването на 64-елемент
векторно натоварване с крачка 1? С крачка 32?
Отговор Тъй като броят на банките е по-голям от времето на заетост на банката, за крачка от 1
натоварването ще отнеме 12 + 64 = 76 тактови цикъла или 1,2 тактови цикъла на елемент. The
най-лошата възможна стъпка е стойност, която е кратна на броя на банките памет,
както в този случай със стъпка от 32 и 8 банки памет. Всеки достъп до паметта
(след първия) ще се сблъска с предишния достъп и ще трябва да изчака
времето за заетост на банката с 6 часовникови цикъла. Общото време ще бъде 12 + 1 + 6 * 63 = 391
тактови цикли или 6,1 тактови цикъла на елемент.
Gather-Scatter: Работа с редки матрици във вектор

Архитектури
Както бе споменато по-горе, разредените матрици са често срещани, така че е важно да ги има
техники, които позволяват на програми с разредени матрици да се изпълняват във векторен режим. в
разредена матрица, елементите на вектор обикновено се съхраняват в някаква компактна
форма и след това се осъществява индиректен достъп. Приемайки опростена рядка структура, ние
може да видите код, който изглежда така:
за (i = 0; i < n; i=i+1)
A[K[i]] = A[K[i]] + C[M[i]];
Този код прилага разредена векторна сума на масивите A и C, използвайки индексни вектори K и M
за обозначаване на ненулевите елементи на A и C. (A и C трябва да имат
същия брой ненулеви елементи - n от тях - така че K и M са с еднакъв размер.)
Основният механизъм за поддържане на редки матрици е събиране-разпръскване
операции , използващи индексни вектори. Целта на такива операции е да се подпомогне движението
между компресирано представяне (т.е. не са включени нули) и нормално
представяне (т.е. нулите са включени) на разредена матрица. Събирателна операция _
взема индексен вектор и извлича вектора, чиито елементи са на адресите
даден чрез добавяне на базов адрес към отместванията, дадени във вектора на индекса. Резултатът
е плътен вектор във векторен регистър. След като тези елементи се оперират в
плътна форма, редкият вектор може да се съхранява в разширена форма чрез разпръснато хранилище,
използвайки същия индексен вектор. Хардуерната поддръжка за такива операции се нарича
gather-scatter и се появява на почти всички съвременни векторни процесори. VMIPS
инструкциите са LVI (зареждане на вектор, индексиран или събиран) и SVI (запаметен вектор, индексиран
или разпръснати). Например, ако Ra, Rc, Rk и Rm съдържат началните адреси на
вектори в предишната последователност, можем да кодираме вътрешния цикъл с векторни инструкции
като:
LV Vk, Rk ;зареди
LVI Va, (Ra+Vk) K ;зареди A[K[]]
LV Vm, Rm ;зареди М
LVI Vc, (Rc+Vm) ;зареди C[M[]]
ADDVV.D Va, Va, Vc ;добавете ги
SVI (Ra+Vk), Va ;съхранение A[K[]]
Тази техника позволява код с разредени матрици да се изпълнява във векторен режим. А
простият векторизиращ компилатор не може автоматично да векторизира изходния код
по-горе, защото компилаторът няма да знае, че елементите на K са различни
стойности и по този начин не съществуват зависимости. Вместо това директива за програмист
ще каже на компилатора, че е безопасно да стартира цикъла във векторен режим.
Въпреки че индексираните зареждания и съхранявания (събиране и разпръскване) могат да бъдат тръбопроводни, те
обикновено се изпълняват много по-бавно от неиндексираните зареждания или съхранявания, тъй

като банките с памет не са известни в началото на инструкцията. Всеки елемент има индивидуален
адрес, така че те не могат да се обработват в групи и може да има конфликти в
много места в системата на паметта. По този начин всеки отделен достъп носи
значителна латентност. Въпреки това, както показва раздел 4.7 , системата с памет може да осигури
по-добра производителност чрез проектиране за този случай и използване на повече хардуер
ресурси срещу когато архитектите имат laissez faire отношение към тях
достъпи.
Както ще видим в раздел 4.4, всички зареждания са сборове и всички съхранявания са разпръснати
в GPU. За да избегнете бавното бягане в честия случай на единични крачки, е до
програмистът на GPU, за да гарантира, че всички адреси в събиране или разпръскване са към
съседни местоположения. Освен това хардуерът на GPU трябва да разпознае последователността
от тези адреси по време на изпълнение, за да превърне събиранията и разпръскванията в повече
ефективен достъп до паметта на единица.
Програмиране на векторни архитектури
Предимство на векторните архитектури е, че компилаторите могат да кажат на програмистите

време за компилиране дали част от кода ще се векторизира или не, като често дава съвети като
защо не векторизира кода. Този лесен модел на изпълнение позволява
експерти в други области, за да научат как да подобрят ефективността, като преразгледат своите
код или чрез даване на съвети на компилатора кога е добре да се приеме независимост
между операциите, като например за събиране-разпръскване на данни. Това е този диалог
между компилатора и програмиста, като всяка страна дава съвети за
други за това как да се подобри производителността, което опростява програмирането на вектор
компютри.
Днес основният фактор, който влияе върху успеха, с който се изпълнява една програма
векторният режим е структурата на самата програма: циклите имат ли верни данни
зависимости (вижте раздел 4.5), или могат да бъдат преструктурирани така, че да нямат такива
зависимости? Този фактор се влияе от избраните алгоритми и някои
степен, от това как са кодирани.
Като индикация за нивото на векторизация, постижимо в научните програми, нека да
разгледаме нивата на векторизация, наблюдавани за бенчмарковете на Perfect Club. Фигура 4.7
показва процента на операциите, изпълнени във векторен режим за
две версии на кода, работещ на Cray Y-MP. Първата версия е такава
получен само с оптимизация на компилатора върху оригиналния код, докато вторият
версията използва обширни съвети от екип от програмисти на Cray Research. Няколко
проучванията на производителността на приложенията върху векторни процесори показват голямо
разнообразие в нивото на векторизация на компилатора.
Операциите са изпълнени Операциите са изпълнени

Бенчмарк във векторен режим, във векторен режим, Ускоряване от
име оптимизиран за компилатор с помощта на програмист оптимизация на намек
BDNA 96,1% 97,2% 1.52
MG3D 95,1% 94,5% 1,00
FLO52 91,5% 88,7% N/A
ARC3D 91,1% 92,0% 1.01
SPEC77 90,3% 90,4% 1.07
ЦХР 87,7% 94,2% 1.49
TRFD 69,8% 73,7% 1.67
ДИФЕСМ 68,8% 65,6% N/A
ADM 42,9% 59,6% 3.60
ОКЕАН 42,8% 91,2% 3.92
ТРАК 14,4% 54,6% 2.52
ПОДПРАВКА 11,5% 79,9% 4.06
КХД 4,2% 75,1% 2.15
Фигура 4.7 Ниво на векторизация сред бенчмарковете на Perfect Club, когато

изпълнен на Cray Y-MP [Vajapeyam 1991]. Първата колона показва нивото на векторизация,
получено с компилатора без подсказки, докато втората колона показва
резултатите след кодовете са подобрени със съвети от екип на Cray Research
програмисти.
Богатите на подсказки версии показват значителни подобрения в нивото на векторизация за кодове

компилаторът не може да векторизира добре сам, като всички кодове вече са над 50%
векторизация. Средната векторизация се подобри от около 70% до около 90%.
4.3 Разширения на SIMD инструкции за мултимедия
Мултимедийните разширения на SIMD започнаха с простото наблюдение, че много

медийните приложения работят с по-тесни типове данни от 32-битовите процесори
бяха оптимизирани за. Много графични системи използват 8 бита за представяне на всеки от
три основни цвята плюс 8 бита за прозрачност. В зависимост от приложението,
аудио пробите обикновено се представят с 8 или 16 бита. Чрез разделяне на носенето
вериги в рамките на, да речем, 256-битов суматор, процесорът може да изпълнява едновременно
операции върху къси вектори от тридесет и два 8-битови операнда, шестнадесет 16-битови операнда,
осем 32-битови операнда или четири 64-битови операнда. Допълнителните разходи за такива разделени
суматори бяха малки. Фигура 4.8 обобщава типичен мултимедиен SIMD
инструкции. Подобно на векторните инструкции, SIMD инструкцията определя същото
операция върху вектори от данни. За разлика от векторните машини с големи регистрови файлове
като VMIPS векторен регистър, който може да съдържа до шестдесет и четири 64 бита
елементи във всеки от 8 векторни регистъра, SIMD инструкциите са склонни да определят по-малко
операнди и следователно използват много по-малки регистрови файлове.
За разлика от векторните архитектури, които предлагат елегантен набор от инструкции, който

е предназначен да бъде целта на векторизиращ компилатор, SIMD разширенията имат
три основни пропуска:
Мултимедийните SIMD разширения фиксират броя на операндите за данни в

opcode, което доведе до добавянето на стотици инструкции в
MMX, SSE и AVX разширения на x86 архитектурата. Векторните архитектури имат регистър на
дължината на вектора, който определя броя на операндите за

текущата операция. Тези векторни регистри с променлива дължина лесно побират програми, които
естествено имат по-къси вектори от максималния размер
архитектурата поддържа. Освен това векторните архитектури имат имплицитно
максимална дължина на вектора в архитектурата, която се комбинира с вектора
регистърът на дължината избягва използването на много кодове за операции.
Категория на инструкциите Операнди
Събиране/изваждане без знак Тридесет и два 8-битови, шестнадесет 16-битови, осем 32-битови или четири 64-битови
Максимум/минимум Тридесет и два 8-битови, шестнадесет 16-битови, осем 32-битови или четири 64-битови
Средно аритметично Тридесет и два 8-битови, шестнадесет 16-битови, осем 32-битови или четири 64-битови
Преместване надясно/наляво Тридесет и два 8-битови, шестнадесет 16-битови, осем 32-битови или четири 64-битови
Плаваща запетая Шестнадесет 16-битови, осем 32-битови, четири 64-битови или две 128-битови
Фигура 4.8 Обобщение на типичната SIMD мултимедийна поддръжка за 256-битови операции. Имайте предвид, че стандартът IEEE
754-2008 с плаваща запетая добави половин прецизност (16 бита)
и операции с плаваща запетая с четири точност (128 бита).

4.3 Разширения на SIMD инструкции за мултимедия 283
Мултимедийният SIMD не предлага по-сложните режими на адресиране на векторните архитектури,

а именно бърз достъп и достъп с събиране и разпръскване.
Тези функции увеличават броя на програмите, които векторният компилатор може успешно да
векторизира (вижте раздел 4.7).
Мултимедийният SIMD обикновено не предлага регистрите на маската за поддръжка на условия

ционално изпълнение на елементи като във векторните архитектури.
Тези пропуски правят по-трудно за компилатора генерирането на SIMD код и увеличават трудността на
програмирането на асемблерния език на SIMD.
За x86 архитектурата инструкциите MMX, добавени през 1996 г., пренасочиха 64-битовите регистри
с плаваща запетая, така че основните инструкции можеха да изпълняват осем 8-битови операции или
четири 16-битови операции едновременно. Към тях се присъединиха паралелни MAX и MIN операции,
голямо разнообразие от маскиращи и условни инструкции, операции, които обикновено се срещат в
цифрови сигнални процесори, и ad hoc инструкции, за които се смяташе, че са полезни във важни
медийни библиотеки. Имайте предвид, че MMX повторно използва инструкциите за прехвърляне на
данни с плаваща запетая за достъп
памет.
Наследникът на Streaming SIMD Extensions (SSE) през 1999 г. добави отделни регистри с ширина 128
бита, така че сега инструкциите могат едновременно да изпълняват шестнадесет 8-битови операции,
осем 16-битови операции или четири 32-битови операции. Той също така извършва паралелна
аритметика с плаваща запетая с единична точност. Тъй като SSE имаше отделни регистри, имаше нужда
от отделни инструкции за прехвърляне на данни. Intel скоро добави SIMD типове данни с плаваща
запетая с двойна точност чрез SSE2 през 2001 г., SSE3 през 2004 г. и SSE4 през 2007 г. Инструкциите с
четири операции с плаваща запетая с единична точност или две паралелни операции с двойна точност
увеличиха пиковия плаващ производителност на x86 компютрите, стига програмистите да поставят
операндите един до друг. С всяко поколение те добавят и ad hoc инструкции, чиято цел е да ускорят
специфични мултимедийни функции, които се възприемат като важни.
Разширените векторни разширения (AVX), добавени през 2010 г., удвояват ширината на регистрите
отново до 256 бита и по този начин предлагат инструкции, които удвояват броя на операциите върху
всички по-тесни типове данни. Фигура 4.9 показва AVX инструкции, полезни за изчисления с плаваща
запетая с двойна точност. AVX включва подготовка за разширяване на ширината до 512 бита и 1024
бита в бъдещите поколения на архитектурата.
Като цяло, целта на тези разширения е да ускорят внимателно написаните библиотеки, вместо
компилаторът да ги генерира (вижте Приложение H), но последните x86 компилатори се опитват да
генерират такъв код, особено за приложения с интензивно използване на плаваща запетая .
Предвид тези слабости, защо мултимедийните SIMD разширения са толкова популярни? Първо,
те струват малко за добавяне към стандартната аритметична единица и са лесни за прилагане. Второ,
те изискват малко допълнително състояние в сравнение с векторните архитектури, което винаги е
проблем за времето за превключване на контекста. Трето, имате нужда от голяма честотна лента на
паметта, за да поддържате векторна архитектура, която много компютри нямат. Четвърто, SIMD не
трябва да се справя с проблеми в
Инструкция за AVX Описание
VADDPD Добавете четири пакетирани операнда с двойна точност
VSUBPD Извадете четири пакетирани операнда с двойна точност
ВМУЛПД Умножете четири опаковани операнда с двойна точност
VDIVPD Разделете четири пакетирани операнда с двойна точност
VFMADDPD Умножете и добавете четири опаковани операнда с двойна точност
VFMSUBPD Умножете и извадете четири опаковани операнда с двойна точност
VCMPxx Сравнете четири опаковани операнда с двойна точност за EQ, NEQ, LT, LE, GT, GE, ...
VMOVAPD Преместете подравнени четири опаковани операнда с двойна точност
VBROADCASTSD Излъчване на един операнд с двойна точност до четири местоположения в 256-битов регистър
Фигура 4.9 AVX инструкции за x86 архитектура, полезни в програми с плаваща запетая с двойна точност. Packed-double за 256-битов AVX означава четири 64-
битови операнда, изпълнени в SIMD режим. Тъй като ширината се увеличава с AVX, това е така
все по-важно е да се добавят инструкции за пермутация на данни, които позволяват комбинации от тесни операнди от различни части на широките регистри.
AVX включва инструкции, които разбъркват 32-битови, 64-битови или 128-битови операнди в рамките на
256-битов регистър. Например BROADCAST репликира 64-битов операнд 4 пъти в AVX регистър. AVX включва също a
голямо разнообразие от слети инструкции за умножение-събиране/изваждане; показваме само две тук.
виртуална памет, когато една инструкция може да генерира 64 памет

достъпите могат да получат грешка на страницата в средата на вектора. Използване на SIMD разширения
отделни трансфери на данни за SIMD група от операнди, които са подравнени в паметта и така не
могат да пресичат границите на страницата. Друго предимство на късото,
„вектори“ с фиксирана дължина на SIMD е, че е лесно да се въведат инструкции, които
може да помогне с нови медийни стандарти, като инструкции, които извършват пермутации или
инструкции, които консумират по-малко или повече операнди от векторите
може да произвежда. И накрая, имаше загриженост за това колко добре са векторните архитектури
може да работи с кешове. По-новите векторни архитектури са адресирани към всички
тези проблеми, но наследството от минали недостатъци оформи скептичното отношение

към вектори сред архитектите.
Пример За да дадем представа как изглеждат мултимедийните инструкции, приемете, че сме добавили
256-битови SIMD мултимедийни инструкции към MIPS. Ние се концентрираме върху плаваща
запетая в този пример. Добавяме суфикса „4D“ към инструкциите, които работят
четири операнда с двойна точност наведнъж. Подобно на векторните архитектури, можете
мислете за SIMD процесор като за ленти, четири в този случай. MIPS SIMD ще
повторно използване на регистрите с плаваща запетая като операнди за 4D инструкции, точно
както двойна точност използва повторно регистри с единична точност в оригиналния MIPS. Този пример
показва MIPS SIMD код за DAXPY цикъла. Да приемем, че началните адреси
на X и Y са съответно в Rx и Ry. Подчертайте промените в MIPS
код за SIMD.
Отговор Ето MIPS кода:

MOV F1, F0 ;копирайте a във F1 за SIMD MUL
DADDIU R4,Rx,#512 ;последен адрес за зареждане Loop:
L.4D F4,0(Rx) ;зареждане X[i], X[i+1], X[i+2], X[i+3]
MUL.4D F4,F4,F0 ;a×X[i],a×X[i+1],a×X[i+2],a×X[i+3]
L.4D F8,0(Ry); натоварване Y[i], Y[i+1], Y[i+2], Y[i+3]
ADD.4D F8,F8,F4 ;a×X[i]+Y[i], ..., a×X[i+3]+Y[i+3]
S.4D F8,0(Rx) ; съхранява в Y[i], Y[i+1], Y[i+2], Y[i+3]
DADDIU Rx,Rx,#32 ;увеличаване на индекса до X
DADDIU Ry,Ry,#32 ;увеличаване на индекса до Y
DSUBU R20,R4,Rx ;изчисление обвързано
BNEZ R20, Loop; проверете дали е готово
Промените заменяха всяка MIPS инструкция с двойна точност с нейната 4D

еквивалент, увеличаване на увеличението от 8 на 32 и промяна на регистрите
от F2 и F4 до F4 и F8, за да получите достатъчно място в регистрационния файл за четири
последователни операнди с двойна точност. Така че всяка SIMD лента ще има своя
собствено копие на скалара a, ние копирахме стойността на F0 в регистри F1, F2 и F3.
(Истинските разширения на SIMD инструкции имат инструкция за излъчване на стойност към всички
други регистри в група.) Така умножението прави F4*F0, F5*F1, F6*F2 и
F7*F3. Въпреки че не е толкова драматично, колкото 100× намалението на честотната лента
на динамичните инструкции на VMIPS, SIMD MIPS получава 4× намаление: 149 срещу 578
инструкции, изпълнени за MIPS.
Програмиране на мултимедийни SIMD архитектури
Предвид ad hoc характера на SIMD мултимедийните разширения, най-лесният начин

за да използвате тези инструкции е било чрез библиотеки или чрез писане в асемблиране
език.
Последните разширения станаха по-редовни, давайки на компилатора повече
разумна цел. Като заимстват техники от векторизиращи компилатори, компилаторите
започват автоматично да произвеждат SIMD инструкции. Например,
напредналите компилатори днес могат да генерират SIMD инструкции с плаваща запетая за
осигуряват много по-висока производителност за научни кодове. Програмистите обаче
трябва да сте сигурни, че подравнявате всички данни в паметта спрямо ширината на модула SIMD
който кодът се изпълнява, за да попречи на компилатора да генерира скаларни инструкции
за иначе векторизиращ код.
Моделът за визуална производителност Roofline
Един визуален, интуитивен начин за сравняване на потенциалната производителност с плаваща запетая на

вариации на SIMD архитектурите е моделът Roofline [Williams et al. 2009].
О(1) НА)
O(log(N))
Ритметична интензивност
Спектрален
Разредени Плътен
методи N-тяло
матрица матрица
(FFT) (Частица
(SpMV) (BLAS3)
методи)
Структуриран Структуриран
решетки решетки
(Шаблони, (Решетка
PDE) методи)
Фигура 4.10 Аритметичен интензитет, определен като броя на операциите с плаваща запетая за изпълнение
на програмата, разделен на броя байтове, достъпни в основната памет
[Уилямс и др. 2009]. Някои ядра имат аритметичен интензитет, който се мащабира с размера на проблема,
като плътна матрица, но има много ядра с аритметичен интензитет
независимо от размера на проблема.
Той свързва производителността с плаваща запетая, производителността на паметта и

аритметичния интензитет в двуизмерна графика. Аритметичният интензитет е отношението на
операции с плаваща запетая на байт достъпна памет. Може да се изчисли по
като общия брой операции с плаваща запетая за програма разделен на
общият брой байтове данни, прехвърлени към основната памет по време на изпълнение на
програмата. Фигура 4.10 показва относителната аритметична интензивност на няколко примера
ядки.
Пикова производителност с плаваща запетая може да се намери чрез хардуерните

спецификации. Много от ядрата в този казус не се побират в кеша на чипа, така че пик
производителността на паметта се определя от системата на паметта зад кеш паметта. Забележка
че имаме нужда от пиковата честотна лента на паметта, която е достъпна за процесорите, не
само на щифтовете на DRAM, както е на Фигура 4.27 на страница 325. Един от начините да намерите
(доставената) пикова производителност на паметта е да стартирате сравнителния тест на Stream.
Фигура 4.11 показва модела Roofline за векторния процесор NEC SX-9 на

отляво и многоядрения компютър Intel Core i7 920 отдясно. Вертикалната
Y-ос е постижима производителност с плаваща запетая от 2 до 256 GFLOP/сек. The
хоризонталната ос Х е аритметичен интензитет, вариращ от 1/8 FLOP/DRAM байт
достъпен до 16 FLOP/ DRAM байта, достъпен и в двете графики. Имайте предвид, че графиката
е логаритмична скала и че Rooflines се правят само веднъж за компютър.
За дадено ядро можем да намерим точка на оста X въз основа на неговата аритметика
интензивност. Ако начертаем вертикална линия през тази точка, представянето на
ядрото на този компютър трябва да лежи някъде по тази линия. Можем да начертаем хоризонтална
линия, показваща пиковата производителност на компютъра с плаваща запетая. очевидно,
действителната производителност с плаваща запетая не може да бъде по-висока от хоризонталната линия,
тъй като това е хардуерно ограничение.
Как можем да начертаем пиковата производителност на паметта? Тъй като оста X е FLOP/
байт и Y-оста е FLOP/сек, байт/сек е просто диагонална линия под 45 градуса
ъгъл на тази фигура. Следователно можем да начертаем трета линия, която дава максимума
производителност с плаваща запетая, която системата с памет на този компютър може да поддържа
Intel Core i7 920

Процесор NEC SX-9
256 256 (Нехалем)
128 102,4 GFLOP/сек 128
64 64 42,66 GFLOP/сек
162 GB/s (поток)
32 32
реG
Д
пс
реG
Д
пс
Fкв
Fкв
L
L
е
е
цо
цо
иO
иO
й
й
н
н
тсоназ/P
тсоназ/P
16 16
16,4 GB/s (поток)
8 8
4 4
2 2
1/8 1/4 1/2 1 2 4 8 16 1/8 1/4 1/2 1 2 4 8 16
Аритметична интензивност Аритметична интензивност
Фигура 4.11 Модел Roofline за един векторен процесор NEC SX-9 отляво и многоядрения Intel Core i7 920
компютър със SIMD разширения отдясно [Williams et al. 2009]. Тази Roofline е за достъп до паметта с крачка на единица
и производителност с плаваща запетая с двойна точност. NEC SX-9 е векторен суперкомпютър, обявен през 2008 г., който струва
милиони долари. Той има пикова DP FP производителност от 102,4 GFLOP/sec и пикова честотна лента на паметта от 162
GBytes/sec от бенчмарка Stream. Core i7 920 има пикова DP FP производителност от 42,66 GFLOP/sec и
пикова честотна лента на паметта от 16,4 GBytes/sec. Показват се прекъснатите вертикални линии при аритметичен интензитет от 4 FLOP/байт
че и двата процесора работят с максимална производителност. В този случай SX-9 при 102,4 FLOP/сек е 2,4 пъти по-бърз от Core
i7 при 42,66 GFLOP/сек. При аритметичен интензитет от 0,25 FLOP/байт, SX-9 е 10 пъти по-бърз при 40,5 GFLOP/сек спрямо 4,1
GFLOP/сек за Core i7.
за дадена аритметична интензивност. Можем да изразим границите като формула за начертаване
тези линии в графиките на фигура 4.11:
Достижими GFLOP/сек Мин.= пикова( памет BW аритметичен

× интензитет , Пикова производителност с плаваща запетая )
Хоризонталните и диагоналните линии дават името на този прост модел и показват неговата стойност.
„Roofline“ задава горна граница на производителността на ядрото
в зависимост от неговата аритметична интензивност. Ако мислим за аритметичния интензитет като за полюс
който удря покрива, или удря плоската част на покрива, което означава изпълнение
е изчислително ограничено или удря наклонената част на покрива, което означава
производителността в крайна сметка е ограничена от честотната лента на паметта. На Фигура 4.11
вертикалната пунктирана линия вдясно (аритметичен интензитет 4) е пример за предшественика, а
вертикалната пунктирана линия вляво (аритметичен интензитет 1/4) е
пример за последното. Имайки модел Roofline на компютър, можете да го приложите
многократно, тъй като не се различава според ядрото.
Обърнете внимание, че „точката на билото“, където се срещат диагоналния и хоризонталния покрив,
предлага интересна представа за компютъра. Само ако е много вдясно
ядрата с много висок аритметичен интензитет могат да постигнат максималната производителност на този
компютър. Ако е много вляво, тогава почти всяко ядро може потенциално да постигне максимална
производителност. Както ще видим, този векторен процесор има
както много по-висока честотна лента на паметта, така и точка на билото далеч вляво в сравнение с други
SIMD процесори.
Фигура 4.11 показва, че пиковата изчислителна производителност на SX-9 е
2,4 пъти по-бърз от Core i7, но производителността на паметта е 10 пъти по-бърза. За програми
с аритметичен интензитет от 0,25, SX-9 е 10 пъти по-бърз (40,5 срещу 4,1 GFLOP/сек). По-
високата честотна лента на паметта премества точката на билото от 2,6 при Core i7 до 0,6 при
SX-9, което означава, че много повече програми могат да достигнат върхова изчислителна
производителност на векторния процесор.
4.4 Графични процесори
За няколкостотин долара всеки може да си купи GPU със стотици паралелни единици с
плаваща запетая, което прави високопроизводителните изчисления по-достъпни. Интересът
към GPU компютрите процъфтява, когато този потенциал се комбинира с програмен език,
който прави GPU по-лесни за програмиране. Следователно много програмисти на научни и
мултимедийни приложения днес обмислят дали да използват GPU или CPU.
GPU и CPU не се връщат назад в генеалогията на компютърната архитектура до общ

прародител; няма липсваща връзка, която да обяснява и двете. Както е описано в раздел 4.10 ,
основните предшественици на GPU са графичните ускорители, тъй като добрата графика е
причината GPU да съществуват. Докато графичните процесори се движат към масовите
изчисления, те не могат да се откажат от отговорността си да продължат да превъзхождат
графиките. По този начин дизайнът на графичните процесори може да има повече смисъл,
когато архитектите питат, като се има предвид инвестираният хардуер за добра графика, как
можем да го допълним, за да подобрим производителността на по-широк набор от приложения?
Имайте предвид, че този раздел се концентрира върху използването на GPU за изчисления.
За да видите как GPU изчисленията се комбинират с традиционната роля на графичното
ускорение, вижте „Графични и изчислителни графични процесори“ от Джон Никълс и Дейвид
Кърк (Приложение А в 4-то издание на Компютърна организация и дизайн от същите автори
като тази книга).
Тъй като терминологията и някои хардуерни характеристики са доста различни от
векторните и SIMD архитектурите, ние вярваме, че ще бъде по-лесно, ако започнем с
опростения модел на програмиране за GPU, преди да опишем архитектурата.
Програмиране на GPU
CUDA е елегантно решение на проблема с представянето на паралелизма в алгоритмите, не

всички алгоритми, но достатъчно, за да има значение. Изглежда, че резонира по някакъв
начин с начина, по който мислим и кодираме, позволявайки по-лесно, по-естествено
изразяване на паралелизъм извън нивото на задачата.
Винсент Натол
„Поздравления за CUDA“, HPC Wire (2010)
Предизвикателството за GPU програмиста не е просто да постигне добра производителност

на GPU, но и в координирането на планирането на изчисленията на системния процесор и
GPU и прехвърлянето на данни между системната памет и GPU паметта. Освен това, както ще
видим по-късно в този раздел, графичните процесори имат практически всеки тип
паралелизъм, който може да бъде уловен от програмната среда: многопоточност, MIMD,
SIMD и дори ниво на инструкция.
NVIDIA реши да разработи C-подобен език и среда за програмиране, която ще

подобри производителността на GPU програмистите, като атакува както
предизвикателствата на хетерогенните изчисления, така и на многостранния паралелизъм.
Името на тяхната система е CUDA, за Compute Unified Device Architecture.
CUDA произвежда C/C++ за системния процесор (хост) и C и C++ диалект за GPU
(устройство, оттук и D в CUDA). Подобен език за програмиране е OpenCL, който
няколко компании разработват, за да предложат независим от доставчика език за
множество платформи.
NVIDIA реши, че обединяващата тема на всички тези форми на паралелизъм е
нишката CUDA. Използвайки това най-ниско ниво на паралелизъм като програмен
примитив, компилаторът и хардуерът могат да обединят хиляди CUDA нишки
заедно, за да използват различните стилове на паралелизъм в GPU: многопоточност,
MIMD, SIMD и паралелизъм на ниво инструкции. Следователно NVIDIA класифицира
програмния модел CUDA като единична инструкция, множество нишки (SIMT).
Поради причини, които скоро ще видим, тези нишки се блокират заедно и се
изпълняват в групи от 32 нишки, наречени Блокиране на нишки. Ние наричаме
хардуера, който изпълнява цял блок от нишки, многонишков SIMD процесор.
Трябват ни само няколко подробности, преди да можем да дадем пример за CUDA програма:
За да се прави разлика между функциите за GPU (устройството) и функциите за

системния процесор (хост), CUDA използва __device__или __global__за for-mer и
__host__за последния. CUDA
променливите, декларирани като в__device__or__global__functions, се разпределят

към GPU паметта (вижте по-долу), която е достъпна от всички многонишкови
SIMD процесори.
Разширеният синтаксис за извикване на функция за името на функцията , която работи на GPU, е
име<<<dimGrid, dimBlock>>>(... списък с параметри ...)
където dimGrid и dimBlock указват размерите на кода (в блокове) и размерите

на блок (в нишки).
В допълнение към идентификатора за блокове (blockIdx) и идентификатора за

нишки на блок (threadIdx), CUDA предоставя ключова дума за броя на нишките
на блок (blockDim), която идва от параметъра dimBlock в куршума по-горе.
Преди да видим CUDA кода, нека започнем с конвенционалния C код за цикъла

DAXPY от раздел 4.2:
// Извикване на
DAXPY daxpy(n, 2.0, x, y); //
DAXPY в C void
daxpy(int n, двойно a, двойно *x, двойно *y) {
за (int i = 0; i < n; ++i) y[i] = a*x[i] +

y[i];
}
По-долу е версията на CUDA. Стартираме n нишки, по една на векторен елемент, с 256 CUDA
нишки на блок нишка в многонишков SIMD процесор. Функцията GPU започва с изчисляване
на съответния индекс на елемент i въз основа на идентификатора на блока, броя на нишките
на блок и идентификатора на нишката. Докато този индекс е в масива (i < n), той изпълнява
умножението и събирането.
// Извикване на DAXPY с 256 нишки на блок нишка __host__ int nblocks

= (n+ 255) /
256; daxpy<<<nblocks, 256>>>(n, 2.0, x,
y); // DAXPY в CUDA __устройство__ void daxpy(int n,
двойно a, двойно *x,
двойно *y) {
int i = blockIdx.x*blockDim.x + threadIdx.x; ако (i < n) y[i] = a*x[i]

+ y[i];
}
Сравнявайки кодовете C и CUDA, виждаме общ модел за паралелизиране на CUDA код

с паралелни данни. Версията C има цикъл, при който всяка итерация е независима от
другите, което позволява цикълът да се трансформира директно в паралелен код, където
всяка итерация на цикъл става независима нишка. (Както е споменато по-горе и описано
подробно в раздел 4.5, векторизиращите компилатори също разчитат на липса на
зависимости между итерациите на цикъл, които се наричат пренасяни от цикъл
зависимости.) Програмистът определя паралелизма в CUDA изрично, като указва размерите
на мрежата и брой нишки на SIMD процесор. Чрез присвояване на една нишка на всеки
елемент няма нужда да се синхронизира между нишките при записване на резултати в
паметта.
Хардуерът на GPU обработва паралелно изпълнение и управление на нишки; това не
се прави от приложения или от операционната система. За да се опрости планирането от
хардуера, CUDA изисква блоковете с нишки да могат да се изпълняват независимо и в
произволен ред. Различните блокове на нишки не могат да комуникират директно, въпреки
че могат да се координират , използвайки операции с атомарна памет в Global Memory.
Както скоро ще видим, много хардуерни концепции на GPU не са очевидни в CUDA.
Това е нещо добро от гледна точка на производителността на програмистите, но повечето
програмисти използват GPU вместо CPU, за да получат производителност.
Програмистите за производителност трябва да имат предвид хардуера на GPU, когато пишат
в CUDA. Поради причини, обяснени накратко, те знаят, че трябва да поддържат групи от 32
нишки заедно в контролен поток, за да получат най-добрата производителност от
многонишкови SIMD процесори, и да създадат много повече нишки на многонишков SIMD
процесор, за да скрият латентността към DRAM. Те също трябва да поддържат адресите на
данните локализирани в един или няколко блока памет, за да получат очакваната
производителност на паметта.
Подобно на много паралелни системи, компромисът между производителността и
производителността е CUDA да включва присъщи елементи, за да даде на програмистите
изричен контрол върху хардуера. Борбата между производителността, от една страна, и
позволяването на програмиста да може да изрази всичко, което хардуерът може да направи, от друга
се случва често при паралелно изчисление. Ще бъде интересно да видим как езикът се развива в
тази класическа битка между производителност и производителност, както и дали CUDA ще стане
популярна за други графични процесори или дори за други архитектурни стилове.
NVIDIA GPU изчислителни структури

Необичайното наследство, споменато по-горе, помага да се обясни защо GPU имат свой собствен
архитектурен стил и собствена терминология, независима от CPU. Една пречка за разбирането на
GPU е жаргонът, като някои термини дори имат подвеждащи имена. Това препятствие беше
изненадващо трудно за преодоляване, както свидетелстват множеството пренаписвания на тази
глава. За да се опитаме да преодолеем двойните цели да направим архитектурата на GPU разбираема
и да научим многото термини на GPU с нетрадиционни дефиниции, нашето окончателно решение е
да използваме терминологията CUDA за софтуер, но първоначално да използваме по-описателни
термини за хардуера, понякога заимствайки термини, използвани от OpenCL. След като обясним
архитектурата на графичния процесор с нашите термини, ще ги пренесем в официалния жаргон на
графичните процесори на NVIDIA.
Отляво надясно, Фигура 4.12 изброява по-описателния термин, използван в този раздел, най-
близкия термин от основните компютри, официалния термин на NVIDIA GPU, в случай че се
интересувате, и след това кратко описание на термина. Останалата част от този раздел обяснява
микроархитектурните характеристики на GPU с помощта на тези описателни термини отляво на
фигурата.
Ние използваме системите на NVIDIA като наш пример, тъй като те са представителни за GPU
архитектури. По-конкретно, следваме терминологията на езика за паралелно програмиране CUDA по-
горе и използваме архитектурата Fermi като пример (вижте раздел 4.7).
Подобно на векторните архитектури, GPU работят добре само с паралелни проблеми на ниво
данни. И двата стила имат трансфери на събиране-разпръскване на данни и маскиращи регистри, а
GPU процесорите имат дори повече регистри, отколкото векторните процесори. Тъй като нямат
близък скаларен процесор, графичните процесори понякога прилагат функция по време на
изпълнение в хардуера, която векторните компютри прилагат по време на компилатор в софтуера.
За разлика от повечето векторни архитектури, графичните процесори също разчитат на
многопоточност в рамките на един многонишков SIMD процесор, за да скрият латентността на
паметта (вижте глави 2 и 3). Въпреки това, ефективният код както за векторни архитектури, така и за
графични процесори изисква програмистите да мислят в групи от SIMD операции.
Grid е кодът, който се изпълнява на GPU, който се състои от набор от блокове на нишки.
Фигура 4.12 прави аналогията между решетка и векторизиран цикъл и между блок на нишка и тялото
на този цикъл (след като е бил стрип-миниран, така че да е пълен изчислителен цикъл). За да дадем
конкретен пример, нека предположим, че искаме да умножим два вектора заедно, всеки с дължина
8192 елемента. Ще се върнем към този пример в този раздел. Фигура 4.13 показва връзката между
този пример и първите два термина на GPU. Кодът на графичния процесор, който работи върху
цялото умножение на елементи 8192, се нарича Grid (или векторизиран цикъл). За да се раздели на
по-управляеми размери, мрежата е съставена от блокове с нишки (или тяло на векторизиран цикъл),
всеки с до 512 елемента. Имайте предвид, че SIMD инструкция изпълнява 32 елемента наведнъж. С
8192 елемента във векторите, този пример има 16 блока от нишки, тъй като 16 = 8192 ÷ 512. Решетката
и блокът от нишки
По-описателно Най-близкият стар Официален CUDA/
Тип име термин извън GPU NVIDIA GPU термин Дефиниция на книгата
С възможност за векторизиране
Векторизируема контурна мрежа Векторизиран цикъл, изпълняван на графичния процесор,
Цикъл съставен от един или повече блокове от нишки (тела на
векторизиран цикъл), които могат да се изпълняват паралелно.
Тяло на Тялото на а Блокиране на нишка Векторизиран цикъл, изпълняван на многонишков SIMD

Векторизиран цикъл (минодобив) процесор, съставен от една или повече нишки от SIMD
Векторизиран цикъл инструкции. Те могат да комуникират чрез локална памет.
ииинцмкаарргтосрбП
а
Последователност на Една итерация на Нишка CUDA Вертикален разрез на нишка от SIMD инструкции,
SIMD Lane скаларен цикъл съответстваща на един елемент, изпълнен от една SIMD
Операции лента. Резултатът се съхранява в зависимост от маската
и предикатен регистър.
Нишка от Нишка на вектор Деформация Традиционна нишка, но съдържа само SIMD инструкции,
SIMD Инструкции които се изпълняват на многонишков SIMD процесор.
кеабМ
о
Резултатите се съхраняват в зависимост от маска за всеки

ненитш
елемент.
SIMD Векторна инструкция PTX инструкция Единична SIMD инструкция, изпълнена през SIMD линии.
Многонишков (Многонишков) Поточно предаване Многонишковият SIMD процесор изпълнява нишки от

SIMD Векторен процесор Мултипроцесор SIMD инструкции, независимо от други SIMD процесори.
Процесор
Блокиране на нишка Скаларен процесор Giga Thread Присвоява множество нишкови блокове (тела на
Планировчик Двигател векторизиран цикъл) на многонишкови SIMD
процесори.
SIMD нишка Планировчик на Warp Scheduler Хардуерен модул, който планира и издава нишки от SIMD
щавтроебуадррбаО
х
Планировчик нишки в Multithreaded инструкции, когато са готови за изпълнение; включва

процесор табло за проследяване на изпълнението на SIMD Thread.
SIMD Lane Вектор Лейн Процесор на нишки SIMD лента изпълнява операциите в нишка от SIMD инструкции върху
един елемент. Резултатите се съхраняват в зависимост от
маската.
GPU памет Основна памет Глобална памет DRAM памет, достъпна от всички многонишкови SIMD
процесори в GPU.
Частно Подреждане или нишка Локална памет Част от DRAM паметта е частна за всяка SIMD лента.
памет Локално хранилище (ОС)
рап
анретуедм Х
Локална памет Локална памет Споделена памет Бърза локална SRAM за един многонишков SIMD процесор,
недостъпна за други SIMD процесори.
SIMD Lane Вектор Лейн Процесор на нишки Регистрира се в една SIMD лента, разпределена в цял блок на
Регистри Регистри Регистри нишка (тяло на векторизиран цикъл).
Фигура 4.12 Бързо ръководство за GPU термините, използвани в тази глава. Използваме първата колона за хардуерни термини. Четири
групи групират тези 11 термина. Отгоре надолу: абстракции на програмата, машинни обекти, хардуер за обработка,
и хардуер за памет. Фигура 4.21 на страница 309 свързва векторни термини с най-близките термини тук, а Фигура 4.24
на страница 313 и Фигура 4.25 на страница 314 разкриват официалните термини и дефиниции на CUDA/NVIDIA и AMD заедно с
термините, използвани от OpenCL.
A[ 0 ] = B [ 0 ] * C [ 0 ]
SIMD А[ 1]=B[1 ] * C[ 1 ]
Нишка0 … … … … ………
A[ 31 ] = B [ 31 ] * C [ 31 ]
A[ 32 ] = B [ 32 ] * C [ 32 ]
SIMD A[ 33 ] = B [ 33 ] * C [ 33 ]
Нишка1 … … … … ………
Нишка
Блок 0 A[ 63 ] = B [ 63 ] * C [ 63 ]
A[ 64 ] = B [ 64 ] * C [ 64 ]
… … … … ………
A[ 479 ] = B [ 479 ] * C [ 479 ]

A[ 480 ] = B [ 480 ] * C [ 480 ]
SIMD
A[ 481 ] = B [ 481 ] * C [ 481 ]
Нишка1
5 … … … … ………
A[ 511 ] = B [ 511 ] * C [ 511 ]

A[ 512 ] = B [ 512 ] * C [ 512 ]
Решетка … …… … … … ………
A[ 7679 ] = B [ 7679 ] * C [ 7679 ]

A[ 7680 ] = B [ 7680 ] * C [ 7680 ]
SIMD A[ 7681 ] = B [ 7681 ] * C [ 7681 ]
Нишка0 … … … … ………
A[ 7711 ] = B [ 7711 ] * C [ 7711 ]

A[ 7712 ] = B [ 7712 ] * C [ 7712 ]
SIMD A[ 7713 ] = B [ 7713 ] * C [ 7713 ]
Нишка1 … … … … ………
Нишка
Блок A[ 7743 ] = B [ 7743 ] * C [ 7743 ]
15
A[ 7744 ] = B [ 7744 ] * C [ 7744 ]
… … … … ………
A[ 8159 ] = B [ 8159 ] * C[ 8159 ]

A[ 8160 ] = B [ 8160 ] * C [ 8160 ]
SIMD
A[ 8161 ] = B [ 8161 ] * C [ 8161 ]
Нишка1
5 … … … … ………
A[ 8191 ] = B [ 8191 ] * C[ 8191 ]
Фигура 4.13 Картографирането на Grid (векторизиран цикъл), блокове на нишки (основни блокове на SIMD) и нишки на SIMD
инструкции за умножение на вектор-вектор, като всеки вектор е дълъг 8192 елемента. Всяка нишка от SIMD инструкции
изчислява 32 елемента на инструкция и в този пример всеки Thread Block съдържа 16 нишки от SIMD
инструкции и решетката съдържа 16 блока с нишки. Хардуерният Thread Block Scheduler присвоява Thread Blocks на
многонишкови SIMD процесори и хардуерният Thread Scheduler избира коя нишка от SIMD инструкции да се изпълнява
всеки тактов цикъл в SIMD процесор. Само SIMD нишките в един и същ блок с нишки могат да комуникират чрез локално
памет. (Максималният брой SIMD нишки, които могат да се изпълняват едновременно на блок нишка, е 16 за графични процесори
от поколение Tesla и 32 за графични процесори от поколение Fermi.)
Warp Scheduler Табло с резултати
Номер на деформация Адрес SIMD инструкции Операнди?

Кеш за 1 42 ld.global.f64 Готов
инструкции
1 43 mul.f64 Не
3 95 shl.s32 Готов
3 96 add.s32 Не
8 11 ld.global.f64 Готов
8 12 ld.global.f64 Готов Готов
Регистър на инструкциите
SIMD ленти
(Нишка
процесори)
Рег Рег Рег Рег Рег Рег Рег Рег Рег Рег Рег Рег Рег Рег Рег
Регистри
1K × 32 1K × 32 1K × 32 1K × 32 1K × 32 1K × 32 1K × 32 1K × 32 1K × 32 1K × 32 1K × 32 1K × 32 1K × 32 1K × 32 1K × 32 1K × 32
Заредете Заредете Заредете Заредете Заредете Заредете Заредете Заредете Заредете Заредете Заредете Заредете Заредете Заредете Заредете Заредете
складова складова складова складова складова складова складова складова складова складова складова складова складова складова складова складова
единица единица единица единица единица единица единица единица единица единица единица единица единица единица единица единица
Блок за обединяване на адреси Мрежа за взаимно свързване
Към Глобал
Локална памет
памет
64 KB
Фигура 4.14 Опростена блокова диаграма на многонишков SIMD процесор. Има 16 SIMD ленти. SIMD Thread
Scheduler има, да речем, 48 независими нишки от SIMD инструкции, които планира с таблица от 48 компютъра.
са абстракции за програмиране, внедрени в хардуера на GPU, които помагат на

програмистите да организират своя CUDA код. (Блокът на нишката е аналогичен на
векторен цикъл с ленти с дължина на вектора 32.)
Thread Block се присвоява на процесор, който изпълнява този код, който наричаме
многонишков SIMD процесор, от Thread Block Scheduler. Thread Block Scheduler има
някои прилики с контролен процесор във векторна архитектура. Той определя броя на
блоковете от нишки, необходими за цикъла, и продължава да ги разпределя към
различни многонишкови SIMD процесори, докато цикълът приключи. В този пример
той ще изпрати 16 блока нишки към многонишкови SIMD процесори, за да изчисли
всички 8192 елемента на този цикъл.
Фигура 4.14 показва опростена блокова диаграма на многонишков SIMD процесор.
Той е подобен на векторен процесор, но има много паралелни функционални единици
DRAM
DRAM
MARD
DRAM
ои
сйефреттсн Х
L2 кеш памет
DRAM
daerhTagiG
MARD
Фигура 4.15 Етажен план на Fermi GTX 480 GPU. Тази диаграма показва 16 многонишкови SIMD процесора.
Планировчикът за блокиране на нишки е маркиран вляво. The
GTX 480 има 6 GDDR5 порта, всеки с ширина 64 бита, поддържащи до 6 GB капацитет. The
Интерфейсът на хоста е PCI Express 2.0 x 16. Giga Thread е името на планировчика, който
разпределя блокове от нишки към мултипроцесори, всеки от които има своя собствена SIMD нишка
Планировчик.
вместо няколко, които са дълбоко конвейерни, както прави векторният процесор. В примера
за програмиране на Фигура 4.13 всеки многонишков SIMD процесор е присвоен
512 елемента от векторите за работа. SIMD процесорите са пълни процесори с
отделни компютри и се програмират с помощта на нишки (вижте Глава 3).
След това хардуерът на GPU съдържа колекция от многонишкови SIMD процесори, които
изпълняват мрежа от блокове на нишки (тела на векторизиран цикъл); това е

GPU е мултипроцесор, съставен от многонишкови SIMD процесори.
Първите четири реализации на архитектурата Fermi имат 7, 11, 14 или 15
многонишкови SIMD процесори; бъдещите версии може да имат само 2 или 4. За предоставяне
прозрачна мащабируемост между модели GPU с различен брой многонишкови SIMD
процесори, Thread Block Scheduler присвоява Thread Blocks
(тела на векторизиран цикъл) към многонишкови SIMD процесори. Фигура 4.15
показва етажния план на изпълнението на GTX 480 на архитектурата Fermi.
Спускайки още едно ниво на детайлност, машинният обект, който хардуерът създава,
управлява, планира и изпълнява, е нишка от SIMD инструкции.
Това е традиционна нишка, която съдържа изключително SIMD инструкции. Тези
нишките на SIMD инструкции имат свои собствени компютри и работят на многонишков

SIMD процесор. SIMD Thread Scheduler включва таблица с резултати, която му позволява
да знае кои нишки от SIMD инструкции са готови за изпълнение, и след това ги изпраща
до диспечерска единица, която да се изпълнява на многонишковия SIMD процесор. Той
е идентичен с хардуерен планировчик на нишки в традиционен многонишков процесор
(вижте Глава 3), само че планира нишки на SIMD инструкции. По този начин хардуерът
на GPU има две нива на хардуерни програмисти: (1) Thread Block Scheduler , който
присвоява Thread Blocks (тела от векторизирани цикли) на многонишкови SIMD
процесори, което гарантира, че блоковете от нишки са присвоени на процесорите,
чиито локални памети имат съответните данни и (2) SIMD Thread Scheduler в рамките на
SIMD процесор, който планира кога трябва да се изпълняват нишки от SIMD инструкции.
SIMD инструкциите на тези нишки са широки 32, така че всяка нишка от SIMD
инструкции в този пример ще изчисли 32 от елементите на изчислението. В този
пример Thread Blocks ще съдържат 512/32 = 16 SIMD нишки (вижте Фигура 4.13).
Тъй като нишката се състои от SIMD инструкции, SIMD процесорът трябва да има
паралелни функционални единици, за да изпълни операцията. Ние ги наричаме SIMD
ленти и те са доста подобни на векторните ленти в раздел 4.2.
Броят на лентите на SIMD процесор варира в зависимост от поколенията на GPU. С
Fermi всяка 32-широка нишка от SIMD инструкции се нанася на 16 физически SIMD
ленти, така че всяка SIMD инструкция в нишка от SIMD инструкции отнема два тактови
цикъла, за да завърши. Всяка нишка от SIMD инструкции се изпълнява в стъпка на
заключване и се планира само в началото. Оставайки с аналогията на SIMD процесор
като векторен процесор, можете да кажете, че той има 16 ленти, дължината на вектора
ще бъде 32, а звънецът е 2 тактови цикъла. (Тази широка, но плитка природа е причината
да използваме термина SIMD процесор вместо векторен процесор, тъй като е по-описателен.)
Тъй като по дефиниция нишките на SIMD инструкциите са независими, SIMD Thread
Scheduler може да избере коя нишка от SIMD инструкции е готова и не е необходимо да
се придържа към следващата SIMD инструкция в последователността в нишката. SIMD
Thread Scheduler включва таблица с резултати (вижте глава 3), за да следите до 48 нишки
от SIMD инструкции, за да видите коя SIMD инструкция е готова за работа. Това табло е
необходимо, тъй като инструкциите за достъп до паметта могат да отнемат
непредсказуем брой тактови цикли поради конфликти в банка памет, например. Фигура
4.16 показва SIMD Thread Scheduler, избиращ нишки от SIMD инструкции в различен ред
във времето. Предположението на GPU архитектите е, че GPU приложенията имат
толкова много нишки от SIMD инструкции, че многонишковостта може както да скрие
латентността към DRAM, така и да увеличи използването на многонишкови SIMD
процесори. Въпреки това, за да хеджират техните залози, скорошният NVIDIA Fermi GPU
включва L2 кеш (вижте раздел 4.7).
Продължавайки нашия пример за векторно умножение, всеки многонишков SIMD
процесор трябва да зареди 32 елемента от два вектора от паметта в регистри, да
извърши умножението чрез четене и запис на регистри и да съхрани продукта обратно
от регистрите в паметта. За да поддържа тези елементи на паметта, SIMD процесорът
има впечатляващите 32 768 32-битови регистъра. Точно като векторен процесор, тези
регистри са разделени логически между векторните ленти или, в този случай, SIMD
ленти. Всяка SIMD нишка е ограничена до не повече от 64 регистъра, така че може да помислите за SIMD
:аек
ръкй нШ
днуиуж
имм Д
С
Планировчик на SIMD нишки
време
SIMD нишка 8 инструкция 11
Фигура 4.16 Планиране на нишки на SIMD инструкции. Планировчикът избира готова

нишка от SIMD инструкции и издава инструкция синхронно към всички SIMD линии,
изпълняващи SIMD нишката. Тъй като нишките на SIMD инструкциите са независими,
планировчикът може да избира различна SIMD нишка всеки път.
Нишката има до 64 векторни регистъра, като всеки векторен регистър има 32 елемента и
всеки елемент е с ширина 32 бита. (Тъй като операндите с плаваща запетая с двойна точност
използват два съседни 32-битови регистъра, алтернативен изглед е, че всяка SIMD нишка
има 32 векторни регистъра от 32 елемента, всеки от които е с ширина 64 бита.)
Тъй като Fermi има 16 физически SIMD линии, всяка съдържа 2048 регистъра.
(Вместо да се опитват да проектират хардуерни регистри с много портове за четене и портове
за запис на бит, графичните процесори ще използват по-прости структури на паметта, но ще
ги разделят на банки, за да получат достатъчна честотна лента, точно както правят векторните
процесори.) Всяка нишка CUDA получава по един елемент от всяка от векторните регистри.
За да се справят с 32-те елемента на всяка нишка от SIMD инструкции с 16 SIMD ленти,
нишките CUDA на блок нишка могат да използват колективно до половината от 2048 регистъра.
За да можете да изпълнявате много нишки от SIMD инструкции, на всяка от тях
динамично се разпределя набор от физически регистри на всеки SIMD процесор, когато се
създават нишки от SIMD инструкции и се освобождава, когато SIMD нишката излезе.
Обърнете внимание, че CUDA нишка е просто вертикално изрязване на нишка от SIMD

инструкции, съответстваща на един елемент, изпълнен от една SIMD лента. Имайте предвид,
че CUDA нишките са много различни от POSIX нишките; не можете да правите произволни
системни извиквания от нишка CUDA.
Вече сме готови да видим как изглеждат инструкциите на GPU.
Архитектура на NVIDA GPU Instruction Set
За разлика от повечето системни процесори, целта на набора от инструкции на компилаторите

на NVIDIA е абстракция на набора от хардуерни инструкции. PTX (Parallel Thread Execu-tion)
осигурява стабилен набор от инструкции за компилаторите, както и съвместимост
през поколения графични процесори. Наборът от хардуерни инструкции е скрит от програмиста.
PTX инструкциите описват операциите върху една CUDA нишка,
и обикновено картографират едно към едно с хардуерни инструкции, но един PTX може да се разшири
към много машинни инструкции и обратно. PTX използва виртуални регистри, така че
компилаторът открива от колко физически векторни регистри се нуждае една SIMD нишка,
и след това оптимизатор разделя наличното хранилище на регистъра между SIMD
нишки. Този оптимизатор също елиминира мъртъв код, сгъва инструкции заедно и
изчислява местата, където клоните могат да се разминават, и местата, където пътеките се разминават
биха могли да се сближат.
Въпреки че има известно сходство между микроархитектурите x86 и PTX,

тъй като и двете се превеждат във вътрешна форма (микроинструкции за x86), разликата е, че
този превод се случва в хардуера по време на изпълнение по време на изпълнение на
x86 спрямо софтуера и времето за зареждане на GPU.
Форматът на PTX инструкция е
opcode.type d, a, b, c;
където d е дестинационният операнд; a, b и c са операнди източник; и типът операция е едно

от следните:
Тип .тип спецификатор
Нетипизирани битове 8, 16, 32 и 64 бита .b8, .b16, .b32, .b64
Цяло число без знак 8, 16, 32 и 64 бита .u8, .u16, .u32, .u64
Цяло число със знак 8, 16, 32 и 64 бита .s8, .s16, .s32, .s64
Плаваща запетая 16, 32 и 64 бита .f16, .f32, .f64
Операндите източник са 32-битови или 64-битови регистри или постоянна стойност. Дестинации
са регистри, с изключение на инструкциите на магазина.
Фигура 4.17 показва основния набор от PTX инструкции. Всички инструкции могат да бъдат
предикатирани от 1-битови предикатни регистри, които могат да бъдат зададени от набор предикат
инструкция (setp). Инструкциите за контролен поток са извикване на функции и
връщане, изход от нишка, разклоняване и синхронизиране на бариери за нишки в a
блок на нишка (bar.sync). Поставяне на предикат пред инструкция за разклоняване
ни дава условни разклонения. Компилаторът или PTX програмистът декларира виртуални
регистри като 32-битови или 64-битови въведени или нетипизирани стойности. Например R0,
R1, ... са за 32-битови стойности, а RD0, RD1, ... са за 64-битови регистри. Припомням си
че присвояването на виртуални регистри към физически регистри става по време на зареждане
с PTX.
Група Инструкция Пример Значение Коментари
аритметичен .type = .s32, .u32, .f32, .s64, .u64, .f64
add.type d = a + b; add.f32 d, a, b sub.f32
подтип d = a – b; d, a, b mul.f32 d, a, b
mul.type * b; mad.f32 d, a, b, c d=a
mad.type * b + c; div.type d = a /div.f32

b; d = ad,%a,b;b drem.u32
= |a|; d, d=a умножение-събиране
a, b abs.f32 d, a множество микроинструкции
рем.тип neg.f32 d, a min.f32 цяло число остатък
абс.тип d, a, b max.f32 d,
Аритметика
отр.тип a, b setp.lt.f32 p, d = 0 - а;
мин.тип a, b d = (a < b)? a:b; d = (a > floating избира не-NaN
макс.тип b)? a:b; p = (a < b); floating избира не-NaN
setp.cmp.type сравнете и задайте предикат
числови .cmp = eq, ne, lt, le, gt, ge; неподреден cmp = equ, neu, ltu, leu, gtu, geu, num, nan
mov.type mov.b32 d, a d = a; d ход
selp.type selp.f32 d, a, b, p cvt.f32.s32 = p? а: б; d = изберете с предикат
cvt.dtype.atype d, a конвертиране (a); конвертирайте atype в dtype
special .type = .f32 (някои .f64)
rcp.type rcp.f32 d, a d = 1/a; d = реципрочен
sqrt.type sqrt.f32 d, a sqrt(a); d = 1/ корен квадратен
Специален rsqrt.type rsqrt.f32 d, a sin.f32 sqrt(a); d = sin(a); d реципрочен квадратен корен

функция
грях.вид d, a cos.f32 d, a = cos(a); d = синус
cos.тип lg2.type lg2.f32 log(a)/log(2) d косинус
d, a ex2.type ex2.f32 d, a logic. тип = 2 ** двоичен логаритъм
= .pred, .b32, .b64 а; двоична експоненциална
and.type and.b32 d, a, b or.b32 d, a, b xor.b32 d, a, b d = a & b;
or.type not.b32 d, a, b d = a | b;
xor.type cnot.b32 d, a, b d = a ^ b;
Логично
не.тип shl.type shl.b32 d , a, d = ~a; d едно допълнение
възел.тип b shr.type shr.s32 d, a, = (a==0)? 1:0; d = a << C логично не
b memory.space = .global, .shared, .local, .const; .type b; d = a >> b; изместване наляво
= .b8, .u8, .s8, .b16, .b32, .b64 изместване надясно
ld.space.type ld.global.b32 d, [a+off] d = *(a+off); st.shared.b32 [d+off], a *(d+off) = a; зареждане от паметта
st.space.type tex.2d.v4.f32.f32 d, a, bd = tex2d(a, b); atom.global.add.u32 d, съхранявайте в пространството на паметта

памет
Достъп tex.nd.dtyp.btype [a], b atomic {d = *a; *a = atom.global.cas.b32 d, [a], b, c търсене на текстура
атомарна операция за четене-
atom.spc.op.type op(*a, b); } модифициране-запис
atom.op = and, or, xor, add, min, max, exch, cas; .spc = .глобален; .тип = .b32
клон @p bra target call if (p) goto target; ret = условен клон
обадете се
(ret), func, (params) функция (параметри); функция за повикване
контрол
ret ret връщане; връщане от извикване на функция
Поток
bar.sync bar.sync d изчакайте теми бариерна синхронизация
изход изход изход; прекратете изпълнението на нишка
Фигура 4.17 Основни инструкции за нишка на PTX GPU.

Следната последователност от PTX инструкции е за една итерация на нашата

DAXPY цикъл на страница 289:
shl.u32 R8, blockIdx, 9 add.u32 R8, ; ID на блока на нишката * Размер на блока (512 или 29 )
R8, threadIdx; R8 = i = моят ID на CUDA нишка
shl.u32 R8, R8, 3; байт отместване
ld.global.f64 RD0, [X+R8] ; RD0 = X[i] ld.global.f64 RD2,
[Y+R8] ; RD2 = Y[i] mul.f64 RD0, RD0, RD4; Продукт в RD0
= RD0 * RD4 (скалар a)
add.f64 RD0, RD0, RD2; Сума в RD0 = RD0 + RD2 (Y[i])
st.global.f64 [Y+R8], RD0; Y[i] = сума (X[i]*a + Y[i])
Както беше показано по-горе, програмният модел CUDA присвоява един CUDA
Нишка към всяка итерация на цикъл и предлага уникален идентификационен номер на всяка нишка
блок (blockIdx) и един към всяка CUDA нишка в рамките на блок (threadIdx).
По този начин той създава 8192 нишки CUDA и използва уникалния номер за адресиране на всяка
елемент в масива, така че няма код за увеличаване или разклоняване. Първите три
PTX инструкциите изчисляват този уникален байт отместване на елемент в R8, който се добавя
към основата на масивите. Следните PTX инструкции зареждат два операнда с плаваща запетая с
двойна точност, умножават ги и ги събират и съхраняват сумата. (Добре
опишете PTX кода, съответстващ на CUDA кода „ако (i < n)“ по-долу.)
Имайте предвид, че за разлика от векторните архитектури, графичните процесори нямат отделни инструкции
за последователни трансфери на данни, бързи трансфери на данни и трансфери на събиране-разпръскване на
данни. Всички трансфери на данни са сбор-разпръскване! За да възвърнете ефективността на последователното
(единични) трансфери на данни, графичните процесори включват специален хардуер за обединяване на адреси
за разпознаване кога SIMD лентите в нишка от SIMD инструкции колективно издават последователни
адреси. Този хардуер по време на изпълнение след това уведомява
Интерфейсен модул на паметта, за да поиска блоково прехвърляне на 32 последователни думи. За да получите
това важно подобрение на производителността, програмистът на GPU трябва да гарантира, че

съседните CUDA нишки имат достъп до близките адреси едновременно, което може да бъде
обединени в един или няколко блока памет или кеш, което прави нашият пример.
Условно разклоняване в GPU

Точно както в случая с прехвърлянето на данни с единична стъпка, има големи прилики
между това как векторните архитектури и графичните процесори обработват IF изрази, като първият
прилага механизма до голяма степен в софтуер с ограничена хардуерна поддръжка, а вторият
използва още повече хардуер. Както ще видим, в
в допълнение към изричните предикатни регистри, хардуерът на клона на GPU използва вътрешни
маски, стек за синхронизиране на разклонения и маркери за инструкции за управление кога
клон се разделя на множество пътеки за изпълнение и когато пътищата се събират.
На ниво PTX асемблер контролният поток на една CUDA нишка се описва от
PTX инструкциите за разклоняване, повикване, връщане и изход, плюс индивидуална лента за нишка
предсказване на всяка инструкция, посочена от програмиста с лента за нишка
1-битови предикатни регистри. PTX асемблерът анализира PTX разклонителната графика и
оптимизира го до най-бързата последователност от хардуерни инструкции на GPU.
На ниво хардуерни инструкции на GPU контролният поток включва разклоняване, прескачане,
индексиран скок, повикване, индексирано повикване, връщане, изход и специални инструкции, които управляват
стека за синхронизиране на клонове. Хардуерът на GPU осигурява всяка SIMD нишка
със собствен стек; запис в стека съдържа токен за идентификатор, целева инструкция
адрес и активна маска на целевата нишка. Има специални инструкции за GPU, които
записи в стек за натискане за SIMD нишка и специални инструкции и инструкции
маркери, които изваждат запис в стека или отвиват стека до определен запис и разклонение
към адреса на целевата инструкция с активната маска на целевата нишка. Инструкциите за хардуер на
графичния процесор също имат индивидуално предсказване за всяка лента (активиране/деактивиране),
определен с 1-битов предикатен регистър за всяка лента.
PTX асемблерът обикновено оптимизира просто външно ниво IF/THEN/ELSE
израз, кодиран с инструкции за разклоняване на PTX към само предсказуеми инструкции за GPU, без никакви
инструкции за разклоняване на GPU. По-сложният контролен поток обикновено води до комбинация от
предсказание и инструкции за разклоняване на GPU със специални
инструкции и маркери, които използват стека за синхронизиране на разклонения, за да избутат стек
влизане, когато някои платна се разклоняват към целевия адрес, докато други пропадат.
NVIDIA казва, че клонът се разминава, когато това се случи. Използва се и тази смес
когато SIMD Lane изпълнява маркер за синхронизация или конвергира, което изскача
запис в стека и разклонения към адреса на входа в стека с активната маска на нишката за вход в стека.
PTX асемблерът идентифицира разклоненията на цикъла и генерира разклонение на GPU
инструкции, които се разклоняват към върха на цикъла, заедно със специални инструкции за стек за
справяне с отделни ленти, излизащи от цикъла и сливащи се
SIMD ленти, когато всички ленти са завършили цикъла. GPU индексиран скок и
индексираните инструкции за повикване натискат записи в стека, така че когато всички ленти завършат
операторът switch или извикването на функция SIMD нишката се събира.
Предикатна инструкция за задаване на GPU (setp на фигурата по-горе) оценява условната част на израза
IF. След това инструкцията за разклоняване на PTX зависи от
този предикат. Ако PTX асемблерът генерира предсказуеми инструкции с no
Инструкции за клон на GPU, той използва предикатен регистър за всяка лента, за да активира или деактивира
всяка SIMD лента за всяка инструкция. Инструкциите за SIMD в темите
вътре в частта THEN на операциите за излъчване на оператора IF към всички SIMD
платна. Тези ленти с предикат, зададен на едно, изпълняват операцията и съхраняват
резултата, а другите SIMD линии не извършват операция или съхраняват резултат.
За оператора ELSE инструкциите използват допълнението на предиката
(спрямо оператора THEN), така че SIMD лентите, които са били неактивни, сега работят
операцията и съхраняват резултата, докато техните бивши активни братя и сестри не го правят. В
в края на оператора ELSE, инструкциите са непредсказуеми, така че първоначалното изчисление може да
продължи. По този начин, за пътища с еднаква дължина работи IF-THEN-ELSE
при 50% ефективност.

IF операторите могат да бъдат вложени, оттук и използването на стек и PTX асемблер
обикновено генерира комбинация от предсказани инструкции и клон на GPU и специални
инструкции за синхронизиране за сложен контролен поток. Имайте предвид, че дълбокото гнездене може
означава, че повечето SIMD линии са неактивни по време на изпълнение на вложени условни команди. По
този начин, двойно вложени IF оператори с равни по дължина пътеки работят с 25% ефективност, тройно
вложени с 12,5% ефективност и т.н. Аналогичният случай би бил
векторен процесор, работещ там, където само няколко от битовете на маската са единици.
Спускайки ниво на детайлност, асемблерът на PTX задава маркер за „синхронизиране

на разклонения“ върху подходящи инструкции за условно разклоняване, който натиска
текуща активна маска в стек във всяка SIMD нишка. Ако условният клон
разминава се (някои ленти хващат клона, други падат), бута купчина
запис и задава текущата вътрешна активна маска въз основа на условието. Клон
маркерът за синхронизация изскача записа на разклонения клон и обръща битовете на маската
преди частта ELSE. В края на оператора IF PTX асемблерът добавя
друг маркер за синхронизиране на разклонения, който премахва предишната активна маска от
стек в текущата активна маска.
Ако всички битове на маската са зададени на едно, тогава инструкцията за разклоняване в края на
СЛЕД това пропуска инструкциите в частта ДРУГО. Има подобна оптимизация за частта
THEN в случай, че всички битове на маската са нула, тъй като условната
клон прескача инструкциите THEN. Паралелни IF изрази и PTX
клоновете често използват условия за клонове, които са единодушни (всички ленти са
съгласни да следват един и същ път), така че SIMD нишката да не се разделя на различни
индивидуален поток за управление на лентата. PTX асемблерът оптимизира такива разклонения за пропускане
върху блокове от инструкции, които не се изпълняват от никоя лента на SIMD нишка.

Тази оптимизация е полезна при проверка на състояние на грешка, например, когато
трябва да се направи тест, но рядко се прави.
Кодът за условен оператор, подобен на този в раздел 4.2, е
ако (X[i] != 0)
X[i] = X[i] – Y[i];
иначе X[i] = Z[i];
Този IF оператор може да се компилира до следните PTX инструкции (при положение, че

че R8 вече има мащабиран идентификатор на нишка), с *Push, *Comp, *Pop, указващи
маркери за синхронизиране на разклонения, вмъкнати от PTX асемблера, които изтласкват старите
маска, допълнете текущата маска и поп, за да възстановите старата маска:
ld.global.f64 RD0, [X+R8] ; RD0 = X[i]

setp.neq.s32 P1, RD0, #0 @!P1, ; P1 е предикатен регистър 1
сутиен ELSE1, *Push ; Натиснете старата маска, задайте нови битове на маската
; ако P1 е невярно, отидете на ELSE1

ld.global.f64 RD2, [Y+R8] sub.f64 ; RD2 = Y[i]
RD0, RD0, RD2 st.global.f64 ; Разлика в RD0
[X+R8], RD0 @P1, сутиен ENDIF1, ; X[i] = RD0
*Комп. ; комплемент маска битове
; ако P1 е вярно, отидете на ENDIF1
ELSE1: ld.global.f64 RD0, [Z+R8] ; RD0 = Z[i]
st.global.f64 [X+R8], RD0; X[i] = RD0
ENDIF1: <следваща инструкция>, *Поп ; pop за възстановяване на старата маска
Още веднъж, обикновено всички инструкции в израза IF-THEN-ELSE се изпълняват от SIMD

процесор. Просто само някои от SIMD лентите са такива
активиран за инструкциите THEN и някои ленти за инструкциите ELSE. Като
споменато по-горе, в изненадващо често срещания случай, че отделните ленти са съгласни
на предицирания клон—като например разклоняване на стойност на параметър, който е
същото за всички ленти, така че всички битове на активната маска да са нули или всички да са единици—
клонът пропуска инструкциите THEN или инструкциите ELSE.

Тази гъвкавост прави да изглежда, че даден елемент има свой собствен програмен брояч; обаче, в
най-бавния случай само една SIMD лента може да съхранява резултата си на всеки два тактови цикъла, а
останалите са неактивни. Аналогичният най-бавен случай за векторни архитектури работи само с един
бит на маската, зададен на единица. Тази гъвкавост може да доведе до лоша производителност на
наивните GPU програмисти, но може да бъде полезна в ранните етапи на разработване на програмата.
Имайте предвид обаче, че единственият избор за SIMD лента в тактовия цикъл е да изпълните операцията,
посочена в PTX инструкцията, или да бъдете неактивни; две SIMD линии не могат да изпълняват
едновременно различни инструкции.
Тази гъвкавост също помага да се обясни името CUDA нишка , дадено на всеки елемент в нишка от
SIMD инструкции, тъй като създава илюзията за независимо действие. Един наивен програмист може да
си помисли, че тази абстракция на нишката означава, че GPU обработват условните разклонения по-
грациозно. Някои нишки вървят в една посока, останалите в друга, което изглежда вярно, стига да не
бързате. Всяка CUDA нишка изпълнява същата инструкция като всяка друга нишка в блока с нишки или е
неактивна.
Тази синхронизация улеснява обработката на цикли с условни разклонения, тъй като възможността за
маска може да изключи SIMD Lanes и автоматично открива края на цикъла.
Полученото изпълнение понякога противоречи на тази проста абстракция. Писането на програми,

които работят със SIMD ленти в този силно независим MIMD режим, е като писане на програми, които
използват много виртуално адресно пространство на компютър с по-малка физическа памет. И двете са
правилни, но може да работят толкова бавно, че програмистът да не е доволен от резултата.
Векторните компилатори биха могли да правят същите трикове с масковите регистри, както
графичните процесори в хардуера, но това ще включва скаларни инструкции за запазване, допълване и
възстановяване на масковите регистри. Условното изпълнение е случай, при който GPU правят в хардуера
по време на изпълнение това, което правят векторните архитектури по време на компилиране. Една
оптимизация, налична по време на изпълнение за графични процесори, но не и по време на компилиране
за векторни архитектури, е да се пропуснат частите THEN или ELSE, когато битовете на маската са всички
нули или всички единици.
По този начин ефективността, с която графичните процесори изпълняват условни изрази, се свежда
до това колко често клоновете ще се разминават. Например, едно изчисление на собствените стойности
има дълбоко условно влагане, но измерванията на кода показват, че около 82% от проблемите с тактовия
цикъл имат между 29 и 32 от 32-те маскиращи бита, зададени на единица, така че графичните процесори
изпълняват този код по-ефективно отколкото може да се очаква.
Обърнете внимание, че същият механизъм се справя с извличането на векторни цикли - когато броят
на елементите не съответства напълно на хардуера. Примерът в началото на този раздел показва, че
оператор IF проверява дали този номер на SIMD Lane елемент (съхранен в R8 в примера по-горе) е по-
малък от ограничението (i < n) и задава маски по подходящ начин.
NVIDIA GPU структури на паметта
Фигура 4.18 показва структурите на паметта на NVIDIA GPU. Всяка SIMD лента
в многонишков SIMD процесор се дава частна секция от DRAM извън чипа,
което наричаме лична памет. Използва се за стекова рамка, за разливане
регистри и за частни променливи, които не се побират в регистрите. SIMD Lanes правят
не споделяйте лични спомени. Последните GPU кешират тази частна памет в L1
и L2 кешове за подпомагане на преливането на регистъра и за ускоряване на извикванията на функции.
Ние наричаме паметта на чипа, която е локална за всеки многонишков SIMD процесор
или локална памет. Той се споделя от SIMD лентите в рамките на многонишков SIMD
Процесор, но тази памет не се споделя между многонишкови SIMD процесори.
Многонишковият SIMD процесор динамично разпределя части от
Локална памет към блок нишка, когато създава блок нишка и освобождава
памет, когато всички нишки от блока на нишката излязат. Тази част от Local
Паметта е частна за този блок от нишки.
И накрая, наричаме DRAM извън чипа, споделена от целия GPU и всички нишки
блокира GPU паметта. Нашият пример за векторно умножение използва само GPU памет.
Нишка CUDA
Частна памет за CUDA нишка
Блокиране на резби
На блок
Локална памет
Решетка 0 Последователност
...
Междурешеткова синхронизация GPU памет

Решетка 1
...
Фигура 4.18 Структури на паметта на GPU. Паметта на GPU се споделя от всички мрежи (векторизирани
цикли), локалната памет се споделя от всички нишки на SIMD инструкции в блок нишка
(тяло на векторизиран цикъл), а частната памет е частна за една CUDA нишка.
Системният процесор, наречен хост, може да чете или записва GPU памет. Локалната памет не
е достъпна за хоста, тъй като е частна за всеки многонишков SIMD процесор. Личните спомени
също не са достъпни за хоста.
Вместо да разчитат на големи кешове, за да съдържат целите работни комплекти на дадено
приложение, графичните процесори традиционно използват по-малки кешове за стрийминг и
разчитат на обширно многопоточност на нишки на SIMD инструкции, за да скрият дългото забавяне
на DRAM, тъй като работните им набори могат да бъдат стотици мегабайти. Като се има предвид
използването на многопоточност за скриване на латентността на DRAM, областта на чипа, използвана
за кешове в системните процесори, се изразходва вместо това за изчислителни ресурси и за големия
брой регистри за задържане на състоянието на много нишки на SIMD инструкции. За разлика от
това, както бе споменато по-горе, векторните зареждания и съхранявания амортизират латентността
в много елементи, тъй като те плащат латентността само веднъж и след това тръбопроводят останалата част
достъпи.
Въпреки че скриването на латентността на паметта е основната философия, имайте предвид,

че най-новите GPU и векторни процесори имат добавени кешове. Например, неотдавнашната
архитектура на Fermi добави кешове, но те се смятат или за филтри за честотна лента за намаляване
на изискванията към GPU паметта, или за ускорители за малкото променливи, чиято латентност не
може да бъде скрита от многопоточност. По този начин локалната памет за стекови рамки,
извиквания на функции и преливане на регистър е добро съвпадение с кеш паметта, тъй като
забавянето има значение при извикване на функция. Кешовете също пестят енергия, тъй като
достъпът до кеша в чипа отнема много по-малко енергия от достъпа до множество външни DRAM
чипове.
За да подобрят честотната лента на паметта и да намалят режийните разходи, както бе
споменато по-горе, PTX инструкциите за трансфер на данни обединяват отделни паралелни заявки
за нишки от една и съща SIMD нишка заедно в една заявка за блок памет, когато адресите попадат
в един и същ блок. Тези ограничения са поставени върху програмата на графичния процесор,
донякъде аналогично на насоките за програмите на системния процесор за ангажиране на
предварително извличане на хардуер (вижте Глава 2). Контролерът на паметта на GPU също ще
задържа заявки и ще ги изпраща заедно към една и съща отворена страница, за да подобри
честотната лента на паметта (вижте раздел 4.6). Глава 2 описва DRAM достатъчно подробно, за да се
разберат потенциалните ползи от групирането на свързани адреси.
Иновации в Fermi GPU архитектурата
Многонишковият SIMD процесор на Fermi е по-сложен от опростената версия на фигура 4.14. За да

се увеличи използването на хардуера, всеки SIMD процесор има два SIMD Thread Schedulers и два
модула за изпращане на инструкции. Двойният SIMD Thread Scheduler избира две нишки от SIMD
инструкции и издава по една инструкция от всяка към два комплекта от 16 SIMD линии, 16 единици
за зареждане/съхраняване или 4 единици със специална функция. По този начин две нишки от SIMD
инструкции се планират на всеки два тактови цикъла към всяка от тези колекции. Тъй като нишките
са независими, няма нужда да се проверява за зависимости на данните в потока от инструкции.
Тази иновация би била аналогична на многонишков векторен процесор, който може да издава
векторни инструкции от две независими нишки.
Фигура 4.19 показва инструкциите за издаване на Dual Scheduler, а Фигура 4.20 показва
блоковата диаграма на многонишковия SIMD процесор на Fermi GPU.
Планировчик на SIMD нишки Планировчик на SIMD нишки
Единица за изпращане на инструкции Единица за изпращане на инструкции
SIMD нишка 8 инструкция 11 SIMD нишка 9 инструкция 11
емерв
Фигура 4.19 Блокова диаграма на Dual SIMD Thread Scheduler на Fermi. Сравнете този
дизайн с единичния дизайн на SIMD нишка на Фигура 4.16.
Fermi въвежда няколко иновации, за да доближи графичните процесори много по-близо до мейнстрийма
системни процесори от Tesla и предишни поколения GPU архитектури: Бърза аритметика с плаваща
запетая с двойна точност—Fermi отговаря на относителната скорост с двойна точност на конвенционалните
процесори от приблизително половината от скоростта на единичната точност срещу една десета от
скоростта на единичната точност в предишното поколение на Tesla. Това означава, че няма порядък на
изкушението да се използва единична точност, когато точността изисква двойна точност. Пиковата
производителност с двойна точност нарасна от 78 GFLOP/сек в предшестващия графичен процесор до
515 GFLOP/сек при използване на инструкции за умножаване и добавяне.
Кешове за GPU памет – Докато философията на GPU е да има достатъчно нишки, за да се скрие латентността
на DRAM, има променливи, които са необходими в нишките, като локалните променливи, споменати по-
горе. Fermi включва L1 кеш за данни и L1 кеш за инструкции за всеки многонишков SIMD процесор и
единичен 768 KB L2 кеш, споделен от всички многонишкови SIMD процесори в GPU. Както бе споменато
по-горе, в допълнение към намаляването на натиска върху честотната лента на GPU паметта, кешовете
могат да пестят енергия, като остават в чипа, вместо да преминават извън чипа към DRAM. Кешът L1
всъщност съжителства със същата SRAM като локалната памет. Fermi има бит за режим, който предлага
избор за използване на 64 KB SRAM като 16 KB L1 кеш с 48 KB локална памет или като 48 KB L1 кеш с 16
KB локална памет. Обърнете внимание, че GTX 480 има обърната йерархия на паметта: Размерът на
общия регистърен файл е 2 MB, размерът на всички L1 кешове за данни е между 0,25 и 0,75 MB (в
зависимост от това дали са 16 KB или 48 KB) и размерът на L2 кеша е 0,75 MB. Ще бъде интересно да
видим въздействието на това обърнато съотношение върху GPU приложенията.
64-битово адресиране и унифицирано адресно пространство за всички GPU памети—Тази иновация прави
много по-лесно предоставянето на указателите, необходими за C и C++.

Кеш за инструкции
SIMD Thread Scheduler SIMD Thread Scheduler
Диспечерска единица Диспечерска единица
Регистър файл (32 768 × 32 бита)
LD/ST
SIMD SIMD SIMD SIMD
Лейн Лейн Лейн Лейн LD/ST
SFU
LD/ST
SIMD SIMD SIMD SIMD
Лейн Лейн лента Лейн LD/ST
SIMD Lane LD/ST

SIMD SIMD SIMD SIMD
Пристанище за изпращане Лейн Лейн Лейн Лейн LD/ST
Колектор на операнд SFU
LD/ST
SIMD SIMD SIMD SIMD
FP единица INT единица
LD/ST
SIMD SIMD SIMD SIMD
Опашка с резултати
SFU
LD/ST
SIMD SIMD SIMD SIMD
LD/ST
SIMD SIMD SIMD SIMD
SFU
LD/ST
SIMD SIMD SIMD SIMD
Взаимосвързана мрежа
64 KB споделена памет/L1 кеш
Единен кеш
Fermi стрийминг мултипроцесор (SM)
Фигура 4.20 Блокова диаграма на многонишков SIMD процесор на Fermi GPU.

Всяка SIMD лента има конвейерна единица с плаваща запетая, конвейерна целочислена единица, някаква
логика за изпращане на инструкции и операнди към тези единици и опашка за задържане на резултатите.
Четирите специални функционални единици (SFU) изчисляват функции като квадратни корени,
реципрочни стойности, синуси и косинуси.
Кодове за коригиране на грешки за откриване и коригиране на грешки в паметта

и регистрите (вижте Глава 2)—За да направят дълготрайните приложения
надеждни на хиляди сървъри, ECC е норма в центъра за данни (вижте Глава 6).
По-бързо превключване на контекста—Като се има предвид голямото състояние на

многонишков SIMD процесор, Fermi има хардуерна поддръжка за много по-бързо
превключване на контексти. Fermi може да превключва за по-малко от 25 микросекунди,
около 10 пъти по-бързо от своя предшественик.
По-бързи атомни инструкции - за първи път включени в архитектурата на Tesla, Fermi
подобрява производителността на Atomic инструкциите с 5 до 20 пъти, до няколко микросекунди.

Специален хардуерен модул, свързан с L2 кеша, не вътре в
многонишкови SIMD процесори, обработва атомни инструкции.
Прилики и разлики между вектор

Архитектури и графични процесори
Както видяхме, наистина има много прилики между векторните архитектури

и графични процесори. Заедно със странния жаргон на графичните процесори, тези прилики
допринесоха за объркването в архитектурните среди за това колко нови всъщност са графичните процесори.
Сега, след като видяхте какво се крие под капаците на векторните компютри и GPU,
можете да оцените както приликите, така и разликите. Тъй като и двете архитектури са проектирани
да изпълняват паралелни програми на ниво данни, но приемат различни
пътища, това сравнение е задълбочено, за да се опитаме да разберем по-добре какво е
необходими за DLP хардуер. Фигура 4.21 показва векторния член първо и след това
най-близкия еквивалент в GPU.
SIMD процесорът е като векторен процесор. Множеството SIMD процесори
в GPU действат като независими MIMD ядра, точно както имат много векторни компютри
множество векторни процесори. Този изглед би разглеждал NVIDIA GTX 480 като a
15-ядрена машина с хардуерна поддръжка за многопоточност, където всяко ядро има
16 платна. Най-голямата разлика е многопоточността, която е фундаментална за графичните процесори
и липсва в повечето векторни процесори.
Разглеждайки регистрите в двете архитектури, VMIPS регистрационният файл
съдържа цели вектори - тоест непрекъснат блок от 64 двойки. За разлика от това, единичен вектор в
GPU ще бъде разпределен между регистрите на всички SIMD линии.
Процесорът VMIPS има 8 векторни регистъра с 64 елемента или 512 елемента
обща сума. Една GPU нишка от SIMD инструкции има до 64 регистъра с 32 елемента
всеки, или 2048 елемента. Тези допълнителни GPU регистри поддържат многопоточност.
Фигура 4.22 е блокова диаграма на изпълнителните модули на векторен процесор
отляво и многонишков SIMD процесор на GPU отдясно. За педагогически цели приемаме, че векторният
процесор има четири ленти и многонишковият SIMD процесор също има четири SIMD ленти. Тази
фигура показва, че
четири SIMD ленти действат съгласувано много като векторна единица с четири ленти и това a
SIMD процесорът действа много като векторен процесор.

В действителност има много повече ленти в графичните процесори, така че „камбанките“ на графичния процесор са по-къси.
Докато векторният процесор може да има 2 до 8 ленти и дължина на вектора, да речем,

32—създаване на звънец 4 до 16 тактови цикъла—многонишков SIMD процесор
може да има 8 или 16 ленти. SIMD нишка е широка 32 елемента, така че GPU звънец
ще бъдат само 2 или 4 тактови цикъла. Тази разлика е причината, поради която използваме „SIMD
Processor“ като по-описателен термин, защото е по-близо до SIMD дизайн, отколкото е
към традиционен дизайн на векторен процесор.
Най-близкият GPU термин до векторизиран цикъл е Grid, а PTX инструкция е
най-близо до векторна инструкция, тъй като SIMD Thread излъчва PTX инструкция към всички
SIMD линии.
Най-близкият CUDA/NVIDIA
Тип вектор термин GPU термин Коментирайте
а
Векторизиран цикъл Решетка Концепциите са подобни, като GPU използва по-малко

описателния термин.
Звънец --
Тъй като една векторна инструкция (PTX инструкция) отнема
само два цикъла на Fermi и четири цикъла на Tesla, за да
завърши, звънецът е кратък в GPU.
Векторна инструкция PTX инструкция PTX инструкция на SIMD нишка се излъчва към всички SIMD
линии, така че е подобна на векторна инструкция.
Събиране/разпръскване Глобално зареждане/съхранение Всички зареждания и съхранявания на GPU се събират и

(ld.global/st.global) разпръскват, като всяка SIMD лента изпраща уникален адрес. От
кеабМ
о
GPU Coalescing Unit зависи да получи производителност на

инниитш
единица, когато адресите от SIMD лентите го позволяват.
Регистри на маски Предикатни регистри и Регистрите на векторната маска са изрично част от

Регистри за вътрешни маски архитектурното състояние, докато регистрите на маската на GPU
са вътрешни за хардуера. Условният хардуер на GPU добавя
нова функция отвъд предикатните регистри за динамично

управление на маските.
Векторен процесор Многонишков SIMD Те са подобни, но SIMD процесорите са склонни да имат много
Процесор ленти, като отнемат няколко тактови цикъла на лента за
завършване на вектор, докато векторните
архитектури имат малко ленти и отнемат много цикли за
завършване на вектор. Те също са многонишкови,
където векторите обикновено не са.
Контролен процесор Планировчик на блокиране на нишки Най-близкият е Thread Block Scheduler, който присвоява Thread
Blocks на многонишков SIMD процесор. Но графичните

процесори нямат скаларно-векторни операции и
инструкции за прехвърляне на данни с единична стъпка

или стъпки, които контролните процесори често предоставят.
Скаларен процесор Системен процесор Поради липсата на споделена памет и високата латентност за
комуникация през PCI шина (1000 секунди тактови цикли),
системният процесор в GPU рядко поема същите задачи, които
изпълнява скаларният процесор във векторна архитектура.
дм
туеа
актроеб ааи
рб п
о
Хз
Вектор Лейн SIMD Lane И двете по същество са функционални единици с

регистри.
Векторни регистри SIMD Lane Регистри Еквивалентът на векторен регистър е един и същ регистър
във всички 32 SIMD линии на многонишков SIMD процесор,
изпълняващ нишка от SIMD инструкции. Броят на
регистрите на SIMD нишка е гъвкав, но максимумът е 64, така
че максималният брой векторни регистри е 64.
Главна памет GPU памет Памет за GPU срещу системна памет във векторен случай.
Фигура 4.21 GPU еквивалент на векторни термини.

SIMD Thread Scheduler
Инструкция настолен компютър

кеш памет кеш памет

Диспечерска единица
Регистър на инструкциите Регистър на инструкциите
Маска Маска Маска Маска Маска Маска Маска Маска
контрол
FU FU FU FU FU ФУ
FU0 1 2 3 FU0 1 2 3
процесор
0123 000 0
4 5 6 7 1 1 1 1
• • • • • • • •
• • • • • • • •
иртсигеР
• • • • • • • •
си
иинррто ткгеВ
р
60 61 62 63 1023 1023 1023 1023
Векторна единица за зареждане/съхранение SIMD Зареждане/съхраняване на единица
Блок за обединяване на адреси
Интерфейс на паметта
Интерфейсен модул на паметта
мерна единица
Фигура 4.22 Векторен процесор с четири ленти отляво и многонишков SIMD процесор на GPU с четири
SIMD ленти вдясно. (GPU обикновено има от 8 до 16 SIMD ленти.) Контролният процесор доставя скаларни операнди за
скаларно-векторни операции, увеличава адресирането за единични и неединични крачки на достъп до паметта и извършва други
операции от счетоводен тип. Пиковата производителност на паметта се постига само в GPU, когато модулът за обединяване на адреси може
открийте локализирано адресиране. По същия начин, пикова изчислителна производителност възниква, когато всички битове на вътрешната маска са зададени
идентично. Обърнете внимание, че SIMD процесорът има един компютър на SIMD нишка, за да помогне при многопоточност.
По отношение на инструкциите за достъп до паметта в двете архитектури, всички GPU

зарежданията са инструкции за събиране, а всички съхранявания на GPU са инструкции за разпръскване. Ако данните
адресите на нишките CUDA се отнасят до близки адреси, които попадат в същия кеш/
блок памет в същото време, модулът за обединяване на адреси на GPU ще
осигурете висока честотна лента на паметта. Изричните инструкции за зареждане и съхраняване на единица стъпка
на векторните архитектури срещу имплицитната единична стъпка на GPU програмирането е защо

писането на ефективен GPU код изисква програмистите да мислят от гледна точка на SIMD операции,
въпреки че програмният модел CUDA изглежда като MIMD. Като CUDA
Нишките могат да генерират свои собствени адреси, както във векторните архитектури, така и в
графичните процесори.
Както споменахме няколко пъти, двете архитектури са много различни
подходи за скриване на латентността на паметта. Векторните архитектури го амортизират навсякъде
елементите на вектора, като имате дълбоко конвейерен достъп, така че плащате
латентност само веднъж на векторно зареждане или съхранение. Следователно векторните зареждания и
съхранявания са като блоков трансфер между паметта и векторните регистри. За разлика от това,
графичните процесори скриват латентността на паметта, използвайки многопоточност. (Някои
изследователи проучват добавянето на многопоточност към векторни архитектури, за да се опитат да
уловят най-доброто от двата свята.)
По отношение на инструкциите за условно разклоняване, и двете архитектури ги реализират с

помощта на маскови регистри. И двата пътя на условно разклоняване заемат време и/или пространство
дори когато не съхраняват резултат. Разликата е, че векторният компилатор управлява регистрите на
маските изрично в софтуера, докато GPU хардуерът и асемблерът ги управляват имплицитно, използвайки
маркери за синхронизиране на разклонения и вътрешен стек за запазване, допълване и възстановяване

на маски.
Както бе споменато по-горе, механизмът за условно разклоняване на графичните процесори елегантно
се справя с проблема за копаене на лента на векторните архитектури. Когато дължината на вектора е
неизвестна по време на компилиране, програмата трябва да изчисли модула на дължината на вектора на
приложението и максималната дължина на вектора и да го съхрани в регистъра за дължина на вектора.
След това лентово настроеният цикъл нулира регистъра за дължина на вектора до максималната дължина
на вектора за останалата част от цикъла. Този случай е по-прост с GPU, тъй като те просто повтарят цикъла,
докато всички SIMD линии достигнат границата на цикъла. При последната итерация някои SIMD линии
ще бъдат маскирани и след това възстановени след завършване на цикъла.
Управляващият процесор на векторен компютър играе важна роля при изпълнението на векторни
инструкции. Той излъчва операции към всички векторни ленти и излъчва стойност на скаларен регистър
за векторно-скаларни операции. Той също така прави имплицитни изчисления, които са изрични в
графичните процесори, като автоматично увеличаване на адресите на паметта за зареждания и
запаметявания с единична и не-единична стъпка.
Контролният процесор липсва в GPU. Най-близката аналогия е Thread Block Scheduler, който присвоява
Thread Blocks (тела на векторен цикъл) на многонишкови SIMD процесори. Хардуерните механизми за
изпълнение в GPU, които едновременно генерират адреси и след това откриват дали са съседни, което е
често срещано явление в много DLP приложения, вероятно са по-малко енергийно ефективни от
използването на контролен процесор.
Скаларният процесор във векторен компютър изпълнява скаларните инструкции на векторна

програма; това означава, че изпълнява операции, които биха били твърде бавни за изпълнение във
векторната единица. Въпреки че системният процесор, който е свързан с GPU, е най-близката аналогия на
скаларния процесор във векторна архитектура, отделните адресни пространства плюс прехвърляне през
PCle шина означава хиляди тактови цикли на натоварване, за да ги използвате заедно. Скаларният
процесор може да бъде по-бавен от векторния процесор за изчисления с плаваща запетая във векторен
компютър, но не със същото съотношение като системния процесор спрямо многонишковия SIMD
процесор (като се имат предвид режийните разходи).
Следователно всяка „векторна единица“ в GPU трябва да прави изчисления, които бихте очаквали да
направите на скаларния процесор във векторен компютър. Тоест, вместо да изчислявате със закъснение
на системния процесор и да съобщавате резултатите, може да бъде по-бързо да дезактивирате всички
освен една SIMD лента, като използвате регистрите на предикатите и вградените маски и да извършите
скаларната работа с една SIMD лента. Сравнително простият скаларен процесор във векторен компютър
вероятно ще бъде по-бърз и по-енергийно ефективен от GPU
решение. Ако системните процесори и графичните процесори станат по-тясно свързани помежду си
в бъдеще ще бъде интересно да видим дали системните процесори могат да играят същата роля
както правят скаларните процесори за векторни и мултимедийни SIMD архитектури.
Прилики и разлики между мултимедийни SIMD

Компютри и графични процесори
На високо ниво многоядрените компютри с мултимедийни SIMD разширения за инструкции наистина

споделят прилики с GPU. Фигура 4.23 обобщава приликите
и различия.
И двата са мултипроцесори, чиито процесори използват множество SIMD ленти,

въпреки че GPU имат повече процесори и много повече ленти. И двете използват хардуер
многопоточност за подобряване на използването на процесора, въпреки че GPU имат хардуер
поддръжка за много повече теми. Последните иновации в GPU означават, че сега и двете
имат подобни съотношения на производителност между единична и двойна точност
аритметика с плаваща запетая. И двете използват кешове, въпреки че GPU използват по-малък поток
кешовете и многоядрените компютри използват големи многостепенни кешове, които се опитват да съдържат
цели работни комплекти напълно. И двете използват 64-битово адресно пространство, въпреки че
физическата основна памет е много по-малка в GPU. Докато графичните процесори поддържат памет
защита на ниво страница, те не поддържат страниране при поискване.
В допълнение към големите числени разлики в процесорите, SIMD лентите,
поддръжка на хардуерни нишки и размери на кеша, има много архитектурни разлики. Скаларният
процесор и мултимедийните SIMD инструкции са тясно интегрирани в традиционните компютри; те
са разделени от I/O шина в GPU и
те дори имат отделни основни спомени. Множеството SIMD процесори в a
GPU използва едно адресно пространство, но кешовете не са кохерентни, както са в традиционните
многоядрени компютри. За разлика от GPU, мултимедийните SIMD инструкции го правят
не поддържа събиране-разпръскване на достъп до паметта, което Раздел 4.7 показва, че е значителен
пропуск.
Особеност Многоядрен със SIMD GPU
SIMD процесори 4 до 8 8 до 16
SIMD ленти/процесор 2 до 4 8 до 16
Многонишкова хардуерна поддръжка за SIMD нишки 2 до 4 16 до 32
Типично съотношение на производителност с единична точност към производителност с двойна точност 2:1 2:1
Най-голям размер на кеша 8 MB 0,75 MB
Размер на адреса на паметта 64-битов 64-битов
Размер на основната памет 8 GB до 256 GB 4 до 6 GB
Защита на паметта на ниво страница да да
Пейджинг по заявка да Не
Интегриран скаларен процесор/SIMD процесор да Не
Кохерентен кеш да Не
Фигура 4.23 Прилики и разлики между многоядрени с мултимедийни SIMD разширения и последните GPU.
Резюме
Сега, когато завесата е повдигната, можем да видим, че GPU всъщност са просто
многонишкови SIMD процесори, въпреки че имат повече процесори, повече ленти на
процесор и повече многонишков хардуер, отколкото традиционните многоядрени
компютри. Например Fermi GTX 480 има 15 SIMD процесора с 16 ленти
на процесор и хардуерна поддръжка за 32 SIMD нишки. Ферми дори прегръща
паралелизъм на ниво инструкция чрез издаване на инструкции от две SIMD нишки към
два комплекта SIMD ленти. Те също имат по-малко кеш памет - L2 кеша на Fermi е такъв
0,75 мегабайта—и не е кохерентен с отдалечения скаларен процесор.
По- Официален
описателно CUDA/
име, използвано NVIDIA Определение на книгата и Официален CUDA/NVIDIA
Тип в тази книга термин Условия на AMD и OpenCL определение
Векторизиращ се Решетка Векторизиран цикъл, изпълняван на GPU, Мрежата е масив от блокове с

цикъл съставен от един или повече „блокове на нишки, които могат да се
нишки“ (или тела на векторизиран цикъл), които изпълняват едновременно,

могат да се изпълняват паралелно. Името на последователно или смесено.
OpenCL е „индексен диапазон“. Името на AMD е

„NDRange“.
Тяло на Нишка Векторизиран цикъл, изпълняван на Блокът от нишки е масив от CUDA

Векторизиран Блокирайте многонишков SIMD процесор, съставен от една или нишки, които се изпълняват
цикъл повече нишки от SIMD инструкции. Тези едновременно заедно и могат да си

SIMD нишки могат да комуникират чрез локална сътрудничат и комуникират чрез
памет. Името на AMD и OpenCL е „работна група“. споделена памет и бариерна
а
синхронизация. Блок на нишка

има ID на блок на нишка в своята
мрежа.
Последователност на CUDA Вертикален разрез на нишка от SIMD Нишката CUDA е лека нишка, която
Операции на Нишка инструкции, съответстваща на един елемент, изпълнява последователна програма и
SIMD Lane изпълнен от една SIMD лента. Резултатът се може да си сътрудничи с други нишки
съхранява в зависимост от маската. AMD и CUDA, изпълнявани в същия блок нишка.
OpenCL наричат CUDA Thread „работен елемент“. Нишка CUDA има идентификатор на
нишка в своя блок за нишка.
Нишка от Деформация Традиционна нишка, но съдържа само SIMD Warp е набор от паралелни CUDA нишки
SIMD инструкции, които се изпълняват на многонишков (напр. 32), които изпълняват една и
инструкции SIMD процесор. Резултатите се съхраняват в съща инструкция заедно в многонишков
зависимост от маска за всеки елемент. Името на SIMT/SIMD процесор.
кеабМ
ненитш о
AMD е „wavefront“.
SIMD PTX Една SIMD инструкция, изпълнена през SIMD Инструкцията PTX указва инструкция,
инструкция инструкция лентите. Името на AMD е инструкция „AMDIL“ или изпълнена от нишка CUDA.
„FSAIL“.
Фигура 4.24 Преобразуване от термините, използвани в тази глава, към официалния жаргон на NVIDIA/CUDA и AMD. OpenCL
имената са дадени в дефиницията на книгата.
По- Официален
описателно CUDA/
име, използвано NVIDIA Определение на книгата и Официален CUDA/NVIDIA
Тип в тази книга термин Условия на AMD и OpenCL определение
Многонишков Поточно предаване

Многопоточен SIMD процесор, който изпълнява нишка Стрийминг мултипроцесор (SM) е
SIMD на множество от SIMD инструкции, независимо от други SIMD многонишков SIMT/
процесори. И AMD, и OpenCL го наричат SIMD процесор, който изпълнява
процесор процесор
„изчислителна единица“. Програмистът на CUDA деформации на CUDA нишки.
обаче пише програма за една лента, а не за „вектор“ Програмата SIMT определя
от множество SIMD линии. изпълнението на една CUDA
нишка, а не вектор от множество
SIMD линии.
Планировчик Присвоява множество тела на векторизиран цикъл Разпределя и планира блокове

на Двигател на многонишкови SIMD процесори. Името на AMD от нишки на мрежа към
блокове на нишки с гига резба е „Ultra-Threaded Dispatch Engine“. стрийминг мултипроцесори, когато
ресурсите станат налични.
SIMD Хардуерен модул, който планира и издава нишки

щавтроебуадррбаО
х
Warp Warp Scheduler в стрийминг

Scheduler от SIMD инструкции, когато са готови за изпълнение; мултипроцесор планира warps
Планировчик на нишки включва табло за проследяване на изпълнението за изпълнение, когато следващата
на SIMD Thread. Името на AMD е „Планировчик на им инструкция е готова за
работни групи“. изпълнение.
SIMD Нишка Хардуерна SIMD лента, която изпълнява Процесорът на нишка е път
Лейн процесор операциите в нишка от SIMD инструкции върху един за данни и част от
елемент. Резултатите се съхраняват в зависимост регистрационен файл на
от маската. OpenCL го нарича „обработващ поточен мултипроцесор, който
елемент“. Името на AMD също е „SIMD Lane“. изпълнява операции за една или
повече ленти на деформация.
GPU Глобален DRAM памет, достъпна от всички Глобалната памет е достъпна от

памет памет многонишкови SIMD процесори в GPU. всички CUDA нишки във всеки блок
OpenCL го нарича „Глобална памет“. от нишки във всяка мрежа;
реализиран като регион на DRAM
и може да бъде кеширан.
Частно Местен Част от DRAM паметта е частна за всяка SIMD лента. Частна „локална нишка“ памет за
памет памет Както AMD, така и OpenCL го наричат „частна памет“. нишка CUDA; реализиран
като кеширана област на DRAM.
Местен Споделено Бърза локална SRAM за един многонишков SIMD Бърза SRAM памет, споделена от
процесор, недостъпна за други SIMD процесори. нишките CUDA, съставящи блок от
рап
Х
памет памет
анретуедм
OpenCL го нарича „Локална памет“. AMD го нишки, и частна за този блок от

нарича "Групова памет". нишки. Използва се за
комуникация между CUDA нишки в
блок на нишка в точки за
синхронизация на бариерата.
SIMD Lane Регистри Регистрира се в една SIMD лента, разпределена в Частни регистри за нишка CUDA;
регистрира тялото на векторизирана верига. AMD също ги реализиран като многонишков
нарича „Регистри“. регистърен файл за определени
ленти от няколко деформации за
всеки процесор на нишка.
Фигура 4.25 Преобразуване от термините, използвани в тази глава, към официалния жаргон на NVIDIA/CUDA и AMD. Имайте предвид, че нашите
описателните термини „Локална памет“ и „Лична памет“ използват терминологията на OpenCL. NVIDIA използва SIMT, една инструкция с множество
нишки, вместо SIMD, за да опише стрийминг мултипроцесор. SIMT е за предпочитане пред SIMD
тъй като разклоняването на нишка и потокът на управление са различни от всяка SIMD машина.
Моделът за програмиране CUDA обгръща всички тези форми на паралелизъм около една
абстракция, нишката CUDA. По този начин програмистът на CUDA може да мисли за програмиране
на хиляди нишки, въпреки че те наистина изпълняват всеки блок от 32 нишки на многото
ленти на многото SIMD процесори.
Програмистът на CUDA, който иска добра производителност, има предвид, че тези нишки се
блокират и изпълняват 32 наведнъж и че адресите трябва да са към съседни адреси, за да
получат добра производителност от системата с памет.

Въпреки че използвахме CUDA и NVIDIA GPU в този раздел, бъдете сигурни, че същите идеи
се намират в езика за програмиране OpenCL и в GPU на други компании.
Сега, когато разбирате по-добре как работят графичните процесори, разкриваме истинския жаргон.
Фигури 4.24 и 4.25 съответстват на описателните термини и определения в този раздел с
официалните термини и определения на CUDA/NVIDIA и AMD. Включваме и условията на OpenCL.
Вярваме, че кривата на обучение на GPU е стръмна отчасти поради използването на термини

като „Поточен мултипроцесор“ за SIMD процесора, „Нишков процесор“ за SIMD Lane и „Споделена
памет“ за локална памет – особено след като локалната памет не се споделя между SIMD
процесори! Надяваме се, че този подход в две стъпки ще ви изкачи тази крива по-бързо, дори и
да е малко косвено.
4.5 Откриване и подобряване на паралелизма на ниво цикъл
Циклите в програмите са изворът на много от типовете паралелизъм, които обсъдихме по-горе

и в Глава 5. В този раздел обсъждаме технологията на компилатора за откриване на степента
на паралелизъм, която можем да използваме в програма, както и хардуерната поддръжка за
тези техники на компилатор. Ние дефинираме точно кога един цикъл е паралелен (или
векторизиран), как зависимостта може да попречи на един цикъл да бъде паралелен и техники
за елиминиране на някои видове зависимости.
Намирането и манипулирането на паралелизма на ниво цикъл е от решаващо значение за
използването както на DLP, така и на TLP, както и на по-агресивните статични ILP подходи (напр.
VLIW), които разглеждаме в Приложение H.
Паралелизмът на ниво цикъл обикновено се анализира на ниво източник или близо до
него, докато повечето анализи на ILP се извършват, след като инструкциите са генерирани от
компилатора. Анализът на ниво цикъл включва определяне какви зависимости съществуват
между операндите в цикъл през итерациите на този цикъл. Засега ще разгледаме само
зависимостите от данни, които възникват, когато операндът е написан в даден момент и
прочетен на по-късен етап. Зависимостите на имената също съществуват и могат да бъдат
премахнати чрез техниките за преименуване, обсъдени в Глава 3.
Анализът на паралелизма на ниво цикъл се фокусира върху определянето дали достъпът
до данни в по-късни итерации зависи от стойностите на данните, произведени в по-ранни
итерации; такава зависимост се нарича зависимост, пренасяна от цикъл. Повечето от
примерите, които разгледахме в глави 2 и 3 , нямаха зависимости, пренасяни от цикъл, и
следователно са паралелни на ниво цикъл. За да видим, че един цикъл е паралелен, нека първо
да разгледаме представянето на източника:
за (i=999; i>=0; i=i-1) x[i] = x[i] + s;

В този цикъл двете употреби на x[i] са зависими, но тази зависимост е в рамките на една
итерация и не се пренася в цикъл. Съществува пренасяна от цикъла зависимост между
последователните употреби на i в различни итерации, но тази зависимост включва
индукционна променлива, която може лесно да бъде разпозната и елиминирана. Видяхме
примери за това как да елиминираме зависимости, включващи индукционни променливи
по време на разгръщане на цикъла в раздел 2.2 на глава 2, и ще разгледаме допълнителни
примери по-късно в този раздел.
Тъй като намирането на паралелизъм на ниво цикъл включва разпознаване на структури
като цикли, препратки към масиви и изчисления на индукционни променливи, компилаторът
може да направи този анализ по-лесно на или близо до нивото на източника, за разлика от
нивото на машинния код. Нека да разгледаме по-сложен пример.
Пример Помислете за цикъл като този:
за (i=0; i<100; i=i+1) {

A[i+1] = A[i] + C[i]; /* S1 */
B[i+1] = B[i] + A[i+1]; /* S2 */
}
Да приемем, че A, B и C са различни, неприпокриващи се масиви. (На практика понякога

масивите могат да бъдат еднакви или да се припокриват. Тъй като масивите могат да бъдат
предадени като параметри на процедура, която включва този цикъл, определянето дали
масивите се припокриват или са идентични често изисква сложен, междупроцедурен
анализ на програмата. ) Какви са зависимостите на данните между изразите S1 и S2 в цикъла?
Отговор Има две различни зависимости:
1. S1 използва стойност, изчислена от S1 в по-ранна итерация, тъй като итерация i изчислява

A[i+1], което се чете в итерация i+1. Същото важи и за S2 за B[i] и B[i+1].
2. S2 използва стойността A[i+1], изчислена от S1 в същата итерация.
Тези две зависимости са различни и имат различен ефект. За да видим как се различават,
нека приемем, че само една от тези зависимости съществува в даден момент.
Тъй като зависимостта на израза S1 е от по-ранна итерация на S1, тази зависимост се пренася
в цикъл. Тази зависимост принуждава последователните итерации на този цикъл да се
изпълняват последователно.
Втората зависимост (S2 в зависимост от S1) е в рамките на една итерация и не се пренася
в цикъл. По този начин, ако това беше единствената зависимост, множество итерации на
цикъла биха могли да се изпълняват паралелно, стига всяка двойка изрази в итерация да се
поддържа в ред. Видяхме този тип зависимост в пример в раздел 2.2, където разгръщането
успя да разкрие паралелизма. Тези вътрешноконтурни зависимости са често срещани;
например последователност от векторни инструкции, която използва верижно свързване,
показва точно този вид зависимост.
Възможно е също така да има зависимост, пренасяна от цикъл, която не предотвратява
паралелизъм, както показва следващият пример.
Пример Помислете за цикъл като този:
за (i=0; i<100; i=i+1) {

A[i] = A[i] + B[i]; /* S1 */
B[i+1] = C[i] + D[i]; /* S2 */
}
Какви са зависимостите между S1 и S2? Този цикъл успореден ли е? Ако не, покажете как
да го направите успореден.
Отговор Изявление S1 използва стойността, присвоена в предишната итерация от изявление S2,

така че има пренасяна от цикъл зависимост между S2 и S1. Въпреки тази зависимост,
пренасяна от цикъла, този цикъл може да бъде направен паралелен. За разлика от
по-ранния цикъл, тази зависимост не е кръгова; нито едно твърдение не зависи от
себе си и въпреки че S1 зависи от S2, S2 не зависи от S1. Един цикъл е паралелен, ако
може да бъде написан без цикъл в зависимостите, тъй като липсата на цикъл
означава, че зависимостите дават частично подреждане на изразите.
Въпреки че няма кръгови зависимости в горния цикъл, той трябва да бъде
трансформиран, за да съответства на частичното подреждане и да изложи паралелизма.
Две наблюдения са критични за тази трансформация:
1. Няма зависимост от S1 към S2. Ако имаше, тогава щеше да има цикъл в
зависимостите и цикълът нямаше да е паралелен. Тъй като тази друга
зависимост отсъства, размяната на двата израза няма да повлияе на
изпълнението на S2.
2. При първата итерация на цикъла операторът S2 зависи от стойността на B[0],

изчислена преди започване на цикъла.
Тези две наблюдения ни позволяват да заменим цикъла по-горе със следната кодова
A[0] = A[0] + B[0]; за (i=0;

i<99; i=i+1) {
B[i+1] = C[i] + D[i];
A[i+1] = A[i+1] + B[i+1];
}
B[100] = C[99] + D[99];
Зависимостта между двата оператора вече не се пренася от цикъл, така че

итерациите на цикъла могат да се припокриват, при условие че операторите във
всяка итерация се поддържат в ред.
Нашият анализ трябва да започне с намирането на всички зависимости, пренасяни от

цикъла. Тази информация за зависимостта е неточна, в смисъл, че ни казва, че такава
зависимост може да съществува. Разгледайте следния пример:
за (i=0;i<100;i=i+1) {
A[i] = B[i] + C[i]
D[i] = A[i] * E[i]
}
Второто позоваване на A в този пример не трябва да се превежда в инструкция за зареждане,

тъй като знаем, че стойността се изчислява и съхранява от предишния оператор; следователно
втората препратка към A може просто да бъде препратка към регистъра
в който A е изчислено. Извършването на тази оптимизация изисква да знаете това
двете препратки винаги са към един и същ адрес на паметта и че няма
интервенционен достъп до същото място. Обикновено само анализ на зависимостта от данни
казва, че една препратка може да зависи от друга; по-сложен анализ е
необходими, за да се определи, че две препратки трябва да са към точно същия адрес. в
в горния пример е достатъчна проста версия на този анализ, тъй като двете препратки са в
един и същи основен блок.
Често зависимостите, пренасяни от цикъл, са под формата на рецидив. Рецидив

възниква, когато променлива е дефинирана въз основа на стойността на тази променлива в по-ранен
итерация, често непосредствено предшестващата, както в следния код

фрагмент:
за (i=1;i<100;i=i+1) {
Y[i] = Y[i-1] + Y[i];
}
Откриването на повторение може да бъде важно по две причини: Някои архитектури

(особено векторни компютри) имат специална поддръжка за изпълнение на повторения и в
контекст на ILP все още може да е възможно да се използва доста количество
паралелизъм.
Намиране на зависимости
Ясно е, че намирането на зависимостите в една програма е важно както за определяне

кои цикли могат да съдържат паралелизъм и да елиминират зависимостите на имената. The
сложността на анализа на зависимостта възниква и поради наличието на масиви
и указатели в езици като C или C++ или параметър за преминаване по препратка
преминаване във Fortran. Тъй като препратките към скаларни променливи изрично се отнасят до име,
те обикновено могат да бъдат анализирани доста лесно с псевдоним поради указатели и
референтни параметри, причиняващи някои усложнения и несигурност в
анализ.
Как компилаторът открива зависимостите като цяло? Почти всяка зависимост
Алгоритмите за анализ работят при предположението, че индексите на масива са афинни. Най-
просто казано, индексът на едномерен масив е афинен, ако може да бъде записан във формата
a × i + b, където a и b са константи и i е променливата на индекса на цикъла. Индексът
на многомерен масив е афинен, ако индексът във всяко измерение е афинен.
Достъпите до редки масиви, които обикновено имат формата x[y[i]], са един от
основни примери за неафинен достъп.
Определяне дали има зависимост между две препратки към
същият масив в цикъл е еквивалентен на определяне дали две афинни функции могат да имат
една и съща стойност за различни индекси между границите на
цикъл. Да предположим например, че сме съхранили в елемент от масив със стойност на индекс
a × i + b и се зарежда от същия масив със стойност на индекс c × i + d, където i е
индексна променлива на for-loop, която върви от m до n. Зависимост съществува, ако са изпълнени

две условия:
1. Има два индекса на итерация, j и k, които са в границите на for цикъла. Тоест mjn mkn
,
2. Цикълът съхранява в елемент на .
масив, индексиран с a × j + b , и по-късно извлича от същия елемент на масив, когато е

индексиран с c × k + d. Тоест a × j + b = c × k + d.
Като цяло не можем да определим дали съществува зависимост по време на компилиране.

Например стойностите на a, b, c и d може да не са известни (може да са стойности в други
масиви), което прави невъзможно да се каже дали съществува зависимост. В други случаи
тестването на зависимостта може да бъде много скъпо, но може да бъде решено по време на
компилация; например, достъпът може да зависи от индексите на итерация на множество
вложени цикли. Много програми обаче съдържат предимно прости индекси, където a, b, c и d
са константи. За тези случаи е възможно да се разработят разумни тестове за времето за
компилиране за зависимост.
Като пример, прост и достатъчен тест за липса на зависимост е тестът за най-голям общ
делител (НОД). Основава се на наблюдението, че ако съществува зависимост, пренасяна от
цикъла, тогава НОД (c,a) трябва да раздели (d b). (Припомнете си, че едно цяло число, x, дели
друго цяло число, y, ако получим частно цяло число, когато извършим делението на y/x и няма
остатък.)
Пример Използвайте теста GCD, за да определите дали съществуват зависимости в следния цикъл:
за (i=0; i<100; i=i+1) { X[2*i+3] = X[2*i]

* 5.0;
}
Отговор При дадени стойности a = 2, b = 3, c = 2 и d = 0, тогава НОД(a,c) = 2 и d b= 3.

Тъй като 2 не дели 3, не е възможна зависимост.
GCD тестът е достатъчен, за да гарантира, че не съществува зависимост; има обаче случаи,

при които GCD тестът е успешен, но не съществува зависимост. Това може да възникне
например, защото GCD тестът не отчита границите на цикъла.
Като цяло, определянето дали действително съществува зависимост е NP-пълно.
На практика обаче много общи случаи могат да бъдат анализирани прецизно на ниска цена.
Напоследък подходите, използващи йерархия от точни тестове, увеличаващи общостта и
разходите, са показали, че са точни и ефективни. (Един тест е точен , ако определя точно дали
съществува зависимост. Въпреки че общият случай е NP-пълен, съществуват точни тестове за
ограничени ситуации, които са много по-евтини.)
В допълнение към откриването на наличието на зависимост, компилаторът иска да
класифицира типа на зависимостта. Тази класификация позволява на компилатора да
разпознава зависимостите на имената и да ги елиминира по време на компилиране чрез
преименуване и копиране.
Пример Следният цикъл има множество типове зависимости. Намерете всички истински зависимости,
изходни зависимости и антизависимости и елиминирайте изхода
зависимости и антизависимости чрез преименуване.
за (i=0; i<100; i=i+1) {

Y[i] = X[i] / c; /* S1 */
X[i] = X[i] + c; /* S2 */
Z[i] = Y[i] + c; /* S3 */
Y[i] = c - Y[i]; /* S4 */
}
Отговор Съществуват следните зависимости между четирите твърдения:
1. Има истински зависимости от S1 до S3 и от S1 до S4 поради Y[i].

Те не се пренасят по цикъл, така че не пречат на цикъла да се счита за паралелен.
Тези зависимости ще принудят S3 и S4 да изчакат S1 да завърши.
2. Има антизависимост от S1 към S2, базирана на X[i].
3. Има антизависимост от S3 към S4 за Y[i].
4. Има зависимост на изхода от S1 до S4, базирана на Y[i].
Следващата версия на цикъла елиминира тези фалшиви (или псевдо) зависимости.
за (i=0; i<100; i=i+1 {

T[i] = X[i] / c; /* Y преименувано на T за премахване на зависимостта на изхода */
X1[i] = X[i] + c;/* X преименуван на X1 за премахване на антизависимостта */
Z[i] = T[i] + c;/* Y преименуван на T за премахване на антизависимостта */
Y[i] = c - T[i];
}
След цикъла променливата X е преименувана на X1. В кода, който следва цикъла,

компилаторът може просто да замени името X с X1. В този случай преименуването го прави
не изисква действителна операция за копиране, тъй като може да се направи чрез заместване на имена или
чрез разпределение на регистъра. В други случаи обаче преименуването ще изисква копиране.
Анализът на зависимостта също е критична технология за използване на паралелизма

що се отнася до подобно на трансформация блокиране, което глава 2 обхваща. За откриване на
паралелизъм на ниво цикъл, анализът на зависимостта е основният инструмент. Ефективното
компилиране на програми за векторни компютри, SIMD компютри или мултипроцесори зависи
критично от този анализ. Основният недостатък на анализа на зависимостта е, че той се прилага
само при ограничен набор от обстоятелства, а именно сред препратки в рамките на едно
гнездо на цикъл и използване на афинни индексни функции. Следователно има много ситуации
където анализът на зависимостта, ориентиран към масиви, не може да ни каже това, което искаме да знаем; за
например, анализирането на достъпи, направени с указатели, а не с индекси на масиви, може

бъде много по-трудно. (Това е една от причините Fortran все още да се предпочита пред C и C++
за много научни приложения, предназначени за паралелни компютри.) По същия начин,
анализирането на препратки между извиквания на процедури е изключително трудно. По

този начин, докато анализът на код, написан на последователни езици, остава важен, ние
също се нуждаем от подходи като OpenMP и CUDA, които пишат изрично паралелни цикли.
Премахване на зависимите изчисления
Както бе споменато по-горе, една от най-важните форми на зависими изчисления е

повторението. Точковият продукт е перфектен пример за повторение:
за (i=9999; i>=0; i=i-1) сума = сума +

x[i] * y[i];
Този цикъл не е паралелен, защото има зависимост, пренасяна от цикъла, от променливата

сума. Можем обаче да го трансформираме в набор от цикли, единият от които е напълно
успореден, а другият може да бъде частично успореден. Първият цикъл ще изпълни напълно
паралелната част от този цикъл. Изглежда като:
за (i=9999; i>=0; i=i-1) сума[i] = x[i] *

y[i];
Забележете, че сумата е разширена от скаларна във векторна величина (трансформация,

наречена скаларна експанзия) и че тази трансформация прави този нов цикъл напълно
паралелен. Когато сме готови обаче, трябва да направим стъпката за намаляване, която
сумира елементите на вектора. Изглежда като:
за (i=9999; i>=0; i=i-1) крайна сума =

крайна сума + сума[i];
Въпреки че този цикъл не е паралелен, той има много специфична структура, наречена
редукция. Редукциите са често срещани в линейната алгебра и, както ще видим в глава 6, те
също са ключова част от първичния примитив за паралелизъм MapReduce, използван в
компютрите от складов мащаб. По принцип всяка функция може да се използва като
редукционен оператор, а често срещаните случаи включват оператори като max и min.
Редукциите понякога се обработват от специален хардуер във векторна и SIMD
архитектура, който позволява стъпката на редуциране да се извърши много по-бързо,
отколкото може да се направи в скаларен режим. Те работят чрез прилагане на техника,
подобна на това, което може да се направи в многопроцесорна среда. Докато общата
трансформация работи с произволен брой процесори, да предположим, че за простота
имаме 10 процесора. В първата стъпка на намаляване на сумата всеки процесор изпълнява
следното (с p като номер на процесора в диапазона от 0 до 9):
за (i=999; i>=0; i=i-1) крайна сума[p]

= крайна сума[p] + сума[i+1000*p];
Този цикъл, който обобщава 1000 елемента на всеки от десетте процесора, е напълно
паралелен. Прост скаларен цикъл може след това да завърши сумирането на последните
десет суми. Подобни подходи се използват във векторни и SIMD процесори.
Важно е да се отбележи, че горната трансформация разчита на асоциативността на добавянето.

Въпреки че аритметиката с неограничен обхват и точност е асоциативна, компютърната аритметика
не е асоциативна нито за целочислената аритметика, поради ограничения обхват, нито за аритметиката
с плаваща запетая, поради обхвата и прецизността. По този начин използването на тези техники за
преструктуриране понякога може да доведе до погрешно поведение, въпреки че такива събития са
редки. Поради тази причина повечето компилатори изискват оптимизациите, които разчитат на
асоциативност, да бъдат изрично разрешени.
4.6 Междусекторни въпроси
Енергия и DLP: Бавен и широк срещу бърз и тесен

Фундаментално енергийно предимство на паралелните архитектури на ниво данни идва от енергийното
уравнение в глава 1. Тъй като приемаме достатъчно паралелизъм на ниво данни, производителността
е същата, ако намалим наполовина тактовата честота и удвоим ресурсите за изпълнение: два пъти
броя на лентите за векторен компютър, по-широки регистри и ALU за мултимедийни SIMD и повече
SIMD ленти за GPU. Ако можем да намалим напрежението, като намалим тактовата честота, всъщност
можем да намалим енергията, както и мощността за изчислението, като същевременно поддържаме

същата пикова производителност.
Следователно DLP процесорите са склонни да имат по-ниски тактови честоти от системните процесори,
които разчитат на високи тактови честоти за производителност (вижте раздел 4.7).
В сравнение с процесорите извън реда, DLP процесорите могат да имат по-проста контролна
логика за стартиране на голям брой операции на тактов цикъл; например контролът е идентичен за
всички ленти във векторните процесори и няма логика за вземане на решение за проблем с множество
инструкции или спекулативна логика на изпълнение. Векторните архитектури също могат да улеснят
изключването на неизползвани части от чипа. Всяка векторна инструкция изрично описва всички
ресурси, от които се нуждае за определен брой цикли, когато инструкцията издаде.
Банкирана памет и графична памет

В раздел 4.2 се отбелязва важността на значителната честотна лента на паметта за векторни архитектури
за поддържане на единична стъпка, неединична стъпка и събиране-разпръскване на достъп.
За да постигнат своята висока производителност, GPU също изискват значителна честотна лента
на паметта. Специални DRAM чипове, предназначени само за графични процесори, наречени GDRAM
за графична DRAM, помагат за осигуряването на тази честотна лента. GDRAM чиповете имат по-висока
честотна лента при по-малък капацитет от конвенционалните DRAM чипове. За да осигурят тази
честотна лента, GDRAM чиповете често се запояват директно върху същата платка като графичния
процесор, вместо да се поставят в DIMM модули, които се поставят в слотовете на платката, какъвто е
случаят със системната памет. DIMM модулите позволяват много по-голям капацитет и надграждане на
системата, за разлика от GDRAM. Този ограничен капацитет - около 4 GB през 2011 г. - е в противоречие
с целта за решаване на по-големи проблеми, което е естествено използване на увеличената
изчислителна мощност на GPU.
4.7 Обединяване на всичко: мобилни срещу сървърни GPU и Tesla срещу Core i7 323
За да осигурят възможно най-добра производителност, графичните процесори се опитват да вземат предвид всички
характеристиките на GDRAM. Те обикновено са подредени вътрешно като 4 до 8 банки,
със степен 2 брой редове (обикновено 16 384) и степен 2 брой на
бита на ред (обикновено 8192). Глава 2 описва подробностите за поведението на DRAM
които GPU се опитват да съпоставят.
Предвид всички потенциални изисквания към GDRAM от двете изчисления
задачи и задачи за графично ускорение, системата с памет може да види голямо
брой некорелирани заявки. Уви, това разнообразие вреди на производителността на паметта.
За да се справи, контролерът на паметта на GPU поддържа отделни опашки от трафик
обвързани с различни GDRAM банки, изчакващи, докато има достатъчно трафик, за да се оправдае
отварянето на ред и прехвърлянето на всички заявени данни наведнъж. Това забавяне
подобрява честотната лента, но удължава латентността и контролерът трябва да гарантира, че не
процесорните единици гладуват, докато чакат данни, тъй като в противен случай съседните процесори
могат да останат неактивни. Раздел 4.7 показва, че техниките събиране-разпръскване и
Техниките за достъп, съобразени с банковата памет, могат да осигурят значително увеличение на

производителността в сравнение с конвенционалните архитектури, базирани на кеш.
Разкрачени достъпи и TLB пропуски
Един проблем с бързия достъп е как те взаимодействат с превода
lookaside buffer (TLB) за виртуална памет във векторни архитектури или GPU.
(Графичните процесори използват TLB за картографиране на паметта.) В зависимост от това как е
организиран TLB и размера на масива, до който се осъществява достъп в паметта, дори е възможно да
вземете един TLB пропуск за всеки достъп до елемент в масива!
4.7 Събираме всичко заедно: мобилни срещу сървърни

GPU и Tesla срещу Core i7
Като се има предвид популярността на графичните приложения, GPU вече се намират и в двете
мобилни клиенти, както и традиционни сървъри или тежки настолни компютри.
Фигура 4.26 изброява ключовите характеристики на NVIDIA Tegra 2 за мобилни клиенти, която се използва
в LG Optimus 2X и работи с Android OS, и Fermi
GPU за сървъри. Инженерите на GPU сървъри се надяват да могат да правят анимация на живо
в рамките на пет години след пускането на филма. Мобилните инженери на GPU на свой ред искат
в рамките на още пет години мобилен клиент може да направи това, което сървър или конзола за игри
прави днес. По-конкретно, основната цел е качеството на графиката на a

филм като Avatar да бъде постигнат в реално време на сървър GPU през 2015 г. и нататък
вашия мобилен графичен процесор през 2020 г.
NVIDIA Tegra 2 за мобилни устройства осигурява както системния процесор
и GPU в един чип, използвайки една физическа памет. Системният процесор е двуядрен ARM Cortex-A9,
като всяко ядро използва извънредно изпълнение
и проблем с двойна инструкция. Всяко ядро включва допълнителна единица с плаваща запетая.
GPU има хардуерно ускорение за програмируемо засенчване на пиксели, програмируеми върхове и
осветление и 3D графики, но не включва GPU
изчислителни функции, необходими за стартиране на CUDA или OpenCL програми.

NVIDIA Tegra 2 NVIDIA Fermi GTX 480
пазар Мобилен клиент Десктоп, сървър
Системен процесор Двуядрен ARM Cortex-A9 Не е приложимо
Системен интерфейс Не е приложимо PCI Express 2.0 × 16
Честотна лента на 6 GBytes/sec (всяка

системния интерфейс Не е приложимо посока), 12 GBytes/sec (общо)
Тактова честота До 1 GHz 1,4 GHz
SIMD мултипроцесори Недостъпен 15
SIMD ленти/SIMD
Недостъпен 32
мултипроцесор
Интерфейс на паметта 32-битов LP-DDR2/DDR2 384-битова GDDR5
Честотна лента на паметта 2,7 GBytes/sec 1 177 GBytes/sec
Капацитет на паметта GByte 1,5 GB
Транзистори 242 М 3030 М
Процес 40 nm TSMC процес G 40 nm TSMC процес G
Зона на матрицата 57 mm2 520 mm2
Мощност 1,5 вата 167 вата
Фигура 4.26 Основни характеристики на GPU за мобилни клиенти и сървъри. Tegra 2 е

референтната платформа за Android OS и се намира в мобилния телефон LG Optimus 2X.
Размерът на матрицата е 57 mm2 (7,5 × 7,5 mm) при 40 nm TSMC процес и той
съдържа 242 милиона транзистора. Консумира 1,5 вата.
NVIDIA GTX 480 на фигура 4.26 е първата реализация на Fermi

архитектура. Тактовата честота е 1,4 GHz и включва 15 SIMD процесора. The
самият чип има 16, но за подобряване на добива само 15 от 16-те трябва да работят за този
продукт. Пътят до GDDR5 памет е широк 384 (6 × 64) бита и свързва това
тактова честота от 1,84 GHz, предлагаща пикова честотна лента на паметта от 177 GBytes/sec от
прехвърляне на двата фронта на часовника на памет с двойна скорост на данни. Свързва се с
хост системен процесор и памет чрез PCI Express 2.0 × 16 връзка, която има a
пикова двупосочна скорост от 12 GBytes/sec.
Всички физически характеристики на матрицата GTX 480 са впечатляващо големи: тя
съдържа 3,0 милиарда транзистора, размерът на матрицата е 520 mm2 (22,8 × 22,8 mm) при 40 nm
TSMC процес, а типичната мощност е 167 вата. Целият модул е 250
вата, което включва GPU, GDRAM, вентилатори, регулатори на мощността и т.н.
Сравнение на GPU и MIMD с мултимедиен SIMD

Група изследователи на Intel публикуваха статия [Lee et al. 2010] сравнявайки a
четириядрен Intel i7 (вижте Глава 3) с мултимедийни SIMD разширения към предишното
поколение GPU, Tesla GTX 280. Фигура 4.27 изброява характеристиките
Core i7-
960 GTX 280 GTX 480 Съотношение 480/i7
Съотношение 280/i7
Брой обработващи елементи (ядра или SM) 4 30 15 7.5 3.8
Тактова честота (GHz) 3.2 1.3 1.4 0,41 0,44
Размер на матрицата 263 576 520 2.2 2.0
технология Intel 45 nm TSMC 65 nm TSMC 40 nm 1.6 1.0
Мощност (чип, не модул) 130 130 167 1.0 1.3
Транзистори 700 M 1400 M 3030 M 2.0 4.4
Честотна лента на паметта (GBytes/sec) 32 141 177 4.4 5.5
SIMD ширина с единична точност 4 8 32 2.0 8.0
SIMD ширина с двойна точност 2 1 16 0,5 8.0
Пиков скаларен FLOPS с единична точност (GFLOP/Sec) 26 117 63 4.6 2.5
Пиков SIMD FLOPS с единична точност (GFLOP/Sec) 102 311 до 933 515 или 1344 3,0–9,1 6,6–13,1
(SP 1 добавяне или умножаване) NA (311) (515) (3,0) (6.6)
(SP 1 инструкция слято умножение-добавяне) NA (622) (1344) (6,1) (13.1)

NA NA --
(Рядка SP двойна емисия слято умножаване-добавяне и умножаване) (933) (9,1)
Пиков SIMD FLOPS с двойна точност (GFLOP/сек) 51 78 515 1.5 10.1
Фигура 4.27 Спецификации на Intel Core i7-960, NVIDIA GTX 280 и GTX 480. Най-десните колони показват
съотношения на GTX 280 и GTX 480 към Core i7. За SIMD FLOPS с единична точност на GTX 280, по-високата скорост (933)
идва от много рядък случай на двойно издаване на слято умножаване-събиране и умножаване. По-разумно е 622 за единични
слято умножение-добавяне. Въпреки че казусът е между 280 и i7, ние включваме 480, за да покажем връзката му
до 280, тъй като е описано в тази глава. Имайте предвид, че тези честотни ленти на паметта са по-високи, отколкото на Фигура 4.28
тъй като това са честотни ленти на DRAM пинове и тези на Фигура 4.28 са при процесорите, измерени от бенчмарк
програма. (От таблица 2 в Lee et al. [2010].)
на двете системи. И двата продукта бяха закупени през есента на 2009 г. Core i7 е
в 45-нанометровата полупроводникова технология на Intel, докато GPU е в TSMC
65-нанометрова технология. Въпреки че може да е по-справедливо да има сравнение от неутрална
страна или от двете заинтересовани страни, целта на този раздел не е да се определи колко по-бърз
е един продукт от друг, а да се опита
за да разберем относителната стойност на характеристиките на тези две контрастиращи архитектури
стилове.
Линиите на покрива на Core i7 920 и GTX 280 на фигура 4.28 илюстрират

разлики в компютрите. 920 има по-бавна тактова честота от 960
(2,66 GHz срещу 3,2 GHz), но останалата част от системата е същата. Не само
има ли GTX 280 много по-висока честотна лента на паметта и двойна точност
производителност с плаваща запетая, но също така неговата точка на билото с двойна точност е
значително вляво. Както бе споменато по-горе, много по-лесно е да постигнете върхова изчислителна
производителност, колкото по-далеч е точката на билото на линията на покрива вляво. The
точката на ръба с двойна точност е 0,6 за GTX 280 срещу 2,6 за Core i7.
За изпълнение с единична точност, точката на билото се премества много надясно, както е
много по-трудно е да достигнеш покрива на производителността с единична точност, защото е така
Core i7 920
128 128 NVIDIA GTX280
(Нехалем)
64 64
Пикова = 42,66 GFLOP/s
32 32
78 GF/сек
16 16
Поток = 16,4 GB/сек
еGдст
еGдст
о
о
чкFв
чкFв
о
о
нL
нL
оOй
оOй
та/сPн
та/сPн
8 8
Поток = 127 GB/сек
4 4
2 2
1 1/8 1/4 1/2 1 2 4 8 16 1 1/8 1/4 1/2 1 2 4 8 16

Core i7 920
1024 1024 NVIDIA GTX280
(Нехалем)
624 GF/сек
512 512
256 256
128 128
85,33 GF/сек
78 GF/сек
еGест
еGест
о
о
LчкFд
LчкFд
ни
ни
оO
оO
и
и
антч/сP
антч/сP
Поток = 127 GB/сек

64 64
42,66 GF/сек
32 Поток = 16,4 GB/сек 32
16 16
8 1/8 1/4 1/2 1 2 4 8 16 8 1/8 1/4 1/2 1 2 4 8 16

Фигура 4.28 Модел на покрив [Williams et al. 2009]. Тези линии на покрива показват производителност с плаваща
запетая с двойна точност в горния ред и производителност с единична точност в долния ред. (Таванът на
производителността на DP FP също е в долния ред, за да даде перспектива.) Core i7 920 отляво има пикова DP FP
производителност от 42,66 GFLOP/сек, пикова SP FP 85,33 GFLOP/сек и пикова памет честотна лента от 16,4 GBytes/sec.
NVIDIA GTX 280 има DP FP пик от 78 GFLOP/sec, SP FP пик от 624 GFLOP/sec и 127 GBytes/sec честотна лента на паметта.
Прекъснатата вертикална линия вляво представлява аритметичен интензитет от 0,5 FLOP/байт. Той е ограничен от
честотната лента на паметта до не повече от 8 DP GFLOP/сек или 8 SP GFLOP/сек на Core i7. Прекъснатата вертикална
линия вдясно има аритметичен интензитет от 4 FLOP/байт. Той е ограничен само изчислително до 42,66 DP GFLOP/сек
и 64 SP GFLOP/сек при Core i7 и 78 DP GFLOP/сек и 512 DP GFLOP/сек при GTX 280. За да достигнете най-високата скорост
на изчисление на Core i7, трябва да използвате всички 4 ядра и SSE инструкции с равен брой умножения и добавяния.
За GTX 280 трябва да използвате инструкции за слято умножение-добавяне на всички многонишкови SIMD процесори.
Гуз и др. [2009] имат интересен аналитичен модел за тези две архитектури.
много по-високо. Имайте предвид, че аритметичният интензитет на ядрото се основава на

байтовете, които отиват в основната памет, а не байтовете, които отиват в кеш паметта. По този начин,
кеширането може да промени аритметичната интензивност на ядрото на конкретен компютър, като се
предполага, че повечето препратки наистина отиват в кеша. Покривните линии помагат
обяснете относителната ефективност в този казус. Обърнете внимание също, че тази честотна лента е
за единичен достъп и в двете архитектури. Истинско събиране-разпръскване
адресите, които не са обединени, са по-бавни на GTX 280 и на Core i7,
както ще видим.
Изследователите казаха, че са избрали бенчмарк програмите чрез анализ

изчислителните характеристики и характеристиките на паметта на четири наскоро предложени
комплекта за сравнение и след това „формулира набор от изчислителни ядра с производителност, които
улови тези характеристики.“ Фигура 4.29 описва тези 14 ядра, а Фигура
4.30 показва резултатите от производителността, като по-големите числа означават по-бързо.
Ядро Приложение SIMD TLP Характеристики
SGEMM (SGEMM) Линейна алгебра Редовен През 2D плочки Обвързване на изчисления след подреждане
Монте Карло (MC) Компютърни Редовен Напречни пътеки Обвързано с изчислението

финанси
Конволюция (конв.) Анализ на изображението Редовен През пикселите Изчисление обвързано; BW обвързан за
малки филтри
FFT (FFT) Обработка на сигнала Редовна Напречно по-малък Изчислете обвързаност или BW обвързаност
БПФ в зависимост от размера
SAXPY (SAXPY) Точков продукт Редовен През вектор BW, ограничен за големи вектори
LBM (LBM) Времева миграция Редовен През клетките BW обвързан
Решаване на ограничения (Solv) Физика на твърдото тяло Gather/Scatter През ограничения Синхронизация обвързана
SpMV (SpMV) Разреден решаващ инструмент

Съберете се В ненулева BW граница за типични големи матрици
GJK (GJK) Откриване на сблъсък Gather/Scatter През обекти Обвързано с изчислението
Сортиране (Сортиране) База данни Събиране/разпръскване Между елементи Обвързани изчисления
Леене на лъчи (RC) Обемно изобразяване Gather Напречни лъчи 4-8 MB работен комплект от първо ниво;
над 500 MB работен набор от последно
ниво
Търсене (Търсене) База данни Събиране/разпръскване През заявките Изчисление, свързано с малко дърво,
BW обвързан в долната част на дървото за
голямо дърво
Хистограма (Hist) Анализ на изображението Изисква откриване на През пикселите Намаляване/синхронизация

конфликти
Фигура 4.29 Характеристики на ядрото за изчислителна пропускателна способност (от таблица 1 в Lee et al. [2010].) Името в скоби идентифицира името на
бенчмарка в този раздел. Авторите предполагат, че кодът за двете машини е еднакъв
усилия за оптимизация.
GTX 280/
Ядро Единици Core i7-960 GTX 280 i7-960
SGEMM GFLOP/сек 94 364 3.9
MC Милиард пътеки/сек 0,8 1.4 1.8
Реал Милиони пиксела/сек 1250 3500 2.8
БПФ GFLOP/сек 71.4 213 3.0
SAXPY GBytes/sec 16.8 88.8 5.3
LBM Милиони търсения/сек 85 426 5.0
Решаване Кадри/сек 103 52 0,5
SpMV GFLOP/сек 4.9 9.1 1.9
GJK Кадри/сек 67 1020 15.2
Вид Милиони елементи/сек 250 198 0,8
RC Кадри/сек 5 8.1 1.6
Търсене Милиони заявки/сек 50 90 1.8
Хист Милиони пиксела/сек 1517 2583 1.7
Билат Милиони пиксела/сек 83 475 5.7
Фигура 4.30 Сурова и относителна производителност, измерена за двете платформи. В това

проучване, SAXPY се използва просто като мярка за честотна лента на паметта, така че правилната единица е
GBytes/sec, а не GFLOP/sec. (Въз основа на таблица 3 в [Lee et al. 2010].)
Като се има предвид, че суровите спецификации на производителността на GTX 280 варират от

2,5 × по-бавно (тактова честота) до 7,5 × по-бързо (ядра на чип), докато производителността
варира от 2,0 × по-бавно (Solv) до 15,2 × по-бързо (GJK), изследователите на Intel
проучи причините за разликите:
Честотна лента на паметта. Графичният процесор има 4,4 пъти по-голяма честотна лента на паметта, което помага
обяснете защо LBM и SAXPY работят 5.0 и 5.3 пъти по-бързо; техните работни комплекти са
стотици мегабайти и следователно не се побират в кеша на Core i7. (Влизам
интензивно памет, те не са използвали блокиране на кеша на SAXPY.) Следователно,
наклонът на линиите на покрива обяснява тяхното представяне. SpMV също има голям
работен набор, но работи само 1,9×, защото плаващата запетая с двойна точност
на GTX 280 е само 1,5 пъти по-бърз от Core i7. (Припомнете си, че Ферми
GTX 480 с двойна точност е 4 пъти по-бърз от Tesla GTX 280.)
Изчислете честотната лента. Пет от останалите ядра са обвързани с изчисленията:

SGEMM, Conv, FFT, MC и Bilat. GTX е по-бърз с 3.9, 2.8, 3.0, 1.8,
и съответно 5,7. Първите три от тях използват аритметика с плаваща запетая с единична
точност, а GTX 280 с единична точност е 3 до 6 пъти по-бърза. (
9 пъти по-бързо от Core i7, както е показано на Фигура 4.27, се среща само в много
специален случай, когато GTX 280 може да издаде слято умножение-добавяне и умножение
на тактов цикъл.) MC използва двойна точност, което обяснява защо е само
1,8× по-бързо, тъй като DP производителността е само 1,5× по-бърза. Bilat използва
трансцендентални функции, които GTX 280 поддържа директно (вижте Фигура 4.17). The
4.7 Обединяване на всичко: мобилни срещу сървърни графични процесори и Tesla срещу Core i7 329
Core i7 прекарва две трети от времето си в изчисляване на трансцендентални функции, така

че GTX 280 е 5,7 пъти по-бърз. Това наблюдение помага да се посочи стойността на
хардуерната поддръжка за операции, които се случват във вашето работно натоварване:
плаваща запетая с двойна точност и може би дори трансцендентални.
Предимства на кеша. Ray casting (RC) е само 1,6 пъти по-бърз при GTX, тъй като блокирането
на кеша с кешовете на Core i7 го предпазва от обвързване с честотната лента на паметта,
както е при GPU. Блокирането на кеша може да помогне и на Търсене. Ако индексните
дървета са малки, така че да се поберат в кеша, Core i7 е два пъти по-бърз. По-големите
индексни дървета ги правят обвързани с честотната лента на паметта. Като цяло GTX 280
работи с търсене 1,8 пъти по-бързо. Блокирането на кеша също помага за сортирането.
Въпреки че повечето програмисти не биха изпълнили Sort на SIMD процесор, той може да
бъде написан с 1-битов примитив Sort, наречен split. Алгоритъмът за разделяне обаче
изпълнява много повече инструкции, отколкото скаларното сортиране. В резултат на това
GTX 280 работи само 0,8 пъти по-бързо от Core i7. Имайте предвид, че кешовете също
помагат на други ядра на Core i7, тъй като блокирането на кеша позволява на SGEMM, FFT и
SpMV да станат обвързани с изчисленията. Това наблюдение подчертава отново важността
на оптимизациите за блокиране на кеша в Глава 2. (Би било интересно да видим как
кешовете на Fermi GTX 480 ще повлияят на шестте ядра, споменати в този параграф.)
Gather-Scatter. Мултимедийните SIMD разширения са от малка помощ, ако данните са

разпръснати из основната памет; оптималната производителност идва само когато данните
са подравнени на 16-байтови граници. По този начин GJK получава малка полза от SIMD на
Core i7. Както бе споменато по-горе, графичните процесори предлагат събирателно-
разпръскващо адресиране, което се намира във векторна архитектура, но е пропуснато от
SIMD разширенията. Устройството за обединяване на адреси също помага, като комбинира
достъп до една и съща DRAM линия, като по този начин намалява броя на събиранията и разпръсквани
Контролерът на паметта също групира достъпите до една и съща DRAM страница заедно.
Тази комбинация означава, че GTX 280 работи с GJK стряскащо 15,2 пъти по-бързо от Core
i7, което е по-голямо от всеки отделен физически параметър на Фигура 4.27. Това
наблюдение засилва значението на събирането-разпръскване за векторни и GPU
архитектури, което липсва в SIMD разширенията.
Синхронизация. Синхронизирането на производителността е ограничено от атомарни

актуализации, които са отговорни за 28% от общото време на изпълнение на Core i7,
въпреки че има хардуерна инструкция за извличане и увеличаване. Така Hist е само 1,7 ×
по-бърз на GTX 280. Както бе споменато по-горе, атомните актуализации на Fermi GTX 480 са
5 до 20 × по-бързи от тези на Tesla GTX 280, така че отново би било интересно да стартирате
Hist на по-новата GPU. Solv разрешава пакет от независими ограничения в малко количество
изчисления, последвано от бариерна синхронизация. Core i7 се възползва от атомарните
инструкции и модела на последователност на паметта, който гарантира точните резултати,
дори ако не всички предишни достъпи до йерархията на паметта са завършени. Без модела
за последователност на паметта, версията GTX 280 стартира някои партиди от системния
процесор, което води до GTX 280, работещ 0,5 пъти по-бързо от Core i7. Това наблюдение
показва как ефективността на синхронизацията може да бъде важна за някои проблеми с
паралелни данни.
Учудващо е колко често слабостите в Tesla GTX 280, които са били открити от ядрата,
избрани от изследователите на Intel, вече са били адресирани в архитектурата наследник
на Tesla: Fermi има по-бърза производителност с плаваща запетая с двойна точност,
атомарни операции и кеш памети. (В свързано проучване изследователите на IBM
направиха същото наблюдение [Bordawekar 2010].) Беше също така интересно, че
поддръжката на събиране и разпръскване на векторни архитектури, които предшестват
SIMD инструкциите с десетилетия, беше толкова важна за ефективната полезност на тези
разширения на SIMD. sije, които някои бяха предвидили преди сравнението [Gebis и
Patterson 2007] Изследователите на Intel отбелязаха, че 6 от 14-те ядра биха използвали
SIMD по-добре с по-ефективна поддръжка на събиране-разпръскване на Core i7. Това
проучване със сигурност установява и значението на блокирането на кеша. Ще бъде
интересно да видим дали бъдещите поколения многоядрен и GPU хардуер, компилатори и
библиотеки отговарят с функции, които подобряват производителността на такива ядра.
Надяваме се, че ще има повече подобни сравнения на многоядрени GPU. Обърнете
внимание, че важна характеристика, липсваща в това сравнение, описваше нивото на
усилие за получаване на резултатите за двете системи. В идеалния случай бъдещите
сравнения биха пуснали кода, използван и на двете системи, така че другите да могат да
пресъздадат същите експерименти на различни хардуерни платформи и евентуално да
подобрят резултатите.
Въпреки че паралелизмът на ниво данни е най-лесната форма на паралелизъм след ILP от

гледна точка на програмиста и вероятно най-лесният от гледна точка на архитекта, той все
още има много грешки и клопки.
Погрешните графични процесори страдат от това, че са копроцесори.
Въпреки че разделянето между основната памет и GPU паметта има недостатъци, има
предимства да сте на разстояние от CPU.
Например, PTX съществува отчасти поради естеството на I/O устройството на GPU.
Това ниво на индиректност между компилатора и хардуера дава на архитектите на GPU
много повече гъвкавост, отколкото на архитектите на системните процесори. Често е
трудно да се знае предварително дали една архитектурна иновация ще бъде добре
поддържана от компилатори и библиотеки и ще бъде важна за приложенията. Понякога
нов механизъм дори ще се окаже полезен за едно или две поколения и след това ще
загуби своята важност с промените в ИТ света. PTX позволява на архитектите на GPU да
изпробват иновациите спекулативно и да ги изоставят в следващите поколения, ако те
разочароват или избледняват по важност, което насърчава експериментирането.
Обосновката за включване е разбираемо много по-висока за системните процесори - и
следователно може да се случи много по-малко експериментиране - тъй като
разпространението на двоичен машинен код обикновено предполага, че новите функции
трябва да се поддържат от всички бъдещи поколения на тази архитектура.
Демонстрация на стойността на PTX е, че архитектурата на Fermi радикално промени
набора от хардуерни инструкции - от ориентиран към паметта като x86 до
да бъде ориентиран към регистър като MIPS, както и да удвои размера на адреса до 64
битове—без да се прекъсва софтуерният стек на NVIDIA.
Клопка Концентриране върху върхова производителност във векторни архитектури и игнориране на стартиране
отгоре.
Ранни векторни процесори памет-памет като TI ASC и CDC

STAR-100 имаше дълго време за стартиране. За някои проблеми с вектори трябваше да има вектори
по-дълъг от 100, за да бъде векторният код по-бърз от скаларния! На
CYBER 205—извлечен от STAR-100—началните разходи за DAXPY
е 158 тактови цикъла, което значително увеличава точката на рентабилност. Ако
тактовите честоти на Cray-1 и CYBER 205 бяха идентични, Cray-1 би
бъдете по-бързи, докато дължината на вектора стане по-голяма от 64. Тъй като часовникът Cray-1
също беше по-бърз (въпреки че 205 беше по-нов), точката на пресичане беше a
дължина на вектора над 100.
Клопка Повишаване на векторната производителност, без сравними увеличения на скаларната пер-

формация.
Този дисбаланс беше проблем на много ранни векторни процесори и място

където Сиймор Крей (архитектът на компютрите Cray) пренаписва правилата.
Много от ранните векторни процесори имаха сравнително бавни скаларни единици (също така
като големи начални режийни разходи). Дори днес процесор с по-ниска векторна производителност,
но по-добра скаларна производителност може да надмине процесор с по-висок пик
векторно изпълнение. Добрата скаларна производителност намалява режийните разходи (strip
добив, например) и намалява въздействието на закона на Амдал.
Добър пример за това идва от сравняването на бърз скаларен процесор и a
векторен процесор с по-ниска скаларна производителност. Ядрата Livermore Fortran
са колекция от 24 научни ядра с различна степен на векторизация.
Фигура 4.31 показва производителността на два различни процесора при този бенчмарк. Въпреки
по-високата пикова производителност на векторния процесор, неговата ниска скаларна
Минимална скорост Максимална скорост Средно хармонично от
за всеки цикъл за всеки цикъл всичките 24 бримки

Процесор (MFLOPS) (MFLOPS) (MFLOPS)
MIPS M/120-5 0,80 3,89 1,85
Stardent-1500 0,41 10.08 1.72
Фигура 4.31 Измервания на производителността за ядрата Livermore Fortran на две

различни процесори. Както MIPS M/120-5, така и Stardent-1500 (бивш
Ardent Titan-1) използват 16,7 MHz MIPS R2000 чип за основния процесор. Stardent-1500
използва своята векторна единица за скаларен FP и има около половината от скаларната
производителност (измерена чрез минималната скорост) на MIPS M/120-5, който използва MIPS R2010 FP чип.
Векторният процесор е повече от коефициент 2,5 пъти по-бърз за силно векторизираща линия
(максимална ставка). Въпреки това, по-ниската скаларна производителност на Stardent-1500 отрича
по-високата векторна производителност, когато общата производителност се измерва чрез хармоника
средно на всичките 24 бримки.
производителността го прави по-бавен от бърз скаларен процесор, измерено чрез средната

хармонична стойност.
Обръщането на тази опасност днес е увеличаване на векторната производителност - да речем с

увеличаване на броя на лентите—без увеличаване на скаларната производителност. Такива
късогледството е друг път към небалансиран компютър.
Следващата заблуда е тясно свързана.
Заблуда Можете да получите добра векторна производителност, без да осигурявате честотна лента на паметта.
Както видяхме с цикъла DAXPY и модела Roofline, честотната лента на паметта е

доста важен за всички SIMD архитектури. DAXPY изисква 1,5 препратки към паметта
на операция с плаваща запетая и това съотношение е типично за много научни кодове. Дори
ако операциите с плаваща запетая не отнемат време, Cray-1 не може да увеличи производителността
на използваната векторна последователност, тъй като паметта е ограничена. Производителността на
Cray-1 на Linpack скочи, когато компилаторът използва блокиране, за да промени
изчисление, така че стойностите да могат да се съхраняват във векторните регистри. Този подход
намали броя на препратките към паметта на FLOP и подобри производителността
с почти коефициент две! По този начин честотната лента на паметта на Cray-1 стана достатъчна за
цикъл, който преди изискваше повече честотна лента.
Грешка При GPU просто добавете повече нишки, ако нямате достатъчно производителност на паметта.
Графичните процесори използват много нишки CUDA, за да скрият латентността към основната памет. Ако паметта
достъпите са разпръснати или не са корелирани между CUDA нишките, системата с памет ще стане
постепенно по-бавна в отговора на всяка отделна заявка. В крайна сметка дори много нишки няма да
покрият латентността. За „повече CUDA
нишки”, за да работите, не само имате нужда от много CUDA нишки, но и
Самите CUDA нишки също трябва да се държат добре по отношение на локалността на
достъпи до паметта.

Паралелизмът на ниво данни става все по-важен за личните мобилни устройства,
предвид популярността на приложенията, показващи значението на аудио, видео и
игри на тези устройства. Когато се комбинира с по-лесен за програмиране модел от
паралелизъм на ниво задача и потенциално по-добра енергийна ефективност, лесно е да се предвиди
ренесанс за паралелизъм на ниво данни през следващото десетилетие. Наистина можем
вече виждам този акцент в продуктите, като графични процесори и традиционни процесори
увеличават броя на SIMD лентите поне толкова бързо, колкото досега
добавяне на процесори (вижте Фигура 4.1 на страница 263).
Следователно виждаме, че системните процесори придобиват повече от характеристиките на
GPU и обратно. Една от най-големите разлики в производителността между
конвенционалните процесори и графични процесори са за адресиране на събиране и разпръскване.
Традиционните векторни архитектури показват как да добавите такова адресиране към SIMD
инструкциите и очакваме да видим още идеи, добавени от добре доказания вектор
архитектури към SIMD разширения във времето.
Както казахме при откриването на Раздел 4.4, въпросът за GPU не е просто коя архитектура
е най-добра, но, като се има предвид инвестицията в хардуер за добра графика, как може да се
подобри, за да поддържа изчисления, които са по-общи? Въпреки че векторните архитектури
имат много предимства на хартия, остава да се докаже дали векторните архитектури могат да
бъдат толкова добра основа за графики, колкото GPU.
GPU SIMD процесорите и компилаторите все още са с относително прост дизайн.
Техники, които са по-агресивни, вероятно ще бъдат въведени с течение на времето, за да се
увеличи използването на GPU, особено след като GPU изчислителните приложения тепърва
започват да се разработват. Чрез изучаване на тези нови програми дизайнерите на GPU със
сигурност ще открият и внедрят нови машинни оптимизации. Един въпрос е дали скаларният
процесор (или управляващият процесор), който служи за пестене на хардуер и енергия във
векторните процесори, ще се появи в GPU.
Архитектурата на Fermi вече включва много функции, открити в конвенционалните
процесори, за да направи графичните процесори по-масови, но все още има други, необходими
за запълване на празнината. Ето няколко, които очакваме да бъдат разгледани в близко бъдеще.
Виртуализирани графични процесори. Виртуализацията се оказа важна за сървърите и е в

основата на облачните изчисления (вижте глава 6). За да могат графичните процесори да
бъдат включени в облака, те ще трябва да бъдат също толкова виртуализируеми, колкото
процесорите и паметта, към които са
свързани. Сравнително малък размер на GPU паметта. Разумното използване на по-бързи

изчисления е за решаване на по-големи проблеми, а по-големите проблеми често имат по-
голям отпечатък от паметта. Това несъответствие на GPU между скорост и размер може да
бъде адресирано с повече капацитет на паметта. Предизвикателството е да се поддържа
висока честотна лента, като същевременно
се увеличава капацитетът. Директен I/O към GPU памет. Истинските програми правят I/O
към устройства за съхранение, както и към буфери на кадри, а големите програми могат
да изискват много I/O, както и памет с размери. Днешните GPU системи трябва да
прехвърлят между I/O устройства и системна памет и след това между системна памет и
GPU памет. Този допълнителен скок значително намалява I/O производителността в някои
програми, правейки GPU по-малко привлекателни. Законът на Амдал ни предупреждава
какво се случва, когато пренебрегвате една част от задачата, докато ускорявате други.
Очакваме, че бъдещите графични процесори ще превърнат всички I/O в първокласни
граждани, точно както се прави с I/O буфера днес. Обединени физически памети.
Алтернативно решение на предишните два куршума е да имате една физическа памет за
системата и GPU, точно както някои евтини GPU правят за PMD и лаптопи. Архитектурата
AMD Fusion, обявена точно когато това издание беше завършено, е първоначално сливане
между традиционни графични процесори и традиционни процесори. NVIDIA също обяви
Project Denver, който комбинира ARM скаларен процесор с NVIDIA GPU в едно адресно
пространство. Когато тези системи бъдат доставени, ще бъде интересно да научим колко
тясно интегрирани са те и въздействието на интеграцията върху производителността и
енергията както на паралелните данни, така и на графичните приложения.
След като разгледа многото версии на SIMD, следващата глава се гмурка в царството на
MIMD.

Раздел L.6 (достъпен онлайн) включва дискусия за Illiac IV (представител на ранните SIMD
архитектури) и Cray-1 (представител на векторни архитектури). Ние също така разглеждаме
мултимедийните SIMD разширения и историята на GPU.
Казус и упражнения от Джейсън Д. Бакос
Казус от практиката: Внедряване на векторно ядро върху вектор

Процесор и GPU
Програмиране на векторни процесори
Програмиране на GPU
Оценка на ефективността
MrBayes е популярно и добре известно приложение за изчислителна биология за извеждане

на еволюционните истории сред набор от входни видове въз основа на техните многократно
подредени данни за ДНК последователности с дължина n. MrBayes работи, като извършва
евристично търсене в пространството на всички двоични топологии на дърво, за които
входните данни са листата. За да се оцени конкретно дърво, приложението трябва да
изчисли n × 4 условна таблица на вероятността (наречена clP) за всеки вътрешен възел.
Таблицата е функция на таблиците на условната вероятност на двата низходящи възела на
възела (clL и clR, с плаваща запетая с единична точност) и свързаните с тях n × 4 × 4 таблици
на вероятността за преход ( tiPL и tiPR, с плаваща запетая с единична точност). Едно от ядрата
на това приложение е изчисляването на тази таблица с условна вероятност и е показано по-долу:
за (k=0; k<seq_length; k++) {

clP[h++] = (tiPL[AA]*clL[A] + tiPL[AC]*clL[C] + tiPL[AG]*clL[G] + tiPL[AT]*clL[T])
*(tiPR[ AA]*clR[A] + tiPR[AC]*clR[C] + tiPR[AG]*clR[G] + tiPR[AT]*clR[T]);
clP[h++] = (tiPL[CA]*clL[A] + tiPL[CC]*clL[C] + tiPL[CG]*clL[G] + tiPL[CT]*clL[T])
*(tiPR[ CA]*clR[A] + tiPR[CC]*clR[C] + tiPR[CG]*clR[G] + tiPR[CT]*clR[T]);
clP[h++] = (tiPL[GA]*clL[A] + tiPL[GC]*clL[C] + tiPL[GG]*clL[G] + tiPL[GT]*clL[T])
*(tiPR[ GA]*clR[A] + tiPR[GC]*clR[C] + tiPR[GG]*clR[G] + tiPR[GT]*clR[T]);
clP[h++] = (tiPL[TA]*clL[A] + tiPL[TC]*clL[C] + tiPL[TG]*clL[G] + tiPL[TT]*clL[T])
*(tiPR[ TA]*clR[A] + tiPR[TC]*clR[C] + tiPR[TG]*clR[G] + tiPR[TT]*clR[T]);
clL += 4;
clR += 4;
tiPL += 16;
tiPR += 16;
}
Константи Стойности
AA,AC,AG,AT 0,1,2,3
CA,CC,CG,CT 4,5,6,7
GA, GC, GG, GT 8,9,10,11
TA,TC,TG,TT 12,13,14,15
A,C,G,T 0,1,2,3
Фигура 4.32 Константи и стойности за казуса.
4.1 [25] <4.2, 4.3> Да приемем константите, показани на Фигура 4.32. Покажете кода за
MIPS и VMIPS. Да приемем, че не можем да използваме разпръснати товари или складове. Да приемем
началните адреси на tiPL, tiPR, clL, clR и clP са в RtiPL, RtiPR, RclL,
RclR и RclP, съответно. Да приемем, че дължината на VMIPS регистъра е програмируема от
потребителя и може да бъде присвоена чрез задаване на специален регистър VL (напр. li VL 4). За улеснение
редукции на векторно добавяне, приемем, че добавяме следните инструкции към VMIPS:
SUMR.S Fd, Vs Vector Summation Reduction Единична точност:
Тази инструкция извършва редукция на сумиране на векторен регистър Vs, запис

към сумата в скаларния регистър Fd.
4.2 [5] <4.2, 4.3> Ако приемем seq_length == 500, каква е динамичната инструкция
брои и за двете реализации?
4.3 [25] <4.2, 4.3> Да приемем, че инструкцията за векторна редукция се изпълнява на

векторна функционална единица, подобна на инструкция за добавяне на вектор. Покажете как кодът
последователността е разположена в конвои, като се приема един екземпляр на всяка
векторна функционална единица. Колко звънчета ще изисква кодът? Колко цикъла на FLOP
са необходими, игнорирайки проблем с векторни инструкции?
4.4 [15] <4.2, 4.3> Сега приемете, че можем да използваме разпръснати натоварвания и съхранявания (LVI
и SVI). Да приемем, че tiPL, tiPR, clL, clR и clP са подредени последователно
в памет. Например, ако seq_length==500, tiPR масивът ще започне 500 *
4 байта след масива tiPL. Как това се отразява на начина, по който можете да пишете
VMIPS код за това ядро? Да предположим, че можете да инициализирате векторни регистри с
цели числа, като се използва следната техника, която например би инициализирала
векторен регистър V1 със стойности (0,0,2000,2000):
LI R2,0
SW R2, vec
SW R2,vec+4
LI R2,2000
SW R2,vec+8
SW R2,vec+12
LV V1,vec
Да приемем, че максималната дължина на вектора е 64. Има ли начин производителността да бъде

подобрено чрез събиране-разпръскване на товари? Ако да, с колко?
4.5 [25] <4.4> Сега приемете, че искаме да внедрим ядрото MrBayes на GPU
с помощта на блок с една нишка. Пренапишете C кода на ядрото с помощта на CUDA.
Да приемем, че указва условната вероятност и вероятността за преход
таблиците са посочени като параметри на ядрото. Извиквайте една нишка за всяка итерация на
цикъла. Заредете всички повторно използвани стойности в споделена памет преди изпълнение
операции върху него.
4.6 [15] <4.4> С CUDA можем да използваме груб паралелизъм на ниво блок, за да
изчислете условните вероятности на множество възли паралелно. Да приемем, че ние
искате да изчислите условните вероятности от дъното на дървото нагоре.
Да приемем, че масивите с условна вероятност и вероятност за преход са организирани в паметта,
както е описано във въпрос 4 и групата от таблици за всеки от
12 листови възела също се съхраняват в последователни места в паметта в реда на възела
номер. Да приемем, че искаме да изчислим условната вероятност за възли 12
до 17, както е показано на фигура 4.33. Променете метода, по който изчислявате
индекси на масиви във вашия отговор от упражнение 4.5, за да включите номера на блока.
4.7 [15] <4.4> Преобразувайте вашия код от Упражнение 4.6 в PTX код. Колко
необходими са инструкции за ядрото?
4.8 [10] <4.4> Колко добре очаквате да работи този код на GPU? Обяснете вашето
отговор.
22
21
18 19 20
12 13 14 15 16 17
0 1 23456 7 8 9 10 11
Фигура 4.33 Примерно дърво.

4.9 [10/20/20/15/15] <4.2> Разгледайте следния код, който умножава два вектора, които съдържат
комплексни стойности с единична точност:
за (i=0;i<300;i++) {
c_re[i] = a_re[i] * b_re[i] – a_im[i] * b_im[i]; c_im[i] = a_re[i] * b_im[i] + a_im[i]
* b_re[i];
Да приемем, че процесорът работи на 700 MHz и има максимална дължина на вектора от 64.
Модулът за зареждане/запаметяване има начална стойност от 15 цикъла; единица за умножение,
8 цикъла; и единицата за събиране/изваждане, 5
цикъла. а. [10] <4.2> Какъв е аритметичният интензитет на това ядро? Обосновете своето
отговор.
b. [20] <4.2> Преобразувайте този цикъл във VMIPS асемблерен код с помощта на лентово
копаене. ° С. [20] <4.2> Ако приемем верижно свързване и един конвейер на паметта, колко
звънчета са необходими? Колко тактови цикъла са необходими за сложна резултатна
стойност, включително режийни разходи при стартиране?
д. [15] <4.2> Ако векторната последователност е верижна, колко тактови цикъла са

изисква се за комплексна резултатна стойност, включително режийни?
д. [15] <4.2> Сега приемете, че процесорът има три конвейера на паметта и верига. Ако няма
банкови конфликти в достъпите на цикъла, колко тактови цикъла са необходими за резултат?
4.10 [30] <4.4> В този проблем ще сравним производителността на векторен процесор с хибридна
система, която съдържа скаларен процесор и GPU-базиран копроцесор. В хибридната система
хост процесорът има превъзходна скаларна производителност спрямо GPU, така че в този случай
целият скаларен код се изпълнява на хост процесора, докато целият векторен код се изпълнява
на GPU. Ще наричаме първата система векторен компютър, а втората система хибриден
компютър. Да приемем, че вашето целево приложение съдържа векторно ядро с аритметичен
интензитет от 0,5 FLOPs на достъпен DRAM байт; обаче, приложението има и скаларен компонент,
който трябва да се изпълни преди и след ядрото, за да се подготвят предварително входните
вектори и съответно изходните вектори. За примерен набор от данни, скаларната част на кода
изисква 400 ms време за изпълнение както на векторния процесор, така и на хост процесора в
хибридната система. Ядрото чете входни вектори, състоящи се от 200 MB данни, и има изходни
данни, състоящи се от 100 MB данни. Векторният процесор има пикова честотна лента на паметта
от 30 GB/sec, а GPU има пикова честотна лента на паметта от 150 GB/sec. Хибридната система
има допълнително натоварване, което изисква всички входни вектори да бъдат прехвърлени
между паметта на хоста и локалната памет на GPU преди и след извикване на ядрото. Хибридната
система има честотна лента с директен достъп до паметта (DMA) от 10 GB/sec и средна латентност
от 10 ms. Да приемем, че както векторният процесор, така и графичният процесор са
производителност, обвързана с честотната лента на паметта. Изчислете времето за изпълнение,

необходимо на двата компютъра за това приложение.
4.11 [15/25/25] <4.4, 4.5> Раздел 4.5 обсъжда редукционната операция, която редуцира вектор
до скалар чрез многократно прилагане на операция. Редукцията е специален тип
повторение на цикъла. По-долу е показан пример:
точка=0,0;
за (i=0;i<64;i++) точка = точка + a[i] * b[i];
Векторизиращият компилатор може да приложи трансформация, наречена скаларно

разширяване, която разширява точката във вектор и разделя цикъла, така че
умножението да може да се извърши с векторна операция, оставяйки редуцирането
като
отделна скаларна операция: for (i=0;i< 64;i++) точка[i] =
a[i] * b[i]; за (i=1;i<64;i++) точка[0] = точка[0] + точка[i];
Както бе споменато в раздел 4.5, ако позволим добавянето с плаваща запетая да бъде
асоциативно, има няколко налични техники за паралелизиране на намаляването.
а. [15] <4.4, 4.5> Една техника се нарича рекурентно удвояване, която добавя
последователности от прогресивно по-къси вектори (т.е. два вектора с 32 елемента,
след това два вектора с 16 елемента и т.н.). Покажете как би изглеждал C кодът при
изпълнение на втория цикъл по този начин.
b. [25] <4.4, 4.5> В някои векторни процесори отделните елементи във векторните
регистри са адресируеми. В този случай операндите към векторна операция могат
да бъдат две различни части от един и същи векторен регистър. Това позволява
друго решение за намалението, наречено частични суми. Идеята е да се намали
векторът до m суми, където m е общата латентност през векторната функционална
единица, включително времето за четене и запис на операнда. Да приемем, че
VMIPS векторните регистри са адресируеми (напр. можете да инициирате векторна
операция с операнд V1(16), което показва, че входният операнд започва с елемент
16). Освен това приемете, че общото забавяне за добавяне, включително oper-и
четене и запис на резултат, е осем цикъла. Напишете VMIPS кодова последователност,
която намалява съдържанието на V1 до осем частични суми.
° С. [25] <4.4, 4.5> Когато се извършва редукция на GPU, една нишка се свързва с всеки
елемент във входния вектор. Първата стъпка е всяка нишка да запише съответната
си стойност в споделена памет. След това всяка нишка влиза в цикъл, който добавя
всяка двойка входни стойности. Това намалява броя на елементите наполовина
след всяка итерация, което означава, че броят на активните нишки също намалява
наполовина след всяка итерация. За да се максимизира производителността на
намаляването, броят на напълно запълнените изкривявания трябва да бъде
максимизиран по време на хода на цикъла. С други думи, активните нишки трябва
да са съседни. Освен това всяка нишка трябва да индексира споделения масив по
такъв начин, че да избегне банкови конфликти в споделената памет. Следният цикъл нарушава
само първата от тези насоки и също така използва модулния оператор, който е
много скъп за GPU:
unsigned int tid = threadIdx.x;
for(unsigned int s=1; s < blockDim.x; s *= 2) { if ((tid % (2*s)) == 0)
{ sdata[tid] += sdata[tid + s]; }
__syncthreads(); }
Пренапишете цикъла, за да изпълните тези насоки и елиминирайте използването на

модулния оператор. Да приемем, че има 32 нишки на деформация и възниква конфликт на
банка всеки път, когато две или повече нишки от една и съща деформация препращат към
индекс, чийто модул по 32 е равен.
4.12 [10/10/10/10] <4.3> Следното ядро изпълнява част от метода на крайната разлика във
времевата област (FDTD) за изчисляване на уравненията на Максуел в триизмерно
пространство, част от един от тестовете SPEC06fp:
за (int x=0; x<NX-1; x++) {
for (int y=0; y<NY-1; y++) { for (int z=0;
z<NZ-1; z++) { int index = x*NY*NZ +
y*NZ + z; if (y>0 && x >0) { material =
IDx[index]; dH1 =
(Hz[индекс] – Hz[индекс-
инкрементY])/dy[y]; dH2 = (Hy[индекс] – Hy[индекс-инкрементZ])/
dz[z];
Ex[индекс] = Ca[материал]*Ex[индекс]+Cb[материал]*(dH2-dH1); }}}}
Да приемем, че dH1, dH2, Hy, Hz, dy, dz, Ca, Cb и Ex са всички масиви с плаваща запетая
с единична точност. Да приемем, че IDx е масив от unsigned int. а.
[10] <4.3> Какъв е аритметичният интензитет на това ядро? b. [10]
<4.3> Това ядро податливо ли е на векторно или SIMD изпълнение? Защо или защо
не?
° С. [10] <4.3> Да приемем, че това ядро трябва да се изпълни на процесор, който има 30 GB/сек
честотна лента на паметта. Това ядро ще бъде ли обвързано с памет или обвързано с
изчисления?
д. [10] <4.3> Разработете покривен модел за този процесор, като приемете, че има
пикова изчислителна производителност от 85 GFLOP/сек.
4.13 [10/15] <4.4> Да приемем GPU архитектура, която съдържа 10 SIMD процесора.
Всяка SIMD инструкция има ширина 32 и всеки SIMD процесор съдържа 8 ленти за
аритметика с единична точност и инструкции за зареждане/съхранение, което означава, че
всяка неотклонена SIMD инструкция може да произведе 32 резултата на всеки 4 цикъла.

Да приемем, че ядрото има различни клонове, което кара средно 80% от нишките да
бъдат активни. Да приемем, че 70% от всички изпълнени SIMD инструкции са аритметика
с единична точност и 20% са зареждане/съхраняване. Тъй като не всички закъснения на
паметта са обхванати, приемете средна честота на издаване на SIMD инструкции от 0,85.
Да приемем, че GPU има тактова честота
от 1,5 GHz. а. [10] <4.4> Изчислете пропускателната способност в GFLOP/сек за това ядро на този
GPU.
b. [15] <4.4> Да приемем, че имате следните възможности за избор:
(1) Увеличаване на броя на лентите с единична точност до 16

(2) Увеличаване на броя на SIMD процесорите до 15 (да приемем, че тази промяна не
засяга никакви други показатели за производителност и че кодът се мащабира
към допълнителните процесори)
(3) Добавяне на кеш, който ефективно ще намали латентността на паметта с 40%,
което ще увеличи процента на издаване на инструкции до
0,95 Какво е ускоряване на пропускателната способност за всяко от тези подобрения?
4.14 [10/15/15] <4.5> В това упражнение ще разгледаме няколко цикъла и ще анализираме

техния потенциал за паралелизиране.
а. [10] <4.5> Следният цикъл има ли зависимост, пренасяна от цикъл?
за (i=0;i<100;i++) {
A[i] = B[2*i+4];
B[4*i+5] = A[i]; }
b. [15] <4.5> В следващия цикъл намерете всички истински зависимости, изходни

зависимости и антизависимости. Елиминирайте изходните зависимости и
антизависимости чрез преименуване.
за (i=0;i<100;i++) {
A[i] = A[i] * B[i]; /* S1 */ B[i] = A[i] + c; /*
S2 */ A[i] = C[i] * c; /* S3 */ C[i] = D[i]
* A[i]; /* S4 */ c. [15] <4.5>
Разгледайте следния цикъл: for (i=0;i
< 100;i++) {
A[i] = A[i] + B[i]; /* S1 */
B[i+1] = C[i] + D[i]; /* S2 */ }
Има ли зависимости между S1 и S2? Този цикъл успореден ли е? Ако не, покажете как да го
направите успореден.
4.15 [10] <4.4> Избройте и опишете поне четири фактора, които влияят на производителността на GPU ядрата. С
други думи, кои поведения по време на изпълнение, причинени от кода на ядрото, причиняват
намаляване на използването на ресурсите по време на изпълнение на ядрото?
4.16 [10] <4.4> Да приемем хипотетичен GPU със следните характеристики:
Тактова честота 1,5 GHz
Съдържа 16 SIMD процесора, всеки от които съдържа 16 плаващи модула с единична точност
точкови единици
Има честотна лента на паметта извън чипа 100 GB/sec
Без да се взема предвид честотната лента на паметта, каква е пиковата пропускателна способност с
плаваща запетая с единична точност за този GPU в GLFOP/сек, като се приеме, че всички закъснения
на паметта могат да бъдат скрити? Устойчива ли е тази пропускателна способност предвид ограничението
на честотната лента на паметта?
4.17 [60] <4.4> За това упражнение по програмиране ще напишете и характеризирате поведението на CUDA ядро,
което съдържа голямо количество паралелизъм на ниво данни, но също така съдържа поведение при
условно изпълнение. Използвайте комплекта инструменти NVIDIA CUDA заедно с GPU-SIM от
Университета на Британска Колумбия (http://www.ece.ubc.ca/~aamodt/gpgpu-sim/ ) или CUDA Profiler за

писане и компилиране на CUDA ядро, което изпълнява 100 итерации на Conway's Game of Life за
игрална дъска 256 × 256 и връща крайното състояние на игралната дъска на хоста.
Да приемем, че платката е инициализирана от хоста. Свържете една нишка с всяка клетка. Уверете се,
че сте добавили бариера след всяка итерация на играта. Използвайте следните правила на играта:
Всяка жива клетка с по-малко от два живи съседа умира. Всяка жива
клетка с два или трима живи съседи продължава да живее в следващото поколение. Всяка жива
клетка с повече от три живи съседи умира. Всяка мъртва клетка с точно
трима живи съседи става жива клетка.
След като завършите ядрото, отговорете на следните въпроси:
а. [60] <4.4> Компилирайте вашия код с помощта на опцията –ptx и проверете PTX представянето на
вашето ядро. Колко PTX инструкции съставляват PTX изпълнението на вашето ядро? Условните
секции на вашето ядро включваха ли инструкции за разклоняване или само предсказуеми
инструкции без разклоняване?
b. [60] <4.4> След изпълнение на вашия код в симулатора, какъв е динамичният брой инструкции? Какви
са постигнатите инструкции за цикъл (IPC) или процентът на издаване на инструкции? Каква е
разбивката на динамичните инструкции по отношение на инструкции за управление, инструкции
за аритметично-логическа единица (ALU) и инструкции за памет? Има ли конфликти в банки със
споделена памет? Каква е ефективната честотна лента на паметта извън чипа?
° С. [60] <4.4> Внедрете подобрена версия на вашето ядро, където препратките към памет извън чипа
са обединени и наблюдавайте разликите в производителността по време на изпълнение.
5.2 Централизирани архитектури със споделена памет 351
5.4 Разпределена споделена памет и кохерентност, базирана на директории 378
5.5 Синхронизация: Основите 386
5.6 Модели на последователност на паметта: Въведение 392
5.8 Събираме всичко заедно: многоядрени процесори и тяхната производителност 400
5.11 Исторически перспективи и препратки Казуси 412
и упражнения от Амр Заки и Дейвид А. Ууд 412

5
Паралелизъм на ниво нишка 1
Отдръпването от конвенционалната организация дойде в средата на 60-те

години на миналия век, когато законът за намаляващата възвръщаемост
започна да влиза в сила в усилията за увеличаване на оперативната скорост на компютъра. . . .
Електронните схеми в крайна сметка са ограничени в скоростта си на работа от
скоростта на светлината. . . и много от веригите вече работеха в диапазона от
наносекунди.
W. Jack Bouknight и др.

Системата Илиак IV (1972)
Ние посвещаваме цялото си бъдещо разработване на продукти на многоядрени

дизайни. Вярваме, че това е ключова повратна точка за индустрията.
Президентът на Intel Пол Отелини,
описвайки бъдещата посока на Intel в

Форум за разработчици на Intel през 2005 г

344 Глава пета Паралелизъм на ниво нишка
Както показват цитатите, които започват тази глава, мнението, че напредъкът в еднопроцесорната
архитектура е към своя край, се поддържа от някои изследователи за
много години. Очевидно тези възгледи бяха преждевременни; всъщност през периода на
1986–2003 г., нарастване на производителността на еднопроцесорния процесор, управляван от микропроцесора,
беше в най-високата си скорост от първите транзисторни компютри в края на 50-те години

и началото на 1960 г.
Независимо от това, значението на мултипроцесорите нараства през цялото време
1990 г., когато дизайнерите търсеха начин да изградят сървъри и суперкомпютри, които
постигна по-висока производителност от единичен микропроцесор, като същевременно използваше
огромни предимства в съотношението цена-производителност на обикновените микропроцесори. Тъй като ние
обсъдено в глави 1 и 3, възниква забавяне на производителността на еднопроцесорния процесор

от намаляващата възвръщаемост при използване на паралелизъм на ниво инструкции (ILP), съчетан с
нарастваща загриженост относно мощността, води до нова ера в компютъра
архитектура - ера, в която мултипроцесорите играят основна роля от ниския клас до
високият клас. Вторият цитат улавя тази ясна инфлексна точка.
Това повишено значение на мултипроцесирането отразява няколко основни фактора:
Драматично по-ниската ефективност на силиция и потреблението на енергия

срещани между 2000 и 2005 г., когато дизайнерите се опитват да намерят и
използват повече ILP, което се оказа неефективно, тъй като разходите за енергия и силиций
нарастват по-бързо от производителността. Освен ILP, единственият мащабируем
и начин с общо предназначение знаем как да увеличим производителността по-бързо
отколкото позволява основната технология (от гледна точка на превключване).
многопроцесорност.
Нарастващ интерес към сървъри от висок клас, тъй като облачните изчисления и
софтуерът като услуга стават все по-важни.
Ръст в приложенията с интензивно използване на данни, движен от наличието на масивни

количества данни в интернет.
Прозрението, че увеличаването на производителността на работния плот е по-малко

важно (поне извън графиката), защото текущата производителност е приемлива или
тъй като приложенията, изискващи много изчисления и данни, се изпълняват
Облакът.
Подобрено разбиране за това как да се използват ефективно мултипроцесорите, особено

в сървърни среди, където има значителен естествен паралелизъм,
произтичащи от големи набори от данни, естествен паралелизъм (който се среща в научните
кодове), или паралелизъм сред голям брой независими заявки (паралелизъм на ниво заявка).
Предимствата на използването на инвестиция в дизайн чрез репликация, а не чрез

уникален дизайн; всички мултипроцесорни дизайни предоставят такова предимство.
В тази глава се фокусираме върху използването на паралелизма на ниво нишка (TLP). TLP
предполага наличието на множество програмни броячи и следователно се използва предимно
чрез MIMDs. Въпреки че MIMD съществуват от десетилетия, движението

на паралелизъм на ниво нишка на преден план в обхвата на изчисленията от
вградените приложения към сървъри от висок клас са сравнително скорошни. По същия начин,
широкото използване на паралелизъм на ниво нишка за приложения с общо предназначение, срещу
научни приложения, е сравнително ново.
Нашият фокус в тази глава е върху мултипроцесорите, които определяме като компютри,
състоящи се от тясно свързани процесори, чиято координация и използване са
обикновено се контролират от една операционна система и споделят памет чрез
споделено адресно пространство. Такива системи използват паралелизъм на ниво нишка чрез
два различни софтуерни модела. Първият е изпълнението на плътно свързан комплект
нишки, които си сътрудничат по една задача, което обикновено се нарича паралелна обработка.
Второто е изпълнението на множество, относително независими процеси, които могат да произхождат
от един или повече потребители, което е форма на паралелизъм на ниво заявка, макар и в много по-
малък мащаб от това, което изследваме в
следваща глава. Паралелизмът на ниво заявка може да се използва от едно приложение
работещи на множество процесори, като например база данни, отговаряща на заявки, или множество
приложения, работещи независимо, често наричано мултипрограмиране.
Мултипроцесорите, които разглеждаме в тази глава, обикновено варират по размер от a
двоен процесор към десетки процесори и комуникирайте и координирайте чрез тях
споделянето на паметта. Въпреки че споделянето чрез памет предполага споделено
адресно пространство, това не означава непременно, че има една единствена физическа памет.
Такива мултипроцесори включват както едночипови системи с множество ядра,
известни като многоядрени, и компютри, състоящи се от множество чипове, всеки от които
може да бъде многоядрен дизайн.
В допълнение към истинските многопроцесорни процесори, ще се върнем към темата за
многонишковото обработване, техника, която поддържа множество нишки, изпълнявани в редовна
мода на един процесор с множество проблеми. Много многоядрени процесори също включват
поддръжка за многопоточност.
В следващата глава ще разгледаме ултрамащабни компютри, изградени от много големи
брой процесори, свързани с мрежова технология и често наричани
клъстери; тези широкомащабни системи обикновено се използват за облачни изчисления с a
модел, който предполага или огромен брой независими заявки, или много
паралелни, интензивни изчислителни задачи. Когато тези клъстери нараснат до десетки хиляди
на сървъри и извън тях, ние ги наричаме компютри от складов мащаб.
В допълнение към мултипроцесорите, които изучаваме тук, и складовите
системи от следващата глава, има набор от специални големи мултипроцесори
системи, понякога наричани мултикомпютри, които са по-малко тясно свързани от
многопроцесорни системи, разгледани в тази глава, но по-тясно свързани от системите в складов
мащаб в следващата. Основната употреба на такива мултикомпютри е в
висок клас научни изчисления. Много други книги, като Culler, Singh и
Gupta [1999], обхващат тези системи в детайли. Поради големия и променящ се
естеството на областта на многопроцесорната обработка (току-що споменатата референция на Culler et al. е
над 1000 страници и обсъжда само многопроцесорни!), избрахме да се фокусираме
вниманието ни към това, което вярваме, че е най-важното и с общо предназначение части от
изчислителното пространство. Приложение I обсъжда някои от проблемите, които възникват в
изграждане на такива компютри в контекста на широкомащабни научни приложения.
По този начин нашият фокус ще бъде върху мултипроцесорите с малък до среден брой
процесори (2 до 32). Такива дизайни значително доминират по отношение както на единици,
така и на долари. Ще обърнем само малко внимание на по-мащабното многопроцесорно
пространство (33 или повече процесора), предимно в Приложение I, което обхваща повече
аспекти на дизайна на такива процесори, както и производителността на поведението за
паралелни научни натоварвания, основен клас приложения за големи мултипроцесори. В
големите мултипроцесори мрежите за взаимно свързване са критична част от дизайна;
Приложение F се фокусира върху тази тема.
Мултипроцесорна архитектура: проблеми и подход
За да се възползваме от MIMD мултипроцесор с n процесора, обикновено трябва да имаме

поне n нишки или процеси за изпълнение. Независимите нишки в рамките на един процес
обикновено се идентифицират от програмиста или се създават от операционната система (от
множество независими заявки). В другата крайност една нишка може да се състои от няколко
десетки итерации на цикъл, генерирани от паралелен компилатор, използващ паралелизма
на данни в цикъла. Въпреки че количеството изчисления, присвоени на една нишка,
наречено размер на зърното, е важно при обмислянето на това как да се използва ефективно
паралелизма на ниво нишка, важната качествена разлика от паралелизма на ниво инструкции
е, че паралелизмът на ниво нишка се идентифицира на високо ниво от софтуерната система
или програмиста и че нишките се състоят от стотици до милиони инструкции, които могат да
се изпълняват паралелно.
Нишките също могат да се използват за използване на паралелизъм на ниво данни,
въпреки че е вероятно излишъкът да бъде по-висок, отколкото би се видял със SIMD процесор
или с GPU (вижте Глава 4 ) . Това наддаване означава, че размерът на зърното трябва да бъде
достатъчно голям, за да се използва ефективно паралелизма. Например, въпреки че
векторен процесор или GPU може да успее ефективно да паралелизира операциите върху
къси вектори, полученият размер на зърното, когато паралелизмът е разделен между много
нишки, може да бъде толкова малък, че режийните разходи правят използването на
паралелизма непосилно скъпо в MIMD.
Съществуващите мултипроцесори със споделена памет попадат в два класа в зависимост
от броя на включените процесори, което от своя страна диктува организация на паметта и
стратегия за взаимно свързване. Ние говорим за мултипроцесорите чрез тяхната организация
на паметта, защото това, което представлява малък или голям брой процесори, вероятно ще
се промени с времето.
Първата група, която наричаме симетрични (със споделена памет) мултипроцесори (SMP)
или централизирани мултипроцесори със споделена памет, разполага с малък брой ядра,
обикновено осем или по-малко. За мултипроцесори с толкова малък брой процесори е
възможно процесорите да споделят една централизирана памет, до която всички процесори
имат равен достъп, оттук и терминът симетричен. В многоядрените чипове паметта се
споделя ефективно по централизиран начин между ядрата и всички съществуващи
многоядрени процесори са SMP. Когато е свързано повече от едно многоядрено, има отделни
памети за всяко многоядрено, така че паметта е разпределена, а не централизирана.
SMP архитектурите също понякога се наричат мултипроцесори с унифициран достъп до

паметта (UMA), произтичащи от факта, че всички процесори имат еднаква латентност
от паметта, дори ако паметта е организирана в множество банки. Фигура 5.1 показва как
изглеждат тези мултипроцесори. Архитектурата на SMP е темата на Раздел 5.2 и ние
обясняваме подхода в контекста на многоядрени.
Алтернативният подход към дизайна се състои от мултипроцесори с физически
разпределена памет, наречена разпределена споделена памет (DSM). Фигура 5.2 показва
как изглеждат тези мултипроцесори. За да поддържа по-голям брой процесори, паметта
трябва да бъде разпределена между процесорите, а не централизирана; в противен
случай системата с памет не би могла да поддържа изискванията за честотна лента на по-
голям брой процесори, без да предизвика прекалено дълго забавяне на достъпа.
С бързото увеличаване на производителността на процесора и свързаното с това
увеличаване на изискванията за честотна лента на паметта на процесора, размерът на
мултипроцесора, за който се предпочита разпределената памет, продължава да намалява.
Въвеждането на многоядрени процесори означава, че дори мултипроцесорите с два
чипа използват разпределена памет. По-големият брой процесори също поражда
необходимостта от свързване с висока честотна лента, за което ще видим примери в Приложение F.
Процесор Процесор Процесор Процесор
Едно Едно Едно Едно

Частни
или повече нива или повече или повече или повече
кешове
на кеша нива на кеш нива на кеш нива на кеш
Споделен кеш
Главна памет I/O система
Фигура 5.1 Основна структура на централизиран мултипроцесор със споделена памет,

базиран на многоядрен чип. Множество подсистеми процесор-кеш споделят една и съща
физическа памет, обикновено с едно ниво на споделен кеш и едно или повече нива на
частен кеш за всяко ядро. Ключовото архитектурно свойство е еднаквото време за достъп
до цялата памет от всички процесори. В многочиповата версия споделеният кеш би бил
пропуснат и шината или мрежата за взаимно свързване, свързваща процесорите с
паметта, ще работи между чиповете, а не в рамките на един чип.
Многоядрени Многоядрени Многоядрени Многоядрени

MP MP MP MP
памет I/O памет I/O памет I/O памет I/O
Мрежа за взаимно свързване

MP MP MP MP
Фигура 5.2 Основната архитектура на мултипроцесор с разпределена памет през 2011 г. обикновено се състои от многоядрен
многопроцесорен чип с прикрепена памет и евентуално I/O и интерфейс към мрежа за взаимно свързване, която свързва всички възли.
Всяко процесорно ядро споделя цялата памет, въпреки че времето за достъп до
заключващата памет, прикрепена към чипа на ядрото, ще бъде много по-бърза от времето за достъп до отдалечени памети.
използват се насочени мрежи (т.е. комутатори) и индиректни мрежи (обикновено многоизмерни

мрежи).
Разпределянето на паметта между възлите увеличава честотната лента
и намалява латентността към локалната памет. DSM мултипроцесор също се нарича
NUMA (неравномерен достъп до паметта), тъй като времето за достъп зависи от
местоположение на дума с данни в паметта. Основните недостатъци на DSM са следните
предаването на данни между процесорите става малко по-сложно и
DSM изисква повече усилия в софтуера, за да се възползва от увеличеното
честотна лента на паметта, предоставена от разпределени памети. Тъй като всички многоядрени
мултипроцесори с повече от един процесорен чип (или сокет) използват
разпределена памет, ще обясним работата на мултипроцесорите с разпределена памет от тази
гледна точка.
И в двете SMP и DSM архитектури се осъществява комуникация между нишки
чрез споделено адресно пространство, което означава, че може да се направи препратка към паметта
от всеки процесор до всяко място в паметта, ако приемем, че има правилен достъп
права. Терминът споделена памет , свързан както със SMP, така и с DSM, се отнася до
фактът, че адресното пространство е споделено.
За разлика от тях клъстерите и компютрите от складовия мащаб от следващата глава

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

по същество няма комуникация с работещи паралелни програми, където нишките трябва
комуникирайте, за да изпълните задачата. Две важни пречки, и двете обясними с
Законът на Амдал прави паралелната обработка предизвикателна. Степента, в която тези
препятствията са трудни или лесни се определя както от приложението, така и от
архитектура.
Първото препятствие е свързано с ограничения паралелизъм, наличен в програмите,

а второто произтича от относително високата цена на комуникациите. Ограниченията в наличния
паралелизъм затрудняват постигането на добро ускоряване във всеки
паралелен процесор, както показва нашият първи пример.
Пример Да предположим, че искате да постигнете ускорение от 80 със 100 процесора. Каква дроб
на оригиналното изчисление може да бъде последователно?
Отговор Спомнете си от глава 1 , че законът на Амдал е
1
= -------------------------------------------------- ----------------------------------------------
Ускори Фракционно подобрено
--------------------------------------
+
(1 – фракционно подобрено )
За простота в този пример приемете, че програмата работи само в две

режими: паралелен с пълно използване на всички процесори, което е подобреният режим, или
сериен само с един използван процесор. С това опростяване, ускорението в
подобреният режим е просто броят на процесорите, докато частта от
подобреният режим е времето, прекарано в паралелен режим. Заместване в предишното
уравнение:
1
80 = -------------------------------------------------- ------------------------------------------------
Дроб паралелен
---------------------------------
100 (1 – дроб паралелен + )
Опростяването на това уравнение дава:
0,8 + × 1
Дроб паралелен × 80 (1 – дроб паралелен ) =
– × = 1
80 79.2 Дробпаралел
80 1 –
Дроб паралелен = --------------
79.2
Дроб паралел = 0,9975
По този начин, за да се постигне ускорение от 80 със 100 процесора, само 0,25% от оригинала
изчислението може да бъде последователно. Разбира се, за постигане на линейно ускорение (ускоряване на
n с n процесора), цялата програма обикновено трябва да бъде паралелна без последователна
порции. На практика програмите не работят само напълно паралелно или последователно
режим, но често използват по-малко от пълния набор от процесори, когато работят
в паралелен режим.
Второто голямо предизвикателство при паралелната обработка включва голямото забавяне

на отдалечен достъп в паралелен процесор. В съществуващите мултипроцесори със споделена памет
комуникацията на данни между отделни ядра може да струва 35 до 50 часовника
цикли и между ядра на отделни чипове от 100 тактови цикъла до as
до 500 или повече тактови цикъла (за големи мултипроцесори), в зависимост
относно комуникационния механизъм, вида на мрежата за взаимно свързване и
мащаб на мултипроцесора. Ефектът от дългите забавяния на комуникацията е ясен
съществено. Нека разгледаме един прост пример.
Пример Да предположим, че имаме приложение, работещо на 32-процесорен мултипроцесор, който

има 200 ns време за обработка на препратка към отдалечена памет. За това приложение,
приемете, че всички препратки, с изключение на тези, включващи комуникация, попадат в
йерархия на локалната памет, което е леко оптимистично. Процесорите са блокирали на a
отдалечена заявка, а тактовата честота на процесора е 3,3 GHz. Ако базовият CPI (приемайки, че всички
препратки са попаднали в кеша) е 0,5, колко по-бърз е мултипроцесорът, ако няма комуникация, спрямо
ако 0,2% от инструкциите включват
справка за отдалечена комуникация?
Отговор По-лесно е първо да се изчислят тактовите цикли на инструкция. Ефективният CPI

за мултипроцесора с 0,2% отдалечени референции е
= CPI Скорост на
CPI Base ×
+ отдалечена заявка Стойност на отдалечена заявка
× за отдалечена заявка
+ Разходи
= 0,5 0,2%
Цената на отдалечената заявка е
Разходи за отдалечен достъп 200 ns

---------------------------------------------- = --------------- =
666 цикъла
Време на цикъл 0,3 ns
Следователно можем да изчислим CPI:
CPI = 0,5 + 1,2 = 1,7
Мултипроцесорът с всички локални препратки е 1,7/0,5 = 3,4 пъти по-бърз. в

на практика анализът на ефективността е много по-сложен, тъй като някои части
на некомуникационните препратки ще липсват в локалната йерархия и
времето за отдалечен достъп няма една постоянна стойност. Например цената
на отдалечена препратка може да бъде доста по-лошо, тъй като спорът е причинен от
много препратки, които се опитват да използват глобалното свързване, могат да доведат до увеличаване
закъснения.
Тези проблеми – недостатъчен паралелизъм и дълга латентност на дистанционна комуникация –

са двете най-големи предизвикателства при използването на мултипроцесори.
Проблемът с неадекватния паралелизъм на приложението трябва да бъде атакуван предимно в
софтуер с нови алгоритми, които предлагат по-добра паралелна производителност, както и чрез
софтуерни системи, които максимизират времето, прекарано в пълно изпълнение
допълнение от процесори. Намаляването на въздействието на дългата отдалечена латентност

може да бъде атакувано както от архитектурата, така и от програмиста. Например, можем да
намалим честотата на отдалечения достъп или с хардуерни механизми, като кеширане на
споделени данни, или със софтуерни механизми, като преструктуриране на данните, за да
направим повече достъпи локални. Можем да се опитаме да толерираме забавянето, като
използваме многопоточност (обсъдено по-късно в тази глава) или като използваме предварително
извличане (тема, която разглеждаме подробно в Глава 2).
Голяма част от тази глава се фокусира върху техники за намаляване на въздействието на
дългото забавяне на отдалечената комуникация. Например, раздели 5.2 до 5.4 обсъждат как
кеширането може да се използва за намаляване на честотата на отдалечен достъп, като
същевременно се поддържа съгласуван изглед на паметта. Раздел 5.5 обсъжда синхронизацията,
която, тъй като по своята същност включва междупроцесорна комуникация и също може да
ограничи паралелизма, е основно потенциално тясно място. Раздел 5.6 обхваща техники за
скриване на латентност и модели за последователност на паметта за споделена памет. В
Приложение I се фокусираме основно върху по-мащабни мултипроцесори, които се използват
предимно за научна работа. В това приложение разглеждаме естеството на такива приложения
и предизвикателствата при постигането на ускорение с десетки до стотици
процесори.
5.2 Централизирани архитектури със споделена памет
Наблюдението, че използването на големи, многостепенни кешове може значително да намали

изискванията за честотна лента на паметта на процесора, е ключовото прозрение, което мотивира
мултипроцесорите с централизирана памет. Първоначално всички тези процесори бяха
едноядрени и често заемаха цяла платка, а паметта беше разположена на споделена шина.
При по-нови процесори с по-висока производителност изискванията към паметта са надхвърлили
възможностите на разумните шини и последните микропроцесори директно свързват паметта
към един чип, който понякога се нарича задна страна или шина на паметта, за да се разграничи
от шината, използвана за свързване към I/O. Достъпът до локалната памет на чип, независимо
дали за I/O операция или за достъп от друг чип, изисква преминаване през чипа, който „притежава“
тази памет. По този начин достъпът до паметта е асиметричен: по-бърз към локалната памет и по-
бавен към отдалечената памет. В многоядрената памет тази памет се споделя между всички ядра
на един чип, но асиметричният достъп до паметта на едно многоядрено от паметта на друго
остава.
Машините със симетрична споделена памет обикновено поддържат кеширане както на

споделени, така и на лични данни. Личните данни се използват от един процесор, докато
споделените данни се използват от множество процесори, като по същество осигуряват
комуникация между процесорите чрез четене и запис на споделените данни. Когато частен
елемент се кешира, местоположението му се прехвърля в кеша, намалявайки средното време за
достъп, както и необходимата честотна лента на паметта. Тъй като никой друг процесор не
използва данните, поведението на програмата е идентично с това в еднопроцесорния процесор.
Когато споделените данни се кешират, споделената стойност може да бъде копирана в множество
кеша. В допълнение към намаляването на латентността на достъпа и необходимата честотна лента на паметт
осигурява намаляване на конкуренцията, която може да съществува за споделени елементи от данни, които са
се четат от множество процесори едновременно. Кеширането на споделени данни, обаче, въвежда нов
проблем: кохерентност на кеша.
Какво представлява кохерентността на мултипроцесорния кеш?
За съжаление, кеширането на споделени данни въвежда нов проблем, защото изгледът
паметта, държана от два различни процесора, е чрез техните индивидуални кешове,
което, без никакви допълнителни предпазни мерки, може в крайна сметка да види две различни стойности.
Фигура 5.3 илюстрира проблема и показва как два различни процесора
може да има две различни стойности за едно и също местоположение. Тази трудност е като цяло
наричан проблем с кохерентността на кеша. Забележете, че проблемът с кохерентността
съществува, защото имаме както глобално състояние, дефинирано основно от основната памет, така и
локално състояние, дефинирано от отделните кешове, които са лични за всеки
процесорно ядро. По този начин, в многоядрен, където може да се сподели известно ниво на кеширане
(например L3), докато някои нива са лични (например L1 и L2), то
проблемът с кохерентността все още съществува и трябва да бъде разрешен.
Неофициално бихме могли да кажем, че една паметова система е кохерентна, ако някой прочете a
елемент от данни връща последната записана стойност на този елемент от данни. Тази дефиниция, макар и
интуитивно привлекателна, е неясна и опростена; реалността е много
по-сложни. Тази проста дефиниция съдържа два различни аспекта на паметта
поведение на системата, като и двете са критични за писане на правилни програми за споделена памет.
Първият аспект, наречен кохерентност, определя какви стойности могат да бъдат върнати
четене. Вторият аспект, наречен последователност, определя кога е написана стойност
ще бъде върнат чрез четене. Нека първо разгледаме кохерентността.
Системата на паметта е кохерентна, ако
1. Четене от процесор P към местоположение X, което следва запис от P към X, с не
записи на X от друг процесор, възникващи между записа и четенето от
P, винаги връща стойността, записана от P.
памет
Съдържание на Съдържание на съдържание за
Време Събитие кеша за процесор A кеша за процесор B местоположение X
0 1
1 Процесор А чете X 1 1
2 Процесор B чете X 1 1 1
3 Процесор A съхранява 0 1 0
0вX
Фигура 5.3 Проблемът с кохерентността на кеша за едно място в паметта (X), четене и
написани от два процесора (A и B). Първоначално приемаме, че нито един кеш не съдържа
променливата и че X има стойност 1. Ние също така приемаме кеш за запис; кешът за обратно
записване добавя някои допълнителни, но подобни усложнения. След като стойността на X има
е записано от A, кеша на A и паметта съдържат новата стойност, но кеша на B
не, и ако B прочете стойността на X, ще получи 1!
2. Четене от процесор към местоположение X, което следва запис от друг процесор към X, връща
записаната стойност, ако четенето и записът са достатъчно разделени във времето и няма
други записи към X между двата достъпа.
3. Записите на едно и също място се сериализират; това означава, че две записи на едно и също
място от всеки два процесора се виждат в същия ред от всички процесори. Например, ако
стойностите 1 и след това 2 са записани в местоположение, процесорите никога не могат да
прочетат стойността на местоположението като 2 и след това по-късно да го прочетат като 1.
Първото свойство просто запазва програмния ред - очакваме това свойство да е вярно дори в
еднопроцесорни процесори. Второто свойство дефинира представата за това какво означава да
имаме съгласуван изглед на паметта: Ако процесорът може непрекъснато да чете стара стойност на
данните, ясно бихме казали, че паметта е некохерентна.
Необходимостта от сериализация на запис е по-фина, но също толкова важна. Да предположим,

че не сме сериализирали записите и процесорът P1 записва място X, последвано от P2 място за
запис X. Сериализиране на записите гарантира, че всеки процесор ще види записа, извършен от P2
в даден момент. Ако не сериализираме записите, може да се окаже, че някои процесори могат първо
да видят записа на P2 и след това да видят записа на P1, поддържайки стойността, записана от P1 за
неопределено време. Най-лесният начин да се избегнат подобни трудности е да се гарантира, че
всички записи на едно и също място се виждат в същия ред; това свойство се нарича запис на
сериализация.
Въпреки че трите току-що описани свойства са достатъчни, за да осигурят съгласуваност,
въпросът кога ще се види писмена стойност също е важен. За да разберете защо, забележете, че не
можем да изискваме четенето на X незабавно да види стойността, записана за X от някой друг
процесор. Ако, например, запис на X на един процесор предшества четене на X на друг процесор за
много малко време, може да е невъзможно да се гарантира, че четенето връща стойността на
записаните данни, тъй като записаните данни може дори да не са напуснали процесора в този
момент. Въпросът кога точно написана стойност трябва да бъде видяна от читателя се дефинира от
модел на консистенция на паметта - тема, дискутирана в раздел 5.6.
Кохерентността и последователността се допълват: Кохерентността определя поведението на

четене и запис в едно и също място в паметта, докато последователността определя поведението
на четене и запис по отношение на достъп до други места в паметта. Засега направете следните
две предположения. Първо, записът не завършва (и не позволява следващото записване), докато
всички процесори не видят ефекта от това записване. Второ, процесорът не променя реда на запис
по отношение на друг достъп до паметта. Тези две условия означават, че ако процесор записва
местоположение A, последвано от местоположение B, всеки процесор, който вижда новата стойност
на B, трябва също да вижда новата стойност на A. Тези ограничения позволяват на процесора да
пренареди четенията, но принуждават процесора да завърши запис в програмен ред. Ще разчитаме
на това предположение, докато стигнем до раздел 5.6, където ще видим точно последиците от това
определение, както и алтернативите.
Основни схеми за налагане на съгласуваност
Проблемът с кохерентността за мултипроцесорите и I/O, макар и подобен по произход, има
различни характеристики, които влияят на подходящото решение. За разлика от I/O, където множеството
копия на данни са рядко събитие - трябва да се избягва, когато е възможно - програма, работеща на
множество процесори, обикновено ще има копия на едни и същи данни в
няколко кеша. В един кохерентен мултипроцесор кешовете осигуряват както миграция , така и
репликация на споделени елементи от данни.
Кохерентните кешове осигуряват миграция, тъй като елемент от данни може да бъде преместен в локален
кеш и се използва там по прозрачен начин. Тази миграция намалява както
латентност за достъп до споделен елемент от данни, който е разпределен дистанционно и честотната лента
търсене на споделената памет.
Кохерентните кешове също осигуряват репликация за споделени данни, които се съхраняват
едновременно четене, тъй като кешовете правят копие на елемента с данни в локалния
кеш памет. Репликацията намалява както забавянето на достъпа, така и конкуренцията за четене
споделен елемент от данни. Поддържането на тази миграция и репликация е от решаващо значение за
производителността при достъп до споделени данни. По този начин, вместо да се опитвате да разрешите проблема чрез
избягвайки го в софтуера, мултипроцесорите приемат хардуерно решение чрез въвеждане
протокол за поддържане на кохерентни кешове.
Протоколите за поддържане на кохерентност за множество процесори се наричат кеш
протоколи за съгласуваност. Ключът към прилагането на протокол за кохерентност на кеша е проследяването
състоянието на всяко споделяне на блок от данни. Използват се два класа протоколи,
всяка от които използва различни техники за проследяване на състоянието на споделяне:
Базирано на директория— Статусът на споделяне на конкретен блок от физическа памет се съхранява на
едно място, наречено директория . Има две много различни
видове базирана на директория кеш кохерентност. В SMP можем да използваме една централизирана
директория, свързана с паметта или друга единична сериализация
точка, като например най-външния кеш в многоядрен. В DSM това прави не
има смисъл да има една единствена директория, тъй като това би създало една точка на съперничество
и би затруднило мащабирането до много многоядрени чипове предвид изискванията за памет на
многоядрени процесори с осем или повече ядра. Разпределени директории
са по-сложни от една директория и такива проекти са обект на

Раздел 5.4.
Подслушване—Вместо да поддържа състоянието на споделяне в една директория,
всеки кеш, който има копие на данните от блок физическа памет
може да проследи състоянието на споделяне на блока. В SMP кешовете обикновено са
всички достъпни чрез някаква излъчваща среда (напр. шина свързва всяко ядро
кешира към споделения кеш или памет), а всички кеш контролери наблюдават или
преглеждат носителя, за да определят дали имат или не копие на блок
който е поискан в автобус или комутационен достъп. Snooping може да се използва и като
протокол за кохерентност за многочипов мултипроцесор и някои дизайни поддържат
протокол за подслушване върху протокол на директория във всеки многоядрен!
Протоколите за подслушване станаха популярни при мултипроцесорите, използващи микропроцесори
(едноядрени) и кешове, прикрепени към една споделена памет чрез шина.

Автобусът предостави удобна среда за излъчване за осъществяване на подслушването
протоколи. Многоядрените архитектури промениха значително картината, тъй като всички
многоядрените споделят известно ниво на кеш на чипа. По този начин някои дизайни преминаха към
използвайки протоколи за директории, тъй като режийните разходи бяха малки. За да позволи на читателя да
се запознаете и с двата типа протоколи, ние се фокусираме върху протокол за подслушване
тук и обсъдете протокол за директория, когато стигнем до DSM архитектури.
Подслушване на протоколи за съгласуваност
Има два начина за поддържане на изискването за съгласуваност, описано в предшестващото
подраздел. Един от методите е да се гарантира, че процесорът има изключителен достъп до a
елемент от данни, преди да запише този елемент. Този стил на протокол се нарича протокол за невалидна
дата на запис, защото прави невалидни други копия при запис. Това е най-много
общ протокол. Изключителният достъп гарантира, че никой друг не може да се чете или записва
копия на елемент съществуват, когато се извършва запис: Всички други кеширани копия на елемента
са обезсилени.
Фигура 5.4 показва пример на протокол за невалидност с обратно записване
тайници в действие. За да видите как този протокол осигурява съгласуваност, помислете за писане
последвано от четене от друг процесор: Тъй като записът изисква изключителен
достъп, всяко копие, съхранявано от четящия процесор, трябва да бъде обезсилено (следователно,
име на протокол). По този начин, когато се случи четене, то пропуска в кеша и се принуждава
за извличане на ново копие на данните. За запис ние изискваме процесора за запис
имат ексклузивен достъп, което не позволява на друг процесор да може да пише
Съдържание Съдържание Съдържание

Дейност на процесора Автобусна дейност на кеша на процесор А на кеша на процесор B на място в паметта X
Процесор A чете пропуск на X кеш за X 0 0
Процесор B чете пропуск на X кеш за X 0 0 0
Процесор A записва 1 Невалидност за X 1 0

към X
Процесор B чете пропуск на X кеш за X 1 1 1
Фигура 5.4 Пример за протокол за невалидност, работещ върху подслушваща шина за единичен кеш блок (X) с
кешове за обратно записване. Предполагаме, че нито един кеш първоначално не съдържа X и че стойността на X в паметта е 0.
Съдържанието на процесора и паметта показва стойността, след като дейността на процесора и шината са завършени. Празното
показва, че няма активност или няма кеширано копие. Когато настъпи втората грешка от B, процесорът A отговаря със стойността
анулиране на отговора от паметта. В допълнение, както съдържанието на кеша на B, така и съдържанието на паметта на X са
актуализиран. Тази актуализация на паметта, която се случва, когато блок стане споделен, опростява протокола, но е възможно да
се проследи собствеността и да се принуди обратното записване само ако блокът бъде заменен. Това налага въвеждането на ан
допълнително състояние, наречено „собственик“, което показва, че даден блок може да бъде споделен, но притежаващият процесор е отговорен
за актуализиране на други процесори и памет, когато промени блока или го замени. Ако многоядрен използва споделен
кеш (напр. L3), тогава цялата памет се вижда през споделения кеш; L3 действа като паметта в този пример и
кохерентността трябва да се обработва за частните L1 и L2 за всяко ядро. Именно това наблюдение накара някои дизайнери да
изберете протокол за директория в многоядрения. За да работи това, L3 кешът трябва да бъде включен (вижте страница 397).
едновременно. Ако два процесора се опитат да запишат едни и същи данни едновременно, единият от тях
печели състезанието (ще видим как ще решим кой ще спечели скоро),
което води до анулиране на копието на другия процесор. За другия процесор да
завърши своя запис, той трябва да получи ново копие на данните, които сега трябва да съдържат
актуализираната стойност. Следователно този протокол налага запис на сериализация.
Алтернативата на невалиден протокол е да актуализирате всички кеширани копия на a
елемент от данни, когато този елемент е записан. Този тип протокол се нарича запис на актуализация
или напишете протокол за излъчване. Тъй като протоколът за актуализиране на запис трябва да излъчва всички
пише в споделени кеш линии, изразходва значително повече честотна лента. За това
поради тази причина последните мултипроцесори са избрали да внедрят невалиден протокол за запис и ние
ще се съсредоточим само върху невалидните протоколи до края на главата.
Основни техники за изпълнение

Ключът към прилагането на невалиден протокол в многоядрен е използването на шината,
или друга медия за излъчване, за извършване на недействителни. В по-старите многочипови мултипроцесори
шината, използвана за кохерентност, е шината за достъп до споделена памет. В многоядрен, шината може
да бъде връзката между частните кешове (L1 и L2 в
Intel Core i7) и споделения външен кеш (L3 в i7). За да извършите анулиране,
процесорът просто получава достъп до шината и излъчва адреса, който трябва да бъде невалиден в шината.
Всички процесори непрекъснато подслушват шината, наблюдавайки
адреси. Процесорите проверяват дали адресът на шината е в техния кеш. Ако
така че съответните данни в кеша са невалидни.
Когато възникне запис в блок, който е споделен, процесорът за запис трябва
придобийте достъп до шина, за да излъчите неговата невалидност. Ако два процесора се опитат да пишат
споделени блокове по едно и също време, техните опити за излъчване на невалидна операция ще бъдат
сериализирани, когато арбитрат за шината. Първият процесор към
получаване на достъп до шина ще доведе до невалидност на всички други копия на блока, който пише. Ако
процесорите се опитват да напишат един и същ блок, сериализацията
наложено от автобуса също сериализира техните записи. Едно от последиците от тази схема е
че запис в споделен елемент от данни не може действително да завърши, докато не получи шина
достъп. Всички схеми за съгласуваност изискват някакъв метод за сериализиране на достъпа до
същия кеш блок, или чрез сериализиране на достъпа до комуникационната среда, или
друга споделена структура.
В допълнение към анулирането на оставащи копия на кеш блок, който се намира

записан в, ние също трябва да намерим елемент от данни, когато възникне пропуск в кеша. В
кеш за запис, е лесно да се намери скорошната стойност на елемент от данни, тъй като всички
записаните данни винаги се изпращат в паметта, от която най-новата стойност на
винаги може да бъде извлечен елемент от данни. (Буферите за запис могат да доведат до някои допълнителни
сложност и трябва ефективно да се третират като допълнителни записи в кеша.)
За кеша за обратно записване проблемът с намирането на най-новата стойност на данните е
по-трудно, тъй като най-новата стойност на елемент от данни може да бъде по-скоро в частен кеш
отколкото в споделения кеш или памет. За щастие, кешовете за обратно записване могат да използват същото
схема за подслушване както за пропуски в кеша, така и за записи: Всеки процесор следи
всеки адрес, поставен в споделената шина. Ако процесорът установи, че има замърсен
копие на искания кеш блок, той предоставя този кеш блок в отговор на
заявка за четене и причинява прекратяване на достъпа до паметта (или L3). Допълнителното
сложността идва от необходимостта да се извлече кеш блокът от частния кеш на друг процесор (L1 или
L2), което често може да отнеме повече време, отколкото извличането му от
L3. Тъй като кешовете за обратно записване генерират по-ниски изисквания за честотна лента на паметта,
те могат да поддържат по-голям брой по-бързи процесори. В резултат на това всички многоядрени
процесорите използват обратно записване на най-външните нива на кеша и ние ще изследваме
прилагането на кохерентност с кешове за обратно записване.
Нормалните кеш тагове могат да се използват за прилагане на процеса на подслушване и
валидният бит за всеки блок прави анулирането лесно за изпълнение. Прочетете пропуски,
независимо дали са генерирани от обезсилване или от някакво друго събитие, също са ясни, тъй като те
просто разчитат на възможността за наблюдение. За пише бихме искали
за да знаете дали други копия на блока са кеширани, защото, ако няма
други кеширани копия, тогава записът не трябва да се поставя в шината при обратно записване
кеш памет. Неизпращането на записа намалява както времето за запис, така и необходимото
честотна лента.
За да проследим дали даден кеш блок е споделен или не, можем да добавим допълнителен бит за състояние
свързани с всеки кеш блок, точно както имаме валиден бит и мръсен бит. от
добавяйки малко, показващо дали блокът е споделен, можем да решим дали a
write трябва да генерира невалиден. Когато пишете в блок в споделено състояние
се случи, кешът генерира анулиране на шината и маркира блока като
изключителен. Няма да се изпращат допълнителни анулирания от това ядро за този блок. The
ядрото с единственото копие на кеш блок обикновено се нарича собственик на кеша
блок.
Когато се изпрати невалидност, състоянието на кеш блока на собственика се променя

от споделени към несподелени (или изключителни). Ако друг процесор по-късно поиска това
кеш блок, състоянието трябва отново да се направи споделено. Тъй като нашият подслушващ кеш също
вижда пропуски, той знае кога изключителният кеш блок е бил поискан от
друг процесор и състоянието трябва да се направи споделено.
Всяка шинна транзакция трябва да проверява таговете за адрес на кеша, които потенциално биха
могли да попречат на достъпа до кеша на процесора. Един от начините за намаляване на тази намеса е
за дублиране на таговете и за проследяване на достъпа, насочен към дублиращите се тагове. Друг
подходът е да се използва директория в споделения L3 кеш; указателят показва дали
даден блок се споделя и евентуално кои ядра имат копия. С указателя
информация, невалидните могат да бъдат насочени само към тези кешове с копия на
кеш блок. Това изисква L3 винаги да има копие на всеки елемент от данни в L1 или
L2, свойство, наречено включване, към което ще се върнем в Раздел 5.7.
Примерен протокол
Протоколът за подслушване на кохерентност обикновено се реализира чрез включване на контролер с
ограничено състояние във всяко ядро. Този контролер отговаря на заявки от
процесор в ядрото и от шината (или друга излъчваща среда), променяйки
състояние на избрания кеш блок, както и използване на шината за достъп до данни или за невалидността
им. Логично, можете да мислите за отделен контролер, който да бъде свързан с
всеки блок; т.е. подслушващите операции или заявките за кеширане за различни блокове могат
продължете самостоятелно. В действителните реализации един контролер позволява множество
операции към отделни блокове да се извършват по редовен начин (т.е.
операцията може да бъде инициирана преди друга да е завършена, дори и само една
достъп до кеша или достъп до една шина е разрешен наведнъж). Освен това помнете, че
въпреки че говорим за автобус в следващото описание, всяка мрежа за взаимно свързване, която
поддържа излъчване към всички контролери за съгласуваност и свързаните с тях
личните кешове могат да се използват за прилагане на подслушване.
Простият протокол, който разглеждаме, има три състояния: невалиден, споделен и

модифициран. Споделеното състояние показва, че блокът в личния кеш е потенциално
споделено, докато модифицираното състояние показва, че блокът е актуализиран в
частен кеш; имайте предвид, че модифицираното състояние предполага , че блокът е изключителен.
Фигура 5.5 показва заявките, генерирани от ядро (в горната половина на таблицата)
Състояние
на адресирано Тип
Източник на заявка кеш блок кеш действие Функция и обяснение
Прочетете хит Процесор Споделен или Нормално попадение Прочетете данни в локалния кеш.
модифициран
Прочетете пропуск Процесорът е невалиден Нормална пропуск Поставете прочетена пропуск в автобуса.
Прочетете липсва Процесор Споделен Пропускане на конфликт на заместващ адрес: пропуск на четене на място в автобуса.
Прочетете липсва Процесорът е модифициран Конфликт на заместващ адрес: блок за обратно записване, след което поставете пропуснатото четене в автобуса.
Запис на хит Процесор Модифициран Нормален хит Запис на данни в локалния кеш.
Напишете хит Процесор Споделен Съгласуваност Поставете невалиден в автобуса. Тези операции често се наричат надграждане
или пропуски на собственост , тъй като те не извличат данните, а само променят
състоянието.
Напишете пропуск Невалиден процесор Нормална пропуск Поставете пропуск пропуск в автобуса.
Напишете мис Процесор Споделен Пропускане на конфликт на заместващ адрес: пропуск на запис на място в автобуса.
Пишете пропуск Процесор Модифициран Пропуск при конфликт на заместващ адрес: блок за обратно записване, след което поставете пропуск за запис в
шина.
Прочетете Miss Bus Споделено Не се предприемат действия

Разрешаване на споделен кеш или памет за обслужване на пропуснато четене.
Прочетете Miss Bus Променен Съгласуваност Опит за споделяне на данни: поставете кеш блок в шина и променете състоянието на
споделено.
Невалидност на автобуса Споделено Съгласуваност Опит за запис на споделен блок; анулирайте блока.
Пишете Miss Bus Споделено Съгласуваност Опит за запис на споделен блок; анулирайте кеш блока.
Пишете Miss Bus Променен Съгласуваност Опит за запис на блок, който е изключителен другаде; запишете обратно кеш блока и
направете състоянието му невалидно в локалния кеш.
Фигура 5.5 Механизмът за кохерентност на кеша получава заявки както от процесора на ядрото, така и от споделения
автобус и отговаря на тях въз основа на типа заявка, дали тя удря или пропуска в локалния кеш и състоянието
на локалния кеш блок, посочен в заявката. Четвъртата колона описва типа действие на кеша като нормално
хит или пропуск (същото, което би видял еднопроцесорен кеш), замяна (пропуск при заместване на еднопроцесорен кеш) или
кохерентност (необходима за поддържане на кохерентност на кеша); нормално или заместващо действие може да предизвика кохерентно действие
в зависимост от състоянието на блока в други кешове. За пропуски за четене, пропуски, пропуски при запис или недействителни, подслушвани от
bus, се изисква действие само ако адресите за четене или запис съвпадат с блок в локалния кеш и блокът е валиден.
както и идващите от автобуса (в долната половина на таблицата). Този протокол е за кеш

за обратно записване, но лесно се променя, за да работи за кеш за запис чрез повторно
интерпретиране на модифицираното състояние като изключително състояние и
актуализиране на кеша при записи по нормалния начин за кеш за записване. Най-често
срещаното разширение на този основен протокол е добавянето на изключително
състояние, което описва блок, който е немодифициран, но се съхранява само в един частен кеш.
Ние описваме това и други разширения на страница 362.
Когато в шината се постави невалидност или пропуск на запис, всички ядра, чиито
частни кешове имат копия на кеш блока, го обезсилват. За пропуск на запис в кеш за
обратно записване, ако блокът е изключителен само в един частен кеш, този кеш също
записва обратно блока; в противен случай данните могат да бъдат прочетени от споделения кеш
или памет.
Фигура 5.6 показва диаграма на преход в крайно състояние за единичен частен кеш
блок, използващ протокол за анулиране на запис и кеш за обратно записване. За простота,
трите състояния на протокола се дублират, за да представят преходи, базирани на заявки
на процесор (отляво, което съответства на горната половина на таблицата на Фигура 5.5),
за разлика от преходи, базирани на заявки за шина (вдясно, което съответства на долната
половина на таблицата на фигура 5.5). Удебеленият шрифт се използва за разграничаване
на действията на автобуса, за разлика от условията, от които зависи преходът на
състоянието. Състоянието във всеки възел представлява състоянието на избрания частен
кеш блок, посочен от процесора или заявката за шината.
Всички състояния в този кеш протокол биха били необходими в еднопроцесорен
кеш, където те биха съответствали на невалидните, валидните (и чистите) и мръсните
състояния. Повечето от промените в състоянието, обозначени с дъги в лявата половина
на Фигура 5.6 , биха били необходими в еднопроцесорен кеш с обратно записване, с
изключение на невалидността при записване в споделен блок. Промените в състоянието,
представени от дъгите в дясната половина на Фигура 5.6, са необходими само за
кохерентност и изобщо няма да се появят в еднопроцесорен кеш контролер.
Както бе споменато по-рано, има само една крайна машина за кеш, със стимули,
идващи или от свързания процесор, или от шината. Фигура 5.7 показва как преходите на
състоянието в дясната половина на Фигура 5.6 се комбинират с тези в лявата половина
на фигурата, за да образуват единична диаграма на състоянието за всеки кеш блок.
За да разберете защо работи този протокол, обърнете внимание, че всеки валиден

кеш блок е или в споделено състояние в един или повече частни кеша, или в изключително
състояние в точно един кеш. Всеки преход към изключителното състояние (което се
изисква от процесора да записва в блока) изисква невалидност или пропуск на запис да
бъдат поставени в шината, което кара всички локални кешове да направят блока невалиден.
Освен това, ако някой друг локален кеш е имал блока в ексклузивно състояние, този
локален кеш генерира обратно записване, което доставя блока, съдържащ желания адрес.
И накрая, ако възникне пропуск при четене в шината към блок в изключително състояние,
локалният кеш с изключителното копие променя състоянието си на споделено.
Действията в сиво на Фигура 5.7, които обработват пропуски при четене и запис в
шината, по същество са подслушващият компонент на протокола. Друго свойство, което
се запазва в този протокол и в повечето други протоколи, е, че всеки блок памет в
споделеното състояние е винаги актуален във външния споделен кеш (L2 или L3,
Удар при четене на процесора
Напишете мис за този блок
Невалидност за този
Споделено
блок
Невалиден Четене на процесора Споделено
(само за четене) Невалиден
Поставете прочетена мис в автобуса (Само за четене)
Пропуснато
четене на
CPU запис четене на

процесора
процесора
Поставете
прочетена мис в автобуса

ваМ
бтаосстяи п
в
аз
пътсод
н
асеуо
Пропуснат запис на процесора достъп до паметта

Блок за обратно записване; прекъсвам
Пропуснато четене на процесора Блок за обратно записване
ан
ер
текм
енавастъ п
Поставете прочетена мис в автобуса
ир
к
втса
;еноан лаБ
опб оз
Място
Поставете невалидно при зана
запис писане в автобуса
CPU на шина
Напишете мис за
този блок
Прочетете пропуск
за този блок
Кеширайте преходите на състоянието въз основа
Преходи на състоянието на кеша въз
Ексклузивно Изключителен на заявки от шината
основа на заявки от процесора
(четене/запис) (чети пиши)
Пропуснат запис на процесора
Кеш блок за обратно записване
Място за писане в автобуса
Успешен запис на CPU
Фигура 5.6 Протокол за невалидност на запис, кохерентност на кеша за частен кеш за обратно записване, показващ състоянията
и преходите на състоянията за всеки блок в кеша. Състоянията на кеша са показани в кръгове, като всеки достъп, разрешен от
локалния процесор без преход на състояние, е показан в скоби под името на състоянието. Стимулът, причиняващ промяна на
състоянието, е показан на дъгите на прехода в нормален тип и всички действия на автобуса, генерирани като част от прехода
на състоянието, са показани на дъгата на прехода с удебелен шрифт. Стимулиращите действия се прилагат към блок в личния
кеш, а не към конкретен адрес в кеша. Следователно, пропуск при четене на блок в споделеното състояние е пропуск за този
кеш блок, но за различен адрес. Лявата страна на диаграмата показва преходи на състояния въз основа на действията на
процесора, свързан с този кеш; дясната страна показва преходи въз основа на операции в автобуса. Пропуск при четене в
изключително или споделено състояние и пропуск при запис в изключително състояние възникват, когато адресът, поискан от
процесора, не съвпада с адреса в локалния кеш блок. Такъв пропуск е стандартен пропуск за заместване на кеша. Опит за запис
на блок в споделено състояние генерира невалиден. Всеки път, когато възникне шинна транзакция, всички частни кешове,
които съдържат кеш блока, указан в шинната транзакция, предприемат действието, продиктувано от дясната половина на
диаграмата. Протоколът предполага, че паметта (или споделен кеш) предоставя данни за пропуск на четене за блок, който е чист във всички локални
В действителните реализации тези два комплекта диаграми на състоянието се комбинират. На практика има много фини
вариации на невалидните протоколи, включително въвеждането на изключително немодифицирано състояние по отношение
на това дали процесор или памет предоставя данни при пропуск. В многоядрен чип споделеният кеш (обикновено L3, но
понякога L2) действа като еквивалент на паметта, а шината е шината между частните кешове на всяко ядро и споделения кеш,
който от своя страна се свързва с паметта.
или памет, ако няма споделен кеш), което опростява изпълнението. Всъщност няма
значение дали изходното ниво от частните кешове е споделен кеш или памет; ключът е,
че всички достъпи от ядрата преминават през това ниво.
Въпреки че нашият прост кеш протокол е правилен, той пропуска редица усложнения,
които правят внедряването много по-трудно. Най-важното от тях е, че протоколът приема,
че операциите са атомарни - тоест , една операция може да бъде извършена по такъв
начин, че да не може да се случи никаква намесна операция. Например, описаният
протокол предполага, че пропуските при запис могат да бъдат открити, да се получи шината и
Удар при
четене на
процесора
Напишете мис за този блок
Невалидност за този блок
Споделено
Невалиден Четене на процесора
(само за четене)
Поставете прочетена мис в автобуса
CPU запис
Блок за обратно записване
CPU запис четене на
процесора
Поставете прочетена
мис в автобуса
ир
к
втса лаБ
опб оз
ваМ
п
в
аз
еноан
бтаосстяи
н
Данни за обратно записване; място прочетиПропуснат
мис в автобуса
асеуо
запис на процесора
Прочетете пропуск за блок
Пропуснато четене на процесора
Поставете невалиден в автобуса

Напишете пропуск
за блок
Изключителен
(чети пиши)
Данни за обратно записване
Фигура 5.7 Диаграма на състоянието на кохерентност на кеша с преходите на състоянието,

предизвикани от локалния процесор, показан в черно, и от дейностите на шината, показани в сиво.
Както на фигура 5.6, дейностите при преход са показани с удебелен шрифт.
получавате отговор като едно атомарно действие. В действителност това не е вярно. Всъщност
дори пропускът при четене може да не е атомен; след откриване на пропуск в L2 на многоядрен
процесор, ядрото трябва да арбитрира за достъп до шината, свързваща към споделения L3.
Неатомичните действия въвеждат възможността протоколът да блокира, което означава, че
достига състояние, в което не може да продължи. Ще разгледаме тези усложнения по-късно в
този раздел и когато разглеждаме DSM дизайните.
При многоядрените процесори съгласуваността между процесорните ядра е изцяло
реализирана на чип, като се използва или подслушващ, или обикновен протокол за централна
директория. Много двупроцесорни чипове, включително Intel Xeon и AMD Opteron, поддържат
многочипови мултипроцесори, които могат да бъдат изградени чрез свързване на
високоскоростен интерфейс (наречен съответно Quickpath или Hypertransport). Тези връзки
от следващо ниво не са просто разширения на споделената шина, но използват различен
подход за взаимно свързване на многоядрени ядра.
Мултипроцесор, изграден с множество многоядрени чипове, ще има архитектура с

разпределена памет и ще се нуждае от механизъм за кохерентност между чиповете над и отвъд
този в чипа. В повечето случаи се използва някаква форма на схема на директория.
Разширения към основния протокол за съгласуваност
Протоколът за съгласуваност, който току-що описахме, е прост протокол с три състояния и често
се споменава с първата буква на състоянията, което го прави MSI (променен, споделен, невалиден)
протокол. Има много разширения на този основен протокол, които споменахме в заглавията на
фигурите в този раздел. Тези разширения се създават чрез добавяне на допълнителни състояния
и транзакции, които оптимизират определени поведения, което вероятно води до подобрена
производителност. Две от най-често срещаните разширения са
1. MESI добавя състоянието Exclusive към основния MSI протокол, за да покаже кога кеш блокът
се намира само в един кеш, но е чист. Ако даден блок е в състояние E, той може да бъде
записан без генериране на невалидни, което оптимизира случая, когато блок се чете от един
кеш, преди да бъде записан от същия кеш. Разбира се, когато възникне пропуск при четене
на блок в състояние E, блокът трябва да се промени в състояние S, за да се поддържа
кохерентност. Тъй като всички последващи достъпи се подслушват, е възможно да се
поддържа точността на това състояние. По-специално, ако друг процесор издаде пропуск
при четене, състоянието се променя от изключително на споделено. Предимството на
добавянето на това състояние е, че последващо записване в блок в изключително състояние
от същото ядро не трябва да придобива достъп до шина или да генерира невалидност, тъй
като е известно, че блокът е изключително в този локален кеш; процесорът просто променя
състоянието на модифицирано. Това състояние се добавя лесно чрез използване на бита,
който кодира кохерентното състояние като ексклузивно състояние и използване на мръсния
бит, за да покаже, че блокът е модифициран. Популярният протокол MESI, който е кръстен
на четирите състояния, които включва (променен, изключителен, споделен и невалиден),
използва тази структура. Intel i7 използва вариант на протокол MESI, наречен MESIF, който
добавя състояние (Напред), за да посочи кой процесор за споделяне трябва да отговори на
заявка.
Той е предназначен да подобри производителността в организации с разпределена памет.
2. MOESI добавя състоянието Owned към протокола MESI, за да покаже, че асоциираният блок е
собственост на този кеш и е остарял в паметта. В протоколите MSI и MESI, когато има опит за
споделяне на блок в модифицирано състояние, състоянието се променя на споделено (както
в оригиналния, така и в новия кеш за споделяне) и блокът трябва да бъде записан обратно в
паметта. В протокол MOESI блокът може да бъде променен от модифицирано в притежавано
състояние в оригиналния кеш, без да го записва в паметта. Други кешове, които наскоро
споделят блока, поддържат блока в споделено състояние; състоянието O, което притежава
само оригиналният кеш, показва, че копието на основната памет е остаряло и че определеният
кеш е собственик. Собственикът на блока трябва да го предостави при пропуск, тъй като
паметта не е актуална и трябва да запише блока обратно в паметта, ако бъде заменен. AMD
Opteron използва протокола MOESI.
Следващият раздел разглежда производителността на тези протоколи за нашия паралел

и мултипрограмирани натоварвания; стойността на тези разширения към основен протокол ще
стане ясна, когато разгледаме производителността. Но преди да направим това, нека
разгледайте накратко ограниченията при използването на симетрична структура на паметта
и схема за подслушване на съгласуваност.
Ограничения в мултипроцесорите със симетрична споделена

памет и Snooping Protocols
Тъй като броят на процесорите в мултипроцесор расте или като памет

изискванията на всеки процесор растат, всеки централизиран ресурс в системата може
станете тясно място. Използване на връзка с по-голяма честотна лента, налична в чипа
и споделен L3 кеш, който е по-бърз от паметта, дизайнерите са успели
поддържа четири до осем високопроизводителни ядра по симетричен начин. Такъв
подходът е малко вероятно да мащабира много повече от осем ядра и няма да работи нито веднъж
множество многоядрени се комбинират.
Проследяването на честотната лента в кеш паметта също може да се превърне в проблем, тъй като всеки
кешът трябва да проверява всеки пропуск, поставен в автобуса. Както споменахме, дублирането
на етикетите е едно решение. Друг подход, възприет в някои
последните многоядрени, е да поставите директория на нивото на най-външния кеш.
Директорията изрично показва на кой кеш на процесора има копия
всеки елемент в най-външния кеш. Това е подходът, който Intel използва при i7 и
Серия Xeon 7000. Имайте предвид, че използването на тази директория не елиминира пречките
поради споделена шина и L3 между процесорите, но е много по-просто
за внедряване на схемите за разпределени директории, които ще разгледаме
Раздел 5.4.
Как може един дизайнер да увеличи честотната лента на паметта, за да поддържа повече или
по-бързи процесори? За увеличаване на комуникационната честотна лента между процесорите
и памет, дизайнерите са използвали множество шини, както и мрежи за взаимно свързване, като
напречни ленти или малки мрежи от точка до точка. В такива дизайни,
система с памет (основна памет или споделен кеш) може да бъде конфигурирана в
множество физически банки, така че да се увеличи ефективната честотна лента на паметта, докато
запазване на равномерно време за достъп до паметта. Фигура 5.8 показва как такава система
може да изглежда, ако е реализиран с едночипов многоядрен. Въпреки че такива
може да се използва подход, който позволява повече от четири ядра да бъдат взаимно свързани
единичен чип, той не се мащабира добре до многочипов мултипроцесор, който използва
многоядрени градивни блокове, тъй като паметта вече е прикрепена към отделните многоядрени
чипове, а не централизирана.
AMD Opteron представлява друга междинна точка в спектъра
между протокол за наблюдение и протокол на директория. Паметта е пряко свързана с
всеки многоядрен чип и могат да бъдат свързани до четири многоядрени чипа. Системата е
NUMA, тъй като локалната памет е малко по-бърза. Opteron прилага своя протокол за съгласуваност,
използвайки връзките от точка до точка, за да излъчва до
три други чипа. Тъй като междупроцесорните връзки не се споделят, единствените
начинът, по който процесорът може да разбере кога невалидна операция е приключила, е чрез an
изрично признание. По този начин протоколът за съгласуваност използва излъчване за
Процесор Процесор Процесор Процесор
Едно Едно Едно Едно

или повече или повече или повече или повече
нива на нива на нива на нива на
частен кеш частен кеш частен кеш частен кеш
Банка 0 Банка 1 Банка 2 Банка 3

споделен споделен споделен споделен
кеш кеш кеш кеш
памет I/O система
Фигура 5.8 Многоядрен едночипов мултипроцесор с равномерен достъп до паметта

чрез банков споделен кеш и използване на мрежа за взаимно свързване вместо
шина.
намира потенциално споделени копия, като протокол за подслушване, но използва

потвържденията за подреждане на операции, като протокол за директория. Тъй като
локалната памет е само малко по-бърза от отдалечената памет в реализацията на Opteron,
някои софтуери третират мултипроцесора Opteron като имащ еднаква памет
достъп.
Протоколът за кохерентност на подслушващия кеш може да се използва без

централизирана шина, но все пак изисква да се направи излъчване, за да се подслушват
отделните кешове при всяко пропускане към потенциално споделен кеш блок. Този
кохерентен трафик на кеша създава друго ограничение на мащаба и скоростта на
процесорите. Тъй като кохерентният трафик не се влияе от по-големите кешове, по-
бързите процесори неизбежно ще претоварят мрежата и способността на всеки кеш да
отговаря на заявки за наблюдение от всички останали кешове. В раздел 5.4 разглеждаме
протоколи, базирани на директории, които елиминират необходимостта от излъчване към
всички кешове при пропуск. Тъй като скоростта на процесора и броят на ядрата на
процесор се увеличават, повече дизайнери вероятно ще изберат такива протоколи, за да
избегнат ограничението за излъчване на протокол за наблюдение.
Внедряване на Snooping Cache Coherence

Дяволът е в детайлите.
Класическа поговорка
Когато написахме първото издание на тази книга през 1990 г., последното ни „Putting It All
Together” беше 30-процесорен, едношинен мултипроцесор, използващ Snoop-базиран
съгласуваност; шината имаше капацитет от малко над 50 MB/sec, което нямаше да бъде
достатъчно честотна лента на шината, за да поддържа дори едно ядро на Intel i7 през 2011 г.! Когато ние
написа второто издание на тази книга през 1995 г., наскоро се появиха първите мултипроцесори за
кохерентност на кеша с повече от една шина и ние добавихме
приложение, описващо прилагането на шпиониране в система с множество
автобуси. През 2011 г. повечето многоядрени процесори, които поддържат само едночипов
мултипроцесор, избраха да използват структура на споделена шина, свързваща се или със споделен
памет или споделен кеш. За разлика от тях, всяка многоядрена многопроцесорна система
който поддържа 16 или повече ядра, използва връзка, различна от една шина, и
дизайнерите трябва да се изправят пред предизвикателството да внедрят подслушване без опростяване
на автобус за сериализиране на събития.
Както казахме по-рано, основното усложнение при реалното прилагане на

протоколът за подслушване на кохерентност, който описахме, е този, който записва и надгражда
пропуските не са атомарни в нито един нов мултипроцесор. Етапите на откриване на a
липса на запис или надстройка, комуникация с другите процесори и памет,
получаване на най-новата стойност за пропуск на запис и гарантиране, че всички невалидни дати са
обработени и актуализирането на кеша не може да се направи, сякаш са взели
единичен цикъл.
В единичен многоядрен чип тези стъпки могат да бъдат направени ефективно атомарни чрез
арбитриране първо на шината към споделения кеш или памет (преди промяна на кеша
състояние) и не освобождаване на автобуса, докато не приключат всички действия. Как може процесорът
да знае кога всички невалидни са завършени? В някои многоядрени, единичен
линия се използва за сигнализиране, когато са получени и са получени всички необходими невалидни
се обработва. Следвайки този сигнал, процесорът, генерирал пропуска, може
освободи автобуса, знаейки, че всички необходими действия ще бъдат завършени преди всички
дейност, свързана със следващата мис. Като държите автобуса изключително по време на тези
стъпки, процесорът ефективно прави отделните стъпки атомарни.
В система без шина трябва да намерим някакъв друг метод за създаване на
стъпки в мис атомик. По-специално, трябва да гарантираме, че два процесора, които се опитват да
напишат един и същ блок по едно и също време, ситуация, която се нарича състезание ,
са строго подредени: Едно записване се обработва и предшества, преди да започне следващото.
Няма значение кой от двама пише в състезание печели състезанието, само че има
само един победител, чиито съгласувани действия са завършени първи. В подслушване
система, гарантираща, че състезанието има само един победител, се постига чрез използване на
излъчване за всички пропуски, както и някои основни свойства на мрежата за взаимно свързване. Тези
свойства, заедно с възможността за рестартиране на обработката на пропуски на
губещият в състезание, са ключовете за прилагане на кохерентност на шпионския кеш без шина. Ние
обясняваме подробностите в Приложение I.
Възможно е да се комбинират подслушване и директории, а няколко дизайна използват

подслушване в многоядрени и директории между множество чипове или, обратното, директории
в многоядрени и подслушване между множество чипове.
5.3 Производителност на симетрични мултипроцесори

със споделена памет
В многоядрен, използващ протокол за проследяване на кохерентност, няколко различни явления

се комбинират, за да определят производителността. По-специално, цялостната производителност
на кеша е комбинация от поведението на трафика на пропускане на еднопроцесорния кеш и
трафика, причинен от комуникация, което води до анулиране и последващи пропуски на кеша.
Промяната на броя на процесорите, размера на кеша и размера на блока може да повлияе на
тези два компонента на честотата на пропуски по различни начини, което води до цялостно
поведение на системата, което е комбинация от двата ефекта.
Приложение B разделя честотата на пропуски на еднопроцесор в класификацията на трите

C (капацитет, задължително и конфликт) и дава представа както за поведението на приложението,
така и за потенциалните подобрения на дизайна на кеша. По подобен начин пропуските, които
възникват от междупроцесорната комуникация, които често се наричат пропуски на
кохерентност, могат да бъдат разделени на два отделни източника.
Първият източник са така наречените истински пропуски при споделяне , които възникват
от предаването на данни чрез механизма за кохерентност на кеша. В протокол, базиран на
невалидност, първият запис от процесор в споделен кеш блок причинява невалидност, за да се
установи собствеността върху този блок. Освен това, когато друг процесор се опита да прочете
модифицирана дума в този кеш блок, възниква пропуск и полученият блок се прехвърля. И
двете пропуски се класифицират като истински пропуски при споделяне, тъй като произтичат
директно от споделянето на данни между

процесори.
Вторият ефект, наречен фалшиво споделяне, възниква от използването на алгоритъм за
кохерентност, базиран на невалидност, с един валиден бит на кеш блок. Фалшиво споделяне
възниква, когато блок е невалиден (и последваща препратка причинява пропуск), защото в
блока е записана някаква дума, различна от тази, която се чете. Ако записаната дума действително
се използва от процесора, който е получил невалидната дата, тогава препратката е истинска
препратка за споделяне и би причинила пропуск независимо от размера на блока. Ако обаче
думата, която се записва, и думата, която се чете, са различни и невалидността не води до
комуникиране на нова стойност, а само причинява допълнителен пропуск в кеша, тогава това е
фалшив пропуск при споделяне. При фалшиво пропускане на споделяне блокът се споделя, но
нито една дума в кеша всъщност не се споделя и пропускът няма да възникне, ако размерът на
блока е една дума.
Следният пример изяснява моделите на споделяне.
Пример Да приемем, че думите x1 и x2 са в един и същи кеш блок, който е в споделено състояние в кешовете
както на P1, така и на P2. Приемайки следната последователност от събития, идентифицирайте
всяко пропускане като истинско споделяне, фалшиво споделяне или попадение.
Всеки пропуск, който би възникнал, ако размерът на блока беше една дума, се определя като верен
споделяне мис.
време P1 P2
1 Напишете x1
2 Прочетете x2
3 Напишете x1
4 Напишете х2
5 Прочетете x2
Отговор Ето класификациите по времева стъпка:
1. Това събитие е истинска грешка при споделяне, тъй като x1 беше прочетено от P2 и трябва да бъде
обезсилен от Р2.
2. Това събитие е фалшив пропуск на споделяне, тъй като x2 е анулиран от записа на x1

в P1, но тази стойност на x1 не се използва в P2.
3. Това събитие е фалшива грешка при споделяне, тъй като блокът, съдържащ x1, е маркиран
споделено поради четене в P2, но P2 не прочете x1. Кеш блокът, съдържащ x1, ще бъде в
споделено състояние след четене от P2; изисква се пропуск при запис

за получаване на изключителен достъп до блока. В някои протоколи това ще бъде обработено
като заявка за надграждане, която генерира невалидна шина, но не прехвърля
кеш блока.
4. Това събитие е фалшиво пропускане на споделяне по същата причина като стъпка 3.
5. Това събитие е истинска грешка при споделяне, тъй като стойността, която се чете, е записана от P2.
Въпреки че ще видим ефектите от истински и фалшиви пропуски при споделяне в търговски

натоварвания, ролята на пропуските на кохерентност е по-значима за тясно свързани приложения,
които споделят значителни количества потребителски данни. Разглеждаме техните
ефекти подробно в Приложение I, когато разглеждаме ефективността на паралел
научна натовареност.
Търговско натоварване
В този раздел разглеждаме поведението на системата с памет на четири процесора

мултипроцесор със споделена памет при стартиране на реклама с общо предназначение
натовареност. Изследването, което изследваме, е направено с четирипроцесорна система Alpha
през 1998 г., но остава най-изчерпателното и проницателно изследване на производителността на
мултипроцесор за такива натоварвания. Резултатите бяха събрани
или на AlphaServer 4100, или с помощта на конфигурируем симулатор, моделиран след това
AlphaServer 4100. Всеки процесор в AlphaServer 4100 е Alpha
21164, който издава до четири инструкции на такт и работи на 300 MHz.
Въпреки че тактовата честота на процесора Alpha в тази система е значително

по-бавни от процесорите в системи, проектирани през 2011 г., основната структура на
система, състояща се от процесор с четири броя и кеш йерархия на три нива,
е много подобен на многоядрения Intel i7 и други процесори, както е показано в
Фигура 5.9. По-специално, Alpha кешовете са малко по-малки, но пропускат
времената също са по-ниски от тези на i7. По този начин поведението на системата Алфа
трябва да предостави интересна представа за поведението на съвременните многоядрени
дизайни.
Работното натоварване, използвано за това проучване, се състои от три приложения:
1. Работно натоварване за онлайн обработка на транзакции (OLTP), моделирано след TPC-B

(който има поведение на паметта, подобно на по-новия си братовчед TPC-C, описан в
Глава 1) и използване на Oracle 7.3.2 като основна база данни. Натовареността
се състои от набор от клиентски процеси, които генерират заявки и набор от сървъри
които се справят с тях. Процесите на сървъра отнемат 85% от времето на потребителя, с
останалите отиват за клиентите. Въпреки че I/O латентността е скрита от
внимателна настройка и достатъчно заявки, за да поддържа процесора зает, сървърните
процеси обикновено блокират за I/O след около 25 000 инструкции.
2. Работно натоварване на система за подпомагане на вземането на решения (DSS), базирана на TPC-D, по-старият братовчед
на силно използвания TPC-E, който също използва Oracle 7.3.2 като основен
база данни. Работното натоварване включва само 6 от 17 заявки за четене в TPC-D,
Ниво на кеша Характеристика Алфа 21164 Intel i7
L1 Размер 8 KB I/8 KB D 32 KB I/32 KB D
Асоциативност Директно картографирано 4-посочен I/8-посочен D
Размер на блока 32 Б 64 Б
Пропусната дузпа 7 10
L2 Размер 96 KB 256 KB
Асоциативност 3-посочен 8-посочен
Пропусната дузпа 21 35
L3 Размер 2 MB 2 MB на ядро
Асоциативност Директно картографирано 16-пътен
Пропусната дузпа 80 ~100
Фигура 5.9 Характеристиките на йерархията на кеша на Alpha 21164, използвана в това

проучване и Intel i7. Въпреки че размерите са по-големи и асоциативността е по-висока
i7, наказанията за пропуски също са по-високи, така че поведението може да се различава леко. За
Например, от Приложение B, можем да изчислим процентите на пропуски на по-малката Alpha L1
кеш като 4,9% и 3% за по-големия i7 L1 кеш, така че средното наказание за пропуск на L1 за референтен
номер е 0,34 за Alpha и 0,30 за i7. И двете системи имат високо наказание (125
цикли или повече) за трансфер, необходим от частен кеш. i7 също споделя своя L3
сред всички ядра.
% Време
Бенчмарк % Време потребителски режим % Време ядро бездействие на процесора
OLTP 71 18 11
DSS (средно за всички 87 4 9

заявки)
AltaVista >98 <1 <1
Фигура 5.10 Разпределението на времето за изпълнение в търговските натоварвания. The

OLTP бенчмарк има най-голямата част както от времето на ОС, така и от времето на неактивност на процесора
(което е I/O време на изчакване). DSS бенчмаркът показва много по-малко време за ОС, тъй като го прави
по-малко I/O, но все пак повече от 9% време на неактивност. Обширната настройка на търсенето на AltaVista
двигателят е ясен при тези измервания. Данните за това натоварване са събрани от
Barroso, Gharachorloo и Bugnion [1998] на четирипроцесорен AlphaServer 4100.
въпреки че 6-те заявки, разгледани в бенчмарка, обхващат диапазона от дейности
в целия бенчмарк. За да се скрие I/O латентността, паралелизмът се използва и за двете
в рамките на заявки, където се открива паралелизъм по време на процес на формулиране на заявка,
и между заявки. Блокирането на повиквания е много по-рядко, отколкото в
OLTP бенчмарк; 6-те заявки са средно около 1,5 милиона инструкции преди
блокиране.
3. Бенчмарк за търсене в уеб индекс (AltaVista), базиран на търсене на картирана в памет версия на базата
данни на AltaVista (200 GB). Вътрешният контур е тежък
оптимизиран. Тъй като структурата на търсене е статична, синхронизирането е малко
необходими сред нишките. AltaVista беше най-популярното уеб търсене
двигател преди пристигането на Google.
Фигура 5.10 показва процентите на времето, прекарано в потребителски режим, в ядрото,
и в цикъла на празен ход. Честотата на I/O увеличава както времето на ядрото, така и
време на празен ход (вижте OLTP записа, който има най-голямото съотношение I/O към изчисление).
AltaVista, която картографира цялата база данни за търсене в паметта и е била
широко настроен, показва най-малкото време на ядро или неактивност.
Измервания на ефективността на търговското работно натоварване
Започваме с разглеждане на цялостното изпълнение на процесора за тези показатели на
четирипроцесорна система; както беше обсъдено на страница 367, тези показатели включват значително I/
O време, което се игнорира при измерванията на процесорното време. Ние групираме
шестте DSS заявки като един бенчмарк, отчитащ средното поведение. The
ефективният CPI варира в широки граници за тези сравнителни показатели, от CPI от 1,3 за уеб търсенето
на Alta-Vista, до среден CPI от 1,6 за DSS работното натоварване, до 7,0 за
OLTP работно натоварване. Фигура 5.11 показва как времето за изпълнение се разделя на
изпълнение на инструкции, време за достъп до кеша и паметта на системата и други застоявания
(които са предимно сергии за конвейерни ресурси, но също така включват превод lookaside
буфер (TLB) и неправилно предвиждане на клонове). Въпреки че изпълнението на DSS

100%
Други щандове
90% Достъп до паметта

L3 достъп
L2 достъп
80% Изпълнение на инструкцията
70%
60%
50%
телц
н
еинтеон заП
р
ера
ъоп
м и
н
вз
40%
30%
20%
10%
0%
OLTP DSS AltaVista
Фигура 5.11 Разбивка на времето за изпълнение за трите програми (OLTP, DSS и AltaVista) в търговското
работно натоварване. DSS числата са средните за шест различни заявки. CPI варира в широки граници
от ниско ниво от 1,3 за AltaVista, до 1,61 за DSS заявките, до 7,0 за OLTP. (Поотделно, DSS заявките
показват диапазон на CPI от 1,3 до 1,9.)
„Други спирания“ включват спирания на ресурсите (внедрени с капани за повторение на 21164),
неправилно предвиждане на разклонения, бариера на паметта и пропуски на TLB. За тези сравнителни
показатели спиранията на тръбопровода, базирани на ресурси, са доминиращият фактор. Тези данни
съчетават поведението на достъпа на потребителя и ядрото. Само OLTP има значителна част от
достъпите до ядрото и достъпите до ядрото обикновено се държат по-добре от достъпите на
потребителите! Всички измервания, показани в този раздел, са събрани от Barroso, Gharachorloo и Bugnion [1998].
и работните натоварвания на AltaVista са разумни, производителността на работното натоварване на

OLTP е много лоша, поради лоша производителност на йерархията на паметта.
Тъй като работното натоварване на OLTP изисква най-много от системата с памет с голям брой
скъпи L3 пропуски, ние се фокусираме върху изследването на влиянието на размера на L3 кеша, броя
на процесорите и размера на блока върху OLTP бенчмарка. Фигура 5.12 показва ефекта от увеличаване
на размера на кеша, използвайки двупосочни набори асоциативни кешове, което намалява големия
брой пропуски на конфликти. Времето за изпълнение е подобрено, тъй като L3 кешът расте поради
намаляването на пропуските на L3. Изненадващо, почти цялата печалба се получава при преминаване
от 1 на 2 MB, с малко допълнителна печалба отвъд това, въпреки факта, че пропуските в кеша все още
са причина за значителна загуба на производителност с 2 MB и 4 MB кеш памети. Въпросът е защо?
За да разберем по-добре отговора на този въпрос, трябва да определим кои фактори допринасят
за процента на пропуски L3 и как те се променят с нарастването на кеша L3. Фигура 5.13 показва тези
данни, показвайки броя на циклите за достъп до паметта, предоставени на инструкция от пет
източника. Двата най-големи източника на цикли за достъп до L3 памет с 1 MB L3 са инструкция и
капацитет/конфликт
100
90 Празен
PAL код
80 Достъп до паметта
L2/L3 достъп до кеша
70 Изпълнение на инструкцията
60
50
лм
изниелнае
онареи ърп
м заН
еор и
вз
40
30
20
10
0
1 2 4 8
Размер на L3 кеша (MB)
Фигура 5.12 Относителната производителност на натоварването на OLTP, тъй като размерът на L3 кеша, който
е зададен като асоциативен двупосочен набор, нараства от 1 MB на 8 MB. Времето на неактивност също
нараства с увеличаване на размера на кеша, което намалява някои от печалбите в производителността. Този
растеж се дължи на факта, че при по-малко спирания на системата на паметта са необходими повече сървърни
процеси, за да се покрие I/O латентността. Работното натоварване може да бъде пренастроено, за да се
увеличи балансът изчисление/комуникация, като се държи под контрол времето на неактивност. PAL кодът е
набор от последователности от специализирани инструкции на ниво OS, изпълнявани в привилегирован
режим; пример е TLB манипулаторът на пропуски.
3.25
2,75 Инструкция
Капацитет/конфликт
2.5 Задължително
Фалшиво споделяне
2.25
Истинско споделяне
1,75
1.5
лтм
яицактуитре ааЦ
н
кси и
н
пз
1.25
0,75
0,5
0,25
0
1 2 4 8
Размер на кеша (MB)
Фигура 5.13 Допринасящите причини за изместване на цикъла на достъп до паметта с увеличаване на размера
на кеша. Кешът L3 се симулира като асоциативен двупосочен набор.
3
Задължително
2.5 Фалшиво споделяне
Истинско споделяне
1.5
лтм
яицактуитре ааЦ
н
кси и
н
пз
1
0,5
0
1 2 4 6 8
Брой процесори
Фигура 5.14 Приносът към циклите на достъп до паметта се увеличава с броя на процесорите
се увеличава главно поради увеличеното истинско споделяне. Задължителното пропуска леко
увеличаване, тъй като всеки процесор сега трябва да обработва повече задължителни пропуски.
пропуски. С по-голям L3 тези два източника се свиват до второстепенни сътрудници.
За съжаление пропуските на задължителното, фалшивото и истинското споделяне не се влияят от по-голям L3. По
този начин, при 4 MB и 8 MB, истинските пропуски на споделяне генерират преобладаващата част от пропуските;
липсата на промяна в истинското споделяне
пропуски води до ограничени намаления на общия процент на пропуски при увеличаване
размерът на L3 кеша над 2 MB.
Увеличаването на размера на кеша елиминира повечето от еднопроцесорните пропуски, докато
оставяйки пропуските на мултипроцесора недокоснати. Как става увеличаването на процесора
count влияе върху различни видове пропуски? Фигура 5.14 показва тези данни, приемайки a
базова конфигурация с 2 MB двупосочен асоциативен L3 кеш. Както бихме могли
очаквайте увеличението на истинския процент на пропуски при споделяне, което не се компенсира от
всяко намаляване на пропуските на еднопроцесора води до цялостно увеличаване на циклите на достъп до
паметта за инструкция.
Последният въпрос, който разглеждаме, е дали увеличаването на размера на блока – кое
трябва да намали скоростта на инструкциите и студените пропуски и, в рамките на ограниченията, също да намали
процентът на пропуски на капацитет/конфликт и вероятно истинският процент на пропуски при споделяне – е полезно
за това натоварване. Фигура 5.15 показва броя пропуски на 1000 инструкции
тъй като размерът на блока е увеличен от 32 на 256 байта. Увеличаване на размера на блока от
32 до 256 байта засягат четири от компонентите на честотата на пропускане:
Истинският процент на пропуски при споделяне намалява с повече от коефициент 2, което показва
някаква местност в истинските модели на споделяне.
Задължителният процент пропуски значително намалява, както бихме очаквали.

16
15 Инструкция
14 Капацитет/конфликт
13 Фалшиво споделяне
12 Истинско споделяне
11
10
9
8
0П
а
н
тос0р
ииицкксуурп0 и
н
1
7
6
5
4
3
2
1
0
32 64 128 256
Размер на блок (байтове)
Фигура 5.15 Броят пропуски на 1000 инструкции намалява стабилно с увеличаване на размера
на блока на L3 кеша, което прави добър случай за размер на L3 блок от поне 128 байта. L3 кеш
паметта е 2 MB, двупосочен набор асоциативен.
Липсите на конфликт/капацитет показват малко намаление (коефициент от 1,26 в сравнение с коефициент
от 8 увеличение на размера на блока), което показва, че пространствената локализация не е висока в
еднопроцесорните пропуски, които възникват с L3 кешове, по-големи от 2 MB.
Степента на пропуски при фалшиво споделяне, макар и малка в абсолютно изражение, почти се удвоява.
Липсата на значителен ефект върху процента на пропускане на инструкции е стряскаща. Ако имаше
кеш само за инструкции с това поведение, бихме заключили, че пространствената локализация е много
лоша. В случай на смесен L2 кеш, други ефекти, като например конфликти инструкции-данни, също могат да
допринесат за високия процент пропуски на кеша инструкции за по-големи блокове. Други проучвания са
документирали ниската пространствена локализация в потока от инструкции на големи бази данни и OLTP
работни натоварвания, които имат много кратки основни блокове и кодови последователности със
специално предназначение. Въз основа на тези данни наказанието за пропуск за по-голям размер на блок
L3, както и за 32-байтов размер на блок L3, може да бъде изразено като множител на наказанието за 32-
байтов размер на блок:
Наказание за пропуск спрямо

Размер на блока наказанието за пропуск на 32-байтов блок
64 байта 1.19
128 байта 1.36
256 байта 1.52

С модерните DDR SDRAM, които правят достъпа до блокове бърз, тези числа изглеждат постижими,
особено при размер на блока от 128 байта. Разбира се, трябва да се тревожим и за ефектите от
увеличения трафик към паметта и възможното съревнование за паметта с други ядра. Този последен
ефект може лесно да отмени печалбите, получени от подобряване на производителността на един
процесор.
Мултипрограмиране и натоварване на ОС
Следващото ни проучване е многопрограмирано работно натоварване, състоящо се както от

потребителска дейност, така и от дейност на операционната система. Използваното работно
натоварване е две независими копия на фазите на компилиране на бенчмарка Andrew, бенчмарк,
който емулира среда за разработка на софтуер. Фазата на компилиране се състои от паралелна версия
на командата "make" на Unix, изпълнявана с помощта на осем процесора. Работното натоварване
работи за 5,24 секунди на осем процесора, създавайки 203 процеса и изпълнявайки 787 дискови заявки
на три различни файлови системи. Работното натоварване се изпълнява със 128 MB памет и не се
извършва дейност по страниране.
Работното натоварване има три отделни фази: компилиране на бенчмаркове, което включва
значителна изчислителна дейност; инсталиране на обектните файлове в библиотека; и премахване на
обектните файлове. Последната фаза е изцяло доминирана от I/O и само два процеса са активни (по
един за всеки от циклите). В средната фаза I/O също играе основна роля и процесорът до голяма степен
е неактивен. Цялостното работно натоварване е много по-системно и I/O интензивно от силно
настроеното търговско натоварване.
За измерванията на натоварването приемаме следните памет и I/O системи:
Кеш за инструкции от ниво 1—32 KB, двупосочен набор асоциативен с 64-байтов

блок, време за попадение от 1 тактов цикъл.
Кеш на данни от ниво 1—32 KB, асоциативен двупосочен набор с 32-байтов блок, време за попадение
от 1 тактов цикъл. Ние променяме L1 кеша за данни, за да изследваме ефекта му върху поведението
на кеша.
Кеш от ниво 2—1 MB унифициран, асоциативен двупосочен набор със 128-байтов блок, време за
попадение от 10 тактови цикъла.
Основна памет—единична памет на шина с време за достъп от 100 часа

цикли.
Дискова система—фиксирано забавяне на достъпа от 3 ms (по-малко от нормалното, за да се намали времето на неактивност).
Фигура 5.16 показва как времето за изпълнение се разделя за осемте процесора, използвайки
току-що изброените параметри. Времето за изпълнение е разделено на четири компонента:
1. Idle—Изпълнение в неактивен цикъл на режим на ядрото
2. Потребител—Изпълнение в потребителски код
3. Синхронизация—Изпълнение или изчакване на променливи за синхронизиране 4. Ядро—
Изпълнение в операционната система, която не е нито неактивна, нито в синхронизация

достъп
Потребител Ядро Синхронизация Процесорът е

екзекуция екзекуция изчакайте
неактивен (изчаква I/O)
Инструкциите са изпълнени 27% 3% 1% 69%
Време за изпълнение 27% 7% 2% 64%
Фигура 5.16 Разпределението на времето за изпълнение в мултипрограмирания паралел

„направи“ работно натоварване. Високата част от времето на неактивност се дължи на латентността на диска, когато само един от
осемте процесора са активни. Тези данни и последващите измервания за това

натоварването са събрани със системата SimOS [Rosenblum et al. 1995]. Реалното
проучванията и събирането на данни са направени от M. Rosenblum, S. Herrod и E. Bugnion от
Станфордски университет.
Това мултипрограмно натоварване има значителна загуба на производителност на кеша на инструкциите,

поне за операционната система. Процентът на пропуски в кеша на инструкциите в операционната система за 64-
размер на байтовия блок, двупосочен набор асоциативен кеш варира от 1,7% за 32 KB

кеш на 0,2% за 256 KB кеш. Пропуските в кеша на инструкциите на ниво потребител са
приблизително една шеста от скоростта на ОС, в разнообразието от размери на кеша. Това частично
отчита факта, че въпреки че потребителският код се изпълнява девет пъти повече
инструкции като ядрото, тези инструкции отнемат само около четири пъти повече време от
по-малкия брой инструкции, изпълнявани от ядрото.
Изпълнение на мултипрограмирането и работното натоварване на ОС
В този подраздел разглеждаме производителността на кеша на мултипрограмирания
работно натоварване, тъй като размерът на кеша и размерът на блока се променят. Заради разликите
между поведението на ядрото и това на потребителските процеси, ние ги запазваме
два компонента са разделени. Не забравяйте обаче, че потребителските процеси се изпълняват
повече от осем пъти повече инструкции, така че общият процент на пропуски се определя основно от процента
на пропуски в потребителския код, който, както ще видим, често е една пета от процента на пропуски на ядрото.
Въпреки че потребителският код изпълнява повече инструкции, поведението на операционната система
може да причини повече пропуски в кеша, отколкото потребителските процеси по две причини
извън по-големия размер на кода и липсата на локалност. Първо, ядрото инициализира всички страници
преди да ги разпределите на потребител, което значително увеличава задължителните
компонент на степента на пропуски на ядрото. Второ, ядрото всъщност споделя данни и
по този начин има нетривиален кохерентен пропуск. Обратно, потребителските процеси причиняват пропуски
на кохерентност само когато процесът е планиран на различен процесор и това
компонентът на процента пропуски е малък.
Фигура 5.17 показва скоростта на пропускане на данни спрямо размера на кеша за данни и спрямо блока
размер за ядрото и потребителските компоненти. Увеличаването на размера на кеша за данни влияе
процентът на пропуски на потребителя повече, отколкото влияе върху процента на пропуски на ядрото. Увеличаване на блока
размерът има благоприятен ефект и за двата процента пропуски, тъй като по-голяма част от
пропуските произтичат от принудителен и капацитет, като и двата могат да бъдат потенциално

7% 10%
9%
6%
Скорост на пропуски на ядрото 8%
5% 7%
6%
4%
5%
sestiaMr
sestiaMr
3% Скорост на пропуски на ядрото
4%
2% 3%
2%
1% Процент на пропуски на потребителя
Процент на пропуски на потребителя
1%
0% 0%
32 64 128 256 16 32 64 128
Размер на кеша (KB) Размер на блок (байтове)
Фигура 5.17 Процентите на пропускане на данни за потребителя и компонентите на ядрото се държат по различен начин при увеличения на
размера на L1 кеша за данни (отляво) спрямо увеличенията на размера на L1 кеша за данни (вдясно). Увеличаването на L1 кеша за данни от
32 KB на 256 KB (с 32-байтов блок) води до намаляване на процента на пропуски на потребителя пропорционално повече от процента на
пропуски на ядрото: процентът на пропуски на ниво потребител пада с почти фактор 3, докато честотата на пропуски на ниво ядро пада само
с фактор 1,3. Степента на пропуски както за потребителя, така и за компонентите на ядрото спада стабилно, тъй като размерът на L1 блока се
увеличава (като същевременно L1 кеша се запазва на 32 KB). За разлика от ефектите от увеличаване на размера на кеша, увеличаването на
размера на блока подобрява по-значително процента на пропуски на ядрото (малко под коефициент 4 за препратките на ядрото при
преминаване от 16-байтови към 128-байтови блокове срещу малко под коефициент от 3 за потребителски препратки).
подобрени с по-големи размери на блокове. Тъй като пропуските на кохерентност са относително по-
редки, отрицателните ефекти от увеличаването на размера на блока са малки. За да разберем защо
ядрото и потребителските процеси се държат по различен начин, можем да погледнем как се държат
пропуските на ядрото.
Фигура 5.18 показва вариациите в пропуските на ядрото спрямо увеличенията на размера на

кеша и размера на блока. Пропуските са разделени на три класа: задължителни пропуски, пропуски
на кохерентност (от вярно и невярно споделяне) и пропуски на капацитет/конфликт (които включват
пропуски, причинени от намеса между операционната система и потребителския процес и между
множество потребителски процеси). Фигура 5.18 потвърждава, че за препратките към ядрото
увеличаването на размера на кеша намалява само капацитета на еднопроцесорния/честотата на
пропуски на конфликти. Обратно, увеличаването на размера на блока води до намаляване на
задължителния процент пропуски. Липсата на големи увеличения в степента на пропуски на
кохерентност, тъй като размерът на блока се увеличава, означава, че ефектите на фалшивото
споделяне вероятно са незначителни, въпреки че такива пропуски може да компенсират някои от
печалбите от намаляване на истинските пропуски на споделяне.
Ако изследваме броя на байтовете, необходими за препратка към данни, както е на Фигура 5.19,
виждаме, че ядрото има по-висок коефициент на трафик, който нараства с размера на блока. Лесно е
да разберете защо това се случва: когато преминавате от 16-байтов блок към 128-байтов блок,
процентът на пропуски пада с около 3,7, но броят на байтовете
7% 10%
9% Съгласуваност
6%
8% Задължително
5% 7%
4% 6%
5%
sestiaMr
sestiaMr
3%
4%
2% 3%
2%
1%
1%
0% 0%
32 64 128 256 16 32 64 128
Размер на кеша (KB) Размер на блок (байтове)
Фигура 5.18 Компонентите на честотата на пропускане на данни в ядрото се променят, тъй като
размерът на L1 кеша за данни се увеличава от 32 KB на 256 KB, когато работното натоварване за
мултипрограмиране се изпълнява на осем процесора. Компонентът на задължителния процент на
пропуски остава постоянен, тъй като не се влияе от размера на кеша. Компонентът на капацитета спада
с повече от коефициент 2, докато компонентът на кохерентността почти се удвоява. Увеличаването на
кохерентните пропуски възниква, защото вероятността пропускът да бъде причинен от невалидност се
увеличава с размера на кеша, тъй като по-малко записи се сблъскват поради капацитета. Както бихме
очаквали, нарастващият размер на блока на L1 кеша за данни значително намалява задължителния
процент на пропуски в препратките на ядрото. Той също така има значително влияние върху скоростта
на пропускане на капацитет, като го намалява с коефициент 2,4 в диапазона от размери на блокове.
Увеличеният размер на блока има малко намаление на кохерентния трафик, който изглежда се
стабилизира на 64 байта, без промяна в честотата на пропуски на кохерентност при преминаване към
128-байтови линии. Тъй като няма значителни намаления в степента на пропуски на кохерентност с
увеличаване на размера на блока, частта от процента на пропуски поради кохерентност нараства от около 7% до ок
прехвърлените на пропуск се увеличават с 8, така че общият трафик на пропуски се увеличава

с малко над коефициент 2. Потребителската програма също се удвоява, тъй като размерът на
блока преминава от 16 на 128 байта, но започва на много по-ниско ниво.
За многопрограмираното работно натоварване операционната система е много по-
взискателен потребител на системата с памет. Ако в работното натоварване е включена
повече ОС или подобна на ОС дейност и поведението е подобно на това, което е измерено
за това работно натоварване, ще стане много трудно да се изгради достатъчно способна система с паме
Един възможен начин за подобряване на производителността е да направим операционната
система по-добре осведомена за кеша, или чрез по-добра среда за програмиране, или чрез
помощ от програмист. Например, операционната система използва повторно паметта за
заявки, които възникват от различни системни повиквания. Въпреки факта, че повторно
използваната памет ще бъде напълно презаписана, хардуерът, който не разпознава това, ще
се опита да запази кохерентността и възможността част от кеш блок да бъде прочетена, дори
и да не е. Това поведение е аналогично на повторното използване на местоположенията на
стека при извикване на процедура. Серията IBM Power има поддръжка, за да позволи на
компилатора да посочи този тип поведение при извиквания на процедури и най-новите
3.5
Трафик на ядрото
3.0
2.5
рп
актаи нр
нм
е ап
ъ
о д
к
2.0
1.5
ев
ак
,не р
ти тм
ф
тое йр
аази
н
п
б
в
Т
1.0
Потребителски трафик
0,5
0,0
16 32 64 128
Размер на блок (байтове)
Фигура 5.19 Броят на байтовете, необходими за препратка към данни, нараства с увеличаване на
размера на блока както за ядрото, така и за потребителските компоненти. Интересно е да се
сравни тази диаграма с данните за научни програми, показани в Приложение I.
Процесорите на AMD имат подобна поддръжка. По-трудно е да се открие такова поведение от

операционната система и това може да изисква помощ от програмист, но печалбата е
потенциално още по-голяма.
ОС и търговските натоварвания поставят тежки предизвикателства за многопроцесорните
системи с памет и за разлика от научните приложения, които разглеждаме в Приложение I, те са
по-малко податливи на алгоритмично или компилаторно преструктуриране. Тъй като броят на
ядрата се увеличава, прогнозирането на поведението на такива приложения вероятно ще стане
по-трудно. Методологиите за емулация или симулация, които позволяват симулацията на
стотици ядра с големи приложения (включително операционни системи), ще бъдат от решаващо
значение за поддържането на аналитичен и количествен подход към дизайна.
5.4 Разпределена споделена памет и базирана на директория

Съгласуваност
Както видяхме в раздел 5.2, протоколът за подслушване изисква комуникация с всички кешове
при всяко пропускане на кеша, включително записи на потенциално споделени данни. Липсата
на каквато и да е централизирана структура от данни, която проследява състоянието на
кешовете, е както основното предимство на схемата, базирана на подслушване, тъй като й
позволява да бъде евтина, така и нейната ахилесова пета, когато става въпрос за мащабируемост.
Например, помислете за мултипроцесор, съставен от четири 4-ядрени многоядрени ядра,
способни да поддържат една справка за данни на такт и тактова честота от 4 GHz. От данните в
Раздел I.5 на Приложение I можем да видим, че приложенията може да изискват от 4 GB/sec до
170 GB/sec честотна лента на шината. Въпреки че кешовете в тези експерименти са
5.4 Разпределена споделена памет и базирана на директория кохерентност 379
малък, по-голямата част от трафика е кохерентен трафик, който не се влияе от размера на кеша.
Въпреки че една модерна шина може да поеме 4 GB/sec, 170 GB/sec е далеч отвъд
способност на всяка система, базирана на шина. През последните няколко години развитието на
многоядрените процесори принуди всички дизайнери да преминат към някаква форма на разпределена памет, за
поддържат изискванията за честотна лента на отделните процесори.
Можем да увеличим честотната лента на паметта и честотната лента на взаимното свързване с
разпределяне на паметта, както е показано на Фигура 5.2 на страница 348; това веднага
разделя трафика на локалната памет от трафика на отдалечената памет, намалявайки изискванията за
честотна лента на системата с памет и на мрежата за взаимно свързване.
Освен ако не премахнем необходимостта протоколът за съгласуваност да се излъчва на всеки
пропуснете кеша, разпределянето на паметта ще ни спечели малко.
Както споменахме по-рано, алтернативата на протокола за съгласуваност, базиран на подслушване,
е протокол на директория. Директория пази състоянието на всеки блок, който може
да се кешира. Информацията в директорията включва кои кешове (или колекции от
кешове) имат копия на блока, дали е мръсен и т.н. В рамките на многоядрен процесор със споделен най-
външен кеш (да речем L3) е лесно да се внедри директория
схема: Просто запазете битов вектор с размер, равен на броя на ядрата за
всеки L3 блок. Битовият вектор показва на кои частни кешове може да има копия
блок в L3 и невалидностите се изпращат само до тези кешове. Това работи перфектно за едно
многоядрено, ако L3 е включен, и тази схема е тази, която се използва в
Intel i7.
Решението на единична директория, използвано в многоядрени, дори не е мащабируемо

въпреки че избягва излъчването. Директорията трябва да бъде разпространена, но разпространението
трябва да се извърши по начин, по който протоколът за съгласуваност да знае къде да намери
информация за директорията за всеки кеширан блок памет. Очевидното решение е
за разпространение на директорията заедно с паметта, така че различна съгласуваност
заявките могат да отиват в различни директории, точно както отиват различните заявки за памет
различни спомени. Разпределената директория запазва характеристиката на
състоянието на споделяне на блок винаги е в едно известно местоположение. Този имот,
заедно с поддържането на информация, която казва какви други възли могат да бъдат
кеширането на блока е това, което позволява на протокола за кохерентност да избягва излъчването.
Фигура 5.20 показва как изглежда нашият мултипроцесор с разпределена памет с
директории, добавени към всеки възел.
Най-простите реализации на директорията свързват запис в директорията

с всеки блок памет. При такива реализации количеството информация е
пропорционално на произведението на броя на блоковете памет (където е всеки блок
същия размер като L2 или L3 кеш блок) по броя на възлите, където a
възел е единичен многоядрен процесор или малка колекция от процесори, които

прилага вътрешна съгласуваност. Това натоварване не е проблем за многопроцесорни процесори с по-
малко от няколкостотин процесора (всеки от които може да е многоядрен), тъй като натоварването на
директорията с разумен размер на блока ще бъде
поносимо. За по-големи мултипроцесори се нуждаем от методи за разрешаване на директорията
структурата да бъде ефективно мащабирана, но само системи с размер на суперкомпютър трябва
тревожи се за това.
процесор процесор процесор процесор

+ кешове + кешове + кешове + кешове
Справочник Справочник Справочник Справочник
Справочник Справочник Справочник Справочник
памет I/O памет I/O памет

памет I/O памет I/O
процесор процесор процесор процесор

+ кешове + кешове + кешове + кешове
Фигура 5.20 Към всеки възел се добавя директория, за да се реализира кохерентност на кеша в мултипроцесор с разпределена
памет. В този случай възелът се показва като единичен многоядрен чип и информацията за директорията за асоциирания
паметта може да се намира на или извън многоядрения. Всяка директория отговаря за проследяването на кешовете, които споделят
адреси на паметта на частта от паметта във възела. Механизмът за съгласуваност ще се справи както с поддръжката на
информацията на директорията, така и с всички действия за съгласуваност, необходими в многоядрения възел.
Базирани на директория протоколи за кохерентност на кеша: Основите
Точно както при протокола за подслушване, има две основни операции в директория
протоколът трябва да изпълнява: обработка на пропуск при четене и обработка на запис в споделен,
чист кеш блок. (Обработката на пропуск на запис към блок, който в момента е споделен, е a
проста комбинация от тези две.) За изпълнение на тези операции, директория
трябва да проследява състоянието на всеки кеш блок. В прост протокол тези държави биха могли
бъде следното:
Споделено—Един или повече възли имат кеширания блок и стойността в паметта

е актуален (както и във всички кешове).
Некеширан—Нито един възел няма копие на кеш блока.
Променен—Точно един възел има копие на кеш блока и той е записал

блока, така че копието на паметта е остаряло. Процесорът се нарича
собственик на блока.
В допълнение към проследяването на състоянието на всеки потенциално споделен блок памет, ние
трябва да проследи кои възли имат копия на този блок, тъй като тези копия ще трябва
да бъдат анулирани при запис. Най-лесният начин да направите това е да запазите битов вектор за
5.4 Разпределена споделена памет и базирана на директория съгласуваност 381
всеки блок памет. Когато блокът е споделен, всеки бит от вектора показва
дали съответният процесорен чип (който вероятно е многоядрен) има a
копие на този блок. Можем също да използваме битовия вектор, за да следим собственика на
блока, когато блокът е в изключително състояние. От съображения за ефективност ние също
проследяване на състоянието на всеки кеш блок в отделните кешове.
Състоянията и преходите за крайната машина във всеки кеш са идентични с
това, което използвахме за подслушващия кеш, въпреки че действията при преход са

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

на типовете съобщения, които могат да се изпращат между процесорите и директориите
с цел справяне с пропуски и поддържане на съгласуваност. Фигура 5.21 показва
типовете съобщения, изпращани между възлите. Локалният възел е възелът, където a
произхожда заявка. Началният възел е възелът, където се намира местоположението на паметта и
Съдържание
Тип съобщение Източник Дестинация на съобщението Функция на това съобщение
Прочетете мис Локален кеш Начална директория P, A Възел P има пропуск при четене на адрес A;
поискайте данни и направете P споделящ за четене.
Пишете мис Локален кеш Начална директория P, A Възел P има пропуск при запис на адрес A;
поискайте данни и направете P изключителен собственик.
Невалидност Локален кеш Начална директория A Искане за изпращане на невалидни до всички отдалечени
кешове, които кешират блока на адрес A.
Невалидност Начална директория Отдалечен кеш A Невалидно споделено копие на данни на адрес A.
Извличане
Начална директория Отдалечен кеш A Извлечете блока на адрес A и го изпратете в началната му
директория; променете състоянието на A в отдалечения

кеш на споделено.
Извличане/невалидиране Начална директория Отдалечен кеш A Извлечете блока на адрес A и го изпратете в началната му
директория; анулирайте блока в кеша.
Отговор на стойността на данните Начална директория Локален кеш д Връща стойност на данни от домашната памет.
Обратно записване на данни Отдалечен кеш Начална директория A, D Запишете обратно стойност на данни за адрес A.
Фигура 5.21 Възможните съобщения, изпратени между възлите за поддържане на съгласуваност, заедно с възела източник и местоназначение, съдържанието
(където P = номер на възел, който иска, A = адрес на искане и D = съдържание на данни),
и функцията на съобщението. Първите три съобщения са заявки, изпратени от локалния възел до дома. The
четвърто до шесто съобщение са съобщения, изпратени до отдалечен възел от дома, когато домът има нужда от данните
задоволяване на заявка за пропуск при четене или запис. Отговорите на стойността на данните се използват за изпращане на стойност от началния възел обратно към
искащ възел. Обратно записване на стойност на данни възниква по две причини: когато блок се заменя в кеша и трябва да се запише обратно в неговата
домашна памет, а също и в отговор на извличане или извличане/невалидност на съобщения от домашната. Пиша обратно
стойността на данните всеки път, когато блокът стане споделен, опростява броя на състоянията в протокола, тъй като всяко мръсно
блокът трябва да е ексклузивен и всеки споделен блок винаги да е достъпен в домашната памет.
запис в указателя на пребиваване на адрес. Физическото адресно пространство е статично разпределено, така
че възелът, който съдържа паметта и директорията за дадено физическо
адресът е известен. Например, битовете от висок ред могат да предоставят номера на възела, докато битовете
от нисък ред осигуряват отместването в паметта на този възел.
Локалният възел може да бъде и началният възел. Директорията трябва да бъде достъпна, когато
началният възел е локалният възел, тъй като копия могат да съществуват в трети възел, наречен
отдалечен възел .
Отдалечен възел е възелът, който има копие на кеш блок, независимо дали е изключителен
(в който случай това е единственото копие) или споделено. Отдалеченият възел може да бъде същият като
или локалния възел, или началния възел. В такива случаи основният протокол не го прави
промяна, но междупроцесорните съобщения могат да бъдат заменени с вътрешнопроцесорни
съобщения.
В този раздел приемаме прост модел на последователност на паметта. За да минимизираме вида на
съобщенията и сложността на протокола, ние правим
предположението, че съобщенията ще бъдат получени и ще бъдат обработени в същия ред
изпращат се. Това предположение може да не е вярно на практика и може да доведе до допълнителни
усложнения, някои от които разглеждаме в раздел 5.6 , когато обсъждаме
модели на последователност на паметта. В този раздел използваме това предположение, за да гарантираме
че невалидните съобщения, изпратени от възел, се зачитат, преди да бъдат предадени нови съобщения,
точно както предположихме в дискусията за прилагане на протоколи за шпиониране. Като
направихме в случая с подслушване, пропускаме някои подробности, необходими за прилагането на
протокол за съгласуваност. По-специално, сериализирането на пише и знаейки това
недействителните за завършен запис не са толкова прости, колкото при механизма за наблюдение, базиран на
излъчване. Вместо това се изискват изрични потвърждения в
отговор за писане на пропуски и анулиране на заявки. Ние обсъждаме тези въпроси в
повече подробности в Приложение I.
Примерен протокол за директория
Основните състояния на кеш блок в базиран на директория протокол са точно
като тези в шпионски протокол, а състоянията в директорията също са аналогични на тези, които показахме
по-рано. Така можем да започнем с прости диаграми на състоянието

които показват преходите на състоянието за отделен кеш блок и след това прегледайте
диаграма на състоянието за записа в директорията, съответстващ на всеки блок в паметта. Като
в случая на подслушване тези диаграми на прехода на състоянието не представляват всички
подробности за протокол за съгласуваност; обаче действителният контролер е силно зависим
върху редица детайли на мултипроцесора (свойства за доставка на съобщения, структури за буфериране и т.н.).
В този раздел представяме основните диаграми на състоянието на протокола. Заплетените проблеми, свързани
с прилагането на тези диаграми на прехода на състоянието
са разгледани в Приложение I.
Фигура 5.22 показва действията на протокола, на които отговаря отделен кеш.
Използваме същата нотация като в последния раздел, като заявките идват отвън
възелът в сиво и действията в удебелен шрифт. Преходите на състоянието за отделен кеш

са причинени от пропуски при четене, пропуски при запис, анулиране и заявки за извличане на
данни; Фигура 5.22 показва тези операции. Индивидуален кеш също генерира пропуски при
четене, пропуски при запис и невалидни съобщения, които се изпращат до началната директория.
Пропуските при четене и запис изискват отговори на стойността на данните и тези събития чакат
отговори, преди да променят състоянието. Познаването кога анулирането е завършено е отделен
проблем и се обработва отделно.
Невалидност
Споделено
Невалиден Четене на процесора
Изпратете прочетено съобщение
Обратно записване на данни четене на

CPU запис
процесора
Прочетете мис
Обратно записване на данни; прочети мис
Извличане Изпращане на съобщение за липса
пбааО
ирн
тсан
еноанви н
дз
Пропуснато четене на процесора

иа
ен ещ
нщ сп
аарб аИ
ъ
ози
а н
лзс
Изпращане на невалидно съобщение
Извличане
на невалидни
Променен
(четене/запис)

Обратно записване на данни
Пишете мис
Фигура 5.22 Диаграма на прехода на състоянието за отделен кеш блок в система, базирана
на директория. Заявките от локалния процесор са показани в черно, а тези от домашната
директория са показани в сиво. Състоянията са идентични с тези в случая с подслушване и
транзакциите са много сходни, с изрични заявки за невалидност и обратно записване, които
заместват пропуските за запис, които преди са били излъчвани в автобуса. Както направихме
за подслушващия контролер, приемаме, че опитът за запис на споделен кеш блок се третира
като пропуск; на практика такава транзакция може да се третира като заявка за собственост
или заявка за надграждане и може да достави собственост, без да се изисква извличането
на кеш блока.
Работата на диаграмата на прехода на състоянието за кеш блок на Фигура 5.22 е по същество същата,
както е за случая на подслушване: Състоянията са идентични и стимулът е почти идентичен. Операцията за
пропуск на запис, която е била излъчена по шината (или друга мрежа) в схемата за наблюдение, се заменя
от операциите за извличане на данни и обезсилване, които се изпращат избирателно от контролера на
директорията. Подобно на протокола за подслушване, всеки кеш блок трябва да бъде в изключително
състояние, когато е написан, и всеки споделен блок трябва да е актуален в паметта. В много многоядрени
процесори най-външното ниво в кеша на процесора се споделя между ядрата (както е L3 в Intel i7, AMD
Opteron и IBM Power7), а хардуерът на това ниво поддържа съгласуваност между частните кеши на всеки
ядро на същия чип, използвайки или вътрешна директория, или подслушване. По този начин механизмът
за многоядрена кохерентност на чипа може да се използва за разширяване на кохерентността между по-
голям набор от процесори чрез просто взаимодействие с най-външния споделен кеш.
Тъй като този интерфейс е на ниво L3, спорът между процесора и заявките за кохерентност е по-малък
проблем и дублирането на таговете може да бъде избегнато.
В протокол, базиран на директория, директорията реализира другата половина на протокола за
съгласуваност. Съобщение, изпратено до директория, предизвиква два различни типа действия:
актуализиране на състоянието на директорията и изпращане на допълнителни съобщения за удовлетворяване
на заявката. Състоянията в директорията представляват трите стандартни състояния за блок; за разлика от
схемата за наблюдение, обаче, състоянието на директорията показва състоянието на всички кеширани
копия на блок памет, а не за единичен кеш блок.
Блокът памет може да бъде декеширан от който и да е възел, да бъде кеширан в множество възли и да
бъде четен (споделен) или да бъде кеширан изключително и с възможност за запис в точно един възел. В
допълнение към състоянието на всеки блок, директорията трябва да проследява набора от възли, които
имат копие на блок; ние използваме набор, наречен Sharers, за да изпълним тази функция. В мултипроцесори
с по-малко от 64 възела (всеки от които може да представлява четири до осем пъти повече процесори), този
набор обикновено се запазва като битов вектор.
Заявките за директория трябва да актуализират набора Sharers и също така да прочетат набора, за да
извършат обезсилвания.
Фигура 5.23 показва действията, предприети в директорията в отговор на получените съобщения.
Директорията получава три различни заявки: пропуск при четене, пропуск при запис и обратно записване
на данни. Съобщенията, изпратени в отговор от директорията, са показани с удебелен шрифт, докато
актуализирането на набора Споделящи е показано с удебелен курсив.
Тъй като всички стимулационни съобщения са външни, всички действия се показват в сиво.
Нашият опростен протокол предполага, че някои действия са атомарни, като искане на стойност и
изпращането й до друг възел; реалистична реализация не може да използва това предположение.
За да разберем тези операции с директория, нека разгледаме получените заявки и предприетите
действия всяка държава. Когато един блок е в некеширано състояние, копието в паметта е текущата стойност,
така че единствените възможни заявки за този блок са
Пропускане при четене —Възелът, който иска, получава исканите данни от паметта, а възелът, който
изпраща заявката, става единственият възел за споделяне. Състоянието на блока се прави споделено.
Отговор на стойността на данните;

Споделено
Некеширано Споделящи = {P}
Пишете мис
Пишете мис
Отговор на стойността на данните
Споделящи = Споделящи + {P}

ищяледо}пPС
={
ищяледоп}С
={
нн
рстоив
атт;е оготатО
йн н
дс
Fetch; отговор на стойността на данните; Споделящи = Споделящи + {P}
Обезсилване; Споделящи = {P}; отговор на стойността на данните
Обратно
записване на данни
Изключителен
(чети пиши)
Извличане/невалидиране
Пишете
мис Отговор на стойността на данните
Споделящи = {P}
Фигура 5.23 Диаграмата на прехода на състоянието за директорията има същите

състояния и структура като диаграмата на прехода за отделен кеш. Всички действия са в
сиво, защото всички са причинени отвън. Получерът показва действието, предприето от
директорията в отговор на заявката.
Пропуснат запис —Възелът, който иска, получава стойността и става възел за споделяне.
Блокът е направен изключителен, за да покаже, че единственото валидно копие е
кеширано. Споделящи посочва самоличността на собственика.
Когато блокът е в споделено състояние, стойността на паметта е актуална, така че могат да

възникнат същите две заявки:
Пропуснато четене—на възела, който иска, се изпращат исканите данни от паметта и

искащият възел се добавя към набора за споделяне.
Пропуснат запис —Възелът, който иска, получава стойността. Всички възли в набора Shar-
ers се изпращат невалидни съобщения, а наборът Sharers трябва да съдържа
самоличността на възела, който иска. Състоянието на блока е изключително.
Когато блокът е в изключително състояние, текущата стойност на блока се съхранява в кеш

на възела, идентифициран от набора Sharers (собственикът), така че има три възможни заявки
за директория:
Пропуснато четене—на собственика се изпраща съобщение за извличане на данни, което причинява състоянието на
блокът в кеша на собственика да премине към споделен и кара собственика да
изпрати данните в директорията, където се записват в паметта и се изпращат обратно
заявеният процесор. Идентичността на искащия възел се добавя към
set Sharers, който все още съдържа самоличността на процесора, който е бил
собственик (тъй като все още има четливо копие).
Обратно записване на данни— Собственикът заменя блока и следователно трябва да записва
го обратно. Това обратно записване прави копието на паметта актуално (домашната директория по
същество става собственик), блокът вече не е кеширан и
Наборът споделящи е празен.
Пропуснете писане —блокът има нов собственик. Изпраща се съобщение до стария собственик,
карайки кеша да обезсили блока и да изпрати стойността в директорията,
от който се изпраща до искащия възел, който става новият собственик.
Sharers се задава на самоличността на новия собственик и състоянието на блока

остава изключителен.
Тази диаграма на прехода на състоянието на Фигура 5.23 е опростена, точно както беше в
калъфът за подслушване на кеша. В случай на директория, както и схема за шпиониране
реализирани с мрежа, различна от шина, нашите протоколи ще трябва да се справят с
транзакции с неатомна памет. Приложение I изследва задълбочено тези въпроси.
Протоколите на директорията, използвани в реалните мултипроцесори, съдържат допълнителни
оптимизации. По-специално, в този протокол, когато възникне пропуск при четене или запис за a
блок, който е изключителен, блокът първо се изпраща до директорията в началния възел.
Оттам се съхранява в домашната памет и също се изпраща към оригинала
искащ възел. Много от протоколите, които се използват в търговските мултипроцесори, пренасочват
данните от възела на собственика към възела, който иска, директно (както и извършване на обратно
записване към дома). Такива оптимизации често добавят сложност
чрез увеличаване на възможността за блокиране и чрез увеличаване на видовете съобщения

с което трябва да се работи.
Внедряването на схема на директория изисква решаване на повечето от същите предизвикателства,
които обсъдихме за шпионските протоколи, започвайки на страница 365. Има,
обаче, нови и допълнителни проблеми, които описваме в Приложение I. В раздел 5.8 описваме накратко
как съвременните многоядрени процесори разширяват кохерентността отвъд
единичен чип. Комбинациите от многочипова кохерентност и многоядрена кохерентност
включват и четирите възможности за подслушване/подслушване (AMD Opteron), подслушване/
директория, директория/подслушване и директория/директория!
5.5 Синхронизация: Основите

Механизмите за синхронизиране обикновено се изграждат със софтуерни процедури на потребителско ниво
които разчитат на доставени от хардуера инструкции за синхронизиране. За по-малки мултипроцесори или
ситуации с ниска конкуренция ключовата хардуерна способност е an
непрекъсваема инструкция или последователност от инструкции, способна на атомно извличане
и промяна на стойност. След това се изграждат софтуерни механизми за синхронизиране

използвайки тази възможност. В този раздел се фокусираме върху внедряването на заключване и
отключване на операции за синхронизиране. Заключването и отключването могат да се използват директно
за създаване на взаимно изключване, както и за прилагане на по-сложни механизми за синхронизиране.
В ситуации на голямо съревнование синхронизирането може да се превърне в изпълнение
тясно място, защото конкуренцията въвежда допълнителни закъснения и защото забавянето
е потенциално по-голям в такъв мултипроцесор. Ние обсъждаме как основните механизми за
синхронизиране на този раздел могат да бъдат разширени за голям брой процесори в
Приложение I.
Основни хардуерни примитиви
Ключовата способност, от която се нуждаем, за да реализираме синхронизация в мултипроцесор, е a
набор от хардуерни примитиви с възможност за атомно четене и модифициране на местоположение в
паметта. Без такава възможност разходите за изграждане на основна синхронизация
примитивите ще бъдат твърде високи и ще се увеличават с увеличаване на броя на процесорите.
Има редица алтернативни формулировки на основните хардуерни примитиви,
всички от които предоставят възможност за атомно четене и промяна на местоположение, заедно
с някакъв начин да се каже дали четенето и записът са извършени атомарно. Тези
хардуерните примитиви са основните градивни елементи, които се използват за изграждане на широк
разнообразие от операции за синхронизиране на ниво потребител, включително неща като заключвания
и бариери. Като цяло, архитектите не очакват потребителите да използват основните хардуерни примитиви,
а вместо това очакват, че примитивите ще бъдат използвани от системата
програмисти за изграждане на библиотека за синхронизация, процес, който често е сложен
и сложно. Нека започнем с един такъв хардуерен примитивен елемент и да покажем как може да бъде
използвани за изграждане на някои основни операции за синхронизация.
Една типична операция за изграждане на операции за синхронизация е атомарната
обмен, който обменя стойност в регистър със стойност в паметта. Да видиш
как да използваме това за изграждане на основна операция за синхронизация, приемем, че искаме
за изграждане на проста ключалка, където стойността 0 се използва, за да покаже, че ключалката е свободна
и 1 се използва, за да покаже, че ключалката е недостъпна. Процесор се опитва да зададе
заключване чрез обмен на 1, който е в регистър, с адреса на паметта
съответстващ на ключалката. Стойността, върната от инструкцията за обмен, е 1
ако някой друг процесор вече е поискал достъп и 0 в противен случай. В последния
случай, стойността също се променя на 1, предотвратявайки всякакъв конкурентен обмен от
също извлича 0.
Например, помислете за два процесора, всеки от които се опитва да извърши обмена едновременно:
Това състезание е прекъснато, тъй като точно един от процесорите ще изпълни
обменът първи, връщайки 0, а вторият процесор ще върне 1, когато го
прави размяната. Ключът към използването на примитива за обмен (или суап) за внедряване на
синхронизация е, че операцията е атомарна: обменът е неделим,
и два едновременни обмена ще бъдат наредени от механизмите за запис на сериализация. Невъзможно е
два процесора, които се опитват да настроят променливата за синхронизация по този начин, и двамата да
мислят, че са задали променливата едновременно.

Има редица други атомни примитиви, които могат да се използват за реализиране на

синхронизация. Всички те имат ключовото свойство, че четат и актуализират стойност на паметта по
такъв начин, че да можем да разберем дали двете операции са изпълнени атомарно или не. Една
операция, присъстваща в много по-стари мултипроцесори, е test-and-set, която тества стойност и я
задава, ако стойността премине теста. Например, можем да дефинираме операция, която тества за 0
и да зададе стойност на 1, което може да се използва по начин, подобен на начина, по който
използвахме атомен обмен. Друг примитив за атомна синхронизация е fetch-and-increment: той връща
стойността на място в паметта и я увеличава атомарно. Като използваме стойността 0, за да покажем,
че променливата за синхронизация не е заявена, можем да използваме fetch-and-increment, точно
както използвахме exchange. Има и други употреби на операции като fetch-and-increment, които ще
видим скоро.
Прилагането на една операция с атомна памет въвежда някои предизвикателства, тъй като
изисква както четене на паметта, така и запис в една непрекъсваема инструкция. Това изискване
усложнява прилагането на кохерентност, тъй като хардуерът не може да позволи никакви други
операции между четене и запис и въпреки това не трябва да блокира.
Алтернатива е да има двойка инструкции, където втората инструкция връща стойност, от която
може да се заключи дали двойката инструкции е била изпълнена, сякаш инструкциите са атомарни.
Двойката инструкции е ефективно атомарна, ако изглежда, че всички други операции, изпълнени от
който и да е процесор, са възникнали преди или след двойката. По този начин, когато една двойка
инструкции е ефективно атомарна, никой друг процесор не може да промени стойността между
двойката инструкции.
Двойката инструкции включва специално зареждане, наречено зареждане, свързано или
зареждане заключено , и специално запаметяване, наречено зареждане условно. Тези инструкции се
използват последователно: Ако съдържанието на местоположението в паметта, указано от свързаното
зареждане, се промени, преди да се появи условието за съхраняване към същия адрес, тогава
условието за съхранение е неуспешно. Ако процесорът извърши контекстно превключване между
двете инструкции, тогава условието за съхраняване също е неуспешно. Условието за съхраняване е
дефинирано да връща 1, ако е било успешно, и 0 в противен случай. Тъй като свързаното зареждане
връща първоначалната стойност и условното съхраняване връща 1 само ако успее, следната
последователност прилага атомен обмен на мястото в паметта, указано от съдържанието на R1:
опитайте: MOV R3,R4 ;mov обменна стойност

LL R2,0(R1);зареждане свързано
SC R3,0(R1); съхранява условно
BEQZ R3, опитайте; клоновият магазин е неуспешен
MOV R4,R2 ;поставете стойност на натоварване в R4
В края на тази последователност съдържанието на R4 и местоположението на паметта, посочено от

R1, са атомно разменени (пренебрегвайки всеки ефект от забавени разклонения). Всеки път, когато
процесор се намеси и промени стойността в паметта между инструкциите LL и SC, SC връща 0 в R3,
което кара кодовата последователност да опита отново.
Предимство на условния механизъм за зареждане/запаметяване е, че може да се

използва за изграждане на други примитиви за синхронизация. Например, тук е атомно
извличане и увеличаване:
опитайте: LL R2,0(R1); зареждане свързано

DADDUIR3,R2,#1 ;увеличение
SC R3,0(R1) ;съхранявайте условно
BEQZ R3, опитайте; клоновият магазин е неуспешен
Тези инструкции обикновено се изпълняват чрез следене на адреса, посочен в

инструкцията LL, в регистър, често наричан регистър на връзката. Ако възникне прекъсване
или ако кеш блокът, съответстващ на адреса в регистъра на връзката, е невалиден (например
от друг SC), регистърът на връзката се изчиства. SC инструкцията просто проверява дали
нейният адрес съвпада с този в регистъра на връзките. Ако е така, SC успява; в противен
случай се проваля. Тъй като условието за съхраняване ще се провали или след друг опит за
съхраняване към адреса, свързан със зареждането, или след изключение, трябва да се
внимава при избора на инструкциите, които се вмъкват между двете инструкции. По-
специално, безопасно могат да бъдат разрешени само инструкции за регистър-регистр; в
противен случай е възможно да се създадат ситуации на блокиране, при които процесорът
никога не може да завърши SC. В допълнение, броят на инструкциите между свързаното
зареждане и условието за съхранение трябва да бъде малък, за да се сведе до минимум
вероятността несвързано събитие или конкурентен процесор да причини чести откази на
условието за съхранение.
Внедряване на блокировки с помощта на кохерентност
След като имаме атомарна операция, можем да използваме механизмите за кохерентност на

мултипроцесора, за да реализираме спин-блокировки – блокировки , които процесорът
непрекъснато се опитва да придобие, въртяйки се в цикъл, докато успее. Spin locks се
използват, когато програмистите очакват заключването да бъде задържано за много кратко
време и когато искат процесът на заключване да бъде с ниска латентност, когато заключването е наличн
Тъй като спин заключванията свързват процесора, изчаквайки в цикъл ключалката да се
освободи, те са неподходящи при някои обстоятелства.
Най-простата реализация, която бихме използвали, ако нямаше кохерентност на кеша,
би била да запазим заключващите променливи в паметта. Процесорът може непрекъснато
да се опитва да придобие заключването, използвайки атомарна операция, да речем атомен
обмен от страница 387, и да тества дали обменът е върнал заключването като безплатно. За
да освободи заключването, процесорът просто съхранява стойността 0 към ключалката.
Ето кодовата последователност за заключване на spin lock, чийто адрес е в R1, използвайки
атомен обмен:
DADDUIR2,R0,#1
lockit: EXCHR2,0(R1) ;атомен обмен BNEZR2,lockit ;вече
заключено?
Ако нашият мултипроцесор поддържа кохерентност на кеша, можем да кешираме ключалките,

като използваме механизма за кохерентност, за да поддържаме кохерентно стойността на
заключването. Кеширането на брави има две предимства. Първо, той позволява реализация, при
която процесът на „завъртане“ (опит за тестване и придобиване на заключването в стегнат цикъл)
може да се извърши на локално кеширано копие, вместо да се изисква глобален достъп до паметта
при всеки опит за получаване на заключването. Второто предимство идва от наблюдението, че
често има локалност в достъпа до ключалки; това означава, че процесорът, който последно е
използвал заключването, ще го използва отново в близко бъдеще. В такива случаи стойността на
заключване може да се намира в кеша на този процесор, което значително намалява времето за
получаване на заключването.
Получаването на първото предимство - възможността да се върти върху локално кеширано
копие, вместо да се генерира заявка за памет за всеки опит за придобиване на заключването -
изисква промяна в нашата проста процедура за въртене. Всеки опит за обмен в цикъла директно
отгоре изисква операция за запис. Ако няколко процесора се опитват да получат заключването,
всеки ще генерира записа. Повечето от тези записи ще доведат до пропуски при запис, тъй като
всеки процесор се опитва да получи променливата за заключване в изключително състояние.
По този начин трябва да модифицираме нашата процедура за заключване на завъртане, така
че да се върти, като извършва четене на локално копие на заключване, докато успешно види, че
заключването е налично. След това се опитва да получи ключалката, като извърши операция за
размяна. Процесорът първо чете променливата за заключване, за да тества нейното състояние.
Процесорът продължава да чете и тества, докато стойността на четенето покаже, че ключалката е отключена.
След това процесорът се състезава с всички други процеси, които по подобен начин са били
„изчакващи въртене“, за да види кой може първи да заключи променливата. Всички процеси
използват инструкция за размяна, която чете старата стойност и съхранява 1 в променливата за
заключване. Единственият победител ще види 0, а губещите ще видят 1, поставен там от победителя.

(Губещите ще продължат да задават променливата на заключената стойност, но това няма значение.)
Печелившият процесор изпълнява кода след заключването и когато приключи, съхранява 0 в
заключващата променлива, за да освободи заключването, което започва състезанието отново. Ето
кода за извършване на това заключване на въртене (не забравяйте, че 0 е отключено, а 1 е
заключено):
lockit: LDR2,0(R1) ;натоварване на заключване

BNEZR2,lockit ;не е наличен-завъртане
DADDUIR2,R0,#1 ;зареждане на заключена стойност
EXCHR2,0(R1) ;размяна
BNEZR2,lockit ;разклоняване, ако заключването не е 0
Нека разгледаме как тази схема за „заключване на въртене“ използва механизмите за

кохерентност на кеша. Фигура 5.24 показва операциите на процесора и шината или директорията
за множество процеси, които се опитват да заключат променлива с помощта на атомарна размяна.
След като процесорът с ключалката съхрани 0 в ключалката, всички други кешове се анулират и
трябва да извлекат новата стойност, за да актуализират своето копие на ключалката. Един такъв
кеш първо получава копието на отключената стойност (0) и извършва размяната. Когато пропускът
на кеша на други процесори е удовлетворен, те откриват, че променливата вече е заключена, така
че трябва да се върнат към тестване и въртене.
Кохерентно състояние на
стъпка P0 P1 P2 заключване в края на стъпката Дейност с автобус/указател
1 Има заключване Започва въртене, тествайки дали Започва въртене, тествайки Споделено Пропуските на кеша за P1 и P2 са
заключване = 0 дали заключване = 0 удовлетворени и в двата реда.
Състоянието на заключване става споделено.
2 Задаване на заключване на 0 (Получено невалидно) (Получено невалидно) Изключително (P0) Записване на невалидна променлива за
заключване от P0.
3 Кеш пропуск Кеш пропуск Споделено Услуги за автобус/директория P2

пропуск в кеша; обратно
записване от P0; споделено състояние.
4 (Чака докато автобусът/ Lock = 0 тестът Споделено Кеш пропуск за P2 удовлетворен
директорията е заета) е успешен
5 Заключване = 0 Изпълнява суап, получава Споделено Кеш пропуск за P1 удовлетворен

пропуск в кеша
6 Изпълнява суап, Завършва размяната: Ексклузивно (P2) Услуги за автобус/директория P2
получава пропуск в кеша връща 0 и задава lock = 1 пропуск в кеша; генерира

невалиден; ключалката е изключителна.
7 Swap завършва и връща 1 и Въведете критичната секция Ексклузивно (P1) Услуги за автобус/директория P1
задава lock = 1 пропуск в кеша; изпраща invalidate и
генерира обратен запис от P2.
8 Завъртания, тестване дали Нито един
заключване = 0
Фигура 5.24 Стъпки на кохерентност на кеша и трафик на шина за три процесора, P0, P1 и P2. Тази цифра предполага запис
обезсилва съгласуваността. P0 започва с заключването (стъпка 1), а стойността на заключването е 1 (т.е. заключено); първоначално е изключителен
и притежаван от P0 преди да започне стъпка 1. P0 излиза и отключва ключалката (стъпка 2). P1 и P2 се състезават, за да видят кой чете
отключена стойност по време на размяната (стъпки 3 до 5). P2 печели и влиза в критичната секция (стъпки 6 и 7), докато P1's
опитът е неуспешен, така че започва да чака завъртане (стъпки 7 и 8). В реална система тези събития ще отнемат много повече от 8 часа
отметки, тъй като придобиването на автобуса и отговарянето на пропуски отнема много повече време. След като бъде достигната стъпка 8, процесът може да се повтори
с P2, в крайна сметка получаване на изключителен достъп и настройка на заключването на 0.
Този пример показва друго предимство на условното натоварване, свързано/съхранено

примитиви: Операциите за четене и запис са изрично разделени. Натоварването
свързаните не трябва да причиняват автобусен трафик. Този факт позволява следния прост код
последователност, която има същите характеристики като използваната оптимизирана версия
обмен (R1 има адреса на ключалката, LL е заменил LD и SC
замени EXCH):
lockit: LLR2,0(R1) ;зареждане свързано
BNEZR2,lockit ;не е наличен-завъртане

DADDUIR2,R0,#1 ;заключена стойност
SCR2,0(R1); съхраняване
BEQZR2,lockit ;разклоняване, ако магазинът не успее
Първият клон образува въртящия се контур; вторият клон разрешава състезания, когато
два процесора виждат наличната ключалка едновременно.
5.6 Модели на последователност на паметта: Въведение
Кохерентността на кеша гарантира, че множество процесори виждат последователен изглед на

паметта. Това не отговаря на въпроса колко последователен трябва да бъде възгледът за паметта
бъда. Под „колко последователни“ ние наистина питаме кога процесорът трябва да види стойност
който е актуализиран от друг процесор? Тъй като процесорите комуникират
чрез споделени променливи (използвани както за стойности на данни, така и за синхронизация), the
Въпросът се свежда до следното: В какъв ред процесорът трябва да наблюдава данните
пише за друг процесор? Тъй като единственият начин да „наблюдаваш написаното от друг
процесор” е чрез четене, въпросът става какви трябва да бъдат свойствата
наложени между четения и записи на различни места от различни процесори?
Въпреки че въпросът колко последователна трябва да бъде паметта изглежда прост, той е такъв
забележително сложно, както можем да видим с един прост пример. Ето два кода
сегменти от процеси P1 и P2, показани един до друг:
P1: А = 0; P2: B = 0;
..... .....
А = 1; B = 1;
L1: ако (B == 0)... L2: ако (A == 0)...
Да приемем, че процесите се изпълняват на различни процесори и че местоположенията

A и B първоначално се кешират от двата процесора с първоначална стойност 0. Ако
записите винаги влизат в сила незабавно и се виждат незабавно от други процесори, ще
бъде невъзможно и двете инструкции if (означени с L1 и L2) да оценят
техните условия като верни, тъй като достигането до оператора if означава, че или A, или B
трябва да е била присвоена стойност 1. Но да предположим, че невалидността на записа е забавена,
и на процесора е позволено да продължи по време на това забавяне. Тогава е възможно, че
както P1, така и P2 не са виждали невалидностите за B и A (съответно) преди
те се опитват да разчетат стойностите. Въпросът сега е трябва ли да бъде такова поведение
разрешено и ако да, при какви условия?
Най-простият модел за последователност на паметта се нарича последователен
последователност. Последователната последователност изисква резултатът от всяко изпълнение да бъде
същото, както ако достъпите до паметта, изпълнени от всеки процесор, се съхраняват
ред и достъпите между различните процесори бяха произволно подредени.
Последователната последователност елиминира възможността за някакво неочевидно изпълнение
в предишния пример, защото присвояванията трябва да бъдат завършени преди if
инициират се изявления.
Най-простият начин за прилагане на последователна последователност е да се изисква

процесор-сор да забави завършването на всеки достъп до паметта до всички невалидности
причинени от този достъп са завършени. Разбира се, също толкова ефективно е да отложите
следващ достъп до паметта до завършване на предишния. Запомнете този спомен
последователността включва операции между различни променливи: Двата достъпа, които
трябва да бъдат поръчани всъщност са на различни места в паметта. В нашия пример ние
трябва да забави четенето на A или B (A == 0 или B == 0), докато предишният запис приключи
5.6 Модели на последователност на паметта: Въведение 393
завършен (B = 1 или A = 1). При последователна последователност не можем, напр.

просто поставете записа в буфер за запис и продължете с четенето.
Въпреки че последователната последователност представлява проста парадигма за програмиране, тя
намалява потенциалната производителност, особено в мултипроцесор с голям брой процесори или
дълги закъснения на свързване, както можем да видим в следното
пример.
Пример Да предположим, че имаме процесор, при който липсата на запис отнема 50 цикъла, за да се установи
собственост, 10 цикъла за издаване на всяко обезсилване след установяване на собствеността и
80 цикъла за завършване на невалиден и да бъде потвърден, след като бъде издаден.
Ако приемем, че четири други процесора споделят кеш блок, колко време отнема запис
пропуснете спиране на процесора за запис, ако процесорът е последователно последователен?
Да приемем, че невалидните трябва да бъдат изрично потвърдени, преди контролерът на кохерентността
да разбере, че са завършени. Да предположим, че можем да продължим да изпълняваме
след придобиване на собствеността върху записа, без да се изчакват обезсилванията;
колко време ще отнеме писането?
Отговор Когато чакаме невалидни, всяко записване отнема сумата от времето за собственост плюс
времето за завършване на инвалидите. Тъй като невалидните могат да се припокриват, имаме нужда
безпокойте се само за последния, който започва 10 + 10 + 10 + 10 = 40 цикъла след
се установява собственост. Следователно общото време за запис е 50 + 40 + 80 = 170
цикли. За сравнение, времето за притежание е само 50 цикъла. С подходящи
реализации на буфер за писане, дори е възможно да продължите, преди да е собствеността
установени.
За да осигурят по-добро представяне, изследователи и архитекти са проучили две

различни маршрути. Първо, те разработиха амбициозни реализации, които запазват
последователна последователност, но използвайте техники за скриване на латентността, за да намалите наказанието;
обсъждаме ги в раздел 5.7. Второ, те са развили по-малко ограничителна памет

модели на последователност, които позволяват по-бърз хардуер. Такива модели могат да повлияят как
програмистът вижда мултипроцесора, така че преди да обсъдим тези по-малко ограничаващи модели,
нека да видим какво очаква програмистът.
Гледката на програмиста
Въпреки че моделът на последователна последователност има недостатък в производителността,

от гледна точка на програмиста има предимството на простотата. The
предизвикателството е да се разработи програмен модел, който е лесен за обяснение и все пак
позволява изпълнение с висока производителност.
Един такъв модел на програмиране, който ни позволява да имаме по-ефективно внедряване, е да
приемем, че програмите са синхронизирани. Една програма е синхронизирана, ако всички достъпи до
споделени данни са подредени чрез операции за синхронизиране. А
препратката към данни се подрежда чрез операция за синхронизиране, ако във всички възможни
изпълнение, запис на променлива от един процесор и достъп (или четене, или a
запис) на тази променлива от друг процесор са разделени от двойка операции за синхронизиране, едната
се изпълнява след записа от процесора за запис и една
изпълнява се преди достъпа от втория процесор. Случаи, в които променливите могат
се актуализират без подреждане чрез синхронизиране, се наричат състезания за данни , защото
резултатът от изпълнението зависи от относителната скорост на процесорите и, като
състезания в хардуерния дизайн, резултатът е непредсказуем, което води до друг
име за синхронизирани програми: data-race-free.
Като прост пример, помислете за променлива, която се чете и актуализира от два различни процесора.
Всеки процесор обгражда четенето и актуализирането с ключалка и
отключване, както за да се гарантира взаимно изключване за актуализацията, така и за да се гарантира, че
read е последователен. Ясно е, че всеки запис сега е отделен от четенето от другия
процесор чрез двойка операции за синхронизация: едно отключване (след запис)
и едно заключване (преди четенето). Разбира се, ако два процесора пишат променлива
без междинни четения, тогава записите също трябва да бъдат разделени от операции за синхронизиране.
Широко прието наблюдение е, че повечето програми са синхронизирани.
Това наблюдение е вярно преди всичко, защото ако достъпите са били несинхронизирани,
поведението на програмата вероятно би било непредвидимо поради скоростта на
изпълнението ще определи кой процесор е спечелил надпреварата за данни и по този начин ще повлияе на
резултати от програмата. Дори и при последователна последователност, разсъждения за такива
програми е много трудно.
Програмистите могат да се опитат да гарантират подреждането, като конструират свои собствени
механизми за синхронизация, но това е изключително сложно, може да доведе до програми с грешки и
може да не се поддържа архитектурно, което означава, че може да не
работят в бъдещите поколения на мултипроцесора. Вместо това почти всички програмисти ще изберат да
използват библиотеки за синхронизиране, които са правилни и оптимизирани
за мултипроцесора и вида на синхронизацията.
И накрая, използването на стандартни примитиви за синхронизация гарантира, че дори ако
архитектурата прилага по-спокоен модел на последователност от последователния
последователност, синхронизираната програма ще се държи така, сякаш е внедрен хардуер
последователна последователност.
Спокойни модели на последователност: Основите
Ключовата идея в моделите на облекчена последователност е да се позволи четене и запис да се завършват
без ред, но да се използват операции за синхронизиране, за да се наложи подреждане, така че
че синхронизираната програма се държи така, сякаш процесорът е последователно последователен. Има
разнообразие от спокойни модели, които се класифицират според какво
четат и пишат поръчки, те се отпускат. Ние определяме подрежданията чрез набор от правила на
формата X Y, което означава, че операцията X трябва да завърши преди операция Y
Свършен. Последователната последователност изисква поддържане на всичките четири възможни подреждания:
R W, R R, W RиW W. Спокойните модели се определят от това кои от
тези четири набора от поръчки те релаксират:

1. Разхлабването на подреждането W R води до модел, известен като тотално подреждане в магазина или
последователност на процесора. Тъй като това подреждане запазва подреждането сред записите,
много програми, които работят при последователна последователност, работят при това
модел, без допълнителна синхронизация.
2. Облекчаването на подреждането W W води до модел, известен като частичен ред на съхранение.
3. Разхлабването на подрежданията R WиR R дава разнообразие от модели, включително
слабо подреждане, моделът на последователност на PowerPC и последователност на изданията,
в зависимост от детайлите на ограниченията за поръчка и начина на синхронизиране
операции налагат поръчка.
Чрез облекчаване на тези подреждания, процесорът може евентуално да получи значителни предимства в
производителността. Има обаче много сложности при описването на релаксация
модели на съгласуваност, включително предимствата и сложността на облекчаване на различни поръчки,
определяне точно какво означава записът да завърши и решаване кога процесорите могат да видят
стойностите, които самият процесор е написал. За още
информация за сложността, проблемите с внедряването и ефективността
потенциал от спокойни модели, силно препоръчваме отличния урок от

Adve and Gharachorloo [1996].
Заключителни бележки относно моделите на съгласуваност
Понастоящем много мултипроцесори, които се създават, поддържат някакъв вид спокойна
модел на последователност, вариращ от последователност на процесора до последователност на изданието.
Тъй като синхронизацията е силно специфична за много процесори и податлива на грешки, очакванията
са, че повечето програмисти ще използват стандартни библиотеки за синхронизация и ще
пишете синхронизирани програми, като избирате модел със слаба консистенция
невидими за програмиста и даващи по-висока производителност.
Една алтернативна гледна точка, която обсъждаме по-подробно в следващия раздел, твърди, че със
спекулации голяма част от предимството на производителността на отпуснатото
моделите на последователност могат да бъдат получени с последователна или процесорна последователност.
Ключова част от този аргумент в полза на спокойна последователност се върти около
ролята на компилатора и способността му да оптимизира потенциално достъпа до паметта
споделени променливи; тази тема също се обсъжда в раздел 5.7.
Тъй като мултипроцесорите предефинират много системни характеристики (напр. производителност
оценка, латентност на паметта и значението на скалируемостта), въвеждат те
интересни дизайнерски проблеми, които пресичат целия спектър, засягайки и двата хардуера
и софтуер. В този раздел даваме няколко примера, свързани с въпроса за
последователност на паметта. След това изследваме постигнатата производителност, когато
многопоточността се добави към многопроцесорната обработка.

Оптимизация на компилатора и модел на съгласуваност
Друга причина за дефиниране на модел за последователност на паметта е да се уточни
набор от легални оптимизации на компилатора, които могат да бъдат извършени върху споделени данни. в
изрично паралелни програми, освен ако точките на синхронизация не са ясно дефинирани
и програмите са синхронизирани, компилаторът не може да обменя read и a
запис на два различни споделени елемента от данни, тъй като подобни трансформации биха могли
засягат семантиката на програмата. Това предотвратява дори сравнително прости оптимизации, като
например разпределение на регистър на споделени данни, тъй като такъв процес обикновено
обменя четене и запис. В имплицитно паралелизирани програми - например,
тези, написани на High Performance FORTRAN (HPF)—програмите трябва да бъдат синхронизирани и точките
за синхронизация са известни, така че този проблем не възниква.
Дали компилаторите могат да получат значително предимство от по-спокойна последователност
модели остава открит въпрос, както от изследователска гледна точка, така и от a
практическа гледна точка, където липсата на единни модели вероятно ще забави напредъка
при внедряване на компилатори.
Използване на спекулации за скриване на латентността в
Модели на стриктна последователност
Както видяхме в глава 3, спекулациите могат да се използват за скриване на латентността на паметта. То може
също да се използва за скриване на латентност, произтичаща от модел на стриктна последователност, давайки много
от ползата от спокойния модел на паметта. Основната идея е процесорът да се използва
динамично планиране за пренареждане на препратките към паметта, позволявайки им евентуално изпълнение
извън строя. Изпълнението на препратките към паметта не по ред може да генерира нарушения на
последователната последователност, което може да повлияе на изпълнението на програмата.
Тази възможност се избягва чрез използване на функцията за отложено ангажиране на спекулативното
процесор. Да приемем, че протоколът за съгласуваност се основава на невалидност. Ако процесорът получи
анулиране за препратка към памет преди препратката към паметта
е ангажиран, процесорът използва спекулативно възстановяване, за да се откаже от изчислението и да
рестартира с препратката към паметта, чийто адрес е невалиден.
Ако пренареждането на заявките за памет от процесора доведе до изпълнение

ред, който може да доведе до резултат, който се различава от това, което би се видяло
при последователна последователност, процесорът ще повтори изпълнението. Ключът към
използването на този подход е, че процесорът трябва само да гарантира, че резултатът
би било същото, както ако всички достъпи бяха завършени по ред и може да постигне
това чрез откриване кога резултатите може да се различават. Подходът е привлекателен, защото
спекулативното рестартиране рядко ще се задейства. Ще се задейства само когато
има несинхронизирани достъпи, които всъщност причиняват състезание [Gharachorloo,
Гупта и Хенеси 1992].
Hill [1998] препоръчва комбинацията от последователна или процесорна последователност
заедно със спекулативното изпълнение като модел на последователност по избор. Неговият аргумент има три
части. Първо, агресивното внедряване на последователна консистенция или консистенция на процесора ще
спечели повечето от предимствата на по-спокойна
модел. Второ, такова внедряване добавя много малко към разходите за внедряване
на спекулативен процесор. Трето, такъв подход позволява на програмиста да разсъждава с помощта на по-
прости модели на програмиране на последователна или процесорна консистенция. Дизайнерският екип на MIPS
R10000 имаше това прозрение в средата на 90-те години на миналия век
използва способността на R10000 да не работи, за да поддържа този тип агресия
прилагане на последователна последователност.
Един открит въпрос е колко успешна ще бъде технологията на компилатора в оптимизирането на
препратки към споделени променливи. Състоянието на технологията за оптимизация
и фактът, че споделените данни често са достъпни чрез указатели или индексиране на масиви
са ограничили използването на такива оптимизации. Ако тази технология стане достъпна
и доведе до значителни предимства в производителността, които авторите на компилатори биха искали да бъдат
могат да се възползват от по-спокоен модел на програмиране.
Включването и неговото прилагане
Всички мултипроцесори използват многостепенни йерархии на кеша, за да намалят както търсенето
върху глобалната връзка и латентността на пропуските в кеша. Ако кешът също така предоставя многостепенно
включване - всяко ниво на йерархията на кеша е подмножество на нивото
по-далеч от процесора - тогава можем да използваме многостепенната структура, за да намалим противоречието
между трафика на кохерентност и трафика на процесора, който възниква
когато snoops и достъпът до кеша на процесора трябва да се бори за кеша. много
мултипроцесорите с многостепенни кешове налагат свойството за включване, въпреки че
последните мултипроцесори с по-малък L1 кеш и различни размери на блоковете имат

понякога се избира да не налага включване. Това ограничение се нарича още свойство на подмножество , тъй
като всеки кеш е подмножество на кеша под него в йерархията.
На пръв поглед запазването на свойството за многостепенно включване изглежда тривиално.
Помислете за пример на две нива: Всеки пропуск в L1 или удря в L2, или генерира a
пропуснете в L2, което води до пренасянето му както в L1, така и в L2. По същия начин, всяко обезсилване
че попаденията в L2 трябва да бъдат изпратени до L1, където това ще доведе до анулирането на блока
ако съществува.
Уловката е какво се случва, когато размерите на блоковете на L1 и L2 са различни.
Изборът на различни размери на блока е доста разумен, тъй като L2 ще бъде много по-голям и
имат много по-дълъг компонент на латентност в своето наказание за пропуски и следователно ще искат да използват
по-голям размер на блока. Какво се случва с нашето „автоматично“ налагане на включване
когато размерите на блоковете се различават? Блок в L2 представлява множество блокове в L1 и a
пропуск в L2 причинява подмяна на данни, които са еквивалентни на множество L1 блокове.
Например, ако размерът на блока на L2 е четири пъти по-голям от този на L1, тогава ще има пропуск в L2
замени еквивалента на четири L1 блока. Нека разгледаме подробен пример.
Пример Да приемем, че L2 има размер на блок четири пъти по-голям от L1. Покажете как пропуск за an
адрес, който причинява заместване в L1 и L2, може да доведе до нарушаване на свойството за включване.
Отговор Да приемем, че L1 и L2 са директно картографирани и че размерът на блока на L1 е b байта
и размерът на блока на L2 е 4b байта. Да предположим, че L1 съдържа два блока със стартиране

адреси x и x + b и че x mod 4b = 0, което означава, че x също е началният адрес на блок

в L2; тогава този единичен блок в L2 съдържа L1 блоковете x, x + b, x + 2b и x + 3b. Да
предположим, че процесорът генерира препратка към блок y , която се преобразува в
блока, съдържащ x в двата кеша и следователно пропуска. Тъй като L2 пропусна, той
извлича 4b байта и замества блока, съдържащ x, x + b, x + 2b и x + 3b, докато L1 взема b
байта и замества блока, съдържащ x. Тъй като L1 все още съдържа x + b, но L2 не,
свойството за включване вече не е валидно.
За да поддържаме включване с множество размери на блокове, трябва да

изследваме по-високите нива на йерархията, когато се извършва замяна на по-ниско
ниво, за да гарантираме, че всички думи, заменени на по-ниско ниво, са невалидни в
кешовете на по-високо ниво; различните нива на асоциативност създават едни и същи
проблеми. През 2011 г. дизайнерите все още изглеждат разделени по отношение на
налагането на включването. Baer и Wang [1988] подробно описват предимствата и
предизвикателствата на включването. Intel i7 използва включване за L3, което означава,
че L3 винаги включва съдържанието на всички L2 и L1. Това им позволява да внедрят
ясна схема на директория на L3 и да сведат до минимум намесата от шпиониране на
L1 и L2 до онези обстоятелства, при които директорията показва, че L1 или L2 имат
кеширано копие. AMD Opteron, за разлика от тях, включва L2 от L1, но няма такова
ограничение за L3. Те използват подслушващ протокол, но трябва да подслушват само
L2, освен ако няма попадение, в който случай се изпраща подслушване до L1.
Повишаване на производителността от използването на многопроцесорна обработка и
Многопоточност
В този раздел разглеждаме две различни проучвания за ефективността на използването

на многопоточност на многоядрен процесор; ще се върнем към тази тема в следващия
раздел, когато разгледаме производителността на Intel i7. Нашите две проучвания са
базирани на Sun T1, който представихме в глава 3, и процесора IBM Power5.
Разглеждаме производителността на многоядрения T1, използвайки същите три

сървърно ориентирани теста – TPC-C, SPECJBB (SPEC Java Business Benchmark) и
SPECWeb99 – които разгледахме в глава 3. Бенчмаркът SPECWeb99 се изпълнява само
на четири -ядрена версия на T1, защото не може да се мащабира, за да използва
пълните 32 нишки на осемядрен процесор; другите два бенчмарка се изпълняват с
осем ядра и четири нишки всяка за общо 32 нишки. Фигура 5.25 показва CPI за нишка
и за ядро и ефективния CPI и инструкции за такт (IPC) за осемядрения T1.
IBM Power 5 е двуядрен, който поддържа едновременна многопоточност (SMT). За

да се изследва производителността на многопоточността в мултипроцесор, бяха
направени измервания на IBM система с осем Power 5 процесора, като се използва
само едно ядро на всеки от тях. Фигура 5.26 показва ускоряването за осемпроцесорен
мултипроцесор Power5, със и без SMT, за тестовете SPECRate2000, както е описано в
заглавието. Средно SPECintRate е 1,23 пъти по-бърз, докато SPECfpRate е 1,16 пъти по-
бърз. Обърнете внимание, че няколко числа с плаваща запетая
Бенчмарк CPI за нишка CPI на ядро Ефективен CPI за осем ядра Ефективен IPC за осем ядра
TPC-C 7.2 1.8 0,225 4.4
SPECJBB 5.6 1.40 0,175 5.7
SPECWeb99 6.6 1,65 0,206 4.8
Фигура 5.25 CPI за нишка, CPI за ядро, ефективният осемядрен CPI и ефективният IPC (обратен на
CPI) за осемядрения процесор Sun T1.
wupwise
плувам
mgrid
приложение
меса
галгел
изкуство
facerec
усилвател
Лукас
fma3d
sixtrack
apptu
gzip
vpr
gcc
mcf
хитър
анализатор
еон
perlbmk
празнина
вихър
bzip2
twolf
0,9 1.0 1.1 1.2 1.3 1.4 1.5

Ускори
Фигура 5.26 Сравнение на SMT и еднонишкова (ST) производителност на осемпроцесорния IBM eServer p5
575. Обърнете внимание, че у-оста започва с ускорение от 0,9, загуба на производителност. Има само един процесор във всяко Power5 ядро
активен, което трябва леко да подобри резултатите от SMT чрез намаляване на разрушителната намеса в паметта
система. Резултатите от SMT се получават чрез създаване на 16 потребителски нишки, докато резултатите от ST използват само осем нишки; с
само една нишка на процесор, Power5 се превключва на еднопоточен режим от операционната система. Тези резултати са
събрани от Джон Маккалпин от IBM. Както можем да видим от данните, стандартното отклонение на резултатите за SPECfpRate
е по-висока от тази за SPECintRate (0,13 срещу 0,07), което показва, че подобрението на SMT за FP програмите вероятно ще
варира в широки граници.
бенчмарковете изпитват лек спад в производителността в SMT режим, с

максималното намаление на ускорението е 0,93. Въпреки че може да се очаква, че SMT
би свършил по-добра работа за скриване на по-високите проценти на пропуски на показателите SPECFP, това
изглежда, че се срещат ограничения в системата с памет, когато се изпълнява в SMT

режим на такива показатели.
5.8 Събираме всичко заедно: многоядрени процесори

и тяхната производителност
През 2011 г. многоядреността е тема на всички нови процесори. Реализациите варират

широко, както и тяхната поддръжка за по-големи мултичипови мултипроцесори. В тази секция,
разглеждаме дизайна на четири различни многоядрени процесора и някои характеристики на
производителността.
Фигура 5.27 показва основните характеристики на четири многоядрени процесора

предназначени за сървърни приложения. Intel Xeon е базиран на същия дизайн като
i7, но има повече ядра, малко по-ниска тактова честота (мощността е ограничението) и по-голям L3 кеш.
AMD Opteron и десктоп Phenom споделят същото
основно ядро, докато SUN T2 е свързано със SUN T1, което срещнахме в глава
3. Power7 е разширение на Power5 с повече ядра и по-големи кешове.
Първо, сравняваме производителността и мащабируемостта на производителността на три от
тези многоядрени процесори (без AMD Opteron, където няма достатъчно данни
са налични), когато са конфигурирани като многочипови мултипроцесори.
В допълнение към това как тези три микропроцесора се различават в акцента си върху
ILP срещу TLP, има значителни разлики в техните целеви пазари. По този начин, нашите
фокусът ще бъде по-малко върху сравнителната абсолютна производителност и повече върху скалируемостта
на производителността, тъй като се добавят допълнителни процесори. След като разгледаме тези данни,
ще разгледаме по-подробно многоядрената производителност на Intel Core i7.
Показваме производителността за три набора от показатели: SPECintRate,
SPECfpRate и SPECjbb2005. Бенчмарковете SPECRate, които събираме
заедно, илюстрират производителността на тези мултипроцесори за паралелизъм на ниво заявка, тъй
като се характеризира с паралелно и припокриващо се изпълнение на независими програми. По-
специално не се споделя нищо друго освен системни услуги.
SPECjbb2005 е мащабируем Java бизнес бенчмарк, който моделира три нива
система клиент/сървър, с фокус върху сървъра и е подобна на бенчмарка
използвани в SPECPower, които разгледахме в Глава 1. Упражнения за бенчмарк
имплементациите на Java Virtual Machine, компилатор точно навреме, боклук
колекция, нишки и някои аспекти на операционната система; той също така тества скалируемостта на
многопроцесорни системи.
Фигура 5.28 показва производителността на бенчмарковете на процесора SPECRate като
броят на ядрата се увеличава. Постига се почти линейно ускорение като брой на
процесорни чипове и следователно броят на ядрата се увеличава.
Фигура 5.29 показва подобни данни за бенчмарка SPECjbb2005. Компромисите между използването
на повече ILP и фокусирането само върху TLP са сложни и са
силно зависи от натоварването. SPECjbb2005 е работно натоварване, което се мащабира с добавянето
на допълнителни процесори, задържайки времето, а не размера на проблема,
5.8 Обединяване на всичко: многоядрени процесори и тяхната производителност 401
Особеност AMD Opteron 8439 IBM Power 7 Intel Xenon 7560 Слънце Т2
Транзистори 904 М 1200 М 2300 М 500 М
Мощност (номинална) 137 W 140 W 130 W 95 W
Макс. ядра/чип 6 8 8 8
Многопоточност Не SMT SMT Дребнозърнеста
Нишки/ядро 1 4 2 8
Издаване на инструкции/часовник 3 от една тема 6 от една нишка 4 от една нишка 2 от 2 нишки
Тактова честота 2,8 GHz 4,1 GHz 2,7 GHz 1,6 GHz
Най-външният кеш L3; 6 MB; споделено L3; 32 MB (с помощта L3; 24 MB; споделено L2; 4 MB; споделено
на вградена DRAM);
споделени или частни/основни
Включване Не, въпреки че L2 е Да, суперкомплект L3 Да, суперкомплект L3 да
надмножество на L1
Многоядрен протокол за МОЕСИ Разширен MESI със съвети MESIF МОЕСИ
кохерентност за поведение и
местоположение
(протокол с 13 състояния)
Реализация на Подслушване Указател на L3 Указател на L3 Директория на L2

многоядрена кохерентност
Разширена поддръжка за До 8 процесорни чипа До 32 процесорни чипа До 8 процесорни ядра Реализира се чрез четири
съгласуваност могат да бъдат могат да бъдат свързани с могат да бъдат кохерентни връзки на
свързани с SMP връзките. внедрени чрез процесор, които могат да
HyperTransport в пръстен, Динамична структура на Quickpath се използват за
като се използва разпределена директория. Interconnect. Поддръжка наблюдение. До два
директория или Достъпът до паметта на директории с чипа се свързват
шпиониране. Системата е NUMA. извън 8-ядрен
е симетричен външна логика. директно и до четири
чип. чрез външни ASIC.
Фигура 5.27 Обобщение на характеристиките на четири скорошни многоядрени процесора от висок клас (издания от 2010 г.)
предназначени за сървъри. Таблицата включва версиите с най-голям брой ядра на тези процесори; има версии с
по-нисък брой ядра и по-високи тактови честоти за някои от тези процесори. L3 в IBM Power7 може да бъде споделен
или разделени на по-бързи частни региони, предназначени за отделни ядра. Включваме само едночипови реализации
на многоядрени.
постоянен. В този случай изглежда има достатъчен паралелизъм за постигане на линейно ускоряване
чрез 64 ядра. Ще се върнем към тази тема в заключителните бележки, но първо
нека да разгледаме по-подробно производителността на Intel Core i7 в едночипов, четириядрен
режим.
Производителност и енергийна ефективност на Intel Core i7

Многоядрени
В този раздел разглеждаме производителността на i7 на същите две групи от

бенчмаркове, които разгледахме в глава 3: паралелните бенчмаркове на Java и
паралелни PARSEC бенчмаркове (описани подробно във Фигура 3.34 на страница 231).
SPECintRate SPECfpRate
4096 4096
UltraSPARC T2
Xeon X7560 2048 г
Мощност7
1024 1024
512
256 256
128
64 64
8 16 32 64 8 16 32 64
Общо ядра Ядра
Фигура 5.28 Производителността на тестовете SPECRate за три многоядрени процесора при увеличаване на броя на
процесорните чипове. Забележете, че за този силно паралелен бенчмарк се постига почти линейно ускоряване. И двата
графика са в логаритмична скала, така че линейното ускоряване е права линия.
8192 K
UltraSPARC T2
Xeon X7560
Мощност7
2048 К
512 К
128 К
8 16 32 64
Ядра
Фигура 5.29 Производителността на теста SPECjbb2005 за три многоядрени процесора, тъй като
броят на процесорните чипове се увеличава. Забележете, че за този паралелен бенчмарк се
постига почти линейно ускоряване.
Първо, разглеждаме многоядрената производителност и мащабиране спрямо едноядрен без

използването на SMT. След това комбинираме многоядрените и SMT възможности.
Всички данни в този раздел, като тези в по-ранната i7 SMT оценка (Глава 3, Раздел 3.13) идват
от Esmaeilzadeh et al. [2011]. Наборът от данни е същият като този, използван по-рано (вижте
Фигура 3.34 на страница 231), с изключение на това, че Java бенчмарковете tradebeans и
pjbb2005 са премахнати (оставяйки само петте мащабируеми Java бенчмарка); tradebeans и
pjbb2005 никога не постигат ускоряване над 1,55 дори с четири ядра и общо осем нишки и
следователно не са подходящи за оценка
повече ядра.
Фигура 5.30 показва както ускоряването, така и енергийната ефективност на тестовете

Java и PARSEC без използването на SMT. Показването на енергийна ефективност означава, че
начертаваме съотношението на енергията, консумирана от дву- или четириядрения цикъл,
към енергията, консумирана от едноядрения цикъл; по този начин по-високата енергийна
ефективност е по-добра, като стойност от 1,0 е точката на рентабилност. Неизползваните ядра
във всички случаи бяха в режим на дълбоко заспиване, което минимизира консумацията им на енергия с
5.8 Обединяване на всичко: многоядрени процесори и тяхната производителност 403
3.5 1.06
Ускоряване на Java
Ускоряване на PARSEC 1.04

Енергийна ефективност на Java
3 PARSEC енергийна ефективност 1.02
1,00
2.5 0,98
еинерокPс7и
2
4
уi
0,96
P7и
реф
витгк
анй
тсо н 2
4
еi
2 0,94
0,92
1.5 0,90
0,88
1 0,86
2P 4P
Ядра
Фигура 5.30 Тази диаграма показва ускоряването за дву- и четириядрени изпълнения на

паралелните натоварвания Java и PARSEC без SMT. Тези данни са събрани от Esmaeilzadeh et al.
[2011], използвайки същата настройка, както е описано в Глава 3. Turbo Boost е изключен.
Ускоряването и енергийната ефективност са обобщени с помощта на хармонична средна стойност,
което предполага работно натоварване, при което общото време, прекарано за изпълнение на
всеки 2p бенчмарк, е еквивалентно.
по същество ги изключва. При сравняване на данните за едноядрени и многоядрени бенчмаркове е

важно да запомните, че пълната енергийна цена на L3 кеша и интерфейса на паметта се заплаща в
едноядрен (както и в многоядрен) случай. Този факт увеличава вероятността консумацията на енергия
да се подобри за приложения, които се мащабират сравнително добре. Хармоничната средна стойност
се използва за обобщаване на резултатите с импликацията, описана в надписа.
Както показва фигурата, показателите PARSEC получават по-добро ускоряване от показателите

на Java, постигайки 76% ефективност на ускоряване (т.е. действителното ускоряване, разделено на
броя на процесорите) на четири ядра, докато показателите на Java постигат 67% ефективност на
ускоряване на четири ядра. Въпреки че това наблюдение е ясно от данните, анализирането защо
съществува тази разлика е трудно. Например, много е възможно ефектите от закона на Amdahl да са
намалили ускоряването на работното натоварване на Java.
В допълнение, взаимодействието между архитектурата на процесора и приложението, което засяга
проблеми като цената на синхронизация или комуникация, също може да играе роля. По-специално,
добре паралелизираните приложения, като тези в PARSEC, понякога се възползват от изгодно
съотношение между изчисление и комуникация, което намалява зависимостта от разходите за
комуникация.
(Вижте Приложение I.)
Тези разлики в ускоряването се превръщат в разлики в енергийната ефективност.
Например тестовете PARSEC всъщност леко подобряват енергийната ефективност спрямо
едноядрената версия; този резултат може да бъде значително засегнат
поради факта, че L3 кешът се използва по-ефективно в многоядрените работи, отколкото в

едноядрения случай и разходът на енергия е идентичен и в двата случая.
По този начин, за показателите на PARSEC, многоядреният подход постига това, на което
дизайнерите се надяваха, когато преминаха от дизайн, фокусиран върху ILP, към многоядрен
дизайн; а именно, мащабира производителността толкова бързо или по-бързо от мащабирането
на мощността, което води до постоянна или дори подобрена енергийна ефективност. В случая с
Java виждаме, че нито двуядрените, нито четириядрените изпълнения не успяват да постигнат
дори по отношение на енергийната ефективност поради по-ниските нива на ускоряване на
работното натоварване на Java (въпреки че енергийната ефективност на Java за 2p изпълнението
е същата като за PARSEC! ). Енергийната ефективност в четириядрения корпус на Java е
сравнително висока (0,94). Вероятно ILP-центричният процесор ще се нуждае от още повече
мощност, за да постигне сравнимо ускоряване на работното натоварване PARSEC или Java. По
този начин подходът, ориентиран към TLP, със сигурност е по-добър от подхода, ориентиран
към ILP, за подобряване на производителността на тези приложения.
Съчетаване на Multicore и SMT

И накрая, ние разглеждаме комбинацията от многоядрени и многонишкови, като измерваме
двата набора от показатели за два до четири процесора и една до две нишки (общо четири
точки от данни и до осем нишки). Фигура 5.31 показва
4 1.20
Ускоряване на Java
Ускоряване на PARSEC
1.15
Енергийна ефективност на Java
3.5
PARSEC енергийна ефективност
1.10
3
1.05
1оxкPс7и
еине,Tр2 2
4
уi
2.5 1,00
ви,тT
анй
тсо 2
р
гк P7и
1еxф
н 2
4
еi
0,95
2
0,90
1.5
0,85
1 0,80
2Px1T 2Px2T 4Px1T 4Px2T
Фигура 5.31 Тази диаграма показва ускоряването за дву- и четириядрени изпълнения на

паралелните Java и PARSEC работни натоварвания със и без SMT. Не забравяйте, че резултатите
по-горе варират в броя на нишките от две до осем и отразяват както архитектурните ефекти,
така и характеристиките на приложението. Хармоничната средна стойност се използва за
обобщаване на резултатите, както е обсъдено в заглавието на Фигура 5.30.
ускоряване и енергийна ефективност, получени на Intel i7, когато процесорът се брои

е две или четири и SMT е или не се използва, като се използва хармонична средна стойност за
обобщаване на двата набора от показатели. Ясно е, че SMT може да увеличи производителността, когато е там
е достатъчен паралелизъм на ниво нишка, наличен дори в многоядрената ситуация.
Например, в случай с четири ядра, без SMT, ефективността на ускоряване е 67%
и 76% съответно за Java и PARSEC. С SMT на четири ядра, тези
съотношенията са удивителните 83% и 97%!
Енергийната ефективност представя малко по-различна картина. В случая на PAR-SEC ускоряването
е по същество линейно за четириядрения SMT корпус (осем нишки) и
мощността се мащабира по-бавно, което води до енергийна ефективност от 1,1 за този случай.
Ситуацията с Java е по-сложна; пикове на енергийна ефективност за двуядрения
SMT (четири нишки) работи при 0,97 и пада до 0,89 в четириядрения SMT (8 нишки)
тичам. Изглежда много вероятно тестовете на Java да се сблъскват с тези на Amdahl
правни ефекти, когато са разположени повече от четири нишки. Както някои архитекти имат
наблюдавано, многоядрените прехвърлят повече отговорност за производителността (и следователно
енергийна ефективност) на програмиста и резултатите за работното натоварване на Java
със сигурност приемете това.
Като се има предвид липсата на зрялост в нашето разбиране за паралелни изчисления, има
много скрити капани, които ще бъдат разкрити или от внимателни дизайнери, или от
нещастници. Като се има предвид голямото количество реклами, които заобиколиха мултипроцесорите
през годините, често срещаните заблуди изобилстват. Включили сме селекция от тях.
Клопка Измерване на производителността на мултипроцесорите чрез линейно ускоряване спрямо времето за изпълнение.
Графиките на „минохвъргачен изстрел“ – изобразяване на производителността спрямо броя на

процесорите, показващи линейно ускоряване, плато и след това спад – отдавна се използват за
съди за успеха на паралелните процесори. Въпреки че ускоряването е един аспект на паралелна
програма, то не е пряка мярка за производителност. Първият въпрос е
мощност на процесорите, които се мащабират: Програма, която линейно подобрява производителността
до равни 100 процесора Intel Atom (процесорът от нисък клас, използван за нетбуци), може да е по-бавна
от версията, работеща на осемядрен Xeon. Бъдете особено
внимавайте с интензивни програми с плаваща запетая; обработващите елементи без помощ от хардуер
могат да се мащабират чудесно, но имат лоша колективна производителност.
Сравняването на времето за изпълнение е справедливо само ако сравнявате най-добрите алгоритми
на всеки компютър. Сравняването на идентичен код на два компютъра може
изглежда справедливо, но не е; паралелната програма може да е по-бавна на еднопроцесор от
последователна версия. Разработването на паралелна програма понякога ще доведе до алгоритмични
подобрения, така че сравняването на предишната най-известна последователна програма с паралелния
код - което изглежда справедливо - няма да сравни еквивалент
алгоритми. За да се отрази този проблем, термините относително ускоряване (същата програма) и

понякога се използва истинско ускорение (най-добра програма).
Резултати, които предполагат суперлинейна производителност, когато програма на n процесора е
повече от n пъти по-бърза от еквивалентния еднопроцесор, може да означава
че сравнението е несправедливо, въпреки че има случаи, в които са се срещали „истински“ ускорявания
на суперлини. Например някои научни приложения
редовно постигайте свръхлинейно ускоряване за малки увеличения в броя на процесорите (2 или
4 до 8 или 16). Тези резултати обикновено възникват поради критични структури от данни, които го правят
не се вписват в общите кешове на мултипроцесор с 2 или 4 процесора се вписват в
съвкупният кеш на мултипроцесор с 8 или 16 процесора.
В обобщение, сравняването на производителността чрез сравняване на ускоренията е в най-добрия случай
сложни и в най-лошия случай подвеждащи. Сравняването на ускоренията за два различни мултипроцесора

не ни казва непременно нищо за относителната производителност на мултипроцесорите. Дори
сравнявайки два различни алгоритъма на
един и същ мултипроцесор е труден, тъй като трябва да използваме истинско ускоряване, а не относително
ускоряване, за да получим валидно сравнение.
Заблуда Законът на Амдал не се прилага за паралелни компютри.
През 1987 г. ръководителят на изследователска организация твърди, че законът на Амдал (вж

Раздел 1.9) е повреден от MIMD мултипроцесор. Това твърдение
едва ли означава обаче, че законът е отменен за паралелните компютри; пренебрегваната част от
програмата все още ще ограничава производителността. Да се
разберем основата на медийните доклади, нека видим какво каза Амдал [1967] първоначално:
Доста очевидно заключение, което може да се направи на този етап, е, че усилието

разходите за постигане на високи скорости на паралелна обработка се губят, освен ако не са
придружено от постижения в скоростите на последователна обработка от много почти
същата величина. [стр. 483]
Едно тълкуване на закона беше, че тъй като части от всяка програма трябва да бъдат
последователен, има ограничение за полезния икономически брой процесори - да речем,
100. Като показва линейно ускоряване с 1000 процесора, тази интерпретация на
Законът на Амдал беше опроверган.
Основата за твърдението, че законът на Амдал е „преодолян“, е
използване на мащабирано ускоряване, наричано още слабо мащабиране. Изследователите мащабираха
бенчмарка, за да имат размер на набора от данни, който беше 1000 пъти по-голям, и сравниха времето
за еднопроцесорно и паралелно изпълнение на мащабирания бенчмарк. За това специално
алгоритъм, последователната част на програмата беше постоянна, независима от
размер на входа, а останалото беше напълно паралелно - следователно, линейно ускоряване с 1000
процесори. Тъй като времето за изпълнение нарастваше по-бързо от линейното, всъщност програмата
работи по-дълго след мащабиране, дори и с 1000 процесора.
Ускоряването, което предполага мащабиране на входа, не е същото като истинското ускоряване и
съобщаването му, сякаш е било, е подвеждащо. Тъй като често се изпълняват паралелни бенчмаркове
различни по големина мултипроцесори, важно е да се уточни какъв тип приложение
мащабирането е допустимо и как трябва да се направи това мащабиране. Макар и просто
мащабирането на размера на данните с броя на процесорите рядко е подходящо, като се приеме, че е фиксиран
размерът на проблема за много по-голям брой процесори (наречен силно мащабиране) често е
също е неподходящо, тъй като е вероятно потребителите с много по-голям мултипроцесор да изберат
да стартират по-голяма или по-подробна версия на приложение. Вижте
Приложение I за повече дискусии по тази важна тема.
Необходими са линейни ускорявания, за да се направят мултипроцесорите икономически ефективни .
Широко признато е, че едно от основните предимства на паралелните изчисления е

предлагат „по-кратко време за решение“ от най-бързия еднопроцесор. Много хора,
но също така поддържа мнението, че паралелните процесори не могат да бъдат толкова рентабилни, колкото
еднопроцесорни, освен ако не могат да постигнат перфектно линейно ускоряване. Този аргумент казва
това, защото цената на мултипроцесора е линейна функция на числото
на процесорите, всичко по-малко от линейно ускоряване означава, че производителността/цената
коефициентът намалява, което прави паралелния процесор по-малко рентабилен от използването на уни-
процесор.
Проблемът с този аргумент е, че цената не е само функция на броя на процесорите, но зависи и
от паметта, I/O и режийните разходи на системата (кутия,
захранване, свързване и т.н.). Освен това има по-малко смисъл в многоядрения
ера, когато има няколко процесора на чип.
Ефектът от включването на паметта в цената на системата беше посочен от Wood
и Хил [1995]. Използваме пример, базиран на по-нови данни, използвайки TPC-C и
SPECRate бенчмаркове, но аргументът може да бъде направен и с паралелно натоварване на научно-
научно приложение, което вероятно ще направи случая още по-силен.
Фигура 5.32 показва ускоряването за TPC-C, SPECintRate и SPECfpRate на
мултипроцесор IBM eServer p5, конфигуриран с 4 до 64 процесора. Фигурата
показва, че само TPC-C постига по-добро ускоряване от линейното. За SPECintRate
и SPECfpRate, ускоряването е по-малко от линейно, но също и цената, тъй като за разлика от TPC-C
размерът на основната памет и диска, изискван и двете, се мащабират по-малко от линейно.
Както показва фигура 5.33 , по-големият брой процесори всъщност може да бъде по-рентабилен
от конфигурацията с четири процесора. При сравняване на разходите и ефективността на
два компютъра, трябва да сме сигурни, че включваме точни оценки както на общите системни
разходи, така и на това каква производителност е постижима. За много приложения с по-големи
изисквания към паметта, подобно сравнение може драматично да увеличи привлекателността
използване на мултипроцесор.
Клопка Неразработването на софтуера, за да се възползва от или да се оптимизира за многопроцесорно

сор архитектура.
Има дълга история на изоставане на софтуера при мултипроцесорите, вероятно защото софтуерните
проблеми са много по-трудни. Даваме един пример за
показват тънкостта на проблемите, но има много примери, които можем да изберем
от!
Един често срещан проблем възниква, когато софтуер, предназначен за a

еднопроцесорният е адаптиран към многопроцесорна среда. Например SGI
операционната система през 2000 г. първоначално защити структурата на данните на таблицата на страниците с
едно заключване, ако приемем, че разпределянето на страници е рядко. В еднопроцесор,

72
Линейно ускорение
64
Ускоряване на TPM
Ускоряване на SPECintRate
56 Ускоряване на SPECfpRate
48
40
ироксУ
32
24
16
0
0 8 16 24 32 40 48 56 64
Фигура 5.32 Ускоряване за три бенчмарка на IBM eServer p5 мултипроцесор

когато е конфигуриран с 4, 8, 16, 32 и 64 процесора. Прекъснатата линия показва линейно
ускори.
това не представлява проблем с производителността. В мултипроцесор може

се превърне в основен пречка за производителността на някои програми. Помислете за програма, която
използва голям брой страници, които се инициализират при стартиране, което
UNIX го прави за статично разпределени страници. Да предположим, че програмата е паралелизирана
така че множество процеси да разпределят страниците. Тъй като разпределението на страници изисква
използването на структурата от данни на таблицата на страниците, която е заключена, когато се използва,
дори ядро на ОС, което позволява множество нишки в ОС, ще бъде сериализирано, ако
всички процеси се опитват да разпределят своите страници наведнъж (което е точно това, което ние
може да се очаква по време на инициализация!).
Тази сериализация на таблица на страници елиминира паралелизма при инициализацията и има
значително въздействие върху общата паралелна производителност. Това затруднение в
производителността продължава дори при мултипрограмиране. Да предположим например, че разделяме паралела
програмирайте на отделни процеси и ги стартирайте, по един процес на процесор, така че
че няма споделяне между процесите. (Точно това направи един потребител,
тъй като той основателно вярваше, че проблемът с изпълнението се дължи на непреднамерено
споделяне или намеса в неговото приложение.) За съжаление ключалката все още сериализира всички
процесите, така че дори производителността при мултипрограмиране е лоша. Тази клопка показва вид
фини, но значителни грешки в производителността, които могат да възникнат, когато софтуерът работи
на мултипроцесори. Подобно на много други ключови софтуерни компоненти, ОС
1.15
TPM производителност/цена
SPECint производителност/цена
1.10 SPECfp производителност/цена
1.05
1,00
со
/атн ол
рн ти
сец ро
од о
пав иаи
ре
имзм р
ятон пП
тсреиц
чс
0,95
0,90
0,85
0 8 16 24 32 40 48 56 64
Фигура 5.33 Производителност/цена спрямо 4-процесорна система за три бенчмарка, изпълнявани на IBM eServer
p5 мултипроцесор, съдържащ от 4 до 64 процесора, показва, че по-големият брой процесори може да бъде като цена
ефективен като 4-процесорна конфигурация. За TPC-C конфигурациите са тези, използвани в официалните серии, които
означава, че дискът и паметта се мащабират почти линейно с броя на процесорите и машина с 64 процесора е приблизително два пъти
по-скъпа от версия с 32 процесора. Обратно, дискът и паметта се мащабират по-бавно
(въпреки че все още е по-бърз от необходимото за постигане на най-добрия SPECRate при 64 процесора). По-специално, дисковите
конфигурации преминават от едно устройство за 4-процесорната версия до четири устройства (140 GB) за 64-процесорната версия. Паметта е
мащабиран от 8 GB за 4-процесорната система до 20 GB за 64-процесорната система.
алгоритмите и структурите от данни трябва да бъдат преосмислени в многопроцесорен контекст.

Поставянето на ключалки върху по-малки части от таблицата на страниците ефективно елиминира проблема.
Подобни проблеми съществуват в структурите на паметта, което увеличава кохерентния трафик
в случаите, когато всъщност не се извършва споделяне.
Тъй като многоядрените се превърнаха в доминираща тема във всичко - от настолни компютри до
сървъри, стана очевидна липсата на адекватна инвестиция в паралелен софтуер. Като се има предвид
липсата на фокус, вероятно ще минат много години преди софтуерът
системите, които използваме, адекватно използват този нарастващ брой ядра.

Повече от 30 години изследователи и дизайнери предричаха края на еднопроцесорните процесори и
тяхното доминиране от мултипроцесорите. До ранните години на това
век, тази прогноза постоянно се оказва погрешна. Както видяхме в глава 3,
разходите за опити за намиране и използване на повече ILP са непосилни като ефективност (и двете
в областта на силикона и мощността). Разбира се, многоядреността не решава мощността

проблем, тъй като очевидно увеличава както броя на транзисторите, така и активния брой
на превключване на транзистори, които са двата доминиращи приноса към мощността.
Многоядреността обаче променя играта. Като позволява поставянето на празни ядра
в енергоспестяващ режим може да се постигне известно подобрение на енергийната ефективност,
както показват резултатите в тази глава. По-важното е, че многоядрените измества
бреме за поддържане на заетостта на процесора, като се разчита повече на TLP, за което приложението
и програмистът са отговорни за идентифицирането, отколкото на ILP, за
за което отговаря хардуерът. Както видяхме, тези различия ясно играят
в многоядрената производителност и енергийната ефективност на Java срещу
PARSEC бенчмаркове.
Въпреки че многоядреността осигурява известна директна помощ с енергийната ефективност

предизвикателство и прехвърля голяма част от тежестта върху софтуерната система, остават трудни
предизвикателства и неразрешени въпроси. Например опити за експлоатация
версиите на ниво нишка на агресивни спекулации досега са имали същата съдба като
техните колеги от ILP. Това означава, че подобренията в производителността са скромни и са
вероятно по-малко от увеличаването на потреблението на енергия, така че идеи като спекулативни
нишки или хардуерно изпреварване не са били успешно включени в процесорите. Както при
спекулациите за ILP, освен ако спекулациите почти винаги не са правилни, the
разходите надхвърлят ползите.
В допълнение към основните проблеми на езиците за програмиране и компилатора

технология, многоядрените отвори отново друг дългогодишен въпрос в компютъра
архитектура: Заслужава ли си да се обмислят разнородни процесори? Въпреки че не
такива многоядрени все още не са доставени и хетерогенни мултипроцесори са
имаше само ограничен успех в компютри със специално предназначение или вградени системи
възможностите са много по-широки в многоядрена среда. Както при много проблеми
при многопроцесорна обработка отговорът вероятно ще зависи от софтуерните модели и
системи за програмиране. Ако компилаторите и операционните системи могат ефективно да използват
хетерогенни процесори, те ще станат по-масови. в момента,
справянето ефективно със скромен брой хомогенни основни щамове е отвъд
съществуваща възможност на компилатор за много приложения, но мултипроцесорите, които имат
хетерогенни ядра с ясни разлики във функционалната способност и очевидни
Методите за декомпозиране на приложение стават все по-често срещани, включително специални
процесори като GPU и медийни процесори. Акцент върху
енергийната ефективност също може да доведе до ядра с различна производителност спрямо мощността
съотношенията са включени.
В изданието на този текст от 1995 г. завършихме главата с обсъждане на

два тогавашни спорни въпроса:
1. Каква архитектура би била много широкомащабна, базирана на микропроцесор многопроцесорна

Sors използват?
2. Каква беше ролята на многопроцесорната обработка в бъдещето на микропроцесора

архитектура?
Изминалите години до голяма степен разрешиха тези два въпроса.

Тъй като много големите мултипроцесори не се превърнаха в основен и разрастващ се пазар,

единственият рентабилен начин за изграждане на такива широкомащабни мултипроцесори
беше да се използват клъстери, където отделните възли са или единични многоядрени микропроцесори,
или малки мултипроцесори със споделена памет (обикновено два до четири
многоядрени), а технологията за свързване е стандартна мрежова технология.
Тези клъстери, които са мащабирани до десетки хиляди процесори и
инсталирани в специално проектирани „складове“, са предмет на следващата глава.
Отговорът на втория въпрос стана кристално ясен през последните шест или
седем години: Бъдещото нарастване на производителността на микропроцесорите ще дойде от
по-скоро използването на паралелизъм на ниво нишка чрез многоядрени процесори
отколкото чрез използване на повече ILP.
Вследствие на това ядрата се превърнаха в новите градивни елементи на
чипове, а доставчиците предлагат разнообразие от чипове, базирани на един основен дизайн, използващ
различен брой ядра и L3 кешове. Например Фигура 5.34 показва
Семейството процесори на Intel, изградено само с помощта на ядрото Nehalem (използвано в Xeon
7560 и i7)!
През 80-те и 90-те години на миналия век, с раждането и развитието на ILP, софтуерът в
формата на оптимизиране на компилатори, които могат да използват ILP, беше ключът към неговия
успех. По същия начин успешното използване на паралелизма на ниво нишка ще зависи също толкова от
разработването на подходящи софтуерни системи, както ще се основава на приноса на компютърните
архитекти. Предвид бавния напредък на паралелния софтуер през последните 30+
години, вероятно е широкото използване на паралелизма на ниво нишка да остане предизвикателство
за години напред. Освен това вашите автори вярват, че има значителна възможност за по-добри
многоядрени архитектури. Да проектират тези архитекти ще
изискват дисциплина в количествения дизайн и способност за точно моделиране на десетки
стотици ядра, изпълняващи трилиони инструкции, включително широкомащабни приложения и
операционни системи. Без такава методология и възможност, арх
ще снима на тъмно. Понякога имаш късмет, но често пропускаш.
Тактова честота
Процесор Серия Ядра L3 кеш Мощност (типично) (GHz) Цена
Xeon 7500 8 18–24 MB 130 W 2–2.3 $2837–3692
Xeon 5600 4–6 без SMT 12 MB 40–130 W 1,86–3,33 $440–1663
Xeon 3400–3500 4 без SMT 8 MB 45–130 W 1,86–3,3 $189–999
Xeon 5500 2–4 4–8 MB 80–130 W 1,86–3,3 $80–1600
i7 860–975 4 8 MB 82 W–130 W 2,53–3,33 $284–999
i7 мобилен телефон 720–970 4 6–8 MB 45–55 W 1,6–2,1 $364-378
i5 750–760 4 wo SMT 8 MB 80 W 2,4–2,8 $196-209
i3 330–350 2 без SMT 3 MB 35 W 2,1–2,3
Фигура 5.34 Характеристики за набор от части на Intel, базирани на микроархитектурата Nehalem. Тази диаграма все още
свива различни записи във всеки ред (от 2 до 8!). Цената е при поръчка на 1000 бр.
Раздел L.7 (достъпен онлайн) разглежда историята на мултипроцесорите и паралелната

обработка. Разделен както по времеви период, така и по архитектура, разделът включва
дискусии за ранни експериментални мултипроцесори и някои от големите дебати в паралелната
обработка. Покрити са и последните постижения. Включени са препратки за допълнително
четене.
Казуси и упражнения от Амр Заки и

Дейвид А. Ууд
Казус 1: Многоядрен многопроцесор с един чип

Подслушване на преходите на протокола за съгласуваност
Производителност на протокола за съгласуваност
Оптимизации на протокола за съгласуваност
Синхронизация
Производителност на моделите за съгласуваност на паметта
Простият, многоядрен многопроцесор, илюстриран на Фигура 5.35, представлява

общоприложена симетрична архитектура със споделена памет. Всеки процесор има единичен
частен кеш с кохерентност, поддържана с помощта на протокола за кохерентност за
проследяване от Фигура 5.7. Всеки кеш е директно картографиран, с четири блока, всеки от
които съдържа две думи. За да се опрости илюстрацията, етикетът за адрес на кеша съдържа
пълния адрес и всяка дума показва само два шестнадесетични знака, като най-малко значимата
дума е вдясно. Състоянието на кохерентност се обозначава с M, S и I (променено, споделено и
невалидно).
5.1 [10/10/10/10/10/10/10] <5.2> За всяка част от това упражнение приемете първоначалното състояние
на кеша и паметта, както е показано на фигура 5.35. Всяка част от това упражнение определя
последователност от една или повече операции на процесора във формата:
P#: <оп> <адрес> [<стойност>]
където P# обозначава CPU (напр. P0), <op> е операцията на CPU (напр. четене или запис),
<address> обозначава адреса на паметта и <value> посочва новата дума, която да бъде
присвоена на операция за запис . Третирайте всяко действие по-долу като независимо
приложено към първоначалното състояние, както е показано на Фигура 5.35. Какво е
резултатното състояние (т.е. състояние на съгласуваност, етикети и данни) на кеш паметта и паметта след даденото д
Показване само на блоковете, които се променят; например P0.B0: (I, 120, 00 01) показва, че
блокът B0 на CPU P0 има крайно състояние I, етикет 120 и думи с данни 00 и 01. Също така,
каква стойност се връща от всяка операция за четене?
Казуси и упражнения от Амр Заки и Дейвид А. Ууд 413
P0 P1 P3
Адресен Адресен Адресен

Състояние на
кохерентност Данни
Състояние на
..... Състояние на
B0 аз 00 10 B0 аз 00 10 B0 С 00 20
B1 С 00 08 B1 М 00 68 B1 С 00 08
B2 М 00 30 B2 аз 00 10 B2 аз 00 10
B3 аз етикет 100 108
00110 11810 B3 С етикет 100 12800
110 118 18 B3 аз етикет 120 108
00110 11810
Вътрешно свързване на чип (с мениджър на кохерентност)
памет
Адрес Данни
.... .... ....
100 00 10
108 00 08
110 00 10
118 00 18
120 00 20
128 00 28
130 00 30
... ... ...
Фигура 5.35 Многоядрен (точка до точка) мултипроцесор.
а. [10] <5.2> P0: прочетете 120 b.
[10] <5.2> P0: напишете 120 <-- 80 c. [10] <5.2>
P3: напишете 120 <-- 80 d. [10] <5.2> P1:
прочетете 110
д. [10] <5.2> P0: напишете 108 <-- 48
f. [10] <5.2> P0: напишете 130 <-- 78 g. [10]
<5.2> P3: напишете 130 <-- 78
5.2 [20/20/20/20] <5.3> Ефективността на подслушващ кеш-кохерентен мултипроцесор

зависи от много детайлни проблеми с внедряването, които определят колко бързо
кешът отговаря с данни в ексклузивен или M блок на състояние. В някои
реализации четенето на процесора пропуска до кеш блок, който е изключителен в друг проце
кеша е по-бърз от пропуск на блок в паметта. Това е така, защото кешовете са

по-малък и следователно по-бърз от основната памет. Обратно, в някои реализации пропуските,
удовлетворени от паметта, са по-бързи от тези, удовлетворени от кеш паметта. Това
защото кешовете обикновено са оптимизирани за „предна страна“ или препратки към процесора,
вместо „задна страна“ или подслушване на достъп. За мултипроцесора, илюстриран в
Фигура 5.35, разгледайте изпълнението на последователност от операции на един CPU
където
Ударите за четене и запис на процесора не генерират цикли на спиране.
Пропуските при четене и запис на CPU генерират цикли на спиране на Nmemory и Ncache , ако са задоволителни
управлявани съответно от паметта и кеша.
Ударите при запис на CPU, които генерират невалидна, водят до цикли на спиране на Ninvalidate .
Обратно записване на блок поради конфликт или поради друг процесор

заявка към ексклузивен блок, налага допълнителни цикли на спиране на Nwriteback .
Разгледайте две реализации с различни характеристики на производителност, обобщени на Фигура

5.36. Разгледайте следната последователност от операции, приемайки първоначалното състояние
на кеша на Фигура 5.35. За простота приемете, че второто
операцията започва след първото завършване (въпреки че те са на различни
процесори):
P1: прочетете 110

За изпълнение 1 първото четене генерира 50 цикъла на спиране, тъй като четенето е

удовлетворен от кеша на P0. P1 спира за 40 цикъла, докато чака блока, и P0
спира за 10 цикъла, докато записва блока обратно в паметта в отговор на P1
искане. По този начин второто четене от P3 генерира 100 цикъла на спиране, защото пропускът му е
удовлетворява се от паметта и тази последователност генерира общо 150 цикъла на спиране. За
следните последователности от операции, колко цикъла на спиране се генерират от
всяко изпълнение?
Параметър Изпълнение 1 Изпълнение 2
Nпамет 100 100
Ncache 40 130
Невалидиране 15 15
Nwriteback 10 10
Фигура 5.36 Закъснения на кохерентност при проследяване.

а. [20] <5.3> P0: прочетете 120 P0:

b. [20] <5.3> P0: четене 100 P0: запис

108 <-- 48 P0: запис 130 <--
78
° С. [20] <5.3> P1: прочетете 120 P1:

д. [20] <5.3> P1: четене 100 P1: запис

108 <-- 48 P1: запис 130 <--
78
5.3 [20] <5.2> Много протоколи за подслушване на кохерентност имат допълнителни състояния, преходи
на състояния или шинни транзакции, за да намалят режийните разходи за поддържане на
кохерентността на кеша. В Реализация 1 на Упражнение 5.2, пропуските водят до по-малко цикли
на спиране, когато се доставят от кеша, отколкото когато се доставят от паметта. Някои протоколи
за съгласуваност се опитват да подобрят производителността чрез увеличаване на честотата на
този случай. Обичайна оптимизация на протокола е въвеждането на притежавано състояние
(обикновено означавано O). Състоянието Owned се държи като Споделеното състояние, тъй като
възлите могат да четат само притежавани блокове, но се държи като модифицираното състояние,
тъй като възлите трябва да предоставят данни за пропуски на четене и запис на други възли в
притежавани блокове. Пропускане на четене на блок в състояния Модифициран или Притежаван
доставя данни на искащия възел и преминава към състояние Притежаван. Пропуснат запис в
блок в състояние Модифициран или Притежаван предоставя данни на искащия възел и

преминава към състояние Невалиден. Този оптимизиран MOSI протокол актуализира само
паметта, когато възел замени блок в състояние Модифициран или Притежаван. Начертайте нови
диаграми на протоколи с допълнително състояние и преходи.
5.4 [20/20/20/20] <5.2> За следните кодови последователности и времевите параметри за двете

реализации на Фигура 5.36, изчислете общите цикли на спиране за основния MSI протокол
и оптимизирания MOSI протокол в Упражнение 5.3. Да приемем, че преходите на
състояния, които не изискват автобусни транзакции, не водят до допълнителни цикли на спиране.
а. [20] <5.2> P0: четене на 110 P3:

четене на 110
P0: четене на 110
b. [20] <5.2> P1: четене на 120 P3:

P0: четене на 120
° С. [20] <5.2> P0: запис 120 <-- 80 P3: четене 120

P0: четене 120
д. [20] <5.2> P0: запис 108 <-- 88 P3: четене 108

P0: запис 108 <--
98
5.5 [20] <5.2> Някои приложения първо четат голям набор от данни, след което променят повечето или
всички от тях. Базовият протокол за кохерентност на MSI първо ще извлече всички кеш блокове
в споделено състояние и след това ще бъде принуден да извърши невалидна операция, за да ги
надстрои до модифицирано състояние. Допълнителното забавяне оказва значително влияние
върху някои натоварвания. Допълнителна оптимизация на протокола елиминира необходимостта
от надграждане на блокове, които се четат и по-късно записват от един процесор. Тази
оптимизация добавя състоянието Exclusive (E) към протокола, което показва, че никой друг
възел няма копие на блока, но той все още не е модифициран. Кеш блок влиза в изключително
състояние, когато пропуснатото четене е удовлетворено от паметта и никой друг възел няма
валидно копие. Процесорът чете и записва в този блок, продължавайки без по-нататъшен
трафик на шина, но записите на процесора карат състоянието на кохерентност да премине към
Модифицирано. Exclusive се различава от Modified, тъй като възелът може безшумно да замества
Exclusive блокове (докато Modified блоковете трябва да бъдат записани обратно в паметта).
Освен това пропускът при четене на изключителен блок води до преход към споделен, но не
изисква възелът да отговори с данни (тъй като паметта има актуално копие). Начертайте нови
диаграми на протоколи за протокол MESI, който добавя състоянието Exclusive и преминава към
състоянията Modified, Shared и Invalid на базовия MSI протокол.
5.6 [20/20/20/20/20] <5.2> Да приемем съдържанието на кеша на Фигура 5.35 и времето на Реализация 1
на Фигура 5.36. Какви са общите цикли на спиране за следващите кодови последователности
както с основния протокол, така и с новия протокол MESI в упражнение 5.5? Да приемем, че
преходите на състояния, които не изискват транзакции на взаимно свързване, не водят до
допълнителни цикли на спиране.
а. [20] <5.2> P0: четене на 100 P0: запис

на 100 <-- 40
b. [20] <5.2> P0: четене 120 P0: запис

120 <-- 60
° С. [20] <5.2> P0: четене на 100 P0:

д. [20] <5.2> P0: четене на 100 P1: запис

на 100 <-- 60
д. [20] <5.2> P0: четене на 100 P0: запис

на 100 <-- 60 P1: запис на 100
<-- 40
5.7 [20/20/20/20] <5.5> Заключването на въртене е възможно най-простият механизъм за синхронизиране

на повечето търговски машини със споделена памет. Това заключване на въртене разчита на
обменния примитив за атомно зареждане на старата стойност и съхраняване на нова стойност.
Програмата за заключване извършва операцията за обмен многократно, докато открие, че
заключването е отключено (т.е. върнатата стойност е 0):
DADDUI R2,R0,#1
блокировка: EXCH R2,0(R1)
BNEZ R2, lockit
Отключването на spin lock просто изисква съхраняване на стойността 0:
отключване: SW R0,0(R1)
Както беше обсъдено в раздел 5.5, по-оптимизираното заключване на въртене използва кохерентност на
кеша и използва натоварване, за да провери заключването, което му позволява да се върти със споделена
променлива в кеша:
lockit: LD R2, 0(R1)

BNEZ R2, lockit
ДАДДУИ R2,R0,#1
EXCH R2,0(R1)
BNEZ R2, lockit
Да приемем, че всички процесори P0, P1 и P3 се опитват да получат заключване на адрес 0x100

(т.е. регистър R1 съдържа стойност 0x100). Да приемем съдържанието на кеша от Фигура 5.35 и
параметрите за време от Реализация 1 на Фигура 5.36. За простота приемете, че критичните
секции са дълги 1000 цикъла. а. [20] <5.5> С помощта на обикновеното
заключване със завъртане определете приблизително колко цикъла на спиране на паметта

претърпява всеки процесор, преди да получи заключването.
b. [20] <5.5> Използвайки оптимизираното заключване на въртене, определете приблизително

колко цикъла на спиране на паметта претърпява всеки процесор, преди да получи
заключването. ° С. [20] <5.5> Използвайки обикновеното заключване на въртене, приблизително колко свързва
се случват транзакции?
д. [20] <5.5> Използване на функцията за тестване и тестване и задаване на центрофугиране, приблизително как
се случват много транзакции по взаимно свързване?
5.8 [20/20/20/20] <5.6> Последователната последователност (SC) изисква всички четения и записи да
изглеждат изпълнени в някакъв пълен ред. Това може да наложи процесорът да спре в
определени случаи, преди да изпълни инструкция за четене или запис. Разгледайте следната
кодова последователност:
напишете А,
прочетете Б
където записът A води до пропуск в кеша, а четенето B води до попадение в кеша.
При SC процесорът трябва да спре четенето B, докато не може да нареди (и по този начин да
извърши) запис A. Простите реализации на SC ще спрат процесора, докато кешът не получи
данните и може да извърши записа. По-слабите модели на последователност облекчават
ограниченията за подреждане при четене и запис, намалявайки случаите, в които процесорът
трябва да спре. Моделът на съгласуваност на Total Store Order (TSO) изисква всички записи да
изглеждат в общ ред, но позволява четенията на процесора да предават свои собствени записи.
Това позволява на процесорите да прилагат буфери за запис, които държат ангажирани записи,
които все още не са подредени по отношение на записи на други процесори. На четенията е
разрешено да преминат (и потенциално да заобиколят) буфера за запис в TSO (което не могат
да направят при SC). Да приемем, че една операция на паметта може да бъде изпълнена на
цикъл и че операциите, които попадат в кеша или които могат да бъдат удовлетворени от
буфера за запис, не въвеждат цикли на спиране. Пропуснатите операции водят до закъсненията, изброени
Да приемем съдържанието на кеша от Фигура 5.35. Колко цикъла на спиране възникват преди
всяка операция както за моделите на последователност SC, така и за TSO?
а. [20] <5.6> P0: запис 110 <-- 80 P0: четене 108
b. [20] <5.6> P0: запис 100 <-- 80 P0: четене 108
° С. [20] <5.6> P0: запис 110 <-- 80 P0: запис 100

<-- 90
д. [20] <5.6> P0: запис 100 <-- 80 P0: запис 110 <--
90
Казус 2: Проста кохерентност, базирана на директория
Преходи на протокол за кохерентност на директорията
Оптимизации на протокола за съгласуваност
Разгледайте системата с разпределена споделена памет, илюстрирана на фигура 5.37.

Състои се от два четириядрени чипа. Процесорът във всеки чип споделя L2 кеш (L2$) и
двата чипа са свързани чрез връзка от точка до точка. Системната памет е разпределена
между двата чипа. Фигура 5.38 увеличава част от тази система. Pi,j обозначава процесор i
в чип j. Всеки процесор има единичен директно картографиран L1 кеш, който съдържа
два блока, всеки от които съдържа две думи. Всеки чип има единичен директно
картографиран L2 кеш, който съдържа два блока, всеки от които съдържа две думи. За да
се опрости илюстрацията, таговете за адрес на кеша съдържат пълния адрес и всяка дума
показва само два шестнадесетични знака, като най-малко значимата дума е вдясно.
Състоянията на L1 кеша са обозначени с M, S и I за Modified, Shared и Invalid.
Както L2 кешовете, така и паметите имат директории. Състоянията на директорията са
обозначени като DM, DS и DI за Directory Modified, Directory Shared и Directory Invalid.
Простият протокол на директорията е описан на фигури 5.22 и 5.23. L2 директорията
изброява локалните споделящи/собственици и допълнително записва дали дадена линия
е споделена външно в друг чип; например P1,0;E означава, че дадена линия се споделя от
локалния процесор P1,0 и се споделя външно в някой друг чип. Директорията на паметта
има списък на споделящите чипове/собствениците на линия; например C0,C1 означава, че
една линия е споделена в чипове 0 и 1.
5.9 [10/10/10/10/15/15/15/15] <5.4> За всяка част от това упражнение приемете първоначалното

състояние на кеша и паметта на Фигура 5.38. Всяка част от това упражнение определя
последователност от една или повече операции на процесора във формата:
P#: <op> <адрес> [ <-- <стойност> ]

Чип0 Чип1
P0 P1 P0 P1
P3 P2 P3 P2
L2$ L2$
M0 M1
Фигура 5.37 Мултичип, многоядрен многопроцесор с DSM.
P0,0 P0,1 P3,1
Състояние на Адресен Състояние на Адресен Състояние на Адресен

кохерентност Данни кохерентност Данни ...... кохерентност етикет Данни
B0 М 00 10 B0 М 00 68 B0 С 120 00 108 00 20
B1 С 00
етикет 100 108 08 B1 С 00
етикет 130 118 18 B1 С 08
L2$, 0 L2$,1
Собственик/ Адресен собственик/ Адресен

Адрес състояние споделящи Данни Адрес Държавни делители етикет Данни
B0 DM P0,1 00 10 B0 DS P3,1 120 00 20

B1 ДС P0,0; д 00 08 B1 ДС Р3,1; д 108 00 08
B2 DM 00 68 B2 DI - - 00 10
P1,0
- -
B3 ДС P1,0 00130 11818
етикет 100 108 B3 DI 00 20
M0 M1
Адрес състояние Собственик/споделящи Данни Държава на адреса Собственик/споделящи Данни
100 DM C0 00 10 120 ДС C1 00 20
108 ДС C0, C1 00 08 128 DI - 00 28
110 DI - 00 10 130 DM C0 00 68
118 ДС C0 00 18 138 DI - 00 96
Фигура 5.38 Състояния на кеша и паметта в многочипов, многоядрен многопроцесор.
където P# обозначава CPU (напр. P0,0), <op> е операцията на CPU (напр. четене или запис),
<address> обозначава адреса на паметта и <value> посочва новата дума, която трябва да
бъде присвоена на запис операция. Какво е крайното състояние (т.е. състояние на
кохерентност, споделящи/собственици, тагове и данни) на кеш паметта и паметта след
завършване на дадената последователност от операции на процесора? Също така, каква
стойност се връща от всяка операция за четене?
а. [10] <5.4> P0,0: прочете 100 b. [10]
<5.4> P0,0: прочетете 128 c. [10] <5.4>
P0,0: запишете 128 <-- 78 d. [10] <5.4> P0,0: прочете
120 e. [15] <5.4> P0,0: прочете 120 P1,0:
прочете 120 f. [15] <5.4> P0,0: четене 120

P1,0: запис 120 <--
80
ж. [15] <5.4> P0,0: запис 120 <-- 80 P1,0: четене 120

h. [15] <5.4> P0,0:
запис 120 <-- 80 P1,0: запис 120 <-- 90
5.10 [10/10/10/10] <5.4> Протоколите на директорията са по-мащабируеми от подслушващите

протоколи, тъй като те изпращат изрични заявки и анулират съобщения до тези възли,
които имат копия на блок, докато подслушващите протоколи излъчват всички заявки и
анулират до всички възли. Разгледайте системата с осем процесора, илюстрирана на
Фигура 5.37 , и приемете, че всички непоказани кешове имат невалидни блокове. За всяка
от последователностите по-долу идентифицирайте кои възли (чип/процесор) получават
всяка заявка и ги анулирайте.
а. [10] <5.4> P0,0: запишете 100 <-- 80 b. [10] <5.4>
P0,0: запишете 108 <-- 88 c. [10] <5.4> P0,0: запишете
118 <-- 90 d. [10] <5.4> P1,0: напишете 128 <-- 98
5.11 [25] <5.4> Упражнение 5.3 ви помоли да добавите състоянието Owned към простия протокол за
наблюдение на MSI. Повторете въпроса, но с простия протокол на директорията по-горе.
5.12 [25] <5.4> Обсъдете защо добавянето на Изключително състояние е много по-трудно да се
направи с простия протокол на директорията, отколкото в протокола за наблюдение. Дайте
пример за видовете проблеми, които възникват.
Казус 3: Advanced Directory Protocol

Внедряване на протокол за съгласуваност на директориите
Оптимизации на протокола за кохерентност
Протоколът за кохерентност на директорията в Казус 2 описва кохерентността на директорията на абстрактно
ниво, но предполага атомарни преходи, подобно на простата система за наблюдение. Системите с
високопроизводителни директории използват конвейерни комутирани връзки

които значително подобряват честотната лента, но също така въвеждат преходни състояния и неатомични
сделки. Протоколите за кохерентност на кеша на директориите са по-мащабируеми от шпионирането
протоколи за кохерентност на кеша по две причини. Първо, подслушващите протоколи за кохерентност
на кеша излъчват заявки към всички възли, ограничавайки тяхната мащабируемост. Справочни протоколи
използвайте ниво на индиректност - съобщение до директорията - за да сте сигурни, че заявките са
изпраща се само до възлите, които имат копия на блок. Второ, адресната мрежа на a
системата за наблюдение трябва да доставя заявки в общ ред, докато протоколите на директорията
може да облекчи това ограничение. Някои протоколи на директория не предполагат мрежово подреждане,
което е полезно, тъй като позволява адаптивни техники за маршрутизиране за подобряване на мрежата
честотна лента. Други протоколи разчитат на ред от точка до точка (т.е. съобщения от възел
P0 до възел P1 ще пристигне по ред). Дори и с това ограничение за подреждане, директория
протоколите обикновено имат повече преходни състояния от шпионските протоколи. Фигура 5.39
Замяна препратено_ препратено_ ПоставетеM_
Държавно четене Пишете инв GetS GetM Ack Данни Последно потвърждение
аз Изпратете Изпратете грешка Изпратете грешка грешка грешка грешка грешка

GetS/ISD GetM/ Ack/I
IMAD
S Прочетете Изпрати аз Изпратете грешка грешка грешка грешка грешка
GetM/ Ack/I
IMAD
M Четене Пишете Изпращане грешка Изпратете Грешка при изпращане на данни/I грешка грешка
PutM/MIA данни, изпратете PutMS/
MSA
ISD z z z Изпратете грешка грешка грешка Запазване грешка

Ack/ISID Данни, направи
Прочети/С
ISID z z z Грешка при изпращане на Ack грешка грешка Запазване грешка
Данни, направи
Прочети/аз
IMAD z z z Грешка при изпращане на Ack грешка грешка Запазване грешка
Данни/
IMA
IMA z z z грешка IMSA IMIA грешка грешка Do Write/M
IMIA z z z грешка грешка грешка грешка грешка Do Write, send Data/

I
IMSA z z z Изпратете z z грешка грешка Напишете,

Ack/ изпратете данни/S
IMIA
MSA Прочетете z z грешка Изпращане на данни Изпращане на данни /С грешка грешка

МВР
МВР з z z грешка Изпращане на данни Изпращане на данни/I /I грешка грешка
Фигура 5.39 Преходи на кеш контролера за проследяване на излъчване.

PutMS PutMS
Състояние GetS GetM PutM (собственик) (несобственик) PutM (собственик) (несобственик)
DI Изпращане на данни, добавяне Изпращане на данни, изчистване грешка Грешка при изпращане на PutM_Ack Изпратете PutM_Ack
към споделящи/DS на споделящите, задаване на собственик/
DM
DS Изпращане на данни, добавяне Изпратете INV до грешка Грешка при изпращане на PutM_Ack Изпратете PutM_Ack
към споделящи/DS споделящите, задайте
собственик, изпратете данни/DM
DM Forward GetS, добави към Препратете GetM, Запазване на данни, изпращане Изпращане на PutM_Ack Запазване на данни, добавяне Изпратете PutM_Ack
споделящите/ изпратете INV до PutM_Ack/DI към споделящи, изпращане
DMSD споделящите, PutM_Ack/DS

изчистете споделящите, задайте собственик
DMSD Forward GetS, добавете Препращане на GetM, Запазване на данни, изпращане Изпращане на PutM_Ack Запазване на данни, добавяне Изпратете PutM_Ack
към споделящите изпращане на INV до PutM_Ack/DS към споделящи, изпращане
споделящи, изчистване PutM_Ack/DS

на споделящите, задаване на собственик/
DM
Фигура 5.40 Преходи на контролера на директорията.
представя преходите на състоянието на кеш контролера за опростен протокол на директория, който

разчита на мрежово подреждане от точка до точка. Фигура 5.40 представя преходите на състоянието на
контролера на директорията.
За всеки блок директорията поддържа състояние и текущо поле за собственик или

актуален списък на споделящите (ако има такъв). В името на следващата дискусия и
произтичащ проблем, приемете, че L2 кеш паметта е деактивирана. Да приемем, че
директорията на паметта изброява споделящите/собствениците при детайлност на процесора. Например,
на фигура 5.38 директорията на паметта за ред 108 ще бъде „P0, 0; P3, по-скоро 0”.
отколкото „C0, C1“. Освен това приемете, че съобщенията пресичат границите на чипа - ако е необходимо -
по прозрачен начин.
Редът се индексира от текущото състояние, а колоната от събитието определя кортежа <action/
nextstate> . Ако е посочено само следващо състояние, няма действие
изисква се. Невъзможните случаи са отбелязани с „грешка“ и представляват условия на грешка; "z"
означава, че заявеното събитие не може да бъде обработено в момента.
Следващият пример илюстрира основната работа на този протокол. Да предположим
процесор се опитва да запише в блок в състояние I (невалидно). Съответният кортеж
е „изпрати GetM/IMAD“, което показва, че кеш контролерът трябва да изпрати GetM
(GetModified) заявка към директорията и преминаване към състояние IMAD. В най-простите
В този случай съобщението за заявка намира директорията в състояние DI (Directory Invalid), което
показва, че никой друг кеш няма копие. Директорията отговаря със съобщение с данни
който съдържа и броя Acks, които да очаквате (в този случай нула). В този опростен протокол кеш
контролерът третира това едно съобщение като две съобщения:
Съобщение с данни, последвано от събитие Last Ack. Съобщението с данни се обработва първо,
запазване на данните и преминаване към IMA. След това събитието Last Ack се обработва,
преминаване към състояние M. Накрая записът може да се извърши в състояние M.
Ако GetM намери директорията в състояние DS (споделена директория), директорията
ще изпрати съобщения за невалидност (INV) до всички възли в списъка на споделящите, изпрати данни до
заявителя с броя споделящи и преход към състояние M. Когато INV съобщенията

пристигнат при споделящите, те ще намерят блока в състояние S или състояние I (ако
тихо са обезсилили блока). И в двата случая споделящият ще изпрати Ack директно до
искащия възел. Заявителят ще преброи Acks, които е получил, и ще ги сравни с броя,
изпратен обратно със съобщението с данни. Когато всички Acks са пристигнали,
възниква събитието Last Ack, което задейства кеша за преход към състояние M и
позволява записът да продължи. Обърнете внимание, че е възможно всички Acks да
пристигнат преди съобщението с данни, но не и събитието Last Ack. Това е така, защото
съобщението с данни съдържа броя на Ack. По този начин proto-col приема, че
съобщението Data е обработено преди събитието Last Ack.
5.13 [10/10/10/10/10/10] <5.4> Помислете за разширения протокол на директория, описан по-

горе, и съдържанието на кеша от Фигура 5.38. Каква е последователността от преходни
състояния, през които преминават засегнатите кеш блокове във всеки от следните случаи?
а. [10] <5.4> P0,0: прочете 100 b. [10]
<5.4> P0,0: прочетете 120 c. [10] <5.4>
P0,0: запишете 120 <-- 80 d. [10] <5.4> P3,1:
напишете 120 <-- 80 e. [10] <5.4> P1,0: прочетете
110 f. [10] <5.4> P0,0: напишете 108 <--
48
5.14 [15/15/15/15/15/15/15] <5.4> Разгледайте разширения протокол за директория, описан по-

горе, и съдържанието на кеша от Фигура 5.38. Каква е последователността от преходни
състояния, през които преминават засегнатите кеш блокове във всеки от следните
случаи? Във всички случаи приемете, че процесорите изпращат заявките си в един и
същи цикъл, но директорията подрежда заявките в ред отгоре надолу. Да приемем, че
действията на контролерите изглеждат атомарни (напр. контролерът на директорията
ще изпълни всички действия, необходими за прехода DS --> DM, преди да обработи
друга заявка за същия блок).
а. [15] <5.4> P0,0: прочете 120 P1,0:

прочете 120 b. [15]
<5.4> P0,0: четене 120 P1,0: запис 120

<-- 80 c. [15] <5.4> P0,0: запис
120 P1,0: четене 120
д. [15] <5.4> P0,0: запис 120 <-- 80 P1,0: запис 120

<-- 90
д. [15] <5.4> P0,0: замени 110 P1,0: прочете

110 f. [15] <5.4>
P1,0: запишете 110 <-- 80 P0,0: заменете 110
ж. [15] <5.4> P1,0: прочете 110 P0,0:

замени 110
5.15 [20/20/20/20/20] <5.4> За мултипроцесора, илюстриран на Фигура 5.37 (с дезактивирани L2 кешове), прилагащ
протокола, описан на Фигура 5.39 и Фигура 5.40, приемете следните закъснения: CPU четене и запис
на удари не генерира цикли на застой.
Завършването на пропуск (напр. направете Read и направете
Write) отнема цикли на липса само ако е извършено в отговор на събитието Last Ack (в противен случай
се извършва, докато данните се копират в кеша).
Четене или запис на CPU, което генерира събитие за замяна, издава съответното
съобщение GetShared или GetModified преди съобщението PutModified (например,
използвайки буфер за обратно записване).
Събитие на кеш контролера, което изпраща заявка или съобщение за потвърждение

(напр. GetShared) има цикли на забавяне Lsend_msg .
Събитие на кеш контролера, което чете кеша и изпраща съобщение с данни

латентност Lsend_data цикли.
Събитие на кеш контролера, което получава съобщение с данни и актуализира кеша, има латентност
Lrcv_data. Контролерът
на паметта получава Lsend_msg латентност, когато препраща заявка

съобщение.
Контролерът на паметта изисква допълнителен Linv брой цикли за всеки

анулира, че трябва да изпрати.
Кеш контролерът налага латентност Lsend_msg за всяко невалидно, което получава

(закъснението е, докато не изпрати съобщението Ack).
Контролерът на паметта има Lread_memory цикли за четене на паметта и изпращане на съобщение

с данни.
Контролерът на паметта има латентност Lwrite_memory за запис на съобщение с данни

памет (закъснението е, докато не изпрати съобщението Ack).
Съобщение без данни (напр. заявка, невалидност, Ack) има Lreq_msg цикли на мрежово забавяне.
Съобщението с
данни има мрежово забавяне Ldata_msg цикли. Добавяне на
латентност от 20 цикъла към всяко съобщение, което преминава от чип 0 към чип 1
и обратно.
Помислете за изпълнение с характеристиките на производителността, обобщени на Фигура 5.41.
За последователностите от операции по-долу, съдържанието на кеша на Фигура 5.38 и протокола

на директорията по-горе, каква е латентността, наблюдавана от всеки процесорен възел? а. [20] <5.4>
P0,0: прочете 100 b. [20] <5.4> P0,0: прочетете
128 c. [20] <5.4> P0,0: запишете 128 <-- 68 d.
[20] <5.4> P0,0: запишете 120 <-- 50 e. [20] <5.4> P0,0:
напишете 108 <-- 80

Действие Латентност
Send_msg 6
Изпращане на данни 20
Rcv_данни 15
Четене на паметта 100
Памет за запис 20
инв 1
акк 4
Req-msg 15
Data-msg 30
Фигура 5.41 Закъснения на кохерентността на директорията.
5.16 [20] <5.4> В случай на пропуск в кеша, както превключваният протокол за наблюдение
описано по-рано и протоколът на директорията в този казус изпълнява четенето или
напишете операция възможно най-скоро. По-специално, те правят операцията като част от
преходът към стабилно състояние, а не преход към стабилно състояние и
просто повторете операцията. Това не е оптимизация. По-скоро, за да се осигури напредък напред,
внедряванията на протоколи трябва да гарантират, че работят най-малко
една операция на процесора, преди да се откаже от блок. Да предположим, че протоколът за съгласуваност
внедряването не направи това. Обяснете как това може да доведе до livelock. Дай
прост примерен код, който може да стимулира това поведение.
5.17 [20/30] <5.4> Някои протоколи на директория добавят притежавано (O) състояние към proto-col, подобно на
обсъжданата оптимизация за протоколи за наблюдение. Притежаваното
състояние се държи като споделеното състояние, тъй като възлите могат да четат само притежавани блокове,
но се държи като модифицираното състояние, тъй като възлите трябва да предоставят данни на други
възли' Получаване на заявки към притежавани блокове. Притежаваната държава елиминира случая
където GetShared заявка към блок в състояние Modified изисква възелът да
изпрати данните както към процесора, който иска, така и към паметта. В MOSI
протокол на директория, искане за GetShared към блок или в Modified, или
Притежаваните състояния доставят данни на искащия възел и преминават към притежавания
състояние. Заявка GetModified в състояние Owned се обработва като заявка в състояние
Променен. Този оптимизиран MOSI протокол актуализира паметта само когато възел
замества блок в състояние Променен или Притежаван.
а. [20] <5.4> Обяснете защо състоянието на MSA в протокола по същество е „транс-

сиент” Собствено състояние.
b. [30] <5.4> Променете таблиците на кеша и протокола на директорията, за да поддържате стабилен

Собствена държава.
5.18 [25/25] <5.4> Усъвършенстваният протокол за директория, описан по-горе, разчита на подредена връзка от точка
до точка, за да осигури правилна работа. Приемайки първоначалното
съдържанието на кеша на Фигура 5.38 и следните последователности от операции, обяснете
какъв проблем може да възникне, ако връзката не успее да поддържа точка до точка
поръчване. Да приемем, че процесорите изпълняват заявките по едно и също време, но те се

обработват от директорията в показания ред.
а. [25] <5.4> P1,0: четене 110 P3,1: запис 110

<-- 90
b. [25] <5.4> P1,0: четене на 110 P0,0:

заместване на 110
5.19 [15] <5.1> Да приемем, че имаме функция за приложение от формата F(i, p), която дава частта от времето,
през което точно i процесори са използваеми, като се има предвид, че са налични общо p процесори.
Това означава, че
стр
F(i, p) 1 =
i =1
Да приемем, че когато i процесорите се използват, приложенията работят i пъти по-бързо.

Пренапишете закона на Амдал, така че да дава ускоряването като функция на p за някакво приложение.
5.20 [15/20/10] <5.1> В това упражнение ние изследваме ефекта от топологията на мрежата за взаимно
свързване върху тактовите цикли на инструкция (CPI) на програми, изпълнявани на 64-процесорен
мултипроцесор с разпределена памет. Тактовата честота на процесора е 3,3 GHz, а базовият CPI на
приложение с всички препратки, попадащи в кеша, е 0,5. Да приемем, че 0,2% от инструкциите
включват справка за отдалечена комуникация. Цената на отдалечена комуникационна препратка е
(100 + 10h) ns, където h е броят на прехвърлянията в комуникационната мрежа, които отдалечената
препратка трябва да направи към паметта на отдалечения процесор и обратно. Да приемем, че
всички комуникационни връзки са двупосочни.
а. [15] <5.1> Изчислете разходите за отдалечена комуникация в най-лошия случай, когато 64-те
процесора са подредени като пръстен, като 8×8 процесорна мрежа или като хиперкуб.
(Съвет: Най-дългият комуникационен път на 2n хиперкуб има n връзки.)
b. [20] <5.1> Сравнете базовия CPI на приложението без отдалечена комуникация с CPI, постигнат с
всяка от трите топологии в част (a). ° С. [10] <5.1> Колко по-бързо е приложението без
отдалечена комуникация в сравнение с производителността му с отдалечена комуникация на всяка

от трите топологии в част (a).
5.21 [15] <5.2> Покажете как основният протокол за наблюдение от Фигура 5.7 може да бъде променен за
кеш за запис. Коя е основната хардуерна функционалност, която не е необходима при кеш за
записване в сравнение с кеша за обратно записване?
5.22 [20] <5.2> Добавяне на чисто ексклузивно състояние към основната кохерентност на шпионския кеш
протокол (Фигура 5.7). Покажете протокола във формата на Фигура 5.7.
5.23 [15] <5.2> Едно предложено решение за проблема с фалшивото споделяне е да се добави валиден бит на
дума. Това би позволило на протокола да обезсили дума, без да премахва целия блок, позволявайки
на процесора да запази част от блок в своя
кеш, докато друг процесор записва различна част от блока. Какви допълнителни усложнения се въвеждат
в основния протокол за кохерентност на кеша за наблюдение (Фигура 5.7), ако тази възможност е
включена? Не забравяйте да вземете предвид всички възможни действия на протокола.
5.24 [15/20] <5.3> Това упражнение изучава въздействието на агресивните техники за използване на паралелизма
на ниво инструкции в процесора, когато се използва при проектирането на многопроцесорни системи
със споделена памет. Помислете за две идентични системи с изключение на процесора. Система A
използва процесор с обикновен редов конвейер с единичен проблем, докато система B използва
процесор с четирипосочен проблем, изпълнение извън реда и буфер за пренареждане с 64 записа. а.
[15] <5.3> Следвайки конвенцията от Фигура 5.11, нека
разделим времето за изпълнение на изпълнение на инструкции, достъп до кеша, достъп до паметта и

други застоявания. Как бихте очаквали всеки от тези компоненти да се различава между система А
и система Б?
b. [10] <5.3> Въз основа на обсъждането на поведението на работното натоварване на онлайн
обработката на транзакции (OLTP) в раздел 5.3, каква е важната разлика между работното
натоварване на OLTP и други показатели, които ограничават ползата от по-агресивен дизайн на
процесора?
5.25 [15] <5.3> Как бихте променили кода на приложение, за да избегнете фалшиво споделяне? Какво може да се
направи от компилатор и какво може да изисква програмни директиви?
5.26 [15] <5.4> Да приемем базиран на директория протокол за кохерентност на кеша. В момента директорията
има информация, която показва, че процесорът P1 има данните в „изключителен“ режим. Ако сега
директорията получи заявка за същия кеш блок от процесор P1, какво може да означава това? Какво
трябва да прави контролерът на директория?
(Такива случаи се наричат състезателни условия и са причината, поради която протоколите за
съгласуваност са толкова трудни за проектиране и проверка.)
5.27 [20] <5.4> Контролер на директория може да изпраща невалидни за редове, които са били заменени от
локалния кеш контролер. За да се избегнат подобни съобщения и да се поддържа последователност на
директорията, се използват съвети за заместване. Такива съобщения казват на контролера, че даден
блок е сменен. Променете протокола за съгласуваност на директорията от раздел 5.4 , за да използвате
такива подсказки за заместване.
5.28 [20/30] <5.4> Един недостатък на директното внедряване на директории, използващи напълно попълнени
битови вектори, е, че общият размер на информацията на директорията се мащабира като продукт (т.е.
брой процесор × блокове памет). Ако паметта се увеличава линейно с броя на процесорите, общият
размер на директорията нараства квадратично в броя на процесорите. На практика, тъй като
директорията се нуждае само от 1 бит на блок памет (който обикновено е от 32 до 128 байта), този
проблем не е сериозен за малък до умерен брой процесори. Например, ако приемем 128-байтов блок,
обемът на съхранението на директорията в сравнение с основната памет е броят на процесорите/1024,
или около 10% допълнително място за съхранение със 100 процесора. Този проблем може да бъде
избегнат, като се отбележи, че трябва да съхраняваме само количество информация, което е
пропорционално на размера на кеша на всеки процесор. Ние изследваме някои решения в тези
упражнения.
а. [20] <5.4> Един метод за получаване на мащабируем протокол за директория е да се организира

мултипроцесорът като логическа йерархия с процесорите като листа на
йерархия и директории, разположени в основата на всяко поддърво. Директорията
във всяко поддърво записва кои наследници кешират кои блокове памет, като
както и кои блокове памет с дом в това поддърво са кеширани извън
поддървото. Изчислете количеството памет, необходимо за запис на процесора
информация за директориите, като се приема, че всяка директория е напълно асоциативна.
Вашият отговор трябва да включва и броя на възлите във всеки
ниво на йерархията, както и общия брой възли.
b. [30] <5.4> Алтернативен подход за прилагане на схеми на директории е да

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

кешира блока. Използвайки следи от изпълнение на 64 процесора, симулирайте поведението на
тези схеми. Да приемем перфектен кеш за несподелени препратки, така че
да се съсредоточи върху кохерентното поведение. Определете броя на външните невалидности,
тъй като размерът на кеша на директорията се увеличава.
5.29 [10] <5.5> Приложете класическата инструкция за тестване и задаване, като използвате load-linked/
двойка условни инструкции магазин .
5.30 [15] <5.5> Една често използвана оптимизация на производителността е да се добавят променливи за
синхронизиране, за да няма други полезни данни в същия кеш ред като променливата за
синхронизиране. Конструирайте патологичен пример, когато не правите това, можете
наранено представяне. Да приемем протокол за подслушване на невалиден запис.
5.31 [30] <5.5> Една възможна реализация на load-linked/store-conditional

двойка за многоядрени процесори е да ограничи тези инструкции до използване на некеширани
операции с паметта. Един монитор прихваща всички четения и записи от всяко ядро
към паметта. Той следи източника на свързаните с натоварването инструкции и
дали възникват междинни запаметявания между свързаната с натоварване и съответната условна
инструкция за запаметяване. Мониторът може да предотврати всяка повреда
съхранява условно от записване на каквито и да е данни и може да използва сигналите за взаимно свързване, за да
информирайте процесора, че това съхраняване е неуспешно. Проектирайте такъв монитор за памет

система, поддържаща четириядрен симетричен мултипроцесор (SMP). Вземете в
акаунт, който по принцип заявките за четене и запис могат да имат различни размери на данни
(4, 8, 16, 32 байта). Всяко място в паметта може да бъде целта на свързана с натоварване/
съхранявайте условна двойка и мониторът на паметта трябва да приеме, че load-linked/
условните препратки към всяко местоположение могат евентуално да бъдат вплетени
редовен достъп до едно и също място. Сложността на монитора не трябва да зависи от размера на
паметта.
5.32 [10/12/10/12] <5.6> Както беше обсъдено в Раздел 5.6, моделът на последователност на паметта
предоставя спецификация за това как системата памет ще изглежда на програмиста. Разгледайте следния
кодов сегмент, където са първоначалните стойности
A=флаг=C=0.
P1 P2
A= 2000 докато (флаг ==1){;}
флаг=1 C=A
а. [10] <5.6> В края на кодовия сегмент каква е стойността, която бихте искали
очаквам за C?
b. [12] <5.6> Система с мрежа за взаимно свързване с общо предназначение, базиран на директория
протокол за кохерентност на кеша и поддръжка за неблокиращи зареждания генерира резултат,
където C е 0. Опишете сценарий, при който този резултат е възможен.
° С. [10] <5.6> Ако искате да направите системата последователно последователна, какво
какви са основните ограничения, които трябва да наложите?
Да приемем, че процесорът поддържа модел на спокойна консистенция на паметта. А
моделът на спокойна последователност изисква синхронизацията да бъде изрично идентифицирана.
Да приемем, че процесорът поддържа „бариерна“ инструкция, която гарантира, че всички
операциите с паметта, предшестващи инструкцията за бариера, са завършени, преди всички операции с
паметта, следващи бариерата, да могат да започнат. Къде бихте
включете инструкции за бариера в горния кодов сегмент, за да сте сигурни, че получавате
„интуитивни резултати“ на последователна последователност?
5.33 [25] <5.7> Докажете, че в кеш йерархия на две нива, където L1 е по-близо до
процесор, включването се поддържа без допълнително действие, ако L2 има поне толкова
асоциативност като L1, и двата кеша използват замяна на заменяема единица (LRU) и
и двата кеша имат еднакви размери на блокове.
5.34 [Дискусия] <5.7> Когато се опитвате да извършите подробна оценка на ефективността на a
многопроцесорна система, системните дизайнери използват един от трите инструмента: аналитични
модели, симулация, управлявана от проследяване, и симулация, управлявана от изпълнение. Аналитични модели
използват математически изрази, за да моделират поведението на програмите. Задвижван от проследяване
симулациите изпълняват приложенията на реална машина и обикновено генерират следа
на операции с памет. Тези следи могат да се възпроизвеждат чрез кеш симулатор или
симулатор с прост процесорен модел за прогнозиране на производителността на системата при промяна
на различни параметри. Симулаторите, управлявани от изпълнението, симулират
цялото изпълнение поддържа еквивалентна структура за състоянието на процесора
и така нататък. Какви са компромисите между точността и скоростта между тези подходи?
5.35 [40] <5.7, 5.9> Мултипроцесорите и клъстерите обикновено показват повишение на производителността
докато увеличавате броя на процесорите, като идеалното е n × ускоряване за
n процесори. Целта на този пристрастен бенчмарк е да се направи програма, която получава
по-лоша производителност при добавяне на процесори. Това означава, например, че един процесор на
мултипроцесора или клъстера изпълнява програмата най-бързо, два са по-бавни,
четири са по-бавни от две и т.н. Какви са основните характеристики на ефективността
за всяка организация, която дава обратно линейно ускорение?

6.2 Програмни модели и работни натоварвания за складови компютри 436

6.3 Компютърна архитектура на складови компютри 441
6.4 Физическа инфраструктура и разходи за компютри от складов мащаб 446

6.5 Облачни изчисления: Завръщането на помощните изчисления 455
6.7 Събираме всичко заедно: Компютър с мащаб на Google Warehouse 464

6.10 Исторически перспективи и препратки 476

Компютри с мащаб на склад за
използване на ниво на заявка и

Паралелизъм на ниво данни 1
Центърът за данни е компютърът.
Луис Андре Барозу,

Google (2007)
Преди сто години компаниите спряха да генерират собствена енергия с парни

машини и динамо и се включиха в новоизградената електрическа мрежа.
Евтината енергия, изпомпвана от електроснабдителните компании, не
просто промени начина, по който работят предприятията. Той задейства
верижна реакция от икономически и социални трансформации, довели до
съществуването на съвременния свят. Днес е в ход подобна революция.
Свързани с глобалната изчислителна мрежа на Интернет, масивни инсталации
за обработка на информация започнаха да изпомпват данни и софтуерен код в
нашите домове и фирми. Този път компютрите се превръщат в помощна програма.
Никълъс Кар
The Big Switch: Rewiring the World, от
Edison to Google (2008)

432 Глава шеста Компютри с мащаб на склад за използване на паралелизъм на ниво заявка и ниво данни
Всеки може да изгради бърз процесор. Номерът е да се изгради бърза система.
Сиймор Крей
Считан за бащата на суперкомпютъра
Складовият компютър (WSC)1 е в основата на интернет услугите

много хора използват всеки ден: търсене, социални мрежи, онлайн карти, споделяне на видео, онлайн
пазаруване, имейл услуги и т.н. Огромната популярност на
такива интернет услуги наложиха създаването на WSC, които да могат да се справят с тях
бързите изисквания на обществеността. Въпреки че WSC може да изглеждат просто големи
центрове за данни, тяхната архитектура и работа са доста различни, както ще видим.
Днешните WSC действат като една гигантска машина и струват от порядъка на $150 милиона за
сградата, електрическата и охладителната инфраструктура, сървърите и мрежите
оборудване, което свързва и помещава 50 000 до 100 000 сървъра. Освен това,
бързият растеж на облачните изчисления (вижте раздел 6.5) прави WSC достъпни за всеки с кредитна
карта.
Компютърната архитектура се простира естествено до проектирането на WSC. Например,

Луиз Барозу от Google (цитиран по-рано) прави дисертационно изследване в областта на компютъра
архитектура. Той вярва, че уменията на архитекта да проектира за мащаб, да проектира за
надеждността и уменията за отстраняване на грешки в хардуера са много полезни при създаването и
работата на WSC.
В този изключителен мащаб, който изисква иновации в разпределението на енергия, охлаждането,
наблюдението и операциите, WSC е съвременният наследник на суперкомпютъра, което прави Сиймор
Крей кръстник на днешните WSC архитекти. Неговата
екстремните компютри се справят с изчисления, които не могат да бъдат направени никъде другаде, но
бяха толкова скъпи, че само няколко компании можеха да си ги позволят. Този път на
целта е предоставяне на информационни технологии за света вместо високопроизводителни
изчисления (HPC) за учени и инженери; следователно WSC вероятно играят по-важна роля за
обществото днес, отколкото суперкомпютрите на Cray
в миналото.
Безспорно WSCs имат много повече потребители от
високопроизводителни изчисления и те представляват много по-голям дял от ИТ
пазар. Независимо дали се измерва чрез брой потребители или приходи, Google е поне 250
пъти по-голям от Cray Research някога.
1
Тази глава се основава на материал от книгата Центърът за данни като компютър: Въведение в дизайна на
Warehouse-Scale Machines, от Луиз Андре Барозу и Урс Хьолцле от Google [2009]; блогът Perspectives at
mvdirona.com и разговорите „Икономиите от мащаба на компютърните облаци“ и „Мрежите на центрове за данни са на пътя ми“,
от Джеймс Хамилтън от Amazon Web Services [2009, 2010]; и техническия доклад Над облаците: Бъркли
Изглед на облачните изчисления, от Майкъл Армбруст и др. [2009].
Архитектите на WSC споделят много цели и изисквания със сървърните архитекти:
Разходи-изпълнение – Извършената работа на долар е критична отчасти поради мащаба. Намаляването

на капиталовите разходи на WSC с 10% може да спести $15 милиона.
Енергийна ефективност — Разходите за разпределение на електроенергия са функционално свързани

с консумацията на енергия; имате нужда от достатъчно разпределение на мощността, преди да
можете да консумирате енергия. Разходите на механичната система са функционално свързани с
мощността: Трябва да отделите топлината, която влагате. Следователно пиковата мощност и
консумираната мощност водят както до разходите за разпределение на енергия, така и до разходите
за охладителни системи. Освен това енергийната ефективност е важна част от опазването на
околната среда. Следователно работата, извършена на джаул, е от решаващо значение както за WSC,
така и за сървърите поради високите разходи за изграждане на захранващата и механична
инфраструктура за склад от компютри и за месечните сметки за комунални услуги за захранване на сървъри.
Надеждност чрез излишък— Дълготрайният характер на Интернет услугите означава, че хардуерът и

софтуерът в WSC трябва колективно да осигуряват най-малко 99,99% наличност; това означава, че
трябва да прекъсва по-малко от 1 час на година.
Резервирането е ключът към надеждността както за WSC, така и за сървърите. Докато сървърните
архитекти често използват повече хардуер, предлаган на по-високи цени, за да постигнат висока
достъпност, WSC архитектите разчитат вместо това на множество рентабилни сървъри, свързани
чрез евтина мрежа и резервиране, управлявано от софтуер.
Освен това, ако целта е да надхвърлите „четири деветки“ на наличност, имате нужда от множество
WSC, за да маскирате събития, които могат да извадят цели WSC.
Множеството WSC също намаляват забавянето за услуги, които са широко разпространени.
Мрежов вход/изход – архитектите на сървъра трябва да осигурят добър мрежов интерфейс към външния
свят, както и архитектите на WSC също. Необходима е работа в мрежа, за да се поддържат
последователни данни между множество WSC, както и за интерфейс с обществеността. Работни
натоварвания както при интерактивна, така и при пакетна обработка – докато очаквате високо
интерактивни натоварвания за услуги като търсене и социални мрежи с милиони потребители,
WSC, подобно на сървърите, също изпълняват масивни паралелни пакетни програми за изчисляване
на метаданни, полезни за такива услуги. Например, задачите на MapReduce се изпълняват, за да
преобразуват страниците, върнати от обхождане на мрежата, в индекси за търсене (вижте раздел
6.2).
Не е изненадващо, че има и характеристики, които не са споделени със сървърната архитектура:
Достатъчен паралелизъм – Притеснение за сървърния архитект е дали приложенията в целевия пазар

имат достатъчно паралелизъм, за да оправдаят количеството паралелен хардуер и дали цената е
твърде висока за достатъчен комуникационен хардуер, който да използва този паралелизъм.
Архитектът на WSC няма такова притеснение. Първо, груповите приложения се възползват от
големия брой независими набори от данни, които изискват независима обработка, като например
милиарди уеб страници от уеб обхождане. Тази обработка е паралелизъм на ниво данни , прилаган
към данни в хранилище вместо към данни в памет, което видяхме в глава 4. Второ, приложенията за
интерактивни интернет услуги, известни също като софтуер като услуга (SaaS), могат да се възползват
от милиони независими потребители на интерактивния интернет
434 Глава шеста Компютри с мащаб на склад за използване на паралелизма на ниво заявка и ниво данни
услуги. Четенето и записването рядко са зависими в SaaS, така че SaaS рядко трябва да се
синхронизира. Например търсенето използва индекс само за четене, а имейлът обикновено е
информация, независима от четене и писане. Ние наричаме този тип лесен паралелизъм
паралелизъм на ниво заявка, тъй като много независими усилия могат да протичат паралелно
естествено с малка нужда от комуникация или синхронизация; например актуализирането на
базата на журнал може да намали изискванията за пропускателна способност.
Като се има предвид успехът на SaaS и WSC, по-традиционните приложения като релационни бази
данни са отслабени, за да разчитат на паралелизъм на ниво заявка.
Дори зависещите от четене/запис функции понякога отпадат, за да предложат съхранение, което
може да се мащабира до размера на съвременните WSC.
Отчитат се оперативните разходи – архитектите на сървъри обикновено проектират системите си за

върхова производителност в рамките на бюджета на разходите и се тревожат за мощността само
за да се уверят, че няма да надвишат капацитета за охлаждане на корпуса си. Те обикновено
пренебрегват оперативните разходи на сървъра, като приемат, че те бледнеят в сравнение с
разходите за покупка. WSC имат по-дълъг експлоатационен живот – сградата и електрическата и
охладителната инфраструктура често се амортизират за 10 или повече години – така че оперативните
разходи се сумират: енергията, разпределението на електроенергия и охлаждането представляват
повече от 30% от разходите на WSC за 10 години.
Мащаб и възможностите/проблемите, свързани с мащаба – Често екстремните компютри са

изключително скъпи, защото изискват персонализиран хардуер, но въпреки това разходите за
персонализиране не могат да бъдат ефективно амортизирани, тъй като се правят малко екстремни
компютри. Въпреки това, когато закупите 50 000 сървъра и инфраструктурата, която върви с тях, за
да изградите един WSC, вие наистина получавате отстъпки за обем. WSC са толкова масивни
вътрешно, че получавате икономия от мащаба, дори ако няма много WSC. Както ще видим в раздели
6.5 и 6.10, тези икономии от мащаба доведоха до облачни изчисления, тъй като по-ниските разходи
на единица за WSC означаваха, че компаниите могат да ги наемат с печалба под тази, която струва
на външни лица да го направят сами. Обратната страна на 50 000 сървъра са провалите. Фигура 6.1
показва прекъсвания и аномалии за 2400 сървъра. Дори ако един сървър има средно време до
повреда (MTTF) от невероятните 25 години (200 000 часа), WSC архитектът ще трябва да проектира
за 5 сървърни повреди на ден.
Фигура 6.1 показва годишния процент на отказ на диска като 2% до 10%. Ако имаше 4 диска на
сървър и техният годишен процент на отказ е 4%, при 50 000 сървъра WSC архитектът би трябвало
да очаква да види един диск да се поврежда на час .
Пример Изчислете наличността на услуга, работеща на сървърите 2400 на Фигура 6.1.

За разлика от услуга в истински WSC, в този пример услугата не може да толерира хардуерни или
софтуерни повреди. Да приемем, че времето за рестартиране на софтуера е 5 минути, а времето за
ремонт на хардуера е 1 час.
Отговор Можем да оценим наличността на услугата, като изчислим времето на прекъсвания поради повреда на всеки
компонент. Ще вземем консервативно най-ниското число във всяка категория на Фигура 6.1 и ще
разделим 1000 прекъсвания поравно между четири компонента. Ние игнорираме бавните дискове -
петият компонент от 1000 прекъсвания - оттогава
Прибл. брой събития

през 1-ва година Причина Последица
1 или 2 Неизправности в електрозахранването Загуба на мощност на целия WSC; не сваля WSC, ако UPS и генераторите работят
(генераторите работят около 99% от времето).
Планирано прекъсване за надграждане на инфраструктурата, много пъти за

развиващи се мрежови нужди като повторно окабеляване, за превключване на надстройки
4 Клъстерни надстройки
на фърмуера и т.н. Има около 9 планирани прекъсвания на клъстера за всяко
непланирано прекъсване.
Неизправности на твърдия диск 2% до 10% годишен процент на повреда на диска [Pinheiro 2007]
Бавни дискове Все още работи, но работи 10 пъти до 20 пъти по-бавно
Лоши спомени Една некоригируема DRAM грешка на година [Schroeder et al. 2009]
1000-те
Неправилно конфигурирани машини Конфигурацията доведе до ~30% от прекъсванията на обслужването [Barroso и HÖlzle
2009]
Слаби машини 1% от сървърите се рестартират повече от веднъж седмично [Barroso and HÖlzle 2009]
5000 Индивидуален сървър се срива Рестартиране на машината, обикновено отнема около 5 минути
Фигура 6.1 Списък на прекъсванията и аномалиите с приблизителната честота на възникване през първата година на
нов клъстер от 2400 сървъра. Означаваме това, което Google нарича клъстер, като масив; виж Фигура 6.5. (Въз основа на Barroso [2010].)
те влошават производителността, но не и наличността, както и повреди в електрозахранването, тъй като

системата за непрекъсваемо захранване (UPS) крие 99% от тях.
+
= ( + ( 4 250 250 250 +++ × 1) час 250 5000 ) × 5
Часове прекъсване на услугатаминути
754 438 1192 часа =+=
Тъй като има 365 × 24 или 8760 часа в годината, наличността е:
( 8760 1192 – ) 7568

= ==----------------------------------
----------- 86%
Система за наличност 8760 8760
Тоест, без излишък на софтуер, който да маскира многото прекъсвания, услугата е включена
тези 2400 сървъра ще бъдат изключени средно един ден в седмицата или нула девет
наличност!
Както се обяснява в раздел 6.10 , предшествениците на WSC са компютърни клъстери.

Клъстерите са колекции от независими компютри, които са свързани заедно
използване на стандартни локални мрежи (LAN) и готови комутатори. За работни
натоварвания, които не изискват интензивна комуникация, клъстерите предлагат много повече
рентабилни изчисления от мултипроцесорите със споделена памет. (Споделена памет
мултипроцесорите бяха предшествениците на многоядрените компютри, за които се говори
Глава 5.) Клъстерите станаха популярни в края на 90-те години за научни изчисления и
след това по-късно за интернет услуги. Едно виждане за WSC е, че те са просто логични
еволюция от клъстери от стотици сървъри до десетки хиляди сървъри
днес.
Естествен въпрос е дали WSC са подобни на съвременните клъстери за

високопроизводителни изчисления. Въпреки че някои имат подобен мащаб и цена – има
HPC дизайни с милион процесори, които струват стотици милиони долари – те обикновено
имат много по-бързи процесори и много по-бързи мрежи между възлите, отколкото в WSC,
тъй като HPC приложенията са по- взаимозависими и общуват по-често (вижте раздел 6.3).
HPC дизайните също са склонни да използват персонализиран хардуер - особено в мрежата
- така че често не получават ползите от разходите от използването на обикновени чипове.
Например, само микропроцесорът IBM Power 7 може да струва повече и да използва повече
енергия от цял сървърен възел в Google WSC. Средата за програмиране също набляга на
паралелизма на ниво нишка или паралелизъм на ниво данни (вижте глави 4 и 5), като
обикновено набляга на закъснението за изпълнение на една задача, за разлика от
честотната лента за изпълнение на много независими задачи чрез паралелизъм на ниво
заявка. HPC клъстерите също са склонни да имат дългосрочни задачи, които поддържат
сървърите напълно използвани, дори в продължение на седмици, докато използването на
сървъри в WSC варира между 10% и 50% (вижте Фигура 6.3 на страница 440 ) и варира всеки
ден.
Как се сравняват WSC с конвенционалните центрове за данни? Операторите на
конвенционален център за данни обикновено събират машини и софтуер на трети страни
от много части на организация и ги управляват централно за други. Техният основен фокус
обикновено е консолидирането на многото услуги върху по-малко машини, които са
изолирани една от друга, за да защитят чувствителната информация. Следователно
виртуалните машини са все по-важни в центровете за данни. За разлика от WSC,
конвенционалните центрове за данни са склонни да имат голяма част от хардуерната и
софтуерната хетерогенност, за да обслужват своите разнообразни клиенти в една
организация. Програмистите на WSC персонализират софтуер на трети страни или създават
свой собствен, а WSC имат много по-хомогенен хардуер; целта на WSC е да накара хардуера/
софтуера в склада да действа като единичен компютър, който обикновено изпълнява
различни приложения. Често най-големият разход в конвенционален център за данни са
хората, които го поддържат, докато, както ще видим в раздел 6.4, в добре проектиран WSC
сървърният хардуер е най-големият разход, а разходите за хора се изместват от най-горните
до почти неуместни. Конвенционалните центрове за данни също нямат мащаба на WSC,
така че те не получават икономическите ползи от мащаба, споменати по-горе. Следователно,
докато може да разглеждате WSC като екстремен център за данни, тъй като компютрите се
помещават отделно в пространство със специална електрическа и охлаждаща инфраструктура,
типичните центрове за данни споделят малко с предизвикателствата и възможностите на WSC, било то архитект
Тъй като малко архитекти разбират софтуера, който работи в WSC, ние започваме
с работното натоварване и модела на програмиране на WSC.
6.2 Програмни модели и работни натоварвания

за складови компютри
Ако проблемът няма решение, той може да не е проблем, а факт - не за разрешаване, а за
справяне с времето.
Шимон Перес
6.2 Модели за програмиране и работни натоварвания за компютри от складов мащаб 437
В допълнение към публичните интернет услуги като търсене, споделяне на видео и

социални мрежи, които ги правят известни, WSC също изпълняват пакетни приложения, като например
като конвертиране на видеоклипове в нови формати или създаване на индекси за търсене от уеб обхождания.
Днес най-популярната рамка за групова обработка в WSC е Map-Reduce [Dean and Ghemawat
2008] и нейният близнак с отворен код Hadoop. Фигура 6.2
показва нарастващата популярност на MapReduce в Google с течение на времето. (Фейсбук
изпълнява Hadoop на 2000 сървъра за пакетна обработка от 60 000 сървъра, които се очаква да
има през 2011 г.) Вдъхновен от функциите на Lisp със същото име, Map
първо прилага предоставена от програмиста функция към всеки запис на логически вход. Карта
работи на хиляди компютри, за да произведе междинен резултат от ключ-стойност
двойки. Reduce събира изхода от тези разпределени задачи и ги свива
използвайки друга функция, дефинирана от програмиста. С подходяща софтуерна поддръжка,
и двете са силно паралелни, но лесни за разбиране и използване. В рамките на 30 минути, a
начинаещ програмист може да изпълни задача MapReduce на хиляди компютри.
Например една програма MapReduce изчислява броя на срещанията на
всяка английска дума в голяма колекция от документи. По-долу е дадена опростена версия на
тази програма, която показва само вътрешния цикъл и предполага само едно срещане на всички
английски думи, намерени в документ [Dean and Ghemawat 2008]:
карта (ключ на низ, стойност на низ):

// ключ: име на документ
// стойност: съдържанието на документа
за всяка дума w в стойност:
EmitIntermediate(w, “1”); // Създаване на списък с всички думи
намали (ключ на низ, стойности на итератор):

// ключ: дума
// стойности: списък с преброявания
int резултат = 0;
за всеки v в стойности:
резултат += ParseInt(v); // получаваме цяло число от двойката ключ-стойност

Излъчване(AsString(резултат));
август-04 март-06 септември-07 септември-09
Брой задания на MapReduce 29 000 171 000 2 217 000 3 467 000
Средно време за завършване (секунди) 634 874 395 475
Използвани сървърни години 217 2002 г 11 081 25,562
Прочетени входни данни (терабайти) 3288 52,254 403 152 544,130
Междинни данни (терабайти) 758 6743 34 774 90,120
Записани изходни данни (терабайти) 193 2970 14 018 57,520
Среден брой сървъри на работа 157 268 394 488
Фигура 6.2 Годишно използване на MapReduce в Google с течение на времето. Повече от пет години
броят на заданията на MapReduce се увеличи с коефициент 100 и средният брой на
сървъри на работно място са се увеличили с фактор 3. През последните две години увеличенията бяха фактори
от 1,6 и 1,2, съответно [Dean 2009]. Фигура 6.16 на страница 459 оценява, че работи
работното натоварване за 2009 г. на услугата за облачни изчисления EC2 на Amazon ще струва 133 милиона долара.
Функцията EmitIntermediate, използвана във функцията Map, излъчва всяка дума

документът и стойността. След това функцията Reduce сумира всички стойности
на дума за всеки документ с помощта на ParseInt(), за да получите броя на срещанията
на дума във всички документи. Средата за изпълнение на MapReduce планира карта
задачи и редуцирайте задачата до възлите на WSC. (Пълната версия на програмата се намира в Dean and
Ghemawat [2004].)
MapReduce може да се разглежда като обобщение на единичната инструкция,
операция с множество данни (SIMD) (глава 4)—с изключение на това, че предавате функция на
да се приложи към данните - което е последвано от функция, която се използва при редукция
на изхода от задачата Map. Тъй като намаленията са ежедневие дори в
SIMD програмите, SIMD хардуерът често предлага специални операции за тях. За
например последните инструкции на Intel за AVX SIMD включват „хоризонтални“ инструкции
които добавят двойки операнди, които са съседни в регистрите.
За да се адаптира променливостта в производителността от хиляди компютри,
Планировчикът на MapReduce задава нови задачи въз основа на това колко бързо възлите изпълняват
предишни задачи. Очевидно една бавна задача може да задържи изпълнението на голяма
Задача MapReduce. В WSC решението за бавни задачи е предоставянето на софтуер
механизми за справяне с такава променливост, която е присъща на този мащаб. Това
подходът е в рязък контраст с решението за сървър в конвенционален център за данни, където
традиционно бавните задачи означават, че хардуерът е повреден и трябва да бъде
заменен или сървърният софтуер се нуждае от настройка и пренаписване. Хетерогенността на
производителността е норма за 50 000 сървъра в WSC. Например към края на
програма MapReduce, системата ще започне резервни копия на други възли на
задачите, които все още не са изпълнени, и вземете резултата от това, което завърши
първи. В замяна на увеличаване на използването на ресурси с няколко процента, Дийн и Гемават
[2008] установи, че някои големи задачи се изпълняват с 30% по-бързо.
Друг пример за това как WSC се различават е използването на репликация на данни за преодоляване
на грешки. Като се има предвид количеството оборудване в WSC, не е изненадващо
неуспехите са нещо обичайно, както показва предишният пример. За доставка на 99,99%
наличност, системният софтуер трябва да се справи с тази реалност в WSC. Да се намали
оперативни разходи, всички WSC използват автоматизиран софтуер за наблюдение, така че един оператор
да може да отговаря за повече от 1000 сървъра.
Програмни рамки като MapReduce за групова обработка и
външните SaaS, като търсенето, разчитат на вътрешни софтуерни услуги
техния успех. Например MapReduce разчита на файловата система на Google (GFS)
(Ghemawat, Gobioff и Leung [2003]) за доставяне на файлове на всеки компютър, така че
Задачите на MapReduce могат да бъдат планирани навсякъде.
В допълнение към GFS, примери за такива мащабируеми системи за съхранение включват системата
за съхранение на ключова стойност Dynamo на Ama-zon [DeCandia et al. 2007] и Google
система за съхранение на записи Bigtable [Chang 2006]. Имайте предвид, че такива системи често се изграждат
един върху друг. Например Bigtable съхранява своите регистрационни файлове и данни в GFS, както и
релационна база данни може да използва файловата система, предоставена от операционното ядро
система.
Тези вътрешни услуги често вземат различни решения от подобен софтуер
работещи на единични сървъри. Като пример, вместо да приемем, че съхранението е надеждно, като
например чрез използване на RAID сървъри за съхранение, тези системи често правят пълно
6.2 Програмни модели и работни натоварвания за компютри от складов мащаб 439
реплики на данните. Репликите могат да помогнат при производителността на четене, както и при
наличност; с правилно разположение репликите могат да преодолеят много други системи
повреди, като тези на фигура 6.1. Някои системи използват кодиране за изтриване вместо
пълни реплики, но константата е излишък между сървъри, а не резервиране в рамките на сървър или в
рамките на масив за съхранение. Следователно, повреда на целия сървър или
устройството за съхранение не влияе отрицателно върху наличността на данните.
Друг пример за различен подход е, че WSC софтуерът за съхранение често
използва спокойна последователност, вместо да следва всички изисквания на ACID (атомарност,
консистенция, изолация и издръжливост) на конвенционалните системи за бази данни.
Прозрението е, че е важно множество копия на данни да се съгласуват в крайна сметка,

но за повечето приложения не е необходимо да са в съгласие по всяко време. Например,
евентуалната последователност е добра за споделяне на видео. Евентуалната последователност прави съхранение
системите са много по-лесни за мащабиране, което е абсолютно изискване за WSC.

Изискванията към работното натоварване на тези обществени интерактивни услуги варират
значително; дори популярна глобална услуга като търсенето в Google варира с фактор
две в зависимост от времето на деня. Когато вземете предвид почивните дни, празниците и
популярни периоди от годината за някои приложения - като услуги за споделяне на снимки след Хелоуин
или онлайн пазаруване преди Коледа - можете да видите значително по-големи вариации в използването
на сървъра за интернет услуги. Фигура 6.3
показва средно използване на 5000 сървъра на Google за период от 6 месеца. Забележка
че по-малко от 0,5% от сървърите имат средно 100% използване, а повечето сървъри работят между 10%
и 50% използване. Алтернативно, само 10% от всички сървъри са били използвани повече от 50%.
Следователно е много по-важно за сървърите в
WSC, за да се представите добре, докато правите малко, отколкото просто да се представите ефективно
техния връх, тъй като те рядко работят в своя връх.
В обобщение, хардуерът и софтуерът на WSC трябва да се справят с променливостта на натоварването
въз основа на търсенето на потребителите и в производителността и надеждността поради капризите
хардуер в този мащаб.
Пример В резултат на измервания като тези на Фигура 6.3, бенчмарк SPECPower

измерва мощността и производителността от 0% натоварване до 100% на стъпки от 10% (вижте
Глава 1). Общият единичен показател, който обобщава този показател, е сумата
от всички мерки за производителност (операции на Java от страна на сървъра за секунда), разделени
чрез сумата от всички измервания на мощността във ватове. Следователно всяко ниво е еднакво вероятно.
Как би се променила обобщената метрика на числата, ако нивата бяха претеглени по
честотите на използване на фигура 6.3?
Отговор Фигура 6.4 показва оригиналните тегла и новите тегла, които съвпадат
Фигура 6.3. Тези претегляния намаляват обобщената производителност с 30% от
3210 ssj_ops/ват до 2454.
Като се има предвид мащабът, софтуерът трябва да се справя с повреди, което означава, че има малко
причина да закупите "позлатен" хардуер, който намалява честотата на повреди.

Основното въздействие би било увеличаване на разходите. Барозу и Хьолцле [2009]
установи коефициент 20 разлика в цена-производителност между висок клас
0,03
0,025
0,02
0,015
тЧ
сар
отемте о
в
0,01
0,005
0
0 0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 1.0
Използване на процесора
Фигура 6.3 Средно използване на процесора на повече от 5000 сървъра за 6 месеца

период в Google. Сървърите рядко са напълно неактивни или напълно използвани, вместо това работят
през повечето време между 10% и 50% от максималното им използване. (От фигура 1
в Barroso and Hölzle [2007].) Колоната трета отдясно на Фигура 6.4 изчислява проценти плюс или
минус 5%, за да се получат теглата; по този начин 1,2% за
90% ред означава, че 1,2% от сървърите са били използвани между 85% и 95%.
СПЕЦ Претеглени Претеглени Фигура 6.3 Претеглени претеглени

Производителност на натоварване ватове тегла производителност ватове тегла производителност ватове
100% 2,889,020 662 9,09% 262,638 60 0,80% 22,206 5
90% 2 611 130 617 9,09% 237,375 56 1,20% 31,756 8
80% 2 319 900 576 9,09% 210 900 52 1,50% 35,889 9
70% 2 031 260 533 9,09% 184,660 48 2,10% 42,491 11
60% 1 740 980 490 9,09% 158,271 45 5,10% 88,082 25
50% 1 448 810 451 9,09% 131,710 41 11,50% 166,335 52
40% 1 159 760 416 9,09% 105,433 38 19,10% 221,165 79
30% 869,077 382 9,09% 79,007 35 24,60% 213,929 94
20% 581,126 351 9,09% 52,830 32 15,30% 88,769 54
10% 290,762 308 9,09% 26,433 28 8,00% 23,198 25
0% 0 181 9,09% 0 16 10,90% 0 20
Обща сума 15,941,825 4967 1,449,257 452 933,820 380
ssj_ops/Watt 3210 ssj_ops/Watt 2454
Фигура 6.4 SPECPower резултат от Фигура 6.17, използвайки теглата от Фигура 6.3 вместо четни
тежести.
Мултипроцесор със споделена памет на HP и стоков сървър на HP при изпълнение на теста за

база данни TPC-C. Не е изненадващо, че Google купува сървъри за стоки от нисък клас.
Такива WSC услуги също са склонни да разработват собствен софтуер, вместо да купуват
търговски софтуер на трети страни, отчасти за да се справят с огромния мащаб и отчасти за
да спестят пари. Например, дори при най-добрата цена-производителност платформа за TPC-C
през 2011 г., включително цената на базата данни Oracle и операционната система Windows
удвоява цената на сървъра Dell Poweredge 710. За разлика от тях Google използва Bigtable и
операционната система Linux на своите сървъри, за които не плаща лицензионни такси.
Предвид този преглед на приложенията и системния софтуер на WSC, ние сме

готови да разгледаме компютърната архитектура на WSC.
6.3 Компютърна архитектура на компютри от

складов мащаб
Мрежите са съединителната тъкан, която свързва 50 000 сървъра. Аналогично на йерархията
на паметта от глава 2, WSC използват йерархия от мрежи. Фигура 6.5 показва един пример. В
идеалния случай комбинираната мрежа би осигурила почти производителността на
персонализиран комутатор от висок клас за 50 000 сървъра при почти цената на порт на
стандартен комутатор, предназначен за 50 сървъра. Както ще видим в раздел 6.6, настоящите
решения са далеч от този идеал и мрежите за WSC са област на активно проучване.
19-инчовият (48,26 см) шкаф все още е стандартната рамка за съхранение на сървъри,
въпреки че този стандарт се връща към железопътния хардуер от 30-те години на миналия
век. Сървърите се измерват в броя стелажни единици (U), които заемат в стелаж. Един U е
висок 1,75 инча (4,45 см) и това е минималното пространство, което един сървър може
заемат.
7-футов (213,36 см) шкаф предлага 48 U, така че не е случайно, че най-популярният
комутатор за шкаф е 48-портов Ethernet комутатор. Този продукт се превърна в стока, която
струва само $30 на порт за 1 Gbit/sec Ethernet връзка през 2011 г. [Barroso and Hölzle 2009].
Обърнете внимание, че честотната лента в стелажа е една и съща за всеки сървър, така че
няма значение къде софтуерът поставя изпращача и получателя, стига да са в един и същи
стелаж. Тази гъвкавост е идеална от гледна точка на софтуера.
Тези комутатори обикновено предлагат две до осем връзки нагоре, които напускат
стелажа, за да отидат до следващия по-висок комутатор в мрежовата йерархия. По този начин
честотната лента, излизаща от стелажа, е 6 до 24 пъти по-малка - 48/8 до 48/2 - от честотната
лента в стелажа. Това съотношение се нарича свръхзаписване. Уви, големият прекомерен
абонамент означава, че програмистите трябва да са наясно с последиците за
производителността, когато поставят податели и получатели в различни стелажи. Това
повишено натоварване на софтуерното планиране е друг аргумент за мрежовите комутатори,
проектирани специално за центъра за данни.
Раков
Превключвател на масив
превключвател
1U сървър
Стелаж
Фигура 6.5 Йерархия на комутаторите в WSC. (Въз основа на фигура 1.2 от Barroso и Hölzle
[2009].)
Съхранение
Естественият дизайн е да запълните стелаж със сървъри, без каквото и да е пространство, от което се
нуждаете за основния Ethernet суич за стелажи. Този дизайн оставя отворен въпроса къде да се постави
хранилището. От гледна точка на хардуерната конструкция, най-простото решение би било да се
включат дискове в сървъра и да се разчита на Ethernet свързаност за достъп до информация на
дисковете на отдалечени сървъри. Алтернативата би била да се използва мрежово прикачено
хранилище (NAS), може би през мрежа за съхранение като Infiniband. NAS решението обикновено е по-
скъпо на терабайт място за съхранение, но предоставя много функции, включително RAID техники за
подобряване на надеждността на хранилището.
Както можете да очаквате от философията, изразена в предишния раздел, WSC обикновено

разчитат на локални дискове и предоставят софтуер за съхранение, който се справя със свързаността
и надеждността. Например GFS използва локални дискове и поддържа поне три реплики, за да
преодолее проблемите с надеждността. Това резервиране покрива не само повреди на локален диск,
но и прекъсвания на захранването на стелажи и цели клъстери.
Евентуалната гъвкавост на последователността на GFS намалява разходите за поддържане на
последователност на репликите, което също намалява изискванията за мрежова честотна лента на хранилището
система. Моделите на локален достъп също означават висока честотна лента към локалното хранилище, както ще направим
вижте след малко.
Имайте предвид, че има объркване относно термина клъстер , когато говорим за

архитектура на WSC. Използвайки определението в Раздел 6.1, WSC е просто
изключително голям клъстер. За разлика от тях, Barroso и Hölzle [2009] използват термина
клъстер означава следващото по размер групиране на компютри, в този случай около 30 стелажа.
В тази глава, за да избегнем объркване, ще използваме термина масив за означаване на колекция
на стелажи, запазвайки първоначалното значение на думата клъстер, за да означава всичко
от колекция от мрежови компютри в стелаж до цял склад
пълен с мрежови компютри.
Array Switch
Превключвателят, който свързва масив от стелажи, е значително по-скъп от

Стандартен Ethernet комутатор с 48 порта. Тази цена се дължи отчасти на по-високата
свързаност и отчасти защото честотната лента през комутатора трябва да е много
по-висока, за да се намали проблемът със свръхабонамента. Барозу и Хьолцле [2009]
съобщава, че превключвател, който има 10 пъти по-голяма честотна лента на разделяне по две части - по същество,
вътрешна честотна лента в най-лошия случай—на суич за шкаф струва около 100 пъти повече.
Една от причините е, че цената на честотната лента на комутатора за n порта може да нарасне с n2.
Друга причина за високите разходи е, че тези продукти предлагат високи маржове на

печалба за компаниите, които ги произвеждат. Те оправдават такива цени отчасти с
предоставянето на функции като проверка на пакети, които са скъпи, защото трябва
работят на много високи нива. Например мрежовите комутатори са основните потребители на
чипове памет с адресируемо съдържание и програмируеми на полето гейт масиви
(FPGA), които спомагат за предоставянето на тези функции, но самите чипове са скъпи. Въпреки
че такива функции може да са ценни за интернет настройките, те обикновено са
неизползван в центъра за данни.
WSC Йерархия на паметта
Фигура 6.6 показва латентността, честотната лента и капацитета на йерархията на паметта

вътре в WSC, а Фигура 6.7 показва същите данни визуално. Тези цифри са
въз основа на следните предположения [Barroso and Hölzle 2009]:
Местен Стелаж Масив
DRAM латентност (микросекунди) 0,1 100 300
Закъснение на диска (микросекунди) 10 000 11 000 12 000
DRAM честотна лента (MB/сек) 20 000 100 10
Дискова честотна лента (MB/сек) 200 100 10
DRAM капацитет (GB) 16 1040 31 200
Капацитет на диска (GB) 2000 г 160 000 4 800 000
Фигура 6.6 Закъснение, честотна лента и капацитет на йерархията на паметта на WSC

[Барозу и Хьолцле 2009]. Фигура 6.7 изобразява същата тази информация.
10000000
Капацитет на диска (GB)

1000000
100 000
Дискова честотна лента (MB/сек)
10 000
Закъснение на диска (μsec)
DRAM капацитет (GB)

1000
Латентност на DRAM (μsec)
Дискова честотна лента (MB/сек)
100
10
1
DRAM честотна лента
(MB/сек)
0
Местен Стелаж Масив
Фигура 6.7 Графика на латентност, честотна лента и капацитет на йерархията на паметта на WSC за данни на Фигура
6.6 [Barroso and Hölzle 2009].
Всеки сървър съдържа 16 GB памет с време за достъп от 100 наносекунди и трансфери с 20 GBytes/
sec и 2 терабайта диск, който предлага време за достъп от 10 милисекунди и трансфери с 200
MBytes/sec. Има два гнезда на платка и те споделят един 1 Gbit/sec Ethernet порт.
Всяка двойка стелажи включва един суич за стелажи и побира 80 2U сървъра (вижте
раздел 6.7). Мрежовият софтуер плюс разходите за превключване увеличават
латентността към DRAM до 100 микросекунди и латентността на достъпа до диска до
11 милисекунди. По този начин общият капацитет за съхранение на стелаж е
приблизително 1 терабайт DRAM и 160 терабайта дисково пространство. 1 Gbit/sec
Ethernet ограничава дистанционната честотна лента към DRAM или диск в стелажа до 100 MBytes/sec.
Превключвателят за масив може да обработва 30 стелажа, така че капацитетът за съхранение на

масив се увеличава с фактор 30: 30 терабайта DRAM и 4,8 петабайта диск. Хардуерът и софтуерът
за превключване на масиви увеличават латентността към DRAM в рамките на масив до 500
микросекунди и латентността на диска до 12 милисекунди. Широчината на честотната лента на
превключвателя на масива ограничава отдалечената честотна лента към масив DRAM или
масивен диск до 10 MBytes/sec.
интернет интернет
CR CR
Център за данни
Слой 3
AR AR AR AR
...
Слой 2
LB С С LB
Ключ:
• CR = L3 основен рутер
• AR = L3 рутер за достъп
С С С С
... • S=Превключвател за масив
• LB= балансиращо натоварване
• A= Стелаж с 80 сървъра
с превключвател за стелажи
АА A AA A
.. ..
Фигура 6.8 Мрежата от слой 3, използвана за свързване на масиви заедно и към Интернет [Greenberg et al. 2009]. някои
WSC използват отделен граничен рутер за свързване на интернет към комутаторите на ниво 3 на центъра за данни.
Фигури 6.6 и 6.7 показват, че натоварването на мрежата драстично се увеличава

латентност от локална DRAM към стелажна DRAM и масивна DRAM, но и двете все още имат
повече от 10 пъти по-добра латентност от локалния диск. Мрежата срива
разлика в честотната лента между стелаж DRAM и стелаж диск и между масив
DRAM и масивен диск.
WSC се нуждае от 20 масива, за да достигне 50 000 сървъра, така че има още едно ниво
на мрежовата йерархия. Фигура 6.8 показва конвенционалните рутери от слой 3 към
свържете масивите заедно и към интернет.
Повечето приложения се побират в един масив в WSC. Тези, които имат нужда от повече
отколкото един масив използва шардинг или разделяне, което означава, че наборът от данни е разделен на
независими парчета и след това разпределени в различни масиви. Операции на

целият набор от данни се изпраща до сървърите, хостващи частите, и резултатите са
обединени от клиентския компютър.
Пример Каква е средната латентност на паметта, ако приемем, че 90% от достъпите са локални към
сървъра, 9% са извън сървъра, но в стелажа, а 1% са извън него
багажник, но в рамките на масива?
Отговор Средното време за достъп до паметта е
( () 9%
90%100
0,1××)++ ( 1% 300 × ) = 0,09 9 3 + + = 12,09 микросекунди
или коефициент повече от 120 забавяне спрямо 100% локален достъп. ясно,
местоположението на достъпа в сървъра е жизненоважно за производителността на WSC.
Пример Колко време отнема прехвърлянето на 1000 MB между дискове в сървъра, между сървъри в стелажа и между
сървъри в различни стелажи в масива?
Колко по-бързо е прехвърлянето на 1000 MB между DRAM в трите случая?
Отговор Прехвърляне на 1000 MB между дискове отнема:
В рамките на сървъра = 1000/200 = 5 секунди
В рамките на стелажа = 1000/100 = 10 секунди
В рамките на масива = 1000/10 = 100 секунди
Прехвърлянето на блок от памет към памет отнема
В рамките на сървъра = 1000/20000 = 0,05 секунди
В рамките на стелажа = 1000/100 = 10 секунди
В рамките на масива = 1000/10 = 100 секунди
По този начин, за блокови трансфери извън един сървър, дори няма значение дали данните са в
паметта или на диска, тъй като превключвателят на стелажа и превключвателят на масива са тесните
места. Тези ограничения на производителността засягат дизайна на софтуера WSC и вдъхновяват
необходимостта от превключватели с по-висока производителност (вижте раздел 6.6).
Като се има предвид архитектурата на ИТ оборудването, сега сме готови да видим как да го
приютим, захранваме и охладим и да обсъдим разходите за изграждане и експлоатация на целия
WSC в сравнение само с ИТ оборудването в него.
6.4 Физическата инфраструктура и разходите за

Складови компютри
За да изградите WSC, първо трябва да построите склад. Един от първите въпроси е къде? Агентите за
недвижими имоти наблягат на местоположението, но местоположението на WSC означава близост
до оптични влакна на интернет опората, ниска цена на електроенергия и нисък риск от екологични
бедствия, като земетресения, наводнения и урагани. За компания с много WSC друга грижа е
намирането на място географски близо до настояща или бъдеща популация от интернет потребители,
така че да се намали забавянето в интернет. Има и много по-обикновени проблеми, като ставките
на данъка върху имотите.
Инфраструктурните разходи за разпределение на електроенергия и охлаждане намаляват
разходите за изграждане на WSC, така че ние се концентрираме върху първото. Фигури 6.9 и 6.10
показват инфраструктурата за разпределение на електроенергия и охлаждане в WSC.
Въпреки че има много разгърнати вариации, в Северна Америка електрическото захранване
обикновено преминава през около пет стъпки и четири промени на напрежението по пътя към
сървъра, като се започне с високоволтовите линии на кулата от 115 000 волта: 1. Подстанцията
превключва от
115 000 волта до линии със средно напрежение на

13 200 волта, с ефективност 99,7%.
Разпределение
на високо напрежение
ИТ
Генератори
натоварване (сървъри, съхранение, мрежа, ...)
13,2
115
кв
кв
UPS & Gen
често на 480 v
~1% загуба в превключвателна
апаратура и проводници
80V
2
Подстанция UPS:
Трансформърс Трансформърс
Ротационен или акумулаторен
13,2 кв 13,2 кв 480 V
0,3% загуба 6% загуба 2% загуба 2% загуба

99,7% ефективност 94% ефективност, ~97% наличност 98% ефективност 98% ефективност
Фигура 6.9 Разпределение на мощността и къде възникват загуби. Имайте предвид, че най-доброто подобрение е 11%. (От Хамилтън
[2010].)
2. За да се предотврати спирането на целия WSC в случай на загуба на захранване, WSC има

непрекъсваемо захранване (UPS), точно както някои сървъри. В този случай това включва
големи дизелови двигатели, които могат да поемат управлението от комуналната компания при
авария и батерии или маховици за поддържане на захранването след прекъсване на услугата,
но преди дизеловите двигатели да са готови. Генераторите и батериите могат да заемат толкова
много място, че обикновено се намират в отделна стая от ИТ оборудването. UPS играе три роли:
кондициониране на мощността (поддържа правилни нива на напрежение и други
характеристики), задържане на електрическия товар, докато генераторите стартират и се
включват, и поддържане на електрическия товар при превключване обратно от генераторите
към електрическата мрежа. Ефективността на този много голям UPS е 94%, така че съоръжението
губи 6% от мощността, като има UPS. WSC UPS може да представлява 7% до 12% от цената на
цялото ИТ оборудване.
3. Следващият в системата е разпределителен блок за захранване (PDU), който се преобразува във

вътрешно трифазно захранване с ниско напрежение при 480 волта. Ефективността на
преобразуване е 98%. Типичният PDU се справя с натоварване от 75 до 225 киловата или около 10 рафта.
4. Има още една стъпка надолу към двуфазно захранване при 208 волта, което сървърите могат да
използват, отново при 98% ефективност. (Вътре в сървъра има още стъпки за намаляване на
напрежението до това, което чиповете могат да използват; вижте раздел 6.7.)
загуба
изпар
съоръ 448 Глава шеста Компютри с мащаб на склад за използване на паралелизъм на ниво заявка и ниво данни
Проду
~200
при
ден
gal/ 5. Конекторите, прекъсвачите и електрическото окабеляване към сървъра имат колектив
ефективност 99%.
WSC извън Северна Америка използват различни стойности на преобразуване, но цялостният

дизайн е подобен.
Обединявайки всичко това, ефективността на превръщането на 115 000 волта мощност от помощната
програма в 208 волта мощност, която сървърите могат да използват, е 89%:
99,7% × 94% × 98% × 98% × 99% = 89%

000
MW
Тази обща ефективност оставя само малко над 10% място за подобрение, но както ще видим,
инженерите все още се опитват да я направят по-добра.
Има значително повече възможности за подобряване на охладителната инфраструктура.
Устройството за климатизация на компютърната зала (CRAC) охлажда въздуха в сървърното
помещение с помощта на охладена вода, подобно на това как хладилникът премахва
от
топлината, като я освобождава извън хладилника. Тъй като течността абсорбира топлина, тя се изпарява.
Обратно, когато течността отделя топлина, тя кондензира. Климатиците изпомпват течността
в намотки под ниско налягане, за да се изпарят и абсорбират топлина, която след това се
изпраща към външен кондензатор, където се освобождава. По този начин в модул CRAC
вентилаторите изтласкват топъл въздух покрай набор от намотки, пълни със студена вода, а
помпа премества затоплената вода към външните чилъри, за да се охлади. Хладният въздух
и
за сървърите обикновено е между 64°F и 71°F (18°C и 22°C). Фигура 6.10 показва голямата
8
колекция от вентилатори и водни помпи, които движат въздух и вода в системата.
Първична
Топлообменник
помпа
Охладителна (Икономайзер от страната на водата)
кула
CWS A/C
помпа Кондензатор за климатик изпарител

климатик
компресор
Сървърни вентилатори от 6 до 9 W всеки Разредена топла/студена смес
Изтичане
Фенове Климатизатор
за
Студ компютърна зала
ощероГ
Въздушно работно колело

дутС
Фигура 6.10 Механичен дизайн за охладителни системи. CWS означава циркулираща водна система. (От Хамилтън
[2010].)
Ясно е, че един от най-простите начини за подобряване на енергийната ефективност е просто
работете с ИТ оборудването при по-високи температури, така че да не се налага въздухът да се охлажда
много. Някои WSC използват оборудването си при значително над 71°F (22°C).
В допълнение към чилърите, в някои центрове за данни се използват охладителни кули, за да се
използва по-студения външен въздух за охлаждане на водата, преди да бъде изпратена към чилърите. The
температурата, която има значение, се нарича температура на мокрия термометър. Температурата на мокрия
термометър се измерва чрез продухване на въздух в края на термометъра, който има
вода върху него. Това е най-ниската температура, която може да се постигне чрез изпаряване на водата
с въздух.
Топлата вода тече върху голяма повърхност в кулата, пренасяйки топлина към
външен въздух чрез изпаряване и по този начин охлаждане на водата. Тази техника се нарича
икономия на зоната за излитане и кацане. Алтернатива е да използвате студена вода вместо студен въздух.
WSC на Google в Белгия използва междинен охладител вода-вода, който приема студена вода
от индустриален канал за охлаждане на топлата вода от вътрешността на WSC.
Въздушният поток е внимателно планиран за самото ИТ оборудване с някои дизайни
дори при използване на симулатори на въздушен поток. Ефективните конструкции запазват температурата на
хладен въздух, като намали шансовете за смесване с горещ въздух. Например WSC може
има редуващи се канали за горещ въздух и студен въздух чрез ориентиране на сървъри в противоположни
посоки в редуващи се редове стелажи, така че горещият отработен въздух духа в редуващи се посоки.
Освен загубите на енергия, охладителната система изразходва и много вода
поради изпарение или разливи по канализационните тръби. Например съоръжение с мощност 8 MW
може да използва 70 000 до 200 000 галона вода на ден.
Относителните разходи за мощност на охлаждащото оборудване спрямо ИТ оборудването са типични

център за данни [Barroso and Hölzle 2009] са както следва:
Чилърите представляват 30% до 50% от мощността на ИТ оборудването.
CRAC представлява 10% до 20% от мощността на ИТ оборудването, което се дължи най-вече на феновете.
Изненадващо, не е очевидно да се разбере колко сървъра може WSC
поддръжка, след като извадите режийните разходи за разпределение на мощността и охлаждане. The
така наречената табелка на мощността от производителя на сървъра винаги е консервативна; това е
максималната мощност, която един сървър може да черпи. Тогава първата стъпка е да
измерване на един сървър при различни работни натоварвания, които да бъдат разгърнати в
WSC. (Мрежата обикновено е около 5% от консумацията на енергия, така че може да бъде
игнориран, за да започне.)
За определяне на броя на сървърите за WSC, наличната мощност за ИТ
може просто да се раздели на измерената мощност на сървъра; обаче, това би отново
бъдете твърде консервативни според Fan, Weber и Barroso [2007]. Намериха
че има значителна разлика между това, което хиляди сървъри теоретично биха могли да направят в най-
лошия случай, и това, което ще направят на практика, тъй като никакви реални работни натоварвания няма
да поддържат хиляди сървъри едновременно на техните върхове. Те
установиха, че могат безопасно да надвишат броя на сървърите с толкова
40% въз основа на мощността на един сървър. Те препоръчаха WSC
архитектите трябва да направят това, за да увеличат средното използване на мощността в рамките на a
WSC; въпреки това те също предложиха да се използва обширен софтуер за наблюдение

с механизъм за безопасност, който депланира задачи с по-нисък приоритет, в случай че работното

натоварване се измести.
Разграждайки потреблението на енергия в самото ИТ оборудване, Барозу и
Hölzle [2009] докладва следното за Google WSC, внедрен през 2007 г.:
33% мощност за процесори

30% за DRAM
10% за дискове
5% за работа в мрежа
22% за други причини (вътре в сървъра)
Измерване на ефективността на WSC
Широко използван прост показател за оценка на ефективността на център за данни или WSC се нарича
ефективност на използване на мощността (или PUE):
PUE = (Обща мощност на съоръжението)/(Мощност на ИТ оборудване)
Следователно PUE трябва да бъде по-голямо или равно на 1 и колкото по-голямо е PUE, толкова по-малко
ефективен е WSC.
Greenberg et al. [2006] докладва за PUE на 19 центъра за данни и частта от режийните разходи, които
отиват в инфраструктурата за охлаждане. Фигура 6.11 показва какво са открили, сортирани по PUE от най-до
най-малко ефективни. Средният PUE е 1,69, като инфраструктурата за охлаждане използва повече от
половината енергия от самите сървъри – средно 0,55 от 1,69 е за охлаждане. Имайте предвид, че това са
средни PUE, които могат да варират ежедневно в зависимост от натоварването и дори температурата на
външния въздух, както ще видим.
Тъй като ефективността на долар е най-добрият показател, ние все още трябва да измерваме
ефективността. Както показва фигура 6.7 по-горе, честотната лента спада и латентността се увеличава в
зависимост от разстоянието до данните. В WSC честотната лента на DRAM в сървър е 200 пъти по-голяма,
отколкото в стелаж, който от своя страна е 10 пъти по-голям, отколкото в масив. По този начин има друг вид
местоположение, което трябва да се има предвид при разполагането на данни и програми в WSC.
Докато дизайнерите на WSC често се фокусират върху честотната лента, програмистите, разработващи
приложения на WSC, също се интересуват от латентността, тъй като латентността е видима за потребителите.
Удовлетворението и производителността на потребителите са свързани с времето за реакция на услугата.
Няколко проучвания от дните за споделяне на време съобщават, че производителността на потребителите е
обратно пропорционална на времето за взаимодействие, което обикновено се разделя на време за влизане
на човек, време за реакция на системата и време, необходимо на човека да обмисли отговора, преди да влезе
следващото влизане. Резултатите от експериментите показват, че намаляването на времето за реакция на
системата за рязане с 30% намалява времето на взаимодействие със 70%. Този неправдоподобен резултат се
обяснява с човешката природа: хората се нуждаят от по-малко време за мислене, когато им се даде по-бърз
отговор, тъй като е по-малко вероятно да се разсейват и да останат „в движение“.
Фигура 6.12 показва резултатите от такъв експеримент за търсачката Bing, където закъснения от 50 ms
до 2000 ms бяха вмъкнати в сървъра за търсене. Както се очаква

1.33 ТО
1.35 AC
1.43 други
1.47
1.49
1.52
1.59
1.67
1,69
1,69
со
ети ев
нн лбе
яи тг)р аPн
кEетUф
н
о п
е
Е(
1,69
1.82
2.04
2.04
2.13
2.33
2.38
2.63
3.03
0 0,5 1 1.5 2 2.5 3 3.5
Фигура 6.11 Ефективност на използване на мощността на 19 центъра за данни през 2006 г. [Greenberg et al. 2006]. Силата за въздуха
кондициониране (AC) и други употреби (като разпределение на електроенергия) се нормализира към мощността за ИТ оборудването в
изчисляване на PUE. По този начин мощността за ИТ оборудване трябва да бъде 1,0 и AC варира от около 0,30 до 1,40 пъти
мощност на ИТ оборудването. Мощността за „други” варира от около 0,05 до 0,60 от ИТ оборудването.
от предишни проучвания, времето до следващото щракване приблизително удвоява забавянето; тоест 200
ms забавяне на сървъра доведе до 500 ms увеличение на времето до следващото щракване. приходи
спадна линейно с нарастващо забавяне, както и удовлетвореността на потребителите. Отделно изследване върху
търсачката на Google установи, че тези ефекти се задържат дълго след 4-те седмици
експериментът приключи. Пет седмици по-късно имаше 0,1% по-малко търсещи на ден
потребители, които са имали 200 ms закъснения и е имало 0,2% по-малко търсения от
потребители, които са имали закъснения от 400 ms. Като се има предвид сумата пари, спечелени при търсене,
дори такива малки промени са обезпокоителни. Всъщност резултатите бяха толкова отрицателни, че
те прекратиха експеримента преждевременно [Schurman and Brutlag 2009].
Забавяне на Увеличено време до Запитвания/ Всякакви кликвания/ приходи/

сървъра (ms) следващо кликване (ms) потребител потребител Удовлетвореност на потребителите потребител
50 -- -- -- -- --
200 500 -- 0,3% 0,4% --
500 1200 -- 1,0% 0,9% 1,2%
1000 1900 г 0,7% 1,9% 1,6% 2,8%
2000 г 3100 1,8% 4,4% 3,8% 4,3%
Фигура 6.12 Отрицателно въздействие на закъсненията в сървъра за търсене на Bing върху поведението на потребителите
Шурман и Брутлаг [2009].

Поради тази изключителна загриженост за удовлетворението на всички потребители на интернет
услуга, целите за ефективност обикновено са посочени, че висок процент от

заявките са под прага на латентност, а просто предлагат цел за средната стойност
латентност. Такива прагови цели се наричат цели за ниво на обслужване (SLO) или
споразумения за ниво на обслужване (SLA). SLO може да е това, което трябва да бъдат 99% от заявките
под 100 милисекунди. Така дизайнерите на Dynamo на Amazon имат ключова стойност
системата за съхранение реши, че услугите предлагат добра латентност в допълнение към това
Dynamo, тяхната система за съхранение трябваше да изпълни целта си за латентност 99,9% от
време [DeCandia et al. 2007]. Например, едно подобрение на Dynamo помогна
99,9-ият процентил е много повече от средния случай, което отразява техните
приоритети.
Цената на WSC
Както бе споменато във въведението, за разлика от повечето архитекти, дизайнерите на WSC

тревожете се за оперативните разходи, както и за разходите за изграждане на WSC. Счетоводство
обозначава първите разходи като оперативни разходи (OPEX), а вторите разходи като
капиталови разходи (CAPEX).
За да постави цената на енергията в перспектива, Хамилтън [2010] направи казус
за оценка на разходите за WSC. Той определи, че CAPEX на тези 8 MW
съоръжението беше $88 милиона и че приблизително 46 000 сървъра и съответното мрежово

оборудване добавиха още $79 милиона към CAPEX за WSC. Фигура
6.13 показва останалите допускания за казуса.
Вече можем да оценим общата цена на енергията, тъй като счетоводните правила на САЩ позволяват
да преобразуваме CAPEX в OPEX. Можем просто да амортизираме CAPEX като фиксирани
сума всеки месец за ефективния живот на оборудването. Фигура 6.14 прекъсвания
понижаване на месечните OPEX за този казус. Имайте предвид, че амортизационните проценти се
различават значително, от 10 години за съоръжението до 4 години за мрежата
оборудване и 3 години за сървърите. Следователно WSC съоръжението продължава десетилетие,
но трябва да подменяте сървърите на всеки 3 години и мрежовото оборудване
на всеки 4 години. Чрез амортизиране на CAPEX, Хамилтън излезе с месечна сума
OPEX, включително отчитане на разходите за заемане на пари (5% годишно).
плати за WSC. При $3,8 млн. месечните OPEX са около 2% от CAPEX.
Тази цифра ни позволява да изчислим удобна насока, която да имаме предвид кога
вземане на решения за това кои компоненти да използвате, когато сте загрижени
енергия. Пълната обременена цена на ват на година в WSC, включително цената на
амортизиране на инфраструктурата за захранване и охлаждане
Месечни разходи за инфраструктура+месечни разходи за енергия $765K $475K +

-------------------------------------------------- -------------------------------------------------- -------------------------------- × 12 = = $1,86
------------------------------------- × 12
Размер на съоръжението във ватове 8M
Цената е приблизително 2 долара на ват година. По този начин, за да намалите разходите, като пестите енергия
не трябва да харчат повече от $2 на ват година (вижте раздел 6.8).

Имайте предвид, че повече от една трета от OPEX е свързана с мощността в тази категория
нарастват, докато разходите за сървъри намаляват с течение на времето. Работата в мрежа
Размер на съоръжението (критичен товар ватове) 8 000 000
Средна консумация на енергия (%) 80%
Ефективност при използване на енергия 1.45
Разходи за енергия ($/kwh) $0,07
% Инфраструктура за захранване и охлаждане (% от общите разходи на съоръжението) 82%
CAPEX за съоръжение (без ИТ оборудване) 88 000 000 долара
Брой сървъри 45,978
Цена/сървър 1450 долара
CAPEX за сървъри 66 700 000 долара
Брой рейкови превключватели 1150
Превключвател Cost/rack 4800 долара
Брой превключватели на масива 22
Превключване цена/масив 300 000 долара
Брой превключватели от ниво 3 2
Превключвател цена/слой 3 500 000 долара
Брой гранични рутери 2
Цена/граничен рутер 144 800 долара
CAPEX за мрежово оборудване 12 810 000 долара
Общи CAPEX за WSC 167 510 000 долара
Време за амортизация на сървъра 3 години
Време за амортизация на мрежата 4 години
Време за амортизация на съоръженията 10 години
Годишен разход на пари 5%
Фигура 6.13 Казус за WSC, базиран на Hamilton [2010], закръглен до най-близкия
$5000. Разходите за интернет честотна лента варират според приложението, така че не са включени тук. The
останалите 18% от CAPEX за обекта включват закупуване на имота и разходите
на конструкцията на сградата. Добавихме разходи за хора за сигурност и управление на съоръжения във Фигура 6.14,
които не бяха част от казуса. Имайте предвид, че на Хамилтън
оценките са направени преди той да се присъедини към Amazon и те не се основават на WSC на a
конкретна фирма.
оборудване е значително при 8% от общите OPEX и 19% от CAPEX на сървъра, и

мрежовото оборудване не намалява толкова бързо, колкото сървърите. Тази разлика е
особено вярна за комутаторите в мрежовата йерархия над
шкаф, които представляват по-голямата част от мрежовите разходи (вижте раздел 6.6). хора
разходите за сигурност и управление на съоръженията са само 2% от OPEX. Разделяне на
OPEX на Фигура 6.14 от броя сървъри и часове на месец, цената е
около $0,11 на сървър на час.
Разходи (% общо) Категория Месечни разходи Процентни месечни разходи
Сървъри $2,000,000 53%
Мрежово оборудване $290,000 8%

Амортизирани CAPEX (85%)
Инфраструктура за захранване и охлаждане $765,000 20%
Друга инфраструктура $170,000 4%
Месечна консумация на енергия $475,000 13%

OPEX (15%)
Месечни заплати и обезщетения на хората $85,000 2%
Общи OPEX $3,800,000 100%
Фигура 6.14 Месечни OPEX за Фигура 6.13, закръглени до най-близките $5000. Имайте предвид, че 3-годишната амортизация за
сървъри означава, че трябва да купувате нови сървъри на всеки 3 години, докато съоръжението се амортизира за 10 години. следователно
амортизираните капиталови разходи за сървъри са около 3 пъти повече от тези за съоръжението. Разходите за хора включват 3 охрана
охранява позиции непрекъснато 24 часа в денонощието, 365 дни в годината, на $20 на час на човек и 1 лице на съоръженията
за 24 часа на ден, 365 дни в годината, при $30 на час. Обезщетенията са 30% от заплатите. Това изчисление не включва
цена на честотната лента на мрежата до интернет, тъй като тя варира в зависимост от приложението, нито такси за поддръжка на доставчика, тъй като тя варира в зависимост от
оборудване и по договаряне.
Пример Цената на електроенергията варира според региона в Съединените щати от $0,03 до $0,15 на
киловатчас. Какво е въздействието върху почасовите разходи за сървър на тези две екстремни ставки?
Отговор Умножаваме критичното натоварване от 8 MW по PUE и по средната мощност

използване от Фигура 6.13 за изчисляване на средното потребление на енергия:
8 1,45 80% ×× = 9,28 мегавата
След това месечните разходи за енергия преминават от $475 000 на фигура 6.14 до $205 000
при 0,03 долара за киловатчас и до 1 015 000 долара при 0,15 долара за киловатчас. Тези
промените в разходите за електроенергия променят почасовите разходи за сървър от $0,11 на $0,10 и
$0,13, съответно.
Пример Какво би се случило с месечните разходи, ако всички времена за амортизация бъдат направени
да е същото - да речем, 5 години? Как това променя почасовите разходи за сървър?
Отговор Електронната таблица е достъпна онлайн на http://mvdirona.com/jrh/TalksAndPapers/

PerspectivesDataCenterCostAndPower.xls. Промяна на времето за амортизация на 5
години променя първите четири реда на Фигура 6.14 на
Сървъри $1,260,000 37%
Мрежово оборудване $242,000 7%
Инфраструктура за захранване и охлаждане $1,115,000 33%
Друга инфраструктура $245,000 7%

и общите месечни OPEX са $3,422,000. Ако подменяме всичко на всеки 5 години, цената ще бъде $0,103
на сървърен час, като по-голямата част от амортизираните разходи сега са за съоръжението, а не за
сървърите, както е на фигура 6.14.
Цената от $0,11 на сървър на час може да бъде много по-ниска от цената за много компании, които
притежават и управляват свои собствени (по-малки) конвенционални центрове за данни.
Ценовото предимство на WSC накара големите интернет компании да предложат компютри като
полезност, при която, подобно на електричеството, плащате само за това, което използвате. Днес
комуналните изчисления са по-известни като облачни изчисления.
6.5 Облачни изчисления: Завръщането на помощните изчисления
Ако компютрите от вида, който защитавам, станат компютрите на бъдещето, тогава компютрите може
някой ден да бъдат организирани като обществена услуга, точно както телефонната система е
обществена услуга. . . . Компютърната програма може да се превърне
в основата на нова и важна индустрия.
Джон Маккарти
Честване на стогодишнината на MIT (1961)
Водени от търсенето на все по-голям брой потребители, интернет компании като Amazon, Google и
Microsoft изградиха все по-големи компютри от стандартни компоненти за складове. Това търсене
доведе до иновации в системния софтуер за поддръжка на работа в този мащаб, включително Bigtable,
Dynamo, GFS и MapReduce. Той също така изисква подобряване на оперативните техники за предоставяне
на услуга, налична поне 99,99% от времето, въпреки повреди на компоненти и атаки за сигурност.
Примери за тези техники включват отказ, защитни стени, виртуални машини и защита срещу
разпределени атаки за отказ на услуга. Със софтуера и експертизата, осигуряващи възможност за
мащабиране и нарастващото клиентско търсене, което оправда инвестицията, WSC с 50 000 до 100 000
сървъра станаха обичайни през 2011 г.
С увеличаването на мащаба идват нарастващи икономии от мащаба. Въз основа на проучване от

2006 г., което сравнява WSC с център за данни само с 1000 сървъра, Hamilton [2010] докладва следните
предимства:
5,7 пъти намаление на разходите за съхранение — струваше на WSC $4,6 на GByte на година за
дисково съхранение срещу $26 на GByte за центъра за данни.
7,1 пъти намаление на административните разходи— съотношението сървъри на администратор

беше над 1000 за WSC срещу само 140 за центъра за данни.
7,3 пъти намаление на мрежовите разходи—Интернет честотната лента струва на WSC $13 за Mbit/
sec/месец срещу $95 за центъра за данни. Не е изненадващо, че можете да договорите много по-
добра цена за Mbit/sec, ако поръчате 1000 Mbit/sec, отколкото ако поръчате 10 Mbit/sec.
Друга икономия от мащаба идва по време на покупката. Високото ниво на закупуване води
до цени с отстъпка за обем на сървърите и мрежовото оборудване. Освен това позволява
оптимизиране на веригата за доставки. Dell, IBM и SGI ще доставят новите поръчки за една
седмица до WSC вместо за 4 до 6 месеца. Краткото време за доставка прави много по-лесно
разрастването на помощната програма, за да отговори на търсенето.
Икономиите от мащаба се отнасят и за оперативните разходи. От предишния раздел видяхме,
че много центрове за данни работят с PUE 2.0. Големите фирми могат да оправдаят наемането на
механични и енергийни инженери за разработване на WSC с по-ниски PUE от порядъка на 1,2
(вижте раздел 6.7).
Интернет услугите трябва да бъдат разпределени до множество WSC както за способност за
зависимост, така и за намаляване на латентността, особено за международните пазари. Поради
тази причина всички големи фирми използват множество WSC. За отделните фирми е много по-
скъпо да създават множество малки центрове за данни по целия свят, отколкото един център за
данни в корпоративната централа.
И накрая, поради причините, представени в раздел 6.1, сървърите в центровете за данни са
склонни да се използват само 10% до 20% от времето. Като предоставят WSC на разположение на
обществеността, некорелирани пикове между различни клиенти могат да повишат средното
използване над 50%.
По този начин икономиите от мащаба за WSC предлагат фактори от 5 до 7 за няколко компо-

нентове на WSC плюс няколко коефициента от 1,5 до 2 за целия WSC.
Въпреки че има много доставчици на облачни изчисления, ние представяме Amazon Web
Services (AWS) отчасти поради тяхната популярност и отчасти поради ниското ниво и следователно
по-гъвкавата абстракция на тяхната услуга. Google App Engine и Microsoft Azure повишават нивото
на абстракция до управлявани времена за изпълнение и предлагат услуги за автоматично
мащабиране, които са по-подходящи за някои клиенти, но не са толкова добри, колкото AWS за
материала в тази книга.
Amazon Web Services

Полезните изчисления се връщат към търговските системи за споделяне на време и дори
системите за пакетна обработка от 60-те и 70-те години на миналия век, където компаниите
плащаха само за терминал и телефонна линия и след това бяха таксувани въз основа на това
колко изчисления са използвали. Много усилия след края на споделянето на време са се опитвали
да предложат такива услуги на заплащане, но те често са били посрещнати с неуспех.
Когато Amazon започна да предлага помощни изчисления чрез Amazon Simple Storage Service
(Amazon S3) и след това Amazon Elastic Computer Cloud (Amazon EC2) през 2006 г., той взе някои
нови технически и бизнес решения:
Виртуални машини. Изграждането на WSC с помощта на x86-commodity компютри, работещи с

операционната система Linux и виртуалната машина Xen, реши няколко проблема. Първо,
това позволи на Amazon да защити потребителите един от друг. Второ, той опрости
разпространението на софтуер в рамките на WSC, тъй като клиентите трябва само да
инсталират изображение и след това AWS автоматично ще го разпространи до всички
използвани инстанции. Трето, способността надеждно да убие виртуална машина
улеснява Amazon и клиентите да контролират използването на ресурсите. Четвърто, тъй като

виртуалните машини могат да ограничат скоростта, с която използват физическите процесори,
дискове и мрежата, както и количеството основна памет, това даде на AWS множество ценови точки:
най-ниската ценова опция чрез пакетиране на множество виртуални ядра на един сървър, най-
високата цена за изключителен достъп до всички ресурси на машината, както и няколко междинни
точки. Пето, виртуалните машини крият самоличността на по-стария хардуер, което позволява на AWS
да продължи да продава време на по-стари машини, които иначе биха били непривлекателни за
клиентите, ако знаеха възрастта им. И накрая, виртуалните машини позволяват на AWS да въведе нов
и по-бърз хардуер, като опакова още повече виртуални ядра на сървър или просто като предлага
инстанции, които имат по-висока производителност на виртуално ядро; виртуализацията означава, че

предлаганата производителност не е необходимо да бъде цяло число, кратно на производителността
на хардуера.
Много ниска цена. Когато AWS обяви тарифа от $0,10 на час за инстанция през 2006 г., това беше
изумително ниска сума. Един екземпляр е една виртуална машина и при $0,10 на час AWS разпредели
два екземпляра на ядро на многоядрен сървър. Следователно, едно компютърно устройство EC2 е
еквивалентно на 1,0 до 1,2 GHz AMD Opteron или Intel Xeon от онази епоха. (Първоначално)
разчитане на софтуер с отворен код.
Наличието на софтуер с добро качество, който няма проблеми с лицензирането или разходи, свързани с
работата на стотици или хиляди сървъри, направи изчисленията с помощни програми много по-
икономични както за Amazon, така и за неговите клиенти. Съвсем наскоро AWS започна да предлага
инстанции, включително търговски софтуер на трети страни, на по-високи цени. Без (първоначална)
гаранция за обслужване. Първоначално Amazon обеща само максимални усилия. Ниската цена беше
толкова привлекателна, че мнозина можеха да живеят без гаранция за обслужване. Днес AWS предоставя
SLA за наличност до 99,95% на услуги като Amazon EC2 и Amazon S3. Освен това Amazon S3 е проектиран
за 99,999999999% издръжливост чрез запазване на множество реплики на всеки обект на множество
места. Тоест шансовете за окончателна загуба на обект са едно на 100 милиарда. AWS също така
предоставя табло за управление на състоянието на услугата, което показва текущото работно
състояние на всяка от услугите на AWS в реално време, така че времето за работа и производителността
на AWS са напълно прозрачни.
Не се изисква договор. Отчасти защото разходите са толкова ниски, всичко, което е необходимо, за да
започнете да използвате EC2, е кредитна карта.
Фигура 6.15 показва почасовата цена на много видове инстанции на EC2 през 2011 г. В допълнение
към изчисленията, EC2 таксува за дългосрочно съхранение и за интернет трафик. (Няма разходи за мрежов
трафик в регионите на AWS.) Elastic Block Storage струва $0,10 за GByte на месец и $0,10 за милион I/O
заявки. Интернет трафикът струва $0,10 на гигабайт към EC2 и $0,08 до $0,15 на гигабайт напускащ EC2, в
зависимост от обема. Поставяйки това в историческа перспектива, за $100 на месец можете да използвате
еквивалентния капацитет на сумата от капацитетите на всички магнитни дискове, произведени през 1960
г.!
Съотношение Изчислителни Виртуален Изчислителни памет диск Размер на

Инстанция На час към малък единици ядра единици/ядро (GB) (GB) адреса
Микро $0,020 0,5–2,0 0,5–2,0 1 0,5–2,0 0.6 EBS 32/64 бита
Стандартен малък 0,085 долара 1.0 1.0 1 1,00 1.7 160 32 бита
Standard Large 0,340 долара 4.0 4.0 2 2.00 7.5 850 64 бита
Standard Extra Large High- 0,680 долара 8.0 8.0 4 2.00 15.0 1690 64 бита
Memory Extra Large $0,500 High-Memory 5.9 6.5 2 3.25 17.1 420 64 бита
Double Extra Large $1000 11.8 13.0 4 3.25 34.2 850 64 бита
High-Memory Quadruple 2000 долара 23.5 26.0 8 3.25 68.4 1690 64 бита
Много голям
Среден с висок процесор 0,170 долара 2.0 5.0 2 2.50 1.7 350 32 бита
High-CPU Extra Large 0,680 долара 8.0 20.0 8 2.50 7.0 1690 64 бита
Cluster Quadruple Extra 1600 долара 18.8 33.5 8 4.20 23.0 1690 64 бита
Голям
Фигура 6.15 Цена и характеристики на екземпляри на EC2 по заявка в Съединените щати в региона на Вирджиния през
Януари 2011 г. Микро екземплярите са най-новата и евтина категория и предлагат кратки пакети до 2.0
изчислителни единици само за $0,02 на час. Клиентите съобщават, че Micro Instances са средно около 0,5 изчислителни единици.
Cluster-Compute Instances в последния ред, които AWS идентифицира като специализирани сървъри с двоен сокет Intel Xeon X5570 с четири
ядра на сокет, работещи на 2,93 GHz, предлагат 10 Gigabit/sec мрежи. Те са предназначени за HPC приложения. AWS предлага също спот
инстанции на много по-ниска цена, където вие задавате цената, която сте готови да платите, и
брой инстанции, които сте готови да стартирате, и след това AWS ще ги стартира, когато спот цената падне под вашата
ниво. Те работят, докато не ги спрете или спот цената надвиши лимита ви. Една проба през деня през януари
2011 установи, че спот цената е коефициент от 2,3 до 3,1 по-ниска, в зависимост от типа екземпляр. AWS също предлага
Запазени инстанции за случаи, когато клиентите знаят, че ще използват по-голямата част от инстанцията за една година. Вие плащате годишно
такса за екземпляр и след това почасова ставка, която е около 30% от колона 1, за да го използвате. Ако сте използвали резервиран екземпляр
100% за цяла година, средната цена на час, включително амортизацията на годишната такса, ще бъде около 65% от
процентът в първата колона. Сървърът, еквивалентен на тези на фигури 6.13 и 6.14, ще бъде стандартна екстра
Голям или изключително голям екземпляр с висок процесор, който изчислихме да струва $0,11 на час.
Пример Изчислете разходите за изпълнение на средните задания на MapReduce на Фигура 6.2

страница 437 на EC2. Да приемем, че има много работни места, така че няма значително допълнително
цена за закръгляване, така че да получите цяло число часове. Игнорирайте месечните разходи за
съхранение, но включете разходите за I/O на диска за Elastic Block Storage на AWS
(EBS). След това изчислете разходите за година за изпълнение на всички задания на MapReduce.
Отговор Първият въпрос е какъв е правилният размер на екземпляра, който да съответства на типичния сървър
Google? Фигура 6.21 на страница 467 в раздел 6.7 показва, че през 2007 г. типичен
Сървърът на Google имаше четири ядра, работещи на 2,2 GHz с 8 GB памет. Тъй като а
единичен екземпляр е едно виртуално ядро, което е еквивалентно на 1 до 1,2 GHz AMD
Opteron, най-близкото съответствие на Фигура 6.15 е High-CPU Extra Large с осем
виртуални ядра и 7.0 GB памет. За простота ще приемем средното
Достъпът до EBS хранилище е 64 KB, за да се изчисли броят I/O.
6.5 Облачни изчисления: Завръщането на полезните изчисления 459
август-04 март-06 септември-07 септември-09
Средно време за изпълнение (часове) 0,15 0,21 0,10 0,11
Среден брой сървъри на работа 157 268 394 488
Цена на час за инстанция EC2 High-CPU XL 0,68 долара 0,68 долара 0,68 долара 0,68 долара
Средна цена EC2 за работа в MapReduce 16,35 долара 38,47 долара 25,56 долара 38,07 долара
Среден брой EBS I/O заявки (милиони) 2.34 5.80 3.26 3.19
Цена на EBS за милион I/O заявки $0,10 $0,10 $0,10 $0,10
Средна I/O цена на EBS за задача на MapReduce 0,23 долара 0,58 долара 0,33 долара 0,32 долара
Средна обща цена за задача на MapReduce 16,58 долара 39,05 долара 25,89 долара 38,39 долара
Годишен брой задания на MapReduce 29 000 171 000 2 217 000 3 467 000
Обща цена на работните места на MapReduce на EC2/EBS 480 910 долара $6 678 011 $57,394,985 $133,107,414
Фигура 6.16 Прогнозна цена, ако сте изпълнили работното натоварване на Google MapReduce (Фигура 6.2), използвайки цени от 2011 г. за AWS
ECS и EBS (Фигура 6.15). Тъй като използваме цени от 2011 г., тези оценки са по-малко точни за по-ранни години, отколкото за
по-новите.
Фигура 6.16 изчислява средната и общата цена на година за работа с Google
MapReduce натоварване на EC2. Средната работа в MapReduce за 2009 г. ще струва a

малко под $40 на EC2, а общото натоварване за 2009 г. ще струва $133 милиона на
AWS. Имайте предвид, че достъпът до EBS е около 1% от общите разходи за тези работни места.
Пример Като се има предвид, че разходите за работни места в MapReduce растат и вече надхвърлят $100 милиона
на година, представете си, че вашият шеф иска да проучите начини за намаляване на разходите.
Две потенциално по-евтини опции са или AWS Reserved Instances, или AWS
Точкови случаи. Кое бихте препоръчали?
Отговор AWS Reserved Instances таксува фиксирана годишна ставка плюс почасова ставка за използване.
През 2011 г. годишните разходи за High-CPU Extra Large Instance са $1820 и
часова ставка е $0,24. Тъй като ние плащаме за екземплярите, независимо дали са използвани или не,
нека приемем, че средното използване на резервирани инстанции е 80%. Тогава
средната цена на час става:
Годишна цена 1820 долара

---------------------------------- + Цена на час -------------- + $0,24
Часове годишно 8760
== = ----------------------------------
( 0,21 0,24 + ) × 1,25 0,56 $
-------------------------------------------------- ----------------------
Използване 80%
По този начин спестяванията при използване на резервирани екземпляри биха били приблизително 17% или 23 милиона долара
натоварването на MapReduce за 2009 г.
Вземане на проби от няколко дни през януари 2011 г., почасовата цена на High-CPU Extra
Голям спот екземпляр е средно $0,235. Тъй като това е минималната цена за наддаване
вземете един сървър, това не може да бъде средната цена, тъй като обикновено искате да изпълнявате задачи
до завършване, без да бъдете блъскани. Да предположим, че трябва да платите двойно
минимална цена за изпълнение на големи задачи на MapReduce до завършване. Спестяването на разходи за
Спот инстансите за натоварването през 2009 г. ще бъдат приблизително 31% или $41 милиона.
По този начин вие условно препоръчвате Spot Instances на вашия шеф, тъй като има по-малко
предварителен ангажимент и те потенциално могат да спестят повече пари. Вие обаче казвате на
шефа си, че трябва да опитате да стартирате задания на MapReduce на Spot инстанции, за да видите
какво всъщност плащате в крайна сметка, за да сте сигурни, че задачите се изпълняват докрай и
че наистина има налични стотици високопроцесорни екстра големи инстанции за изпълнение на
тези задания ежедневно.
В допълнение към ниската цена и модела „плащане срещу използване“ на полезни изчисления,
друг силен привлекател за потребителите на облачни изчисления е, че доставчиците на облачни
изчисления поемат рисковете от свръх или недостатъчно предоставяне. Избягването на риска е
божи дар за стартиращите компании, тъй като всяка грешка може да бъде фатална. Ако твърде
много от ценната инвестиция се изразходва за сървъри, преди продуктът да е готов за интензивна
употреба, компанията може да остане без пари. Ако услугата изведнъж стане популярна, но няма
достатъчно сървъри, за да отговори на търсенето, компанията може да направи много лошо
впечатление с потенциалните нови клиенти, от които отчаяно се нуждае, за да расте.
Плакатът за този сценарий е FarmVille от Zynga, игра за социална мрежа във Facebook. Преди
обявяването на FarmVille, най-голямата социална игра имаше около 5 милиона играчи всеки ден.
FarmVille имаше 1 милион играчи 4 дни след старта и 10 милиона играчи след 60 дни. След 270 дни
имаше 28 милиона играчи всеки ден и 75 милиона играчи месечно. Тъй като бяха внедрени в AWS,
те успяха да растат безпроблемно с броя на потребителите. Освен това, той намалява натоварването
въз основа на търсенето на клиентите.
По-утвърдените компании също се възползват от мащабируемостта на облака. През 2011 г.

Netflix мигрира своя уеб сайт и услуга за поточно видео от конвенционален център за данни към
AWS. Целта на Netflix беше да позволи на потребителите да гледат филм на, да речем, мобилния си
телефон, докато пътуват до вкъщи и след това безпроблемно да превключат към телевизора си,
когато се приберат у дома, за да продължат да гледат филма си там, където са спрели. Това усилие
включва групова обработка за конвертиране на нови филми в безброй формати, от които се
нуждаят, за да доставят филми на мобилни телефони, таблети, лаптопи, игрови конзоли и цифрови
видеорекордери. Тези пакетни AWS задания могат да отнемат на хиляди машини няколко седмици,
за да завършат реализациите. Транзакционният бекенд за поточно предаване се извършва в AWS,
а доставката на кодирани файлове се извършва чрез мрежи за доставка на съдържание като
Akamai и ниво 3. Онлайн услугата е много по-евтина от изпращането на DVD дискове по пощата и
произтичащата от това ниска цена направи новата услуга популярна . Според едно проучване
Netflix представлява 30% от интернет трафика за изтегляне в Съединените щати по време на
пиковите вечерни периоди. (За разлика от тях, YouTube беше само 10% в същия период от 20:00 до
22:00 часа.) Всъщност общата средна стойност е 22% от интернет трафика, което прави Netflix
единствен отговорен за най-голямата част от интернет трафика в Северна Америка. Въпреки
ускоряващите се темпове на растеж на абонатните акаунти на Netflix, темпът на растеж на центъра
за данни на Netflix е спрян и цялото разширяване на капацитета в бъдеще се извършва чрез AWS.
Облачните изчисления направиха предимствата на WSC достъпни за всички. Облачните

изчисления предлагат асоциативност на разходите с илюзията за безкрайна мащабируемост без
допълнителни разходи за потребителя: 1000 сървъра за 1 час струват не повече от 1 сървър за
1000 часа. От доставчика на облачни изчисления зависи да гарантира, че има достатъчно

сървъри, място за съхранение и интернет честотна лента, за да отговори на търсенето.
Оптимизираната верига за доставки, спомената по-горе, която намалява времето за доставка
до седмица за нови компютри, е значителна помощ за осигуряване на тази илюзия, без да
фалира доставчикът. Това прехвърляне на рискове, асоциативност на разходите и
ценообразуване на принципа на изплащане е мощен аргумент за компании с различна
големина да използват облачни изчисления.
Два междусекторни въпроса, които оформят разходите и производителността на WSC и
следователно облачните изчисления, са WSC мрежата и ефективността на сървърния хардуер и
софтуер.
Net gear е SUV на центъра за данни.
Джеймс Хамилтън (2009)
WSC мрежата като пречка
Раздел 6.4 показа, че мрежовото оборудване над превключвателя на стелажа е значителна

част от цената на WSC. Напълно конфигуриран, каталожната цена на 128-портов 1 Gbit комутатор
за център за данни от Juniper (EX8216) е $716 000 без оптични интерфейси и $908 000 с тях. (Тези
каталожни цени са силно намалени, но все още струват повече от 50 пъти повече от
превключвателя за шкаф.) Тези превключватели също са склонни да консумират енергия.
Например, EX8216 консумира около 19 200 вата, което е 500 до 1000 пъти повече от сървър в
WSC. Освен това, тези големи превключватели са ръчно конфигурирани и са крехки в голям
мащаб. Поради тяхната цена е трудно да си позволите повече от двойно резервиране в WSC,
използвайки тези големи комутатори, което ограничава възможностите за толерантност към
грешки [Hamilton 2009].
Истинското въздействие върху комутаторите обаче е как прекомерният абонамент засяга
дизайна на софтуера и разполагането на услуги и данни в WSC. Идеалната WSC мрежа би била
черна кутия, чиято топология и честотна лента са безинтересни, защото няма ограничения:
можете да изпълнявате всякакво работно натоварване на всяко място и да оптимизирате за
използване на сървъра, а не за локализиране на мрежовия трафик.
Тесните места в мрежата на WSC днес ограничават разполагането на данни, което от своя страна
усложнява софтуера на WSC. Тъй като този софтуер е един от най-ценните активи на WSC
компания, цената на тази добавена сложност може да бъде значителна.
За читателите, които се интересуват да научат повече за дизайна на комутатора,
Приложение F описва проблемите, свързани с проектирането на мрежи за взаимно свързване.
В допълнение Thacker [2007] предлага заемане на мрежова технология от суперкомпютри, за
да се преодолеят проблемите с цената и производителността. Вахдат и др. [2010] направи също
така и предложи мрежова инфраструктура, която може да се мащабира до 100 000 порта и 1
петабит/сек бисекция на честотната лента. Основно предимство на тези нови превключватели
за центрове за данни е да опростят софтуерните предизвикателства, дължащи се на свръхабонамент.
Ефективно използване на енергия вътре в сървъра
Докато PUE измерва ефективността на WSC, няма какво да се каже за какво
протича вътре в самото ИТ оборудване. По този начин друг източник на електрическа неефективност, който
не е обхванат във Фигура 6.9 , е захранването вътре в сървъра, което преобразува входа от 208 волта или 110
волта в напреженията, използвани от чиповете и дисковете,
обикновено 3,3, 5 и 12 волта. 12-те волта допълнително се намаляват до 1,2 до 1,8
волта на платката, в зависимост от това какво изискват микропроцесорът и паметта. в
2007 г. много захранвания бяха с 60% до 80% ефективност, което означаваше, че има
по-големи загуби вътре в сървъра, отколкото при преминаването през многото стъпки и
промени в напрежението от линиите за високо напрежение в кулата за захранване за захранване на линиите
за ниско напрежение на сървъра. Една от причините е, че те трябва да осигурят диапазон от напрежение на
чиповете и дисковете, тъй като нямат представа какво има на дънната платка. Втората причина е, че
захранването често е прекалено голямо във ватове
какво има на дъската. Нещо повече, такива захранващи устройства често са с най-лоша ефективност при 25%
натоварване или по-малко, въпреки че, както показва Фигура 6.3 на страница 440, много
WSC сървърите работят в този диапазон. Компютърните дънни платки също имат модули за регулиране на
напрежението (VRM) и те също могат да имат относително ниска ефективност.
За да се подобри състоянието на техниката, Фигура 6.17 показва стандартите на Climate Savers Computing
Initiative [2007] за оценка на захранващите устройства и техните цели над
време. Имайте предвид, че стандартът определя изисквания при 20% и 50% натоварване
допълнение към 100% натоварване.
В допълнение към захранването, Barroso и Hölzle [2007] казаха целта за
целият сървър трябва да бъде енергийно пропорционален; тоест сървърите трябва да консумират енергия
пропорционално на количеството извършена работа. Фигура 6.18 показва
колко далеч сме от постигането на тази идеална цел с помощта на SPECpower, сървърен бенчмарк, който
измерва използваната енергия при различни нива на производителност (Глава 1). The
енергийната пропорционална линия се добавя към действителната консумация на енергия на най-ефективния
сървър за SPECpower от юли 2010 г. Повечето сървъри няма да са толкова ефективни; то
беше до 2,5 пъти по-добър от други системи, сравнени през тази година, и късно през a
системите за състезание по бенчмарк често са конфигурирани по начини за спечелване на бенчмарка, които
не са типични за системите в областта. Например най-добре оценените
Сървърите SPECpower използват твърдотелни дискове, чийто капацитет е по-малък от основния
памет! Въпреки това, тази много ефективна система все още използва почти 30% от пълното
бронз Сребро злато

Кондициониране на натоварването База (юни 2008 г.) (юни 2009 г.) (юни 2010 г.)
20% 80% 82% 85% 87%
50% 80% 85% 88% 90%
100% 80% 82% 85% 87%
Фигура 6.17 Оценки на ефективност и цели за захранващи устройства във времето на климата
Savers Computing Initiative. Тези оценки са за захранващи блокове с множество изходи,
които се отнасят до настолни и сървърни захранвания в нередундантни системи. Има
малко по-висок стандарт за PSU с един изход, които обикновено се използват като резервни
конфигурации (1U/2U единични, двойни и четирисокетни и блейд сървъри).
700
600
500
400
Действителна мощност
евотав
300
Енергийна пропорционална мощност

200
100
0
0 300 600 900 1200 1500 1800 2100 2400 2700 3000
Работно натоварване: 1000 операции/секунда
Фигура 6.18 Най-добрите резултати на SPECpower към юли 2010 г. спрямо идеалната енергия
пропорционално поведение. Системата беше HP ProLiant SL2x170z G6, която използва a
клъстер от четири процесора Intel Xeon L5640 с двоен сокет, като всеки сокет има шест работещи ядра
на 2,27 GHz. Системата имаше 64 GB DRAM и малък 60 GB SSD за вторично съхранение. (Фактът, че
основната памет е по-голяма от капацитета на диска, предполага, че тази система
беше съобразен с този показател.) Използваният софтуер беше IBM Java Virtual Machine версия 9 и
Windows Server 2008, Enterprise Edition.
мощност при неактивност и почти 50% от пълната мощност при само 10% натоварване. По този начин енергията
пропорционалността остава висока цел вместо гордо постижение.

Системният софтуер е проектиран да използва целия наличен ресурс, ако потенциално подобрява
производителността, без да се притеснява за енергийните последици. За
например операционните системи използват цялата памет за програмни данни или за файл
кешове, въпреки факта, че голяма част от данните вероятно никога няма да бъдат използвани. Софтуер
архитектите трябва да вземат предвид енергията, както и производителността в бъдещите проекти
[Картър и Раджамани 2010].
Пример Използвайки данните от типа на Фигура 6.18, от какво идва спестяването на енергия
пет сървъра при 10% използване срещу един сървър при 50% използване?
Отговор Един сървър при 10% натоварване е 308 вата, а при 50% натоварване е 451 вата. Спестяванията са тогава
5 308 451 ⁄× = ( 1540 451 ⁄ ) 3,4
или около коефициент 3,4. Ако искаме да бъдем добри стопани на околната среда в нашите
WSC, ние трябва да консолидираме сървъри, когато усвояването спадне, да закупим сървъри
са по-пропорционални на енергията или намерете нещо друго, което е полезно за бягане в периоди
на ниска активност.
464 Шеста глава Компютри с мащаб на склад за използване на паралелизъм на ниво заявка и ниво данни
Имайки предвид предисторията на тези шест раздела, вече сме готови да оценим
работата на архитектите на Google WSC.
6.7 Събираме всичко заедно: Google Warehouse-

мащабен компютър
Тъй като много компании с WSC се конкурират енергично на пазара, доскоро

те не бяха склонни да споделят последните си иновации с обществеността (и
помежду си). През 2009 г. Google описва най-съвременния WSC от 2005 г.
Google любезно предостави актуализация на състоянието от 2007 г. на техния
WSC, което прави този раздел най-актуалното описание на Google WSC
[Clidaras, Johnson и Felderman 2010]. Още по-скоро Facebook описа най-новия
си център за данни като част от http://opencompute.org.
Контейнери
Както Google, така и Microsoft са изградили WSC, използвайки транспортни контейнери.

Идеята за изграждане на WSC от контейнери е дизайнът на WSC да бъде модулен.
Всеки контейнер е независим и единствените външни връзки са мрежа, захранване и
вода. Контейнерите от своя страна доставят мрежа, захранване и охлаждане на
сървърите, поставени вътре в тях, така че работата на WSC е да доставя мрежа,
захранване и студена вода към контейнерите и да изпомпва получената топла вода
към външни охладителни кули и чилъри .
Google WSC, който разглеждаме, съдържа 45 контейнера с дължина 40 фута в
пространство с размери 300 фута на 250 фута или 75 000 квадратни фута (около 7000
квадратни метра). За да се поберат в склада, 30 от контейнерите са подредени на две
високи, или 15 чифта подредени контейнери. Въпреки че местоположението не беше
разкрито, то е построено по времето, когато Google разработи WSCs в Далес, Орегон,
което осигурява умерен климат и е близо до евтина водноелектрическа енергия и
интернет опорни влакна. Този WSC предлага 10 мегавата с PUE от 1,23 за предходните
12 месеца. От тези 0,230 PUE режийни разходи, 85% отиват за загуби при охлаждане
(0,195 PUE) и 15% (0,035) отиват за загуби на мощност. Системата стартира през
ноември 2005 г. и този раздел описва нейното състояние към 2007 г.
Контейнер на Google може да поеме до 250 киловата. Това означава, че
контейнерът може да поеме 780 вата на квадратен фут (0,09 квадратни метра) или 133
вата на квадратен фут в цялото пространство от 75 000 квадратни фута с 40
контейнера. Въпреки това, контейнерите в този WSC са средно само 222 киловата
Фигура 6.19 е разрез на контейнер на Google. Един контейнер побира до 1160
сървъра, така че 45 контейнера имат място за 52 200 сървъра. (Този WSC има около
40 000 сървъра.) Сървърите са подредени на височина 20 в стелажи, които образуват
два дълги реда от 29 стелажа (наричани още отделения) всеки, с по един ред от всяка
страна на контейнера. Рак суичовете са 48-портови, 1 Gbit/sec Ethernet суичове, които
се поставят във всеки друг шкаф.
6.7 Обединяване на всичко: Компютър с мащаб на Google Warehouse 465
104
100
146
137
107
164 142
111 116
101
134 140
119
116
143
107
113
131 125
155 122
161 152
158 143
128
149
155
152
Фигура 6.19 Google персонализира стандартен контейнер 1AAA: 40 x 8 x 9,5 фута (12,2 x 2,4 x 2,9 метра). Сървърите са подредени на
височина до 20 в стелажи, които образуват два дълги реда от по 29 стелажа всеки, с по един ред от всяка страна на контейнера.
Охладената пътека минава надолу по средата на контейнера, като връщането на горещия въздух е от външната страна. Структурата
на висящия стелаж улеснява ремонта на охладителната система, без да се премахват сървърите. За да позволи на хората вътре в
контейнера да ремонтират компоненти, той съдържа системи за безопасност за откриване на пожар и потискане на основата на
мъгла, аварийно излизане и осветление и аварийно изключване на захранването. Контейнерите също имат много сензори:
температура, налягане на въздушния поток, откриване на изтичане на въздух и осветление със сензор за движение. Видео обиколка
на центъра за данни може да бъде намерена на http://www.google.com/corporate/green/datacenters/summit.html . Microsoft, Yahoo! и
много други сега изграждат модулни центрове за данни въз основа на тези идеи, но те са спрели да използват стандартни контейнери
по ISO, тъй като размерът им е неудобен.
Охлаждане и захранване в Google WSC
Фигура 6.20 е напречен разрез на контейнера, който показва въздушния поток. Компютърните
стелажи са прикрепени към тавана на контейнера. Охлаждането е под повдигнат под, който духа в
коридора между стелажите. Горещият въздух се връща зад стелажите. Ограниченото пространство
на контейнера предотвратява смесването на горещ и студен въздух, което подобрява ефективността

на охлаждане. Вентилаторите с променлива скорост работят на най-ниската скорост, необходима за
охлаждане на стелажа, за разлика от постоянна скорост.
„Студеният“ въздух се поддържа 81°F (27°C), което е меко в сравнение с температурите в много
конвенционални центрове за данни. Една от причините центровете за данни традиционно да работят
толкова студено не е ИТ оборудването, а горещите точки в центъра за данни да не причиняват
изолирани проблеми. Чрез внимателно контролиране на въздушния поток за предотвратяване на
горещи точки, контейнерът може да работи при много по-висока температура.
н
|76a79a1808a45f9ed593fb73e46533eа а
:,71е0
8
нн 3
в
ръ т,ъ
у,и
86
р н
т8 нгр
9т8 ъ
к
с3
5 ае
тfн ю
дсм
еи
8
2
1
,в им
8
1
и
4
о
ач N
ф
8
0
в
7
и
х
:гн
трсп
| лм
u
р
1о
ей
1
4
8
х
л
д
о
ртB
ун
d ж
ке
р
9
0
3
7
оw
ъ
а
о S..©
;,еМ П
Л
Д
А
гХ
п
К
g
Б
о
0
2
1
9
e
аI
Фигура 6.20 Въздушен поток в контейнера, показан на Фигура 6.19. Тази диаграма на напречното
сечение показва две стелажи от всяка страна на контейнера. Студеният въздух духа в коридора в
средата на контейнера и след това се засмуква в сървърите. Топлият въздух се връща по краищата
на контейнера. Този дизайн изолира студените и топлите въздушни потоци.
Външните охладители имат изрези, така че, ако времето е подходящо, само външните
охладителни кули трябва да охлаждат водата. Охладителите се пропускат, ако температурата на
водата, напускаща охладителната кула, е 70°F (21°C) или по-ниска.
Имайте предвид, че ако навън е твърде студено, охладителните кули се нуждаят от
нагреватели, за да предотвратят образуването на лед. Едно от предимствата на поставянето на
WSC в The Dalles е, че годишната температура по мокър термометър варира от 15°F до 66°F (–9°C
до 19°C) със средна стойност от 41°F (5°C) , така че охладителите често могат да се изключват. За разлика,
Фигура 6.21 Сървър за Google WSC. Захранването е отляво, а двата диска са отгоре. Двата
вентилатора под левия диск покриват двата цокъла на микропроцесора AMD Bar-celona,
всеки с по две ядра, работещи на 2.2 GHz. Осемте DIMM модула в долния десен ъгъл
съдържат по 1 GB, което дава общо 8 GB. Няма допълнителен метален лист, тъй като
сървърите са включени към батерията и отделен пленум има в багажника за всеки сървър,
за да помогне за контролиране на въздушния поток. Отчасти поради височината на
батериите, 20 сървъра се побират в стелаж.
Лас Вегас, Невада, варира от –42°F до 62°F (–41°C до 17°C) със средна стойност от 29°F (–2°C). В
допълнение, необходимостта от охлаждане само до 81°F (27°C) вътре в контейнера прави много по-
вероятно майката природа да успее да охлади водата.
Фигура 6.21 показва сървъра, проектиран от Google за този WSC. За да се подобри ефективността
на захранването, той доставя само 12 волта на дънната платка, а дънната платка доставя достатъчно
за броя на дисковете, които има на платката.
(Лаптопите захранват своите дискове по подобен начин.) Нормата на сървъра е да доставя много
нива на напрежение, необходими на дисковете и чиповете директно. Това опростяване означава, че
захранването от 2007 г. може да работи с 92% ефективност, което е далеч над рейтинга Gold за
захранвания през 2010 г. (Фигура 6.17).
Инженерите на Google разбраха, че 12 волта означава, че UPS може просто да бъде стандартна
батерия на всеки рафт. Следователно, вместо да има отделно помещение за батерии, което Фигура
6.9 показва като 94% ефективност, всеки сървър има собствена оловно-киселинна батерия, която е
99,99% ефективност. Този „разпределен UPS“ се внедрява постепенно с всяка машина, което означава,
че няма изразходвани пари или енергия за свръхкапацитет. Те използват стандартни готови UPS
устройства за защита на мрежовите комутатори.
Какво ще кажете за пестенето на енергия чрез използване на динамично мащабиране на
напрежението и честотата (DVFS), което е описано в глава 1 ? DVFS не беше внедрен в това семейство
машини, тъй като въздействието върху латентността беше такова, че беше осъществимо само в
региони с много ниска активност за онлайн работни натоварвания и дори в тези случаи
спестяванията за цялата система бяха много малки. Поради това сложната верига за контрол на
управлението, необходима за внедряването му, не може да бъде оправдана.
1.4
А д аз
б Е Дж
°С Ж
д з
1.3
1.2
1.1
1.0
Q3 '07 Q4 '07Q1 '08 Q2 '08Q3 '08Q4 '08 Q1 '09Q2 '09Q3 '09Q4 '09 Q1 '10Q2 '10 Q3 '10Q4 '10
Фигура 6.22 Ефективност на потребление на енергия (PUE) на 10 Google WSC във времето. Google A е WSC,
описан в този раздел. Това е най-високата линия през Q3 '07 и Q2 '10. (От www.google.com/corporate/green/
datacenters/measuring.htm.) Facebook наскоро обяви нов център за данни, който трябва да осигури
впечатляващ PUE от 1.07 (вижте http://opencompute.org/).
Съоръжението в Приневил Орегон няма климатик и охладена вода. Той разчита стриктно на външен въздух,
който се вкарва от едната страна на сградата, филтрира се, охлажда се чрез смесители, изпомпва се през ИТ
оборудването и след това се изпраща навън от сградата чрез смукателни вентилатори. Освен това
сървърите използват персонализирано захранване, което позволява на системата за разпределение на
захранването да пропусне една от стъпките за преобразуване на напрежението на Фигура 6.9.
Един от ключовете за постигане на PUE от 1,23 беше поставянето на измервателни

устройства (наречени токови трансформатори) във всички вериги в контейнерите и на
други места в WSC за измерване на действителното потребление на енергия. Тези
измервания позволиха на Google да настрои дизайна на WSC с течение на времето.
Google публикува PUE на своите WSC всяко тримесечие. Фигура 6.22 показва PUE за 10
Google WSC от третото тримесечие на 2007 г. до второто тримесечие на 2010 г.; този раздел
описва WSC с етикет Google A. Google E работи с PUE от 1,16, като охлаждането е само 0,105,
поради по-високите работни температури и прекъсванията на охладителя. Разпределението
на мощността е само 0,039, поради разпределеното UPS и захранването с едно напрежение.
Най-добрият резултат на WSC беше 1.12, с Google A на 1.23. През април 2009 г. средната
стойност за последните 12 месеца, претеглена по използване във всички центрове за данни,
беше 1,19.
Сървъри в Google WSC

Сървърът на Фигура 6.21 има два сокета, всеки от които съдържа двуядрен процесор AMD
Opteron, работещ на 2,2 GHz. Снимката показва осем DIMMS и
тези сървъри обикновено се разполагат с 8 GB DDR2 DRAM. Нова характеристика е, че шината на

паметта е понижена до 533 MHz от стандартните 666 MHz, тъй като по-бавната шина има малко
влияние върху производителността, но значително влияние върху мощността.
Базовият дизайн има единична мрежова интерфейсна карта (NIC) за 1 Gbit/sec Ethernet
връзка. Въпреки че снимката на Фигура 6.21 показва две SATA дискови устройства, базовият
сървър има само едно. Пиковата мощност на базовата линия е около 160 вата, а мощността на
празен ход е 85 вата.
Този базов възел е допълнен, за да предложи възел за съхранение (или „пълен диск“).
Първо към сървъра е свързана втора тава, съдържаща 10 SATA диска. За да получите още един
диск, втори диск се поставя на празното място на дънната платка, давайки на възела за
съхранение 12 SATA диска. И накрая, тъй като възелът за съхранение може да насити една
единствена Ethernet връзка от 1 Gbit/sec, беше добавен втори Ethernet NIC. Пиковата мощност за
възел за съхранение е около 300 вата, а на празен ход е 198 вата.
Обърнете внимание, че възелът за съхранение заема два слота в стелажа, което е една от
причините Google да разположи 40 000 вместо 52 200 сървъра в 45-те контейнера. В това
съоръжение съотношението беше около два изчислителни възела за всеки възел за съхранение,
но това съотношение варираше значително между WSC на Google. Следователно Google A имаше
около 190 000 диска през 2007 г. или средно почти 5 диска на сървър.
Работа в мрежа в Google WSC
40 000 сървъра са разделени на три масива с повече от 10 000 сървъра всеки. (Масивите се
наричат клъстери в терминологията на Google.) 48-портовият стелажен превключвател използва
40 порта за свързване със сървъри, оставяйки 8 за връзка нагоре към масивните превключватели.
Array комутаторите са конфигурирани да поддържат до 480 1 Gbit/sec Ethernet връзки и
няколко 10 Gbit/sec порта. 1 Gigabit портовете се използват за свързване към стелажните суичове,
тъй като всеки стелажен суич има една връзка към всеки от масивните суичове. 10 Gbit/sec
портовете се свързват към всеки от двата рутера на центъра за данни, които обединяват всички
масиви от рутери и осигуряват връзка с външния свят. WSC използва два рутера за център за
данни за надеждност, така че един отказ на рутер за център за данни не премахва целия WSC.
Броят на портовете за връзка нагоре, използвани за комутатор в стелаж, варира от минимум

2 до максимум 8. В случая с двоен порт, комутаторите в стелаж работят при процент на
свръхабонамент от 20:1. Това означава, че има 20 пъти по-голяма честотна лента на мрежата
вътре в комутатора, отколкото при излизане от комутатора. Приложенията със значителни
изисквания за трафик извън стелажа обикновено страдат от лоша производителност на мрежата.
Следователно дизайнът с 8 порта за връзка нагоре, който осигурява по-нисък процент на
презаписване от само 5:1, беше използван за масиви с по-взискателни изисквания за трафик.
Мониторинг и ремонт в Google WSC
За да отговаря един оператор за повече от 1000 сървъра, имате нужда от обширна инфраструктура
за наблюдение и известна автоматизация, за да помогнете с рутинни събития.
Google внедрява софтуер за наблюдение, за да следи изправността на всички сървъри и

мрежово оборудване. Диагностиката тече през цялото време. Когато една система се повреди, много
от възможните проблеми имат прости автоматизирани решения. В този случай следващата стъпка е
да рестартирате системата и след това да опитате да преинсталирате софтуерните компоненти. По
този начин процедурата се справя с повечето неуспехи.
Машините, които не изпълнят тези първи стъпки, се добавят към опашка от машини за ремонт.
Диагнозата на проблема се поставя в опашката заедно с идентификатора на неуспешната машина.
За да се амортизират разходите за ремонт, повредените машини се адресират на партиди от

ремонтни техници. Когато диагностичният софтуер е уверен в оценката си, частта се заменя
незабавно, без да преминава през процеса на ръчна диагностика. Например, ако диагностиката
казва, че диск 3 на възел за съхранение е лош, дискът се заменя незабавно. Неизправните машини
без диагностика или с диагностика с ниска степен на сигурност се проверяват ръчно.
Целта е да имате по-малко от 1% от всички възли в опашката за ръчни поправки във всеки един
момент. Средното време на опашката за ремонт е една седмица, въпреки че отнема много по-малко
време на ремонтния техник да го поправи. По-дългата латентност предполага значението на
производителността на ремонта, което се отразява на разходите за операции. Имайте предвид, че
автоматизираните ремонти на първата стъпка отнемат минути за рестартиране/преинсталиране до
часове за провеждане на насочени стрес тестове, за да се уверите, че машината наистина работи.
Тези закъснения не отчитат времето за бездействие на повредените сървъри.
Причината е, че голяма променлива е количеството състояние в възела. Възел без състояние отнема
много по-малко време от възел за съхранение, чиито данни може да се наложи да бъдат евакуирани,
преди да могат да бъдат заменени.
Резюме
Към 2007 г. Google вече демонстрира няколко иновации за подобряване на енергийната ефективност
на своите WSC, за да достави PUE от 1,23 в Google A:
В допълнение към осигуряването на евтина обвивка за затваряне на сървъри, модифицираните

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

намалява енергията за движение на въздуха.
Работата на сървъри при по-високи температури означава, че въздухът трябва да се охлади само до
81°F (27°C) вместо традиционните 64°F до 71°F (18°C до 22°C).
По-високата целева температура на студения въздух помага съоръжението да се поддържа по-често в

диапазона, който може да се поддържа от решения за охлаждане с изпаряване (охладителни кули),
които са по-енергийно ефективни от традиционните чилъри.
Разполагане на WSC в умерен климат, за да се позволи използването на изпарително охлаждане

изключително за части от годината.
Внедряването на обширен хардуер и софтуер за наблюдение за измерване на действителния PUE

спрямо проектирания PUE подобрява оперативната ефективност.
Експлоатиране на повече сървъри, отколкото предполага най-лошият сценарий за системата за

разпределение на електроенергия, тъй като е статистически малко вероятно хиляди
всички сървъри биха били много заети едновременно, но въпреки това разчитат на мониторинга
система да разтоварват работата в малко вероятния случай, че са го направили [Fan, Weber и
Barroso 2007] [Ranganathan et al. 2006]. PUE се подобрява, защото съоръжението
работи по-близо до своя напълно проектиран капацитет, където е най-ефективен, тъй като сървърите
и охладителните системи не са пропорционални на енергията.
Такова увеличено използване намалява търсенето на нови сървъри и нови WSC.
Проектиране на дънни платки, които се нуждаят само от едно 12-волтово захранване, така че
UPS функцията може да бъде осигурена от стандартни батерии, свързани с всяка от тях
сървър вместо стая за батерии, като по този начин намалява разходите и намалява един
източник на неефективност на разпределението на електроенергия в WSC.
Внимателно проектиране на самата сървърна платка за подобряване на нейната енергийна ефективност. За
например намаляването на честотата на предната шина на тези микропроцесори намалява

потребление на енергия с незначително въздействие върху производителността. (Имайте предвид,
че такива оптимизации не влияят на PUE, но намаляват общото потребление на WSC енергия.)
Дизайнът на WSC трябва да се е подобрил през следващите години като най-добрият WSC на Google
намали PUE от 1,23 за Google A на 1,12. Facebook обяви през
2011, че са намалили PUE до 1,07 в новия си център за данни (вижте http://
opencompute.org/). Ще бъде интересно да видим какви иновации остават
подобри допълнително ефективността на WSC, така че да бъдем добри пазители на нашата околна среда.
Може би в бъдеще дори ще вземем предвид енергийните разходи за производство на оборудване в WSC
[Chang et al. 2010].
Въпреки че WSC е на по-малко от десетилетие, архитектите на WSC харесват тези в Google

вече са разкрили много клопки и заблуди относно WSC, често научавани
трудният начин. Както казахме във въведението, архитектите на WSC са днешните Sey-mour Crays.
Fallacy Доставчиците на облачни изчисления губят пари.
Популярен въпрос относно облачните изчисления е дали е печелившо при тези ниски цени
цени.
Въз основа на ценообразуването на AWS от Фигура 6.15, бихме могли да таксуваме $0,68 на час на
сървър за изчисления. (Цената от $0,085 на час е за виртуална машина
еквивалентно на една изчислителна единица EC2, а не на пълен сървър.) Ако можехме да продадем 50% от
сървърните часове, това ще генерира $0,34 доход на час на сървър. (Забележка
че клиентите плащат независимо колко малко използват сървърите, които заемат, така че продажбата на
50% от сървърните часове не означава непременно, че средното използване на сървъра е 50%.)
Друг начин за изчисляване на дохода би бил използването на запазени екземпляри на AWS,

където клиентите плащат годишна такса за резервиране на екземпляр и след това по-ниска ставка за
час, за да го използвате. Комбинирайки таксите заедно, AWS ще получи $0,45 доход на час на сървър за цяла
година.
Ако можехме да продадем 750 GB на сървър за съхранение, използвайки ценообразуването на AWS, в
допълнение към приходите от изчисления, това ще генерира още $75 на месец на сървър или още $0,10 на час.
Тези числа предполагат среден доход от $0,44 на час на сървър (чрез екземпляри при поискване) до $0,55
на час (чрез резервирани инстанси). От Фигура 6.13 изчислихме цената на сървър като $0,11 на час за WSC в
Раздел 6.4. Въпреки че разходите във Фигура 6.13 са приблизителни оценки, които не се основават на
действителните разходи за AWS, а 50% продажби за сървърна обработка и 750 GB използване на съхранение
на сървър са само примери, тези допускания предполагат брутен марж от 75% до 80%. Ако приемем, че тези
изчисления са разумни, те предполагат, че облачните изчисления са печеливши, особено за бизнеса с услуги.
Заблуда Капиталовите разходи на WSC съоръжението са по-високи отколкото за сървърите, които се помещават.
Докато един бърз поглед към Фигура 6.13 на страница 453 може да ви доведе до това заключение, този поглед
пренебрегва продължителността на амортизацията за всяка част от пълния WSC.
Съоръжението обаче издържа от 10 до 15 години, докато сървърите трябва да се изкупуват отново на всеки 3
или 4 години. Използвайки времената на амортизация във Фигура 6.13 съответно за 10 години и 3 години,
капиталовите разходи за едно десетилетие са $72 милиона за съоръжението и 3,3 × $67 милиона, или $221
милиона, за сървъри. По този начин капиталовите разходи за сървъри в WSC за едно десетилетие са фактор
три по-високи, отколкото за WSC съоръжението.
Клопка Опитвайки се да спестите енергия с неактивни режими на ниска мощност срещу активна ниска мощност
режими.
Фигура 6.3 на страница 440 показва, че средното използване на сървърите е между 10% и 50%. Като се има
предвид загрижеността относно оперативните разходи на WSC от раздел 6.4, бихте помислили, че режимите с
ниска мощност биха били от огромна помощ.
Както се споменава в глава 1 , не можете да получите достъп до DRAM или дискове в тези неактивни
режими на ниска мощност, така че трябва да се върнете към напълно активен режим, за да четете или пишете,
без значение колко ниска е скоростта. Клопката е, че времето и енергията, необходими за връщане към
напълно активен режим, правят неактивните режими с ниска мощност по-малко привлекателни. Фигура 6.3
показва, че почти всички сървъри имат средно поне 10% използване, така че може да очаквате дълги периоди
на ниска активност, но не и дълги периоди на неактивност.
За разлика от това, процесорите все още работят в режими с по-ниска мощност с малко кратно на
нормалната скорост, така че активните режими с ниска мощност са много по-лесни за използване. Обърнете
внимание, че времето за преминаване към напълно активен режим за процесорите също се измерва в
микросекунди, така че активните режими с ниска мощност също се справят с опасенията за забавяне на
режимите с ниска мощност.
Клопка Използване на твърде слаб процесор, когато се опитвате да подобрите разходната производителност на WSC.
Законът на Amdahl все още се прилага за WSC, тъй като ще има известна серийна работа за всяка заявка и това
може да увеличи латентността на заявката, ако тя работи на бавен сървър [Hölzle 2010] [Lim et al. 2008]. Ако
серийната работа увеличава латентността, тогава разходите за използване на wimpy процесор трябва да
включват разходите за разработка на софтуер за оптимизиране на

код, за да го върне към по-ниската латентност. По-големият брой нишки на много бавни сървъри също
може да бъде по-труден за планиране и балансиране на натоварването и по този начин променливостта
в производителността на нишките може да доведе до по-дълги закъснения. Шансът 1 на 1000 за лошо

планиране вероятно не е проблем с 10 задачи, но е проблем с 1000 задачи, когато трябва да чакате за
най-дългата задача. Много по-малки сървъри също могат да доведат до по-ниско използване, тъй като
е очевидно по-лесно да се планира, когато има по-малко неща за планиране. И накрая, дори някои
паралелни алгоритми стават по-малко ефективни, когато проблемът е разделен твърде фино.
Основното правило на Google понастоящем е да се използва нисък клас компютри от сървърен клас
[Barroso and Hölzle 2009].
Като конкретен пример Reddi et al. [2010] сравнява вградени микропроцесори (Atom) и сървърни
микропроцесори (Nehalem Xeon), работещи с търсачката Bing. Те установиха, че забавянето на заявка
е около три пъти по-дълго при Atom, отколкото при Xeon. Освен това Xeon беше по-здрав.
Тъй като натоварването на Xeon се увеличава, качеството на услугата се влошава постепенно и

умерено. Atom бързо нарушава целта си за качество на услугата, докато се опитва да поеме
допълнително натоварване.
Това поведение се превежда директно в качеството на търсенето. Като се има предвид значението
на латентността за потребителя, както показва Фигура 6.12 , търсачката Bing използва множество
стратегии за прецизиране на резултатите от търсенето, ако латентността на заявката все още не е
надвишила граничната латентност. По-ниската латентност на по-големите Xeon възли означава, че те
могат да отделят повече време за прецизиране на резултатите от търсенето. Следователно, дори когато
Atom почти не беше натоварен, той даде по-лоши отговори в 1% от заявките от Xeon. При нормални
натоварвания 2% от отговорите са по-лоши.
Заблуда Предвид подобренията в надеждността на DRAM и устойчивостта на грешки на WSC системния софтуер, не
е нужно да харчите допълнително за ECC памет в WSC.
Тъй като ECC добавя 8 бита към всеки 64 бита DRAM, потенциално бихте могли да спестите една девета
от разходите за DRAM чрез елиминиране на кода за коригиране на грешки (ECC), особено след като
измерванията на DRAM твърдят, че процентът на отказ е от 1000 до 5000 FIT (повреди на милиард
часове работа) на мегабит [Tezzaron Semiconductor 2004].
Schroeder, Pinheiro и Weber [2009] проучиха измерванията на DRAM с ECC защита в повечето WSC
на Google, което със сигурност беше много стотици хиляди сървъри, за период от 2,5 години. Те откриха
15 до 25 пъти по-високи нива на FIT от публикуваните, или 25 000 до 70 000 повреди на мегабит.
Повредите засегнаха повече от 8% от DIMM модулите, а средният DIMM имаше 4000 коригираеми
грешки и 0,2 некоригируеми грешки на година. Измерени на сървъра, около една трета са имали DRAM
грешки всяка година, със средно 22 000 коригираеми грешки и 1 некоригируема грешка на година.
Тоест за една трета от сървърите една грешка в паметта се коригира на всеки 2,5 часа. Обърнете
внимание, че тези системи използват по-мощните кодове за унищожаване на чипове, а не по-простите
кодове SECDED. Ако беше използвана по-простата схема, процентът на некоригируеми грешки щяха да
бъдат 4 до 10 пъти по-високи.
В WSC, който има само защита срещу грешка при паритет, сървърите ще трябва да се рестартират
за всяка грешка при паритет на паметта. Ако времето за рестартиране беше 5 минути, една трета от
машините биха прекарали 20% от времето си в рестартиране! Подобно поведение би
понижи производителността на съоръжението на стойност $150 милиона с около 6%. Освен това, тези
системи биха претърпели много непоправими грешки, без операторите да бъдат уведомени
че са се случили.
В първите години Google използваше DRAM, която дори нямаше паритетна защита. През 2000 г., по
време на тестването преди изпращането на следващото издание на индекса за търсене,
започна да предлага произволни документи в отговор на тестови запитвания [Барозу и

Hölzle 2009]. Причината беше грешка при блокиране на нула в някои DRAM, която повреди новия индекс.
Google добави проверки за последователност, за да открие такива грешки
бъдещето. Тъй като WSC нарастваше по размер и ECC DIMM модулите ставаха по-достъпни,
ECC стана стандарт в Google WSC. ECC има допълнителното предимство да прави много по-лесно намирането
на счупени DIMM модули по време на ремонт.
Такива данни подсказват защо Fermi GPU (глава 4) добавя ECC към своята памет
където неговите предшественици дори нямаха паритетна защита. Освен това тези FIT
процентите хвърлят съмнения върху усилията за използване на процесора Intel Atom в WSC - поради неговата
подобрена енергийна ефективност—тъй като чипсетът от 2011 г. не поддържа ECC

DRAM.
Заблуда Изключването на хардуера по време на периоди на ниска активност подобрява ефективността на разходите на
WSC.
Фигура 6.14 на страница 454 показва, че разходите за амортизация на електроразпределението
и охладителната инфраструктура е с 50% по-висока от цялата месечна сметка за електроенергия.
Следователно, въпреки че със сигурност ще спести малко пари за компактиране на работните натоварвания и обръщане
изключени от неактивни машини, дори и да можете да спестите половината енергия, това само ще намали
месечна оперативна сметка със 7%. Ще има и практически проблеми за преодоляване, тъй като обширната
инфраструктура за мониторинг на WSC зависи от възможността
да мушнете оборудването и да го видите как реагира. Друго предимство на енергийната пропорционалност
и активните режими с ниска мощност е, че те са съвместими с инфраструктурата за мониторинг на WSC,
което позволява на един оператор да отговаря за повече

над 1000 сървъра.
Традиционната мъдрост на WSC е да изпълнявате други ценни задачи по време на периоди
с ниска активност, така че да възвърне инвестицията в разпределение на електроенергия и охлаждане.
Основен пример са пакетните задания MapReduce, които създават индекси за търсене.
Друг пример за получаване на стойност от ниското използване е спот ценообразуването на AWS,
което описва надписът на Фигура 6.15 на страница 458. Потребителите на AWS, които са гъвкави относно
това кога се изпълняват техните задачи, могат да спестят коефициент от 2,7 до 3 за изчисление
като позволи на AWS да планира задачите по-гъвкаво с помощта на Spot Instances, като напр
когато WSC иначе би имал ниско използване.
Заблуда Замяната на всички дискове с флаш памет ще подобри разходната производителност на WSC.
Флаш паметта е много по-бърза от диска за някои работни натоварвания на WSC, като тези
извършване на много произволни четения и записи. Например Facebook внедри Flash
памет, пакетирана като твърдотелни дискове (SSD) като кеш за обратно записване, наречен Flash-cache, като
част от неговата файлова система в своя WSC, така че горещите файлове остават във Flash, а студените
файловете остават на диска. Въпреки това, тъй като всички подобрения на производителността в WSC трябва
да се прецени по отношение на разходите и производителността, преди да смените всички дискове със

SSD, въпросът наистина е I/O за секунда на долар и капацитет за съхранение на долар. Както видяхме в
глава 2, флаш паметта струва поне 20 пъти повече на GByte от магнитните дискове: $2,00/GByte срещу
$0,09/Gbyte.
Narayanan и др. [2009] разглежда мигрирането на работните натоварвания от диск към SSD чрез
симулиране на следи на работните натоварвания от малки и големи центрове за данни. Тяхното
заключение беше, че SSD дисковете не са икономически ефективни за нито едно от техните работни
натоварвания поради ниския капацитет за съхранение на долар. За да достигнат точката на рентабилност,
устройствата за съхранение с флаш памет трябва да подобрят капацитета на долар с коефициент от 3 до
3000, в зависимост от натоварването.
Дори когато включите мощността в уравнението, е трудно да се оправдае замяната на диск с Flash
за данни, които са рядко достъпни. Диск от един терабайт използва около 10 вата мощност, така че,
използвайки основното правило за $2 на ват година от раздел 6.4, най-многото, което можете да спестите
от намалена енергия, е $20 на година на диск.
Въпреки това, CAPEX разходите през 2011 г. за терабайт място за съхранение са $2000 за Flash и само $90
за диск.

Наследявайки титлата за изграждане на най-големите компютри в света, компютърните архитекти на
WSC проектират голяма част от бъдещите ИТ, които завършват мобилния клиент. Много от нас използват
WSC много пъти на ден и броят пъти на ден и броят на хората, използващи WSC със сигурност ще се
увеличи през следващото десетилетие.
Вече повече от половината от близо седемте милиарда души на планетата имат мобилни телефони. Тъй
като тези устройства стават готови за интернет, много повече хора от цял свят ще могат да се възползват
от WSC.
Нещо повече, икономиите от мащаба, открити от WSC, са реализирали дълго мечтаната цел за
компютри като полезност. Облачните изчисления означават, че всеки навсякъде с добри идеи и бизнес
модели може да използва хиляди сървъри, за да представи своята визия почти мигновено. Разбира се,
има важни пречки, които биха могли да ограничат растежа на облачните изчисления около стандартите,
поверителността и скоростта на растеж на интернет честотната лента, но ние предвиждаме да бъдат
разгледани, така че облачните изчисления да могат да процъфтяват.
Предвид нарастващия брой ядра на чип (вижте глава 5), клъстерите ще се увеличат, за да включват
хиляди ядра. Ние вярваме, че технологиите, разработени за управление на WSC, ще се окажат полезни и
ще преминат към клъстери, така че клъстерите да изпълняват същите виртуални машини и системен
софтуер, разработен за WSC. Едно предимство би било лесната поддръжка на „хибридни“ центрове за
данни, където работното натоварване може лесно да бъде изпратено в облака в крачка и след това да се
свие обратно, за да разчита само на локални изчисления.
Сред многото привлекателни характеристики на облачните изчисления е, че те предлагат

икономически стимули за опазване. Като има предвид, че е трудно да се убедят доставчиците на облачни
изчисления да изключат неизползваното оборудване, за да пестят енергия, предвид

цената на инфраструктурната инвестиция, лесно е да убедите потребителите на облачни

изчисления да се откажат от неактивни копия, тъй като те плащат за тях, независимо дали правят
нещо полезно или не. По същия начин таксуването според употребата насърчава програмистите
да използват ефективно изчисленията, комуникацията и съхранението, което може да бъде трудно
за насърчаване без разбираема ценова схема. Изричното ценообразуване също така дава
възможност на изследователите да оценяват иновациите в съотношението цена/производителност
вместо само изпълнението, тъй като разходите вече са лесно измерени и правдоподобни. И
накрая, облачните изчисления означават, че изследователите могат да оценят своите идеи в
мащаба на хиляди компютри, което в миналото само големите компании можеха да си позволят.
Вярваме, че WSC променят целите и принципите на дизайна на сървърите, точно както

нуждите на мобилните клиенти променят целите и принципите на дизайна на микропроцесорите.
И двамата революционизират и софтуерната индустрия. Производителността на долар и
производителността на джаул управляват както хардуера на мобилния клиент, така и хардуера на
WSC, а паралелизмът е ключът към постигането на тези набори от цели.
Архитектите ще играят жизненоважна роля и в двете половини на този вълнуващ бъдещ свят.
Очакваме с нетърпение да видим — и да използваме — какво ще дойде.
Раздел L.8 (достъпен онлайн) обхваща разработването на клъстери, които са в

основата на WSC и на комуналните изчисления. (Читателите, които искат да научат
повече, трябва да започнат с Barroso и Hölzle [2009] и публикациите в блога и
разговорите на James Hamilton на http://perspectives.mvdirona.com.)
Казуси и упражнения от Parthasarathy

Ранганатан
Казус 1: Обща цена на притежание, влияеща върху склада-
Мащабни компютърни дизайнерски решения
Обща цена на притежание (TCO)
Влияние на цената и мощността на сървъра върху целия WSC
Предимства и недостатъци на сървърите с ниска мощност
Общата цена на притежание е важен показател за измерване на ефективността на компютри от

складов мащаб (WSC). TCO включва както CAPEX, така и OPEX, описани в раздел 6.4 , и отразява
разходите за притежание на целия център за данни за постигане на определено ниво на
производителност. При разглеждането на различни сървъри, мрежи и архитектури за съхранение,
TCO често е важен показател за сравнение
използвани от собствениците на центрове за данни, за да решат кои опции са най-добри; TCO обаче е a
многомерно изчисление, което взема предвид много различни фактори.
Целта на този казус е да се разгледа подробно WSCs, колко различни са
архитектурите влияят на TCO и как TCO управлява решенията на оператора. Този случай
изследването ще използва числата от Фигура 6.13 и Раздел 6.4 и предполага, че
описаният WSC постига целевото ниво на производителност на оператора. TCO е
често се използва за сравняване на различни сървърни опции, които имат множество измерения.
Упражненията в този казус изследват как се правят подобни сравнения в
контекста на WSC и сложността, свързана с вземането на решения.
6.1 [5/5/10] <6.2, 6.4> В тази глава паралелизмът на ниво данни беше обсъден като
начин WSC да постигнат висока производителност при големи проблеми. Вероятно,
още по-голяма производителност може да се постигне чрез използване на сървъри от висок клас; въпреки това,
сървърите с по-висока производителност често идват с нелинейно увеличение на цената.
а. [5] <6.4> Ако приемем сървъри, които са с 10% по-бързи при същото използване, но
20% по-скъпо, какъв е CAPEX за WSC?
b. [5] <6.4> Ако тези сървъри също използват 15% повече енергия, какъв е OPEX?
° С. [10] <6.2, 6.4> Като се има предвид подобрението на скоростта и увеличаването на мощността, какво трябва
цената на новите сървъри да бъде сравнима с оригиналния клъстер? (Съвет:

Въз основа на този TCO модел може да се наложи да промените критичното натоварване на
съоръжение.)
6.2 [5/10] <6.4, 6.8> За да постигнете по-ниски OPEX, една привлекателна алтернатива е да използвате
версии на сървъри с ниска мощност, за да се намали общата електроенергия, необходима за работа на
сървъри; обаче, подобно на сървъри от висок клас, версии с ниска мощност на висок клас
компонентите също имат нелинейни компромиси.
а. [5] <6.4, 6.8> Ако опциите за сървър с ниска мощност предлагат 15% по-ниска мощност при
същата производителност, но са с 20% по-скъпи, добър компромис ли са?
b. [10] <6.4, 6.8> На каква цена сървърите стават сравними с оригинала

последен клъстер? Ами ако токът скочи двойно?
6.3 [5/10/15] <6.4, 6.6> Сървърите, които имат различни режими на работа, предлагат възможности за
динамично изпълнение на различни конфигурации в клъстера, за да съответстват
използване на работното натоварване. Използвайте данните от Фигура 6.23 за режимите мощност/производителност
за даден сървър с ниска мощност.
а. [5] <6.4, 6.6> Ако оператор на сървър реши да спести разходи за енергия, като стартира всички
сървъри със средна производителност, колко сървъра ще са необходими
постигнете същото ниво на производителност?
Режим производителност Мощност
Високо 100% 100%
Среден 75% 60%
ниско 59% 38%
Фигура 6.23 Режими на мощност – производителност за сървъри с ниска мощност.

b. [10] <6.4, 6.6> Какви са CAPEX и OPEX на такава конфигурация? ° С. [15] <6.4, 6.6> Ако има
алтернатива за закупуване на сървър, който е с 20% по-евтин, но по-бавен и използва по-

малко енергия, намерете кривата производителност-мощност, която осигурява TCO,
сравнима с тази на базовия сървър.
6.4 [Дискусия] <6.4> Обсъдете компромисите и ползите от двете опции в Упражнение 6.3, като
приемем, че на сървърите се изпълнява постоянно работно натоварване.
6.5 [Дискусия] <6.2, 6.4> За разлика от клъстерите за високопроизводителни изчисления (HPC), WSC
често изпитват значителни колебания в работното натоварване през целия ден. Обсъдете
компромисите и ползите от двете опции в Упражнение 6.3, като този път приемете работно
натоварване, което варира.
6.6 [Дискусия] <6.4, 6.7> TCO моделът, представен досега, абстрахира значително количество
подробности от по-ниско ниво. Обсъдете въздействието на тези абстракции върху общата
точност на модела TCO. Кога тези абстракции са безопасни за правене? В какви случаи по-
голямата подробност би дала значително различни отговори?
Казус 2: Разпределяне на ресурси в WSCs и TCO
Сървър и захранване в рамките на WSC
Времева вариация на работните натоварвания
Ефекти от отклонението върху TCO
Някои от ключовите предизвикателства пред внедряването на ефективни WSC са правилното

осигуряване на ресурси и пълното им използване. Този проблем е сложен поради размера на
WSC, както и потенциалната вариация на изпълняваните работни натоварвания. Упражненията
в този казус показват как различното използване на ресурси може да повлияе на TCO.
6.7 [5/5/10] <6.4> Едно от предизвикателствата при предоставянето на WSC е определянето на

правилното захранване, като се има предвид размерът на съоръжението. Както е описано в
главата, мощността на табелката често е пикова стойност,
която рядко се среща. а. [5] <6.4> Оценете как се променя TCO за сървър, ако сървърът с табелка
мощността е 200 вата и цената е $3000.
b. [5] <6.4> Също така помислете за по-висока мощност, но по-евтин вариант, чиято мощност е
300 вата и струва $2000.
° С. [10] <6.4> Как се променя TCO за сървър, ако действителното средно потребление на
енергия от сървърите е само 70% от мощността, посочена в табелата?
6.8 [15/10] <6.2, 6.4> Едно предположение в модела TCO е, че критичното натоварване на съоръжението е фиксирано
и количеството сървъри отговаря на това критично натоварване. В действителност, поради вариациите на
мощността на сървъра в зависимост от натоварването, критичната мощност, използвана от дадено
съоръжение, може да варира във всеки един момент. Операторите трябва първоначално да осигурят центъра за данни
въз основа на неговите критични енергийни ресурси и оценка на това колко енергия се използва от
компонентите на центъра за данни. а.
[15] <6.2, 6.4> Разширете модела TCO, за да осигурите първоначално WSC на базата на сървър с мощност
от 300 вата, но също така изчислете действителната месечна използвана критична мощност и TCO,
като приемете, че сървърът е средно 40% използване и 225 вата . Колко капацитет остава неизползван?
b. [10] <6.2, 6.4> Повторете това упражнение с 500-ватов сървър, който е средно 20%
оползотворяване и 300 вата.
6.9 [10] <6.4, 6.5> WSC често се използват по интерактивен начин с крайни потребители, както е споменато в раздел
6.5. Това интерактивно използване често води до колебания на времето от деня, като пиковете са
свързани с конкретни периоди от време. Например, за наемането на Netflix има пик през вечерните
периоди от 8 до 22 часа; съвкупността от тези ефекти на времето от деня е значителна. Сравнете TCO на
сървър на център за данни с капацитет, съответстващ на използването в 4 сутринта в сравнение с 21:00
6.10 [Дискусия/15] <6.4, 6.5> Обсъдете някои опции за по-добро използване на излишните сървъри по време на
ненатоварените часове или опции за спестяване на разходи. Предвид интерактивния характер на WSC,
какви са някои от предизвикателствата пред агресивното намаляване на потреблението на енергия?
6.11 [Дискусия/25] <6.4, 6.6> Предложете един възможен начин за подобряване на TCO чрез фокусиране върху
намаляване на мощността на сървъра. Какви са предизвикателствата при оценяването на вашето предложение?
Оценете подобренията на TCO въз основа на вашето предложение. Какви са предимствата и недостатъците?
6.12 [10/10/10] <6.1> Един от важните фактори на WSC е широкият паралелизъм на ниво заявка, за разлика от
паралелизма на ниво инструкция или нишка. Този въпрос изследва значението на различните типове
паралелизъм върху компютърната архитектура и системния дизайн. а. [10] <6.1> Обсъдете сценарии, при
които подобряването на
паралелизма на ниво инструкция или нишка би осигурило по-големи ползи от постижимите чрез
паралелизъм на ниво заявка.
b. [10] <6.1> Какви са последиците от увеличаването на паралелизма на ниво заявка върху софтуерния
дизайн?
° С. [10] <6.1> Какви са потенциалните недостатъци на нарастващия паралелизъм на ниво заявка?
6.13 [Дискусия/15/15] <6.2> Когато доставчик на облачни изчислителни услуги получи задания, състоящи се от
множество виртуални машини (VM) (напр. задание MapReduce), съществуват много опции за планиране.
Виртуалните машини могат да бъдат планирани по кръгов начин, за да се разпространяват между всички
налични процесори и сървъри, или могат да бъдат консолидирани, за да използват възможно най-малко
процесори. Използвайки тези опции за планиране, ако е изпратено задание с 24 VM и 30 процесора са
налични в облака (всеки може да работи с до 3 VM), кръговият режим ще използва 24 процесора,
докато консолидираното планиране би използвало 8 процесора. Планировчикът може също да намери

налични процесорни ядра в различни обхвати: сокет, сървър, стелаж и масив от стелажи. а. [Дискусия]
<6.2> Ако приемем,
че изпратените задания са тежки изчислителни натоварвания, вероятно с различни изисквания за

честотна лента на паметта, какви са плюсовете и минусите на кръговото в сравнение с
консолидираното планиране по отношение на разходите за захранване и охлаждане,
производителност и надеждност ? b. [15] <6.2> Ако приемем, че всички
изпратени задания са I/O-тежки работни натоварвания, какви са плюсовете и минусите на кръговото и

консолидираното планиране в различни обхвати?
° С. [15] <6.2> Ако приемем, че изпратените задания са тежки натоварвания на мрежата, какви са
плюсовете и минусите на кръговото планиране спрямо консолидираното планиране, в различни
обхвати?
6.14 [15/15/10/10] <6.2, 6.3> MapReduce позволява голямо количество паралелизъм, като изпълнява независими
от данни задачи на множество възли, често използвайки стандартен хардуер; обаче има ограничения
за нивото на паралелизъм. Например, за излишък, MapReduce ще записва блокове данни в множество
възли, консумирайки диск и потенциално мрежова честотна лента. Да приемем общ размер на набора
от данни от 300 GB, честотна лента на мрежата от 1 Gb/сек, скорост на карта 10 сек/ГБ и скорост на
намаляване от 20 сек/ГБ. Да предположим също, че 30% от данните трябва да бъдат прочетени от
отдалечени възли и всеки изходен файл се записва на два други възела за излишък. Използвайте
фигура 6.6 за всички останали параметри. а. [15] <6.2, 6.3> Да приемем, че всички възли са в една и
съща стойка. Какво е
очакваното време за изпълнение с 5 възела? 10 възела? 100 възли? 1000 възли? Обсъдете тесните
места при всеки размер на възела.
b. [15] <6.2, 6.3> Да приемем, че има 40 възела на стелаж и че всяко отдалечено четене/запис има
еднакъв шанс да отиде до всеки възел. Какво е очакваното време за изпълнение при 100 възела?
1000 възли?
° С. [10] <6.2, 6.3> Важно съображение е минимизиране на движението на данни, доколкото е възможно.
Като се има предвид значителното забавяне на преминаването от локален към стелаж към достъп
до масив, софтуерът трябва да бъде силно оптимизиран, за да увеличи максимално локалността.
Да приемем, че има 40 възела на багажник и 1000 възела се използват в задачата MapReduce.
Какво е времето за изпълнение, ако отдалечените достъпи са в рамките на една и съща стойка
през 20% от времето? 50% от времето? 80% от времето?
д. [10] <6.2, 6.3> Като се има предвид простата програма MapReduce в раздел 6.2, обсъдете някои
възможни оптимизации за максимално увеличаване на локалността на работното натоварване.
6.15 [20/20/10/20/20/20] <6.2> WSC програмистите често използват репликация на данни, за да преодолеят
грешките в софтуера. Hadoop HDFS, например, използва трипосочна репликация (едно локално копие,
едно отдалечено копие в стелажа и едно отдалечено копие в отделен стелаж), но си струва да се проучи
кога е необходима такава репликация. а. [20] <6.2> Проучване сред присъстващите на Hadoop
World 2010 показа, че над половината от клъстерите на Hadoop имат 10 възела или по-малко, с размер
на набора от данни от 10 TB или по-малко.
Използвайки данните за честотата на отказите на Фигура 6.1, какъв вид наличност има
Hadoop клъстер с 10 възела с едно-, дву- и трипосочни репликации? b. [20] <6.2> Ако
приемем данните за неизправност във Фигура 6.1 и Hadoop клъстер с 1000 възела, какъв вид
наличност има при едно-, дву- и трипосочни репликации?
° С. [10] <6.2> Относителните режийни разходи за репликация варират в зависимост от

количеството данни, записани за час локално изчисление. Изчислете количеството
допълнителен входно-изходен трафик и мрежовия трафик (вътре и през стелажа) за задача
на Hadoop с 1000 възела, която сортира 1 PB данни, където междинните резултати за
разбъркване на данни се записват в HDFS.
д. [20] <6.2> Като използвате фигура 6.6, изчислете времето за двупосочни и трипосочни
репликации. Като използвате нивата на неуспех, показани на Фигура 6.1, сравнете
очакваните времена за изпълнение при липса на репликация спрямо дву- и трипосочни
репликации.
д. [20] <6.2> Сега помислете за система от бази данни, прилагаща репликация върху
регистрационни файлове, като приемем, че всяка транзакция средно има достъп до
твърдия диск веднъж и генерира 1 KB регистрационни данни. Изчислете режийното време
за дву- и трипосочни репликации. Какво става, ако транзакцията се изпълнява в паметта и
отнема 10 μs? f. [20] <6.2> Сега помислете за система от бази данни с ACID консистенция, която
изисква две обиколки на мрежата за двуфазов ангажимент. Какво е режийното време за
поддържане на последователност, както и репликации?
6.16 [15/15/20/15/] <6.1, 6.2, 6.8> Въпреки че паралелизмът на ниво заявка позволява на много машини
да работят паралелно върху един проблем, като по този начин се постига по-голяма цялостна
производителност, едно от предизвикателствата е избягването на разделяне проблемът е
твърде фин. Ако разгледаме този проблем в контекста на споразуменията за ниво на обслужване
(SLA), използването на по-малки размери на проблема чрез по-голямо разделяне може да
изисква повече усилия за постигане на целевото SLA. Да приемем, че SLA от 95% от заявките
отговарят за 0,5 секунди или по-бързо и паралелна архитектура, подобна на MapReduce, която
може да стартира множество излишни задания, за да постигне същия резултат. За следните
въпроси приемете кривата на времето за заявка-отговор, показана на Фигура 6.24. Кривата
показва латентността на отговора въз основа на броя заявки в секунда за базов сървър, както и
за „малък“ сървър, който използва по-бавен процесорен модел.
а. [15] <6.1, 6.2, 6.8> Колко сървъра са необходими за постигане на това SLA, ако се приеме, че
WSC получава 30 000 заявки в секунда и кривата заявка – време за отговор, показана на
Фигура 6.24 ? Колко „малки“ сървъра са необходими за постигане на това SLA, като се има
предвид тази крива на вероятността за време за реакция?
Разглеждайки само разходите за сървъри, колко по-евтини трябва да бъдат „слабите“
сървъри от нормалните сървъри, за да се постигне предимство в разходите за целевото SLA?
b. [15] <6.1, 6.2, 6.8> Често „малките“ сървъри също са по-малко надеждни поради по-евтините
компоненти. Използвайки числата от Фигура 6.1, приемете, че броят на събитията, дължащи
се на нестабилни машини и лоши спомени, се увеличава с 30%. Колко „малки“ сървъра са
необходими сега? Колко по-евтини трябва да са тези сървъри от стандартните сървъри?
3
Базово ниво
2.5 малък
1.5
)иЛ(
тсонтнета
1
0,5
0
1 2 3 4 5 6 7 8 9 10
Заявки в секунда, за един сървър
Фигура 6.24 Крива на времето за заявка-отговор.
° С. [20] <6.1, 6.2, 6.8> Сега приемете среда за пакетна обработка. „Малките“ сървъри осигуряват
30% от общата производителност на обикновените сървъри. Все още приемайки числата
за надеждност от част (b) на упражнение 6.15, колко „слаби“ възли са необходими, за да
осигурят същата очаквана пропускателна способност на масив от 2400 възела от стандартни
сървъри, като се приеме перфектно линейно мащабиране на производителността спрямо
размера на възела и средна задача дължина от 10 минути на възел?
Ами ако скалирането е 85%? 60%? д. [15]
<6.1, 6.2, 6.8> Често скалирането не е линейна функция, а вместо това е логаритмична функция.
Естествен отговор може вместо това да бъде закупуване на по-големи възли, които имат
повече изчислителна мощност на възел, за да се минимизира размерът на масива.
Обсъдете някои от компромисите с тази архитектура.
6.17 [10/10/15] <6.3, 6.8> Една тенденция при сървърите от висок клас е към включването на
енергонезависима флаш памет в йерархията на паметта, или чрез твърдотелни дискове (SSD),
или PCI Express-прикрепени карти. Типичните SSD имат честотна лента от 250 MB/сек и
латентност от 75 μs, докато PCIe картите имат честотна лента от 600 MB/сек и латентност от 35
μs. а. [10] Вземете Фигура 6.7 и включете
тези точки в йерархията на локалния сървър.

Ако приемем, че идентични коефициенти на мащабиране на производителността като
DRAM са достъпни на различни нива на йерархия, как се сравняват тези устройства с флаш
памет, когато са достъпни през стелажа? През целия
масив? b. [10] Обсъдете някои базирани на софтуер оптимизации, които могат да използват новото ниво
на йерархията на паметта.
° С. [25] Повторете част (a), като вместо това приемете, че всеки възел има 32 GB PCIe карта
който е в състояние да кешира 50% от всички достъпи до диска.
д. [15] Както беше обсъдено в „Заблуди и капани“ (раздел 6.8), замяната на всички дискове със
SSD не е непременно рентабилна стратегия. Помислете за WSC оператор, който го използва
за предоставяне на облачни услуги. Обсъдете някои сценарии, при които използването на
SSD или друга флаш памет би имало смисъл.
6.18 [20/20/Дискусия] <6.3> Йерархия на паметта: Кеширането се използва силно в някои проекти на WSC
за намаляване на латентността и има множество опции за кеширане, за да се задоволят различни
модели и изисквания за достъп. а. [20] Нека
разгледаме дизайнерските опции за поточно предаване на богата медия от мрежата (напр. Netflix).
Първо трябва да преценим броя на филмите, броя на кодираните формати на филм и
потребителите, които гледат едновременно. През 2010 г. Netflix имаше 12 000 заглавия за
онлайн стрийминг, като всяко заглавие имаше поне четири кодирани формата (при 500, 1000,
1600 и 2200 kbps). Да приемем, че има 100 000 едновременни зрители за целия сайт и средно
един филм е с продължителност един час. Оценете общия капацитет за съхранение, I/O и
мрежовите честотни ленти, както и изчислителните изисквания, свързани с поточно видео.
b. [20] Какви са моделите на достъп и референтните характеристики на местоположението за

потребител, за филм и във всички филми? (Съвет: Случайна срещу последователна, добра
срещу лоша времева и пространствена локалност, относително малък спрямо голям работен
размер на набора.)
° С. [Дискусия] Какви опции за съхранение на филми съществуват чрез използване на DRAM, SSD и
твърди дискове? Сравнете ги по производителност и TCO.
6.19 [10/20/20/Дискусия/Дискусия] <6.3> Помислете за уеб сайт за социални мрежи със 100 милиона активни
потребители, които публикуват актуализации за себе си (в текст и снимки), както и разглеждат и
взаимодействат с актуализации в своите социални мрежи .
За да осигурят ниска латентност, Facebook и много други уеб сайтове използват memcached като
кеширащ слой преди нивата за съхранение/база данни в задната
част. а. [10] Оценете генерирането на данни и процентите на заявки за потребител и в целия

целия сайт.
b. [20] Колко DRAM е необходима за уеб сайта за социални мрежи, обсъждан тук, за да хоства
работния си набор? Използвайки сървъри, всеки от които има 96 GB DRAM, преценете колко
достъпа до локална спрямо отдалечена памет са необходими за генериране на начална
страница на потребител?
° С. [20] Сега разгледайте два кандидат-дизайна на memcached сървър, единият използващ

конвенционални процесори Xeon, а другият използващ по-малки ядра, като процесори Atom.
Като се има предвид, че memcached изисква голяма физическа памет, но има ниско използване
на процесора, какви са плюсовете и минусите на тези два дизайна?
д. [Дискусия] Днешното тясно свързване между модулите памет и процесорите често изисква
увеличаване на броя на процесорните гнезда, за да се осигури поддръжка на голяма памет.
Избройте други проекти за осигуряване на голяма физическа памет без пропорционално
увеличаване на броя на гнездата в сървъра. Сравнете ги въз основа на производителност,
мощност, разходи и надеждност.
д. [Дискусия] Информацията на един и същи потребител може да се съхранява както в mem-cash,

така и в сървъри за съхранение и такива сървъри могат да бъдат физически хоствани по
различни начини. Обсъдете плюсовете и минусите на следното оформление на сървъра в
WSC: (1) memcached, разположени на един и същ сървър за съхранение, (2) memcached и
сървър за съхранение на отделни възли в една и съща стойка или (3) memcached сървъри на
едни и същи стелажи и сървъри за съхранение, разположени на отделни стелажи.
6.20 [5/5/10/10/Дискусия/Дискусия] <6.3, 6.6> Мрежа на центъра за данни: Map-Reduce и WSC са мощна
комбинация за справяне с широкомащабна обработка на данни; например Google през 2008 г.
сортира един петабайт (1 PB) записи за малко повече от 6 часа, използвайки 4000 сървъра и 48 000
твърди диска. а. [5] Извлечете честотната лента на диска от Фигура 6.1 и
свързания текст. Колко секунди са необходими, за да се прочетат данните в основната памет и да се

запишат обратно сортираните резултати?
b. [5] Ако приемем, че всеки сървър има две 1 Gb/sec Ethernet мрежови интерфейсни карти (NIC) и
инфраструктурата на WSC комутатора е презаписана с коефициент 4, колко секунди са необходими
за разбъркване на целия набор от данни в 4000 сървъра?
° С. [10] Ако приемем, че мрежовият трансфер е тясното място на производителността за сортиране

на петабайти, можете ли да прецените какъв коефициент на свръхабонамент има Google в своя
център за данни?
д. [10] Сега нека разгледаме ползите от наличието на 10 Gb/sec Ethernet без прекомерен абонамент –
например използване на 48-портов 10 Gb/sec Ethernet (както се използва от победителя в
бенчмарка Indy sort 2010 TritonSort). Колко време отнема разбъркването на 1 PB данни?
д. [Дискусия] Сравнете двата подхода тук: (1) подходът за мащабно мащабиране с висок коефициент
на свръхабонамент на мрежата и (2) сравнително малка по мащаб система с мрежа с висока
честотна лента. Какви са техните потенциални затруднения? Какви са техните предимства и
недостатъци по отношение на скалируемостта и TCO?
f. [Дискусия] Сортиране и много важни научни изчислителни натоварвания са комуникационни тежки,

докато много други натоварвания не са. Избройте три примерни натоварвания, които не се
възползват от високоскоростна мрежа. Какви екземпляри на EC2 бихте препоръчали да
използвате за тези два класа натоварвания?
6.21 [10/25/Дискусия] <6.4, 6.6> Поради огромния мащаб на WSC е много важно да се разпределят правилно
мрежовите ресурси въз основа на работните натоварвания, които се очаква да бъдат изпълнени.
Различните разпределения могат да окажат значително въздействие както върху производителността,
така и върху общите разходи за притежание. а. [10]
Използвайки числата в електронната таблица, подробно описана на Фигура 6.13, какъв е коефициентът
на презаписване при всеки комутатор на ниво за достъп? Какво е въздействието върху TCO, ако
коефициентът на презаписване бъде намален наполовина? Ами ако се удвои?
b. [25] Намаляването на коефициента на свръхабонамент може потенциално да подобри

производителността, ако натоварването е ограничено от мрежата. Да приемем, че задача на
MapReduce използва 120 сървъра и чете 5 TB данни. Приемете същото съотношение на четене/
междинни/изходни данни, както на Фигура 6.2, Септември 2009 г., и използвайте Фигура 6.6, за
да дефинирате честотните ленти на йерархията на паметта. За четене на данни приемете, че 50%
от данните се четат от отдалечени дискове; от тях 80% се четат от стелажа и 20% се четат от
масива. За междинни данни и изходни данни приемете, че 30% от данните използват отдалечени
дискове; от тях 90% са в стелажа и 10% в масива. Какво е цялостното подобрение на
производителността
при намаляване на коефициента на свръхзаписване наполовина? Каква е производителността,

ако се удвои? Изчислете TCO във всеки случай.
° С. [Дискусия] Виждаме тенденцията към повече ядра на система. Виждаме също нарастващо
приемане на оптична комуникация (с потенциално по-висока честотна лента и подобрена
енергийна ефективност). Как мислите, че тези и други нововъзникващи технологични
тенденции ще повлияят на дизайна на бъдещите WSC?
6.22 [5/15/15/20/25] <6.5> Осъзнаване на възможностите на уеб услугите на Amazon: Представете си, че сте
оператор на сайт и мениджър на инфраструктура на Alexa.com топ сайт и обмислят използването
на Amazon Web Services (AWS). Какви фактори трябва да имате предвид, за да решите дали да
мигрирате към AWS, какви услуги и типове инстанции да използвате и колко разходи бихте могли
да спестите? Можете да използвате Alexa и информация за трафика на сайта (напр. Wikipedia
предоставя статистика за показване на страница), за да оцените количеството трафик, получен от
най-популярния сайт, или можете да вземете конкретни примери от мрежата, като например
следния пример от DrupalCon San Francisco 2010: http://2bits.com/sites/2bits.com/files/drupal-single-
server-2.8-million-page-views-a-day.pdf . Слайдовете описват сайт на Alexa #3400, който получава 2,8
милиона показвания на страници на ден, използвайки един сървър. Сървърът има два четириядрени
процесора Xeon 2,5 GHz с 8 GB DRAM и три 15 K RPM SAS твърди диска в конфигурация RAID1 и
струва около $400 на месец. Сайтът използва интензивно кеширане и използването на процесора
варира от 50% до 250% (приблизително 0,5 до 2,5 ядра заети). а. [5] Разглеждайки наличните
екземпляри на EC2 (http://aws.amazon.com/ec2/instance-types/ ), какви типове екземпляри
съответстват или надвишават текущата конфигурация на сървъра?
b. [15] Разглеждайки информацията за цените на EC2 (http://aws.amazon.com/ec2/pricing/ ), изберете

най-рентабилните екземпляри на EC2 (разрешени комбинации), за да хоствате сайта на AWS.
Каква е месечната цена за EC2?
° С. [15] Сега добавете разходите за IP адрес и мрежов трафик към уравнението и да предположим,
че сайтът прехвърля 100 GB/ден в Интернет. Каква е месечната цена за сайта сега?
д. [20] AWS също предлага Micro Instance безплатно за 1 година на нови клиенти и 15 GB честотна
лента всеки за трафик, влизащ и изходящ през AWS. Въз основа на вашата оценка за пиков и
среден трафик от уеб сървъра на вашия отдел, можете ли да го хоствате безплатно на AWS? д.
[25] Много по-голям сайт, Netflix.com,
също мигрира своята инфраструктура за стрийминг и кодиране към AWS. Въз основа на техните
характеристики на услугата, какви AWS услуги могат да се използват от Netflix и за какви цели?
6.23 [Дискусия/Дискусия/20/20/Дискусия] <6.4> Фигура 6.12 показва въздействието на възприеманото от

потребителите време за реакция върху приходите и мотивира необходимостта от постигане на
висока пропускателна способност при поддържане на
ниска латентност. а. [Дискусия] Вземайки уеб търсенето като пример, какви са възможните начини
за намаляване на забавянето на заявката?
b. [Дискусия] Какви статистически данни за наблюдение можете да съберете, за да разберете къде

се изразходва времето? Как планирате да приложите такъв инструмент за наблюдение? ° С.
[20] Ако приемем, че броят достъпи до диска на заявка следва нормално разпределение със средно
2 и стандартно отклонение 3, какъв вид латентност на достъпа до диска е необходима, за да се
удовлетвори SLA за латентност от 0,1 секунди за 95% от заявките ?
д. [20] Кеширането в паметта може да намали честотата на събития с дълга латентност (напр. достъп
до твърди дискове). Ако приемем, че процентът на попадение в стабилно състояние е 40%,
латентност на попадение от 0,05 сек и латентност на пропуск от 0,2 сек, кеширането помага ли
да се постигне SLA за латентност от 0,1 сек за 95% от заявките?
д. [Дискусия] Кога кешираното съдържание може да стане остаряло или дори непоследователно?
Колко често може да се случи това? Как можете да откриете и обезсилите такова съдържание?
6.24 [15/15/20] <6.4> Ефективността на типичните захранващи блокове (PSU) варира в зависимост от промяната
на натоварването; например, ефективността на PSU може да бъде около 80% при 40% натоварване
(напр. мощност 40 вата от 100-ватов PSU), 75%, когато натоварването е между 20% и 40%, и 65%,
когато натоварването е под 20 %. а. [15] Да приемем сървър
с пропорционална мощност, чиято действителна мощност е пропорционална на използването на

процесора, с крива на използване, както е показано на фигура 6.3. Каква е средната ефективност
на PSU?
b. [15] Да предположим, че сървърът използва 2N излишък за PSU (т.е. удвоява броя на PSU), за да
осигури стабилно захранване, когато едно PSU откаже. Каква е средната ефективност на PSU?
° С. [20] Доставчиците на блейд сървъри използват споделен пул от PSU не само за осигуряване на
резервиране, но и за динамично съпоставяне на броя на PSU с действителната консумация на
енергия на сървъра. Корпусът HP c7000 използва до шест PSU за общо 16 сървъра. В този
случай каква е средната ефективност на PSU за корпуса на сървъра със същата крива на
използване?
6.25 [5/Дискусия/10/15/Дискусия/Дискусия/Дискусия] <6.4> Захранването е термин, използван за обозначаване

на мощностен капацитет, който е предоставен, но не се използва в център за данни. Разгледайте
данните, представени на Фигура 6.25 [Fan, Weber и Barroso 2007] за различни групи машини. (Имайте
предвид, че това, което тази статия нарича „клъстер“, е това, което ние наричаме „масив“ в тази
глава.) a. [5] Каква е многожилната мощност на (1) нивото на стелажа, (2)
нивото на разпределителното устройство и (3) нивото на масива (клъстера)? Какви са тенденциите

при свръхзаписване на мощностен капацитет при по-големи групи машини?
b. [Дискусия] Какво мислите, че причинява разликите между захранването на различни групи

машини?
° С. [10] Помислете за колекция от машини на ниво масив, където общите машини никога не
използват повече от 72% от съвкупната мощност (това понякога се нарича също съотношение
между пиковата сума и сумата на пиковото използване) .
Използвайки модела на разходите в казуса, изчислете икономиите на разходи от сравняване
на център за данни, осигурен за пиков капацитет, и такъв, осигурен за действително използване.
1 1
0,8 0,99
0,6 0,98
F DC
FDC
0,4 0,97
0,2 Стелаж 0,96 Стелаж

PDU PDU
Клъстер Клъстер
0,95
0 0,4 0,5 0,6 0,80,7 0,9 1 0,65 0,7 0,75 0,8 0,90,85 0,95 1
Нормализирана мощност Нормализирана
(a) Пълно разпределение мощност (b) Увеличен изглед
Фигура 6.25 Кумулативна функция на разпределение (CDF) на реален център за данни.
д. [15] Да приемем, че проектантът на центъра за данни е избрал да включи допълнителни сървъри

на ниво масив, за да се възползва от блокираната мощност. Като използвате примерната
конфигурация и предположенията в част (a), изчислете колко още сървъра сега могат да бъдат
включени в компютъра с размер на склад за същото общо захранване.
д. [Дискусия] Какво е необходимо, за да работи оптимизацията на част (d) в реално внедряване?

(Съвет: Помислете какво трябва да се случи, за да ограничите мощността в редкия случай,
когато всички сървъри в масива се използват при пикова мощност.)
f. [Дискусия] Могат да се предвидят два вида политики за управление на ограниченията на мощността

[Ranganathan et al. 2006]: (1) превантивни политики, при които енергийните бюджети са
предварително определени („не приемайте, че можете да използвате повече енергия; попитайте,
преди да го направите!“) или (2) реактивни политики, при които енергийните бюджети се
ограничават в случай на енергиен бюджет нарушение („използвайте толкова енергия, колкото
е необходимо, докато не ви кажат, че не можете!“). Обсъдете компромисите между тези подходи
и кога бихте използвали всеки тип.
ж. [Дискусия] Какво се случва с общата напрегната мощност, ако системите станат по-пропорционални
на енергията (приемете работни натоварвания, подобни на тези от Фигура 6.4)?
6.26 [5/20/Дискусия] <6.4, 6.7> Раздел 6.7 обсъжда използването на източници на батерии на сървър в дизайна
на Google. Нека разгледаме последствията от този дизайн. а. [5] Да приемем, че използването на
батерия като UPS на ниво мини сървър е 99,99% ефективно и елиминира необходимостта от UPS за
цялото съоръжение, който е само 92% ефективен. Да приемем, че превключването на
подстанцията е 99,7% ефективно и че ефективността за PDU, понижаващите стъпала и други
електрически прекъсвачи е съответно 98%, 98% и 99%. Изчислете цялостните подобрения на
ефективността на енергийната инфраструктура от използването на резервна батерия за сървър.
488 Шеста глава Компютри с мащаб на склад за използване на паралелизма на ниво заявка и ниво данни
b. [20] Да приемем, че UPS е 10% от цената на ИТ оборудването. Използвайки останалите допускания от

модела на разходите в казуса, каква е точката на рентабилност за разходите за батерия (като част от
цената на единичен сървър), при която общата цена на притежание за базирано на батерии
решение е по-добро от това за UPS за цялото съоръжение?
° С. [Дискусия] Какви са другите компромиси между тези два подхода? По-специално, как мислите, че
моделът на управляемост и отказ ще се промени в тези два различни дизайна?
6.27 [5/5/Дискусия] <6.4> За това упражнение разгледайте опростено уравнение за общата оперативна мощност на
WSC, както следва: Обща оперативна мощност = (1 + множител за неефективност на охлаждане) * мощност
на ИТ оборудване. а. [5] Да приемем 8 MW център за данни при 80% потребление
на енергия, разходи за електроенергия от $0,10 на киловатчас и коефициент на неефективност на

охлаждане от 0,8. Сравнете икономиите на разходи от (1) оптимизация, която подобрява
ефективността на охлаждане с 20%, и (2) оптимизация, която подобрява енергийната ефективност
на ИТ оборудването с 20%.
b. [5] Какъв е процентът на подобрение в енергийната ефективност на ИТ оборудването, необходимо за

постигане на спестяване на разходи от 20% подобрение на ефективността на охлаждане?
° С. [Дискусия/10] Какви изводи можете да направите относно относителната важност на оптимизациите,

които се фокусират върху енергийната ефективност на сървъра и енергийната ефективност на
охлаждането?
6.28 [5/5/Дискусия] <6.4> Както беше обсъдено в тази глава, самото охлаждащо оборудване в WSC може да
консумира много енергия. Разходите за охлаждане могат да бъдат намалени чрез проактивно управление
на температурата. Разполагането на работното натоварване в зависимост от температурата е една
оптимизация, която е предложена за управление на температурата, за да се намалят разходите за
охлаждане. Идеята е да се идентифицира профилът на охлаждане на дадено помещение и да се
картографират по-горещите системи към по-хладните точки, така че на ниво WSC изискванията за
цялостно охлаждане да бъдат
намалени. а. [5] Коефициентът на ефективност (COP) на модул CRAC се определя като съотношението на
отведената топлина (Q) към необходимото количество работа (W) за отстраняване на тази топлина.
COP на CRAC модул се увеличава с температурата на въздуха, който CRAC модулът изтласква в
камерата. Ако въздухът се върне към модула CRAC при 20 градуса по Целзий и ние премахнем 10 KW
топлина с COP от 1,9, колко енергия изразходваме в модула CRAC? Ако охлаждането на същия обем
въздух, но сега връщане на 25 градуса по Целзий, отнема COP от 3,1, колко енергия изразходваме в
модула CRAC сега?
b. [5] Да приемем, че алгоритъмът за разпределение на работното натоварване е в състояние да

съпостави добре горещите работни натоварвания с хладните точки, за да позволи на устройството
за климатизация на компютърната зала (CRAC) да работи при по-висока температура, за да подобри
ефективността на охлаждане, както в упражнението по-горе. Каква е икономията на енергия между
двата случая, описани по-горе?
° С. [Дискусия] Предвид мащаба на WSC системите, управлението на мощността може да бъде сложен,
многостранен проблем. Оптимизации за подобряване на енергийната ефективност
могат да бъдат внедрени в хардуер и в софтуер, на системно ниво и на ниво клъстер за ИТ

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

системата не е енергийно пропорционална). Как тази оптимизация ще взаимодейства с
паралелен алгоритъм, който се опитва да използва различни състояния на захранване (вижте
ACPI, Разширен интерфейс за захранване за конфигурация, за някои примери)? Какви други
примери можете да измислите, когато множество оптимизации могат потенциално да са в
конфликт една с друга в WSC? Как бихте решили този проблем?
6.29 [5/10/15/20] <6.2> Енергийната пропорционалност (понякога наричана още намаляване на енергийния
мащаб) е характеристиката на системата да не консумира енергия, когато е неактивна, но по-важното
е постепенно да консумира повече енергия пропорционално на ниво на активност и свършена
работа. В това упражнение ще изследваме чувствителността на потреблението на енергия спрямо
различните модели на пропорционалност на енергията. В упражненията по-долу, освен ако не е
посочено друго, използвайте данните от Фигура 6.4 като стандартни. а. [5] Лесен начин
да се разсъждава относно пропорционалността на енергията е да се приеме линейност между

активността и потреблението на енергия. Използвайки само данните за пиковата мощност и
мощността на празен ход от Фигура 6.4 и линейна интерполация, начертайте тенденциите на
енергийна ефективност при различни дейности. (Енергийната ефективност се изразява като
производителност на ват.) Какво се случва, ако мощността на празен ход (при 0% активност) е
наполовина от приетата на фигура 6.4? Какво се случва, ако мощността на празен ход е нула?
b. [10] Начертайте тенденциите за енергийна ефективност при различни дейности, но използвайте

данните от колона 3 на Фигура 6.4 за вариация на мощността. Начертайте енергийната
ефективност, като приемете, че мощността на празен ход (само) е половината от това, което се
приема на Фигура 6.4. Сравнете тези диаграми с линейния модел в предишното упражнение.
Какви изводи можете да си направите относно последствията от фокусирането само върху
неактивната мощност?
° С. [15] Да приемем комбинацията от използване на системата в колона 7 на фигура 6.4. За простота

приемете дискретно разпределение между 1000 сървъра, със 109 сървъра при 0% използване,
80 сървъра при 10% използване и т.н. Изчислете общата производителност и общата енергия
за този микс от работно натоварване, като използвате частично предположенията ) и част (b).
д. [20] Потенциално може да се проектира система, която има сублинейна връзка между мощността и
натоварването в областта на нивата на натоварване между 0% и 50%. Това ще има крива на
енергийна ефективност, която достига връх при по-ниско използване (за сметка на по-високо
използване). Създайте нова версия на колона 3 от Фигура 6.4 , която показва такава крива на
енергийна ефективност. Да приемем комбинацията от използване на системата в колона 7 на
Фигура 6.4. За простота приемете дискретно разпределение между 1000 сървъра, със 109 сървъра
при 0% използване, 80 сървъра при 10% използване и т.н. Изчислете общата производителност
и общата енергия за тази комбинация от работни натоварвания.

Дейност (%) 0 10 20 30 40 50 60 70 80 90 100
Мощност, кутия A (W) 181 308 351 382 416 451 490 533 576 617 662
Мощност, кутия B (W) 250 275 325 340 395 405 415 425 440 445 450
Фигура 6.26 Разпределение на мощността за два сървъра.
Дейност (%) 0 10 20 30 40 50 60 70 80 90 100
№ сървъри, случай A и B 109 80 153 246 191 115 51 21 15 12 8
№ сървъри, случай C 504 6 8 11 26 57 95 123 76 40 54
Фигура 6.27 Разпределение на използването в клъстера, без и с консолидация.
6.30 [15/20/20] <6.2, 6.6> Това упражнение илюстрира взаимодействията на моделите за енергийна
пропорционалност с оптимизации като консолидация на сървъри и енергийно ефективни
сървърни проекти. Разгледайте сценариите, показани на Фигура 6.26 и
Фигура 6.27.
а. [15] Да разгледаме два сървъра с разпределението на мощността, показано на Фигура 6.26:

случай A (сървърът, разгледан на фигура 6.4) и случай B (по-малко енергийно
пропорционален, но по-енергийно ефективен сървър от случай A). Да приемем
комбинацията от използване на системата в колона 7 на Фигура 6.4. За простота приемете дискретно
разпределение между 1000 сървъра, със 109 сървъра с 0% използване, 80 сървъра с
10% използване и т.н., както е показано в ред 1 на Фигура 6.27. Приемане на вариация
на производителността въз основа на колона 2 на Фигура 6.4. Сравнете общата сума
производителност и обща енергия за този микс от натоварване за двата типа сървъри.
b. [20] Помислете за клъстер от 1000 сървъра с данни, подобни на данните, показани в

Фигура 6.4 (и обобщена в първите редове на фигури 6.26 и 6.27). Какво
са общата производителност и общата енергия за микса от работно натоварване с тях
предположения? Сега приемете, че сме успели да консолидираме натоварванията към
моделира разпределението, показано в случай C (втори ред на фигура 6.27). Какво са
общата производителност и общата енергия сега? Как се сравнява общата енергия със
система, която има линеен пропорционален на енергия модел с празен ход
мощност от нула вата и пикова мощност от 662 вата?
° С. [20] Повторете част (b), но с модела на захранване на сървър B и сравнете с

резултатите от част (а).
6.31 [10/Дискусия] <6.2, 6.4, 6.6> Тенденции в енергийната пропорционалност на системно ниво:
Помислете за следните разбивки на консумацията на енергия на сървър:
CPU, 50%; памет, 23%; дискове, 11%; работа в мрежа/друго, 16%

CPU, 33%; памет, 30%; дискове, 10%; работа в мрежа/друго, 27%
а. [10] Да приемем, че динамичният обхват на мощността е 3,0× за CPU (т.е. консумацията на

енергия на CPU в неактивен режим е една трета от консумацията му на енергия в
Ниво 1 Единичен път за разпределение на мощността и охлаждането, без 99,0%
излишни компоненти
Ниво 2 (N + 1) резервиране = два пътя за разпределение на мощността и 99,7%
охлаждането
Ниво 3 (N + 2) резервиране = три разпределителни пътя за захранване и 99,98%
охлаждане за време на работа дори по време на поддръжка
Ниво 4 Две разпределителни пътища за активна мощност и охлаждане, с 99,995%
излишни компоненти във всеки път, за да се толерира всяка повреда на

отделно оборудване, без да се влияе върху товара
Фигура 6.28 Преглед на класификациите на нивата на центъра за данни. (Адаптирано от Пит Търнър IV
et al. [2008].)
връх). Да приемем, че динамичният диапазон на системите с памет, дисковете и

мрежи/други категории по-горе са съответно 2,0×, 1,3× и 1,2×.
Какъв е общият динамичен диапазон за цялата система за двата случая?
b. [Дискусия/10] Какво можете да научите от резултатите от част (a)? Как би

постигаме по-добра енергийна пропорционалност на ниво система? (Съвет: Енергия
пропорционалността на системно ниво не може да бъде постигната само чрез оптимизации на
процесора, а вместо това изисква подобрение във всички компоненти.)
6.32 [30] <6.4> Pitt Turner IV et al. [2008] представи добър преглед на центъра за данни
класификации на нива. Класификациите на нива определят производителността на инфраструктурата на сайта. За
простота, разгледайте ключовите разлики, както е показано на Фигура 6.25 (адаптирано от

Пит Търнър IV и др. [2008]). Използвайки модела TCO в казуса, сравнете
отражение върху разходите на различните показани нива.
6.33 [Дискусия] <6.4> Въз основа на наблюденията на Фигура 6.13, какво можете да кажете
качествено относно компромисите между загуба на приходи от престой и разходи
направени за време на работа?
6.34 [15/Дискусия] <6.4> Някои скорошни проучвания са дефинирали показател, наречен TPUE,
което означава „истинска PUE“ или „обща PUE“. TPUE се определя като PUE * SPUE.
PUE, ефективността на използване на мощността, се определя в раздел 6.4 като съотношението на

общата мощност на съоръжението спрямо общата мощност на ИТ оборудването. SPUE или сървър PUE,
е нов показател, аналогичен на PUE, но вместо това се прилага към компютърно оборудване,
и се определя като съотношението на общата входна мощност на сървъра към неговата полезна мощност, където
полезната мощност се определя като мощността, консумирана от електронните компоненти

пряко участващи в изчислението: дънна платка, дискове, процесори, DRAM, I/O
карти и така нататък. С други думи, метриката SPUE улавя неефективността, свързана със захранванията,
регулаторите на напрежение и вентилаторите, разположени на сървъра.
а. [15] <6.4> Помислете за дизайн, който използва по-висока захранваща температура за

единици CRAC. Ефективността на блока CRAC е приблизително квадратична
функция на температурата и следователно този дизайн подобрява цялостното
PUE, да приемем със 7%. (Приемете базовата линия PUE от 1.7.) Въпреки това,
по-високата температура на ниво сървър задейства вградения контролер на вентилатора
работете с вентилатора на много по-високи скорости. Мощността на вентилатора е кубична функция от
скорост, а повишената скорост на вентилатора води до влошаване на SPUE. Да приемем a

модел мощност на вентилатора:
* ns * ns – 75 * * ns ns,
Мощност на вентилатора ns
= 284 * където ns е нормализираната скорост на вентилатора = скорост на
вентилатора в rpm/18 000 и базова сървърна мощност от 350 W. Изчислете SPUE, ако скоростта на вентилатора
се увеличава от (1) 10 000 rpm до 12 500 rpm и (2) 10 000 rpm до 18 000
об/мин. Сравнете PUE и TPUE и в двата случая. (За простота, игнорирайте
неефективността с доставката на енергия в модела SPUE.)
b. [Дискусия] Част (a) илюстрира, че докато PUE е отлична метрика за улавяне на режийните разходи
на съоръжението, тя не улавя неефективността в рамките
самото ИТ оборудване. Можете ли да идентифицирате друг дизайн, където е TPUE
потенциално по-ниска от PUE? (Съвет: Вижте упражнение 6.26.)
6.35 [Дискусия/30/Дискусия] <6.2> Два наскоро пуснати бенчмарка осигуряват

добра отправна точка за отчитане на енергийната ефективност в сървърите –
SPECpower_ssj2008 бенчмарк (достъпен на http://www.spec.org/power_
ssj2008/) и метриката JouleSort (достъпна на http://sortbenchmark.org/).
а. [Дискусия] <6.2> Потърсете описанията на двата бенчмарка. Как са

приличат ли си? С какво се различават? Какво бихте направили, за да ги подобрите
показатели за по-добро постигане на целта за подобряване на енергийната ефективност на WSC?
b. [30] <6.2> JouleSort измерва общата системна енергия за извършване на извънядрено сортиране и
се опитва да извлече показател, който позволява сравнението на системите
вариращи от вградени устройства до суперкомпютри. Вижте описанието на
метриката JouleSort на http://sortbenchmark.org. Изтеглете публично достъпна версия на
алгоритъма за сортиране и я стартирайте на различни класове машини –
лаптоп, компютър, мобилен телефон и др.—или с различни конфигурации. Какво може
учите ли се от оценките на JouleSort за различни настройки?
° С. [Дискусия] <6.2> Помислете за системата с най-добър рейтинг JouleSort от

вашите експерименти по-горе. Как бихте подобрили енергийната ефективност? За
например, опитайте да пренапишете кода за сортиране, за да подобрите рейтинга на JouleSort.
6.36 [10/10/15] <6.1, 6.2> Фигура 6.1 е списък на прекъсванията в масив от сървъри.
Когато се работи с големия мащаб на WSC, е важно да се балансира клъстерът
дизайн и софтуерни архитектури за постигане на необходимия ъптайм без значителни разходи. Този
въпрос изследва последиците от постигането на наличност само чрез хардуер.
а. [10] <6.1, 6.2> Ако приемем, че оператор желае да постигне 95% наличност
само чрез подобрения на сървърния хардуер, колко събития от всеки тип
трябва ли да се намали? Засега приемете, че отделните сривове на сървъра са
напълно обработен чрез излишни машини.
b. [10] <6.1, 6.2> Как се променя отговорът на част (a), ако индивидът
сривовете на сървъра се обработват чрез резервиране в 50% от времето? 20% от времето?
Нито един път?
° С. [15] <6.1, 6.2> Обсъдете важността на софтуерното резервиране за постигане на

високо ниво на достъпност. Ако оператор на WSC обмисли закупуването на машини,
които са по-евтини, но с 10% по-малко надеждни, какви последици ще има това
върху софтуерната архитектура? Какви са предизвикателствата, свързани със
софтуерното резервиране?
6.37 [15] <6.1, 6.8> Потърсете текущите цени на стандартната DDR3 DRAM спрямо DDR3 DRAM,
която има код за коригиране на грешки (ECC). Какво е увеличението на цената на бит за
постигане на по-висока надеждност, която предоставя ECC? Използвайки само цените на
DRAM и данните, предоставени в раздел 6.8, какво е времето за работа на долар на WSC
с не-ECC спрямо ECC DRAM?
6.38 [5/Дискусия] <6.1> Проблеми относно надеждността и управляемостта на WSC:
а. [5] Помислете за клъстер от сървъри, струващ $2000 всеки. Ако приемем годишен
процент на повреда от 5%, средно един час време за обслужване на ремонт и
резервни части, изискващи 10% от системните разходи за повреда, какви са
годишните разходи за поддръжка на сървър? Да приемем почасова ставка от $100
на час за сервизен техник.
b. [Дискусия] Коментирайте разликите между този модел на управляемост спрямо този

в традиционен корпоративен център за данни с голям брой малки или средни по
размер приложения, всяко от които работи на собствена специална хардуерна
инфраструктура.
А.1 Въведение А-2
А.2 Класифициране на архитектурите на набори от инструкции А-3
А.3 Адресиране на паметта А-7
А.4 Тип и размер на операндите А-13
А.5 Операции в набора от инструкции А-14
А.6 Инструкции за контролен поток А-16
A.7 Кодиране на набор от инструкции А-21
А.8 Междусекторни въпроси: Ролята на компилаторите А-24
А.9 Обединяване на всичко: Архитектурата MIPS А-32
А.10 Заблуди и клопки А-39
А.11 Заключителни бележки А-45
А.12 Историческа перспектива и препратки А-47
Упражнения от Грегъри Д. Питърсън А-47

А
Принципи на набора от инструкции 1
An Добавете числото в място за съхранение n в акумулатора.
En Ако числото в акумулатора е по-голямо или равно на нула, изпълнете
следващата поръчка, която стои в място за съхранение n;
в противен случай продължете последователно.
З Спрете машината и позвънете предупредителния звънец.
Уилкс и Ренуик
Избор от списъка с 18 машини
Инструкции за EDSAC (1949)
A-2 Приложение A Принципи на набора от инструкции
А.1 Въведение
В това приложение се концентрираме върху архитектурата на набора от инструкции – частта от

компютър, видим за програмиста или автора на компилатора. Повечето от този материал
трябва да бъде рецензия за читателите на тази книга; включваме го тук за фон. Това
Приложението представя голямото разнообразие от алтернативи за дизайн, достъпни за архитекта на
набора от инструкции. По-специално се фокусираме върху четири теми. Първо, представяме таксономия
на алтернативите на набора от инструкции и даваме някаква качествена оценка на
предимства и недостатъци на различните подходи. Второ, представяме и анализираме някои
измервания на набор от инструкции, които до голяма степен са независими от конкретен
набор от инструкции. Трето, разглеждаме въпроса за езиците и компилаторите и техните
като се има предвид архитектурата на набора от инструкции. И накрая, разделът „Сглобяване на всичко“.
показва как тези идеи са отразени в набора от инструкции на MIPS, който е типичен за
RISC архитектури. Завършваме с грешките и клопките на набора от инструкции
дизайн.
За по-нататъшно илюстриране на принципите, Приложение К също дава четири примера за
RISC архитектури с общо предназначение (MIPS, PowerPC, Precision Architecture,
SPARC), четири вградени RISC процесора (ARM, Hitachi SH, MIPS 16, Thumb),
и три по-стари архитектури (80x86, IBM 360/370 и VAX). Преди да обсъдим
как да класифицираме архитектурите, трябва да кажем нещо за измерването на набора от инструкции.
В това приложение разглеждаме голямо разнообразие от архитектурни измервания. Ясно е, че

тези измервания зависят от измерваните програми и
върху компилаторите, използвани при извършване на измерванията. Резултатите не трябва да бъдат
интерпретиран като абсолютен и може да видите различни данни, ако сте направили измерването с
различен компилатор или различен набор от програми. Вярваме, че
измерванията в това приложение са разумно показателни за типичен клас
приложения. Много от измерванията са представени с помощта на малък набор от показатели, така че
данните да могат да бъдат разумно показани и разликите между
могат да се видят програми. Архитект за нов компютър би искал да анализира a
много по-голяма колекция от програми, преди да вземете архитектурни решения. The
показаните измервания обикновено са динамични – т.е. честотата на измерената
събитие се претегля според броя пъти, в които това събитие се случва по време на изпълнение на
измерената програма.
Преди да започнем с общите принципи, нека прегледаме трите приложения
области от Глава 1. Настолните компютри наблягат на производителността на програми с цели числа и
типове данни с плаваща запетая, като малко се обръща внимание на програмата
размер. Например размерът на кода никога не е бил докладван през петте поколения на
SPEC бенчмаркове. Сървърите днес се използват предимно за база данни, файлов сървър и
Уеб приложения плюс някои приложения за споделяне на време за много потребители. следователно
производителността с плаваща запетая е много по-малко важна за производителността от целите числа
и символни низове, но почти всеки сървърен процесор все още включва инструкции с плаваща запетая.
Личните мобилни устройства и вградените приложения оценяват цената
и енергия, така че размерът на кода е важен, защото по-малкото памет е едновременно по-евтино и
по-ниска енергия и някои класове инструкции (като плаваща запетая) могат да бъдат
по избор за намаляване на разходите за чипове.
A.2 Класифициране на архитектурите на набори от инструкции A-3
По този начин наборите от инструкции и за трите приложения са много сходни. Всъщност, на
Архитектурата MIPS, която управлява това приложение, се използва успешно в настолни компютри, сървъри
и вградени приложения.
Една успешна архитектура, много различна от RISC, е 80x86 (вижте
Приложение К). Изненадващо, неговият успех не опровергава непременно предимствата
на набор от RISC инструкции. Търговското значение на двоичната съвместимост
с компютърен софтуер, комбиниран с изобилието от транзистори, предоставени от
Законът на Мур накара Intel да използва набор от RISC инструкции вътрешно, като същевременно поддържа
Външен набор от инструкции 80x86. Последните 80x86 микропроцесори, като Pen-tium 4, използват хардуер
за превод от 80x86 инструкции към RISC-подобни инструкции и след това изпълняват преведените операции
вътре в чипа. Те поддържат
илюзията за 80x86 архитектура за програмиста, като същевременно позволява на компютъра
дизайнер за внедряване на процесор в стил RISC за производителност.
След като фонът е зададен, започваме с изследване на начина, по който се задават инструкциите
архитектурите могат да бъдат класифицирани.
А.2 Класифициране на архитектурите на набори от инструкции
Типът вътрешна памет в процесора е най-основната диференциация, така че в
този раздел ще се съсредоточим върху алтернативите за тази част от архитектурата.
Основните възможности за избор са стек, акумулатор или набор от регистри. Операнди
могат да бъдат наименувани изрично или имплицитно: Операндите в стековата архитектура са
имплицитно в горната част на стека, а в акумулаторна архитектура един операнд
имплицитно е акумулаторът. Архитектурите на регистър с общо предназначение имат
само изрични операнди - или регистри, или места в паметта. Фигура A.1 показва a
блокова диаграма на такива архитектури, а фигура A.2 показва как кодът
последователност C = A + B обикновено се появява в тези три класа инструкции
комплекти. Явните операнди могат да бъдат достъпни директно от паметта или може да са необходими
първо да се зареди във временно хранилище, в зависимост от класа на архитектурата
и избор на конкретна инструкция.
Както показват цифрите, наистина има два класа регистрационни компютри. един
класът може да има достъп до паметта като част от всяка инструкция, наречена архитектура регистър-
памет , а другият има достъп до паметта само с инструкции за зареждане и съхраняване,
наречена load-store архитектура. Трета класа, която не се намира в доставката на компютри
днес съхранява всички операнди в паметта и се нарича архитектура памет-памет . Някои архитектури на
набори от инструкции имат повече регистри от единичен акумулатор, но поставят ограничения върху
използването на тези специални регистри. Такава архитектура

понякога се нарича разширен акумулатор или регистърен компютър със специално предназначение .
Въпреки че повечето ранни компютри са използвали архитектури в стил стек или акумулатор,
на практика всяка нова архитектура, проектирана след 1980 г., използва регистър за зареждане
архитектура. Основните причини за появата на регистър с общо предназначение
(GPR) компютрите са двойни. Първо, регистрите - подобно на други форми на вътрешно съхранение на
процесора - са по-бързи от паметта. Второ, регистрите са по-ефективни

... ...
Процесор
TOS
... ...
...
ALU ALU ALU ALU
... ... ... ...

памет
... ... ... ...
(а) Купчина (б) Акумулатор (c) Регистър-памет (г) регистър-регистър/

склад за зареждане
Фигура A.1 Разположения на операнд за четири архитектурни класа на набор от инструкции. Стрелките показват дали oper-and е вход или резултат
от операцията на аритметично-логическата единица (ALU), или едновременно вход и резултат. По-светли нюанси
обозначават входове, а тъмният нюанс показва резултата. В (a) регистър Top Of Stack (TOS) сочи към горния вход
операнд, който се комбинира с операнда по-долу. Първият операнд се премахва от стека, резултатът се взема
мястото на втория операнд и TOS се актуализира, за да сочи към резултата. Всички операнди са имплицитни. В (b) акумулаторът е едновременно
косвен входен операнд и резултат. В (c) един входен операнд е регистър, един е в паметта и
резултатът отива в регистър. Всички операнди са регистри в (d) и, подобно на стековата архитектура, могат да бъдат прехвърлени към
памет само чрез отделни инструкции: натиснете или изскочете за (a) и заредете или съхранете за (d).
Регистър
Стек Акумулатор (регистър-памет) Регистриране (зареждане-съхранение)
Натиснете A Заредете А Натоварване R1,A Натоварване R1,A
Натиснете B Добавете Б Добавете R3, R1, B Заредете R2,B
Добавете Магазин C Магазин R3,C Добавете R3, R1, R2
Поп С Магазин R3,C
Фигура A.2 Кодовата последователност за C = A + B за четири класа набори от инструкции. Забележка

че инструкцията Add има имплицитни операнди за стекова и акумулаторна архитектури
и изрични операнди за регистрови архитектури. Приема се, че всички A, B и C принадлежат
в паметта и че стойностите на A и B не могат да бъдат унищожени. Фигура A.1 показва
Добавете операция за всеки клас архитектура.
A.2 Класифициране на архитектурите на набори от инструкции A-5
за използване от компилатор в сравнение с други форми на вътрешна памет. Например, на

регистрационен компютър изразът (A * B) – (B * C) – (A * D) може да бъде оценен
като правите умноженията в произволен ред, което може да е по-ефективно, защото
на местоположението на операндите или поради проблеми с конвейерната обработка (вижте Глава 3).
Независимо от това, на стеков компютър хардуерът трябва да оцени израза в
само една поръчка, тъй като операндите са скрити в стека и може да се наложи да зареди an
операнд многократно.
По-важното е, че регистрите могат да се използват за съхранение на променливи. Когато променливите са
разпределени към регистрите, трафикът на паметта намалява, програмата се ускорява (тъй като
регистрите са по-бързи от паметта) и плътността на кода се подобрява (тъй като регистър
може да се наименува с по-малко битове, отколкото място в паметта).
Както е обяснено в Раздел A.8, авторите на компилатори биха предпочели всички регистри
да бъде еквивалентен и безрезервен. По-старите компютри компрометират това желание, като отделят
регистрите за специални цели, като ефективно намаляват броя на регистрите с общо предназначение.
Ако броят на наистина регистрите с общо предназначение е твърде малък,
опитите за разпределяне на променливи към регистрите няма да бъдат печеливши. Вместо това,
компилаторът ще запази всички некоммитирани регистри за използване при оценка на израз.
Колко регистъра са достатъчни? Отговорът, разбира се, зависи от
ефективност на компилатора. Повечето компилатори запазват някои регистри за оценка на израза,
използват някои за предаване на параметри и позволяват на останалите да бъдат
разпределени за задържане на променливи. Съвременната технология на компилатор и нейната
способност да използва ефективно по-голям брой регистри доведе до увеличаване на броя на регистрите в
по-нови архитектури.
Две основни характеристики на набора от инструкции разделят GPR архитектурите. И двете

характеристики се отнасят до природата на операндите за типична аритметика или логика
инструкция (ALU инструкция). Първият се отнася дали ALU инструкция има
два или три операнда. Във формат с три операнда инструкцията съдържа един
операнд резултат и два операнда източник. Във формат с два операнда, един от
операндите е едновременно източник и резултат за операцията. Второто разграничение
сред GPR архитектурите се отнася колко от операндите могат да бъдат памет
адреси в инструкциите на ALU. Броят операнди на паметта, поддържани от a
типичната ALU инструкция може да варира от нито една до три. Фигура A.3 показва комбинации от
тези два атрибута с примери за компютри. Въпреки че има
седем възможни комбинации, три служат за класифициране на почти всички съществуващи компютри.
Както споменахме по-рано, тези три са load-store (наричани още register-register),
регистър-памет и памет-памет.
Фигура A.4 показва предимствата и недостатъците на всяка от тези алтернативи. Разбира се, тези
предимства и недостатъци не са абсолютни: те са
качествени и действителното им въздействие зависи от компилатора и изпълнението
стратегия. Георадарен компютър с операции памет-памет може лесно да бъде
игнориран от компилатора и използван като компютър за зареждане. Едно от най-разпространените
архитектурни въздействия е върху кодирането на инструкциите и броя на инструкциите, необходими
за изпълнение на задача. Виждаме въздействието на тези архитектурни
алтернативи на подходите за изпълнение в Приложение В и Глава 3.
A-6 Приложение А Принципи на набора от инструкции
Брой Максимален разрешен

адреси на брой операнди
паметта Примери за тип архитектура
0 3 Товарен склад Alpha, ARM, MIPS, PowerPC, SPARC, SuperH,

TM32
1 2 Регистър-памет IBM 360/370, Intel 80x86, Motorola 68000,

TI TMS320C54x
2 2 Памет-памет VAX (също има формати с три операнда)

3 3 Памет-памет VAX (също има формати с два операнда)
Фигура A.3 Типични комбинации от операнди на паметта и общи операнди за типична ALU инструкция с
примери за компютри. Компютрите без препратка към памет за ALU инструкция се наричат компютри за зареждане или регистър-
регистр. Инструкциите с множество операнди на паметта за типична ALU инструкция се наричат регистър-памет или памет-памет,
според това дали имат един или повече от един операнд на паметта.
Тип Предимства Недостатъци
Регистрирайте се-регистрирайте се Просто кодиране на инструкции с фиксирана дължина. По-голям брой инструкции в сравнение с архитектурите с
(0, 3) Прост модел за генериране на код. Инструкциите препратки към паметта в инструкциите. Повече инструкции и
изискват подобен брой часовници за изпълнение по-ниската плътност на инструкциите водят до по-
(вижте Приложение C). големи програми.
Регистър-памет Данните могат да бъдат достъпни без първо отделна Операндите не са еквивалентни, тъй като операнд
(12) инструкция за зареждане. Форматът на инструкциите източник в двоична операция се унищожава.
обикновено е лесен за кодиране и дава добра плътност. Кодирането на номер на регистър и адрес на паметта
във всяка инструкция може да ограничи броя на регистрите.
Тактовете на инструкция варират според местоположението на операнда.
Памет-памет Най-компактен. Не губи регистри за временни Голяма вариация в размера на инструкцията, особено за
(2, 2) или (3, 3) лица. инструкции с три операнда. В допълнение, голяма
вариация в работата по инструкция. Достъпите до паметта
създават тесни места в паметта. (Не се използва днес.)
Фигура A.4 Предимства и недостатъци на трите най-разпространени типа регистриращи компютри с общо предназначение. Нотацията
(m, n) означава m операнда от паметта и n общо операнда. Като цяло компютрите с по-малко алтернативи опростяват задачата на
компилатора, тъй като има по-малко решения, които компилаторът трябва да вземе (вижте раздел A.8).
Компютрите с голямо разнообразие от гъвкави формати на инструкции намаляват броя на битовете, необходими за кодиране на
програмата. Броят на регистрите също влияе върху размера на инструкцията, тъй като имате нужда от log2 (брой регистри) за всеки
спецификатор на регистър в инструкция. По този начин удвояването на броя на регистрите отнема 3 допълнителни бита за регистър-регистър
архитектура, или около 10% от 32-битова инструкция.
Резюме: Класифициране на архитектурите на набори от инструкции
Тук и в края на раздели A.3 до A.8 ние обобщаваме тези характеристики, които бихме
очаквали да открием в нова архитектура на набор от инструкции, изграждайки
основа за MIPS архитектурата, въведена в раздел A.9. От този раздел трябва ясно да очакваме
използването на регистри с общо предназначение. Фигура A.4,

A.3 Адресиране на паметта A-7
комбиниран с Приложение C относно конвейерната обработка, води до очакване за версия за съхранение

на зареждане на регистърна архитектура с общо предназначение.
С обхванатия клас архитектура следващата тема е адресирането на операндите.
A.3 Адресиране на паметта
Независимо от това дали архитектурата е със зареждане или позволява всеки операнд да
бъде препратка към паметта, тя трябва да дефинира как се интерпретират адресите на
паметта и как се специфицират. Представените тук измервания са до голяма степен, но не
напълно, независими от компютъра. В някои случаи измерванията са значително
повлияни от технологията на компилатора. Тези измервания са направени с помощта на
оптимизиращ компилатор, тъй като технологията на компилатора играе критична роля.
Интерпретиране на адреси на паметта
Как се интерпретира адресът на паметта? Тоест кой обект е достъпен като функция на
адреса и дължината? Всички набори от инструкции, обсъдени в тази книга, са байтово
адресирани и осигуряват достъп до байтове (8 бита), половин думи (16 бита) и думи (32
бита). Повечето от компютрите предоставят достъп и за двойни думи (64 бита).
Има две различни конвенции за подреждане на байтовете в рамките на по-голям

обект. Little Endian ред на байтовете поставя байта, чийто адрес е “x. . . x000” на най-малко
значимата позиция в двойната дума (малкия край). Байтовете са номерирани:
76543210
Редът на байтовете Big Endian поставя байта, чийто адрес е „x“. . . x000” в най-значимата
позиция в двойната дума (големият край). Байтовете са номерирани:
01234567
Когато работите в рамките на един компютър, редът на байтовете често е незабележим

- само програми, които имат достъп до едни и същи местоположения като, да речем, думи
и байтове, могат да забележат разликата. Редът на байтовете обаче е проблем при обмен
на данни между компютри с различен ред. Little Endian подреждането също не отговаря
на нормалното подреждане на думите, когато низовете се сравняват. Низовете се появяват
“SDRAWKCAB” (назад) в регистрите.
Втори проблем с паметта е, че в много компютри достъпът до обекти, по-големи от
байт, трябва да бъде подравнен. Достъпът до обект с размер s байта на байт адрес A е
подравнен, ако A mod s = 0. Фигура A.5 показва адресите, на които достъпът е подравнен
или неправилно подравнен.
Защо някой би проектирал компютър с ограничения за подравняване? Неправилното
подравняване причинява хардуерни усложнения, тъй като паметта обикновено е
подравнена по границата на кратно на дума или на двойна дума. Неправилен достъп до паметта
Стойност на 3 бита от нисък ред на байтов адрес
Ширина на обекта 0 1 2 3 4 5 6 7
1 байт (байт) 2 Подравнени Подравнени Подравнени Подравнено Подравнено Подравнени Подравнено Подравнено
байта (половин дума) 2 Подравнени Подравнени Подравнени Подравнени
байта (половин дума) 4 Неправилно подравнен Неправилно подравнен Неправилно подравнен Неправилно подравнен
байта (дума) 4 байта Подравнени Подравнени
(дума) 4 байта (дума) Неправилно подравнен Неправилно подравнен
4 байта (дума) 8 байта Неправилно подравнен Неправилно подравнен
(двойна дума) 8 байта Неправилно подравнен Неправилно подравнен
(двойна дума) 8 байта (двойна Подравнени
дума) 8 байта (двойна дума) 8 Неправилно подравнен
байта (двойна дума) 8 байта Неправилно подравнен
(двойна дума) 8 байта (двойна Неправилно подравнен
дума) 8 байта (двойна дума) Неправилно подравнен
Неправилно подравнен
Фигура A.5 Подравнени и неподравнени адреси на обекти от байтове, половин дума, дума и двойна дума за компютри с байт адрес. За всеки неправилно подравнен пример някои
обекти изискват два достъпа до паметта, за да завършат. Всеки
подравненият обект винаги може да завърши с един достъп до паметта, стига паметта да е толкова широка, колкото и обектът. Фигурата
показва паметта, организирана като широка 8 байта. Отместванията в байтовете, които обозначават колоните, указват 3-те бита от нисък ред на
адресът.
следователно може да приема множество подравнени препратки към паметта. По този начин, дори в
компютри, които позволяват неправилно подравнен достъп, програмите с подравнен достъп работят по-бързо.
Дори ако данните са подравнени, поддържа се достъп до байтове, половин думи и думи
изисква мрежа за подравняване за подравняване на байтове, половин думи и думи в 64-битов
регистри. Например, на фигура A.5 да предположим, че четем байт от адрес
с неговите 3 бита от нисък ред със стойност 4. Ще трябва да преместим надясно 3 байта към
подравнете байта на правилното място в 64-битов регистър. В зависимост от инструкцията може да
се наложи компютърът да подпише и удължи количеството. Магазините са лесни:
Могат да се променят само адресираните байтове в паметта. На някои компютри байт,
половин дума и операцията с дума не засяга горната част на регистъра.
Въпреки че всички компютри, обсъдени в тази книга, позволяват байт, половин дума и
word достъп до паметта, само IBM 360/370, Intel 80x86 и поддръжка на VAX
ALU операции върху регистърни операнди, по-тесни от пълната ширина.
След като обсъдихме алтернативни интерпретации на адресите на паметта,
можем да обсъдим начините, по които адресите се определят чрез инструкции, наречени режими
на адресиране.
Режими на адресиране
При даден адрес вече знаем до кои байтове да имаме достъп в паметта. В този подраздел ще
разгледаме режимите на адресиране – как архитектурите определят адреса
на обект, до който ще имат достъп. Режимите на адресиране определят константи и регистри в
допълнение към местоположения в паметта. Когато се използва място в паметта, действителното
адресът на паметта, определен от режима на адресиране, се нарича ефективен адрес.
Фигура A.6 показва всички режими на адресиране на данни, използвани напоследък
компютри. Непосредствените или литералите обикновено се считат за адресиране на паметта
Режим на адресиране Примерна инструкция Значение Когато се използва
Регистрирам Добавете R4, R3 Правила[R4] Правила[R4] Когато дадена стойност е в регистър.

+ Regs [R3]
Незабавно Добавете R4, #3 Regs[R4] Regs[R4] + 3 За константи.
Изместване Добавете R4100 (R1) Правила[R4] Правила[R4] Достъп до локални променливи

+ Mem[100 + Regs[R1]] (+ симулира индиректни, директни
режими на адресиране).
Регистрирайте индиректно Добавете R4, (R1) Правила[R4] Правила[R4] Достъп с помощта на указател или
+ Mem[Regs[R1]] изчислен адрес.
Индексиран Добавете R3, (R1 + R2) Правила[R3] Правила[R3] Понякога е полезно при
+ Mem[Regs[R1] + Regs[R2]] адресиране на масив: R1 = основа на
масива; R2 = сума на индекса.
Директно или Добавете R1, (1001) Правила[R1] Правила[R1] Понякога е полезно за достъп до
абсолютен + Mem [1001] статични данни; може да се наложи
адресната константа да е голяма.
Индиректна памет Добавете R1,@(R3) Правила[R1] Правила[R1] Ако R3 е адресът на указател p, тогава
+ Mem[Mem[Regs[R3]]] mode дава *p.
Автоматично увеличаване Добавете R1,(R2)+ Правила[R1] Правила[R1] Полезно за преминаване през масиви в
+ Mem[Regs[R2]] рамките на цикъл. R2 сочи към началото
Regs[R2] Regs[R2] + d на масива; всяка препратка увеличава R2
с размер на елемент, d.
Автодекремент Добавете R1, –(R2) Regs[R2] Regs[R2] – d Същата употреба като автоинкремент.
Правила[R1] Правила[R1] Autodecrement/-increment може също
+ Mem[Regs[R2]] да действа като push/pop за внедряване на

стек.
Мащабирано Добавете R1100(R2)[R3] Правила[R1] Правила[R1] Използва се за индексиране на масиви.

+ Mem[100 + Regs[R2] Може да се приложи към всеки режим на
+ Regs[R3] d] *
индексирано адресиране в някои компютри.
Фигура A.6 Избор на режими на адресиране с примери, значение и използване. В автоинкремент/-декремент

и режими на мащабирано адресиране, променливата d обозначава размера на елемента от данни, до който се осъществява достъп (т.е. дали
инструкция има достъп до 1, 2, 4 или 8 байта). Тези режими на адресиране са полезни само когато елементите са
достъпните са съседни в паметта. RISC компютрите използват адресиране с изместване, за да симулират индиректен регистър с 0
за адреса и за симулиране на директно адресиране с помощта на 0 в основния регистър. В нашите измервания използваме първото
име, показано за всеки режим. Разширенията на C, използвани като описания на хардуера, са дефинирани на страница A-36.
режими (въпреки че стойността, до която имат достъп, е в потока от инструкции), въпреки че

регистрите често са разделени, тъй като обикновено нямат адреси на паметта.
Запазихме отделни режимите на адресиране, които зависят от програмния брояч, наречени
адресиране, свързано с PC . PC-относителното адресиране се използва основно за определяне
на кодови адреси в инструкции за прехвърляне на управление, обсъдени в раздел A.6.
Фигура A.6 показва най-често срещаните имена за режимите на адресиране, въпреки че
имената се различават в различните архитектури. На тази фигура и в цялата книга ще използваме
разширение на езика за програмиране C като нотация за описание на хардуера. На тази фигура
се използва само една функция, различна от C: стрелката наляво ( ) се използва за присвояване.
Ние също така използваме масива Mem като име за основна памет и масива Regs за регистри.
Така Mem[Regs[R1]] се отнася до съдържанието на местоположението на паметта, чийто адрес е
даден от съдържанието на регистър 1 (R1). По-късно ще въведем разширения за достъп и
прехвърляне на данни, по-малки от дума.
Режимите на адресиране имат способността значително да намалят броя на инструкциите;
те също така добавят към сложността на изграждането на компютър и могат да увеличат средните
тактови цикли на инструкция (CPI) на компютри, които прилагат тези режими. По този начин
използването на различни режими на адресиране е много важно за подпомагане на архитекта
да избере какво да включи.
Фигура A.7 показва резултатите от измерването на моделите на използване на режима на

адресиране в три програми на VAX архитектурата. Ние използваме старата VAX архитектура за
няколко измервания в това приложение, тъй като тя има най-богатия набор от режими на
адресиране и най-малко ограничения върху адресирането на паметта. Например Фигура A.6 на
страница A-9 показва всички режими, поддържани от VAX. Повечето измервания в това
приложение обаче ще използват по-новите архитектури регистър-регистър, за да покажат как
програмите използват набори от инструкции на текущи компютри.
Както показва фигура A.7 , изместването и незабавното адресиране доминират при
използването на режим на адресиране. Нека да разгледаме някои свойства на тези два силно
използвани режима.
Режим на адресиране на изместване
Основният въпрос, който възниква при режим на адресиране в стил на изместване, е този за
обхвата на използваните измествания. Въз основа на използването на различни размери на
изместване може да се вземе решение какви размери да се поддържат. Изборът на размерите
на полето за изместване е важен, защото те пряко влияят върху дължината на инструкцията.
Фигура A.8 показва измерванията, направени при достъпа до данни в архитектура за зареждане,
използвайки нашите програми за сравнение. Разглеждаме отместванията на разклоненията в

Раздел A.6 – моделите за достъп до данни и разклоненията са различни; малко се печели от
комбинирането им, въпреки че на практика непосредствените размери са еднакви за простота.
Режим на незабавно или буквално адресиране
Незабавните могат да се използват в аритметични операции, в сравнения (предимно за

разклонения) и в ходове, където се иска константа в регистър. Последният случай се среща за
константи, записани в кода - които обикновено са малки - и за
TeX 1%
Памет индиректна подправка 6%
1%
gcc
TeX 0%
Мащабена
подправка
16%
6%
gcc
TeX 24%
Регистрирайте индиректна 3%
подправка
11%
gcc
TeX 43%
Незабавна 17%
подправка
39%
gcc
TeX 32%
Изместване 55%
подправка
40%
gcc
0% 10% 20% 30% 40% 50% 60%
Честота на режима на адресиране
Фигура A.7 Обобщение на използването на режимите на адресиране на паметта (включително незабавни).

Тези основни режими на адресиране представляват всички, освен няколко процента (0% до 3%) от
достъпите до паметта. Режимите на регистриране, които не се броят, представляват половината от
референциите на операндите, докато режимите на адресиране на паметта (включително незабавното)
представляват другата половина. Разбира се, компилаторът засяга какви режими на адресиране се
използват; виж раздел A.8. Индиректният режим на паметта на VAX може да използва изместване,
автоинкремент или автодекремент за формиране на първоначалния адрес на паметта; в тези програми
почти всички индиректни препратки към паметта използват режима на изместване като основа. Режимът
на изместване включва всички дължини на изместване (8, 16 и 32 бита). Режимите на адресиране,
свързани с PC, използвани почти изключително за клонове, не са включени. Показани са само режимите
на адресиране със средна честота над 1%.
адресни константи, които обикновено са големи. За използването на незабавни операции е важно

да знаете дали те трябва да се поддържат за всички операции или само за подмножество. Фигура
A.9 показва честотата на непосредствените операции за общите класове операции с цели числа и
операции с плаваща запетая в набор от инструкции.
Друго важно измерване на набора от инструкции е диапазонът от стойности за незабавни.
Подобно на стойностите на изместване, размерът на непосредствените стойности влияе върху
дължината на инструкцията. Както показва Фигура A.10 , малките непосредствени стойности се
използват най-често. Понякога обаче се използват големи непосредствени стойности, най-вероятно
при изчисления за адресиране.
Резюме: Адресиране на паметта
Първо, поради тяхната популярност бихме очаквали нова архитектура да поддържа поне следните
режими на адресиране: изместване, незабавно и индиректно регистриране. Фигура A.7 показва, че
те представляват 75% до 99% от режимите на адресиране, използвани в нашите измервания. Второ,
бихме очаквали размерът на адреса за режим на изместване да бъде поне 12 до 16 бита, тъй като
надписът на Фигура A.8 предполага, че тези размери ще уловят 75% до 99% от изместванията.
40%
35%
Средно цяло число
30%
25%
20%
мразП
енатвнтесцео и
н
Средна стойност с плаваща запетая

15%
10%
5%
0%
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Брой битове на изместване
Фигура A.8 Стойностите на преместването са широко разпространени. Има както голям брой малки стойности, така и справедлив
брой големи стойности. Широкото разпределение на стойностите на изместване се дължи на множество области за съхранение на
променливи и различни измествания за достъп до тях (вижте раздел A.8), както и на цялостната схема за адресиране, използвана от
компилатора. Оста x е log2 на изместването, тоест размерът на полето, необходим за представяне на величината на изместването.
Нулата на оста x показва процента на измествания със стойност 0. Графиката не включва знаковия бит, който е силно повлиян от
оформлението на паметта. Повечето измествания са положителни, но повечето от най-големите измествания (14+ бита) са
отрицателни. Тъй като тези данни са събрани на компютър с 16-битови измествания, те не могат да ни кажат за по-големи
измествания. Тези данни бяха взети на архитектура Alpha с пълна оптимизация (вижте раздел A.8) за SPEC CPU2000, показвайки
средната стойност на целочислените програми (CINT2000) и средната стойност на програмите с плаваща запетая (CFP2000).
22%
Натоварвания
23%
19%
ALU операции 25%
16%
Всички инструкции
21%
0% 5% 10% 15% 20% 25% 30%
Фигура A.9 Около една четвърт от трансферите на данни и ALU операциите имат непосредствен
операнд. Долните ленти показват, че целочислените програми използват непосредствени в около
една пета от инструкциите, докато програмите с плаваща запетая използват непосредствени в
около една шеста от инструкциите. За зареждания инструкцията за незабавно зареждане зарежда
16 бита във всяка половина на 32-битов регистър. Незабавното зареждане не е зареждане в тесен
смисъл, защото няма достъп до паметта. Понякога се използва двойка незабавни зареждания за
зареждане на 32-битова константа, но това е рядко. (За ALU операции, премествания с постоянна
стойност са включени като операции с непосредствени операнди.) Програмите и компютърът,
използвани за събиране на тези статистически данни, са същите като на фигура A.8.
A.4 Тип и размер на операндите A-13
45%
40%
35%
30%
25%
интвнаебцаозреП
н
20%
15%
10%
5%
0%
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Брой битове, необходими за незабавно
Фигура A.10 Разпределението на непосредствените стойности. Оста x показва броя на битовете, необходими за представяне
на величината на непосредствена стойност - 0 означава, че непосредствената стойност на полето е била 0. Повечето от
непосредствените стойности са положителни. Около 20% са отрицателни за CINT2000 и около 30% са отрицателни за
CFP2000. Тези измервания са направени на Alpha, където максимумът непосредствено е 16 бита, за същите програми като
на Фигура A.8. Подобно измерване на VAX, който поддържа 32-битови незабавни съобщения, показа, че около 20% до 25%
от незабавните данни са по-дълги от 16 бита. Така 16 бита биха уловили около 80%, а 8 бита около 50%.
Трето, бихме очаквали размерът на непосредственото поле да бъде поне 8 до 16 бита.

Това твърдение не е подкрепено от надписа на фигурата, за който се отнася.
След като обхванахме класовете от набори от инструкции и взехме решение за архитектурите
регистър-регистър, плюс предишните препоръки относно режимите на адресиране на данни, сега ще
разгледаме размерите и значенията на данните.
A.4 Тип и размер на операндите

Как се определя типът на операнд? Обикновено кодирането в кода на операцията
обозначава типа на операнд - това е най-често използваният метод. Като алтернатива,
данните могат да бъдат анотирани с тагове, които се интерпретират от хардуера.
Тези етикети указват типа на операнда и операцията се избира съответно. Компютрите
с маркирани данни обаче могат да бъдат намерени само в компютър
музеи.
Нека започнем с архитектурите на работния плот и сървъра. Обикновено типът на

операнд – цяло число, плаваща запетая с единична точност, символ и т.н. – ефективно
дава размера му. Често срещаните типове операнди включват знак (8 бита), половин
дума (16 бита), дума (32 бита), плаваща запетая с единична точност (също 1 дума) и двойна точност
плаваща запетая (2 думи). Целите числа са почти универсално представени като две
допълващи двоични числа. Символите обикновено са в ASCII, но 16-битов
Unicode (използван в Java) набира популярност с интернационализацията на
компютри. До началото на 80-те години повечето производители на компютри избираха своите
представяне с плаваща запетая. Почти всички компютри оттогава следват същото
стандарт за плаваща запетая, IEEE стандарт 754. IEEE стандарт за плаваща запетая
се обсъжда подробно в Приложение J.
Някои архитектури предоставят операции върху символни низове, въпреки че такива
операциите обикновено са доста ограничени и третират всеки байт в низа като единичен
характер. Типични операции, поддържани върху символни низове, са сравненията
и се движи.
За бизнес приложения някои архитектури поддържат десетичен формат,

обикновено се нарича пакетиран десетичен или двоично кодиран десетичен - 4 бита се използват за
кодират стойностите от 0 до 9 и 2 десетични цифри се пакетират във всеки байт.
Цифровите символни низове понякога се наричат неопаковани десетични, а операциите, наречени
опаковане и разопаковане, обикновено се предоставят за преобразуване
напред и назад между тях.
Една от причините да използвате десетични операнди е да получите резултати, които точно

съвпадат с десетични числа, тъй като някои десетични дроби нямат точно представяне в
двоичен. Например 0,1010 е проста дроб в десетична система, но в двоична система
изисква безкраен набор от повтарящи се цифри: 0,0001100110011. . . 2. По този начин
изчисленията, които са точни в десетична система, могат да бъдат близки, но неточни в двоична система, което може да бъде
проблем с финансовите транзакции. (Вижте Приложение J, за да научите повече за precise

аритметика.)
Нашите SPEC бенчмаркове използват байт или знак, половин дума (кратко цяло число), дума
(цяло число), двойна дума (дълго цяло число) и типове данни с плаваща запетая. Фигура A.11
показва динамичното разпределение на размерите на обектите, посочени от паметта
за тези програми. Честотата на достъп до различни типове данни помага при
решаване кои типове са най-важни за ефективна поддръжка. Трябва ли компютърът да има 64-битов
път за достъп или ще са необходими два цикъла за достъп до двоен
думата да е задоволителна? Както видяхме по-рано, достъпът до байтове изисква мрежа за
подравняване: Колко важно е да се поддържат байтове като примитиви? Фигура A.11 използва
препратки към паметта за изследване на типовете данни, до които се осъществява достъп.
В някои архитектури обектите в регистрите могат да бъдат достъпни като байтове или половини
думи. Такъв достъп обаче е много рядък - на VAX той не представлява никакъв
повече от 12% от препратките към регистъра или приблизително 6% от всички достъпи на операнди в
тези програми.
A.5 Операции в набора от инструкции
Операторите, поддържани от повечето архитектури на набори от инструкции, могат да бъдат категоризирани
както е на фигура A.12. Едно основно правило във всички архитектури е, че най-много
широко изпълняваните инструкции са простите операции на набор от инструкции. За
Например, Фигура A.13 показва 10 прости инструкции, които представляват 96% от
A.5 Операции в набора с инструкции A-15
Двойна дума 70%

(64 бита) 59%
Слово 29%
(32 бита) 26%
Половин дума 0%
(16 бита) 5%
Байт 1% Средно цяло число
(8 бита) 10%
0% 20% 40% 60% 80%
Фигура A.11 Разпределение на достъпите до данни по размер за програмите за сравнение. The

типът данни с двойна дума се използва за плаваща запетая с двойна точност в програми с плаваща запетая и за
адреси, тъй като компютърът използва 64-битови адреси. На 32-битов адрес
компютър 64-битовите адреси ще бъдат заменени с 32-битови адреси и така почти всички
достъпът с двойна дума в целочислени програми ще стане достъп с една дума.
Тип оператор Примери
Аритметични и логически Аритметични и логически операции с цели числа: събиране, изваждане и, или,
умножавам, разделям
Трансфер на данни Зарежда-съхранява (инструкции за преместване на компютри с адресиране

на паметта)
контрол Разклоняване, скок, извикване на процедура и връщане, капани
Система Обаждане на операционната система, инструкции за управление на виртуалната памет
Плаваща запетая Операции с плаваща запетая: събиране, умножение, деление, сравнение
десетична Десетично събиране, десетично умножение, преобразувания от десетичен в знак
низ Преместване на низове, сравнение на низове, търсене на низове
Графика Операции с пиксели и върхове, операции за компресия/декомпресия
Фигура A.12 Категории оператори с инструкции и примери за всеки. Всички компютри обикновено предоставят
пълен набор от операции за първите три категории. Подкрепата
за системните функции в набора от инструкции варира значително в различните архитектури, но всички
компютрите трябва да имат някаква поддръжка на инструкции за основни системни функции. Сумата
на поддръжка в набора от инструкции за последните четири категории може да варира от нито една до an
обширен набор от специални инструкции. Инструкции с плаваща запетая ще бъдат предоставени във всеки
компютър, който е предназначен за използване в приложение, което използва много плаващ
точка. Тези инструкции понякога са част от незадължителен набор от инструкции. Десетичен и
инструкциите за низове понякога са примитивни, както във VAX или IBM 360, или могат да бъдат
синтезирани от компилатора от по-прости инструкции. Типични графични инструкции
работят с много по-малки елементи от данни паралелно - например извършване на осем 8-битови
допълнения към два 64-битови операнда.

Ранг Инструкция 80х86 (% общо изпълнени)
1 натоварване 22%
2 условен клон 20%
3 сравнявам 16%
4 магазин 12%
5 добавете 8%
6 и 6%
7 суб 5%
8 преместване регистър-регистър 4%
9 обадете се 1%
10 връщане 1%
Обща сума 96%
Фигура A.13 Първите 10 инструкции за 80x86. Простите инструкции доминират в това

списък и са отговорни за 96% от изпълнените инструкции. Тези проценти са
средно от петте SPECint92 програми.
инструкции, изпълнени за колекция от цели програми, работещи на популярния

Intel 80x86. Следователно, изпълнителят на тези инструкции трябва да е сигурен, че е направил
тези бързи, тъй като са често срещан случай.
Както бе споменато по-горе, инструкциите на фигура A.13 се намират във всеки компютър
за всяко приложение – настолен компютър, сървър, вградено – с вариациите на
операциите на фигура A.12 до голяма степен зависят от това кои типове данни включва
наборът от инструкции.
А.6 Инструкции за контролен поток
Тъй като измерванията на поведението при разклоняване и скок са доста независими от

други измервания и приложения, сега разглеждаме използването на контролния поток
инструкции, които имат малко общо с операциите от предишния
секции.
Няма последователна терминология за инструкции, които променят потока на

контрол. През 50-те години те обикновено се наричаха трансфери. В началото на 1960 г
име клон започва да се използва. По-късно компютрите въвеждат допълнителни имена.
В цялата тази книга ще използваме скок , когато промяната в контрола е безусловна, и
разклоняване , когато промяната е условна.
Можем да различим четири различни типа промяна на контролния поток:
Условни разклонения
Скокове
A.6 Инструкции за контролния поток A-17

8%
Обаждане/връщане Средно цяло число
19%
10%
скочи
6%
82%
Условен клон
75%
0% 25% 50% 75% 100%
Честота на инструкциите за клонове
Фигура A.14 Разбивка на инструкциите на контролния поток в три класа: извиквания или връщания,
прескачане и условни разклонения. Ясно доминират условните разклонения.
Всеки тип се брои в една от трите ленти. Програмите и компютърът, използвани за събиране на
тези статистически данни, са същите като тези на фигура A.8.
Извиквания на процедури
Процедура за връщане
Искаме да знаем относителната честота на тези събития, тъй като всяко събитие е различно, може да
използва различни инструкции и може да има различно поведение. Фигура A.14 показва честотите на тези
инструкции за контролен поток за компютър със зареждане, изпълняващ нашите бенчмаркове.
Режими на адресиране за инструкции за контролен поток
Адресът на местоназначение на инструкция за контролен поток трябва винаги да бъде посочен.
Тази дестинация е посочена изрично в инструкцията в по-голямата част от случаите - връщането на процедура
е основното изключение, тъй като за връщане целта не е известна по време на компилиране. Най-често
срещаният начин за определяне на местоназначението е да се предостави изместване, което се добавя към
програмния брояч (PC). Инструкциите за контролен поток от този вид се наричат PC-относителни. Свързаните
с PC разклонения или скокове са изгодни, тъй като целта често е близо до текущата инструкция и уточняването
на позицията спрямо текущия PC изисква по-малко битове. Използването на PC-относително адресиране
също позволява на кода да работи независимо от това къде е зареден. Това свойство, наречено независимост
на позицията, може да елиминира част от работата, когато програмата е свързана и също е полезно в
програми, свързани динамично по време на изпълнение.
За да се реализират връщания и индиректни скокове, когато целта не е известна по време на
компилиране, е необходим метод, различен от PC-относителното адресиране. Тук трябва да има начин да се
посочи динамично целта, така че да може да се променя по време на изпълнение.
Този динамичен адрес може да бъде толкова прост, колкото именуване на регистър, който съдържа адреса
за получаване на цел; алтернативно, прескачането може да позволи всеки режим на адресиране да се
използва за предоставяне на целевия адрес.

Тези индиректни скокове в регистъра също са полезни за четири други важни функции:
Операции за случай или превключване , намиращи се в повечето езици за програмиране (които

изберете между една от няколко алтернативи)
Виртуални функции или методи в обектно-ориентирани езици като C++ или Java (които позволяват
извикване на различни процедури в зависимост от типа на аргумента)
Функции от висок ред или функционални указатели в езици като C или C++ (които позволяват
функциите да бъдат предавани като аргументи, давайки част от вкуса на обектно-ориентираното
програмиране)
Динамично споделени библиотеки (които позволяват на библиотеката да бъде заредена и свързана

по време на изпълнение само когато е действително извикана от програмата, вместо да се
зарежда и свързва статично преди стартирането на програмата)
И в четирите случая целевият адрес не е известен по време на компилиране и следователно

обикновено се зарежда от паметта в регистър преди непрякото прескачане на регистъра.
Тъй като клоновете обикновено използват PC-относително адресиране, за да уточнят своите
цели, важен въпрос е колко далеч са целите на клоновете от клоновете. Познаването на
разпределението на тези измествания ще помогне при избора на какви отмествания на разклоненията
да се поддържат и по този начин ще повлияе на дължината на инструкцията и кодирането. Фигура
A.15 показва разпределението на изместванията за PC-относителни клонове в инструкциите.
Около 75% от клоните са в посока напред.
30%
25%
20%
Средно
цяло число
15%
но
еинтя етцсозраП
н
р
10%
5%
0%
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15, 16, 17, 18, 19, 20
Части от изместване на клона
Фигура A.15 Разстояния на разклоняване по отношение на броя на инструкциите между целта и инструкцията за разклоняване.
Най-честите разклонения в целочислените програми са към цели, които могат да бъдат кодирани в 4 до 8 бита. Този резултат ни казва,
че късите полета за изместване често са достатъчни за разклонения и че дизайнерът може да получи известна плътност на кодиране,
като има по-кратка инструкция с по-малко изместване на разклоненията. Тези измервания бяха направени на компютър за зареждане
(Alpha архитектура) с всички инструкции, подравнени по границите на думите. Архитектура, която изисква по-малко инструкции за
една и съща програма, като например VAX, ще има по-къси разклонения. Въпреки това, броят на битовете, необходими за
изместването, може да се увеличи, ако компютърът има инструкции с променлива дължина, които да бъдат подравнени на която и да
е граница на байт. Програмите и компютърът, използвани за събиране на тези статистически данни, са същите като тези на фигура A.8.
A.6 Инструкции за контролния поток A-19
Опции за условно разклоняване
Тъй като повечето промени в контролния поток са разклонения, решаването как да се уточни
състоянието на клона е важно. Фигура A.16 показва трите основни техники в
употреба днес и техните предимства и недостатъци.
Едно от най-забележимите свойства на клоните е, че голям брой
сравненията са прости тестове и голям брой са сравнения с нула.
По този начин някои архитектури избират да третират тези сравнения като специални случаи,
особено ако се използва инструкция за сравнение и разклоняване . Фигура A.17 показва
честотата на различни сравнения, използвани за условно разклоняване.
Опции за извикване на процедура
Извикванията и връщанията на процедури включват прехвърляне на контрол и евентуално запазване на
състояние; като минимум обратният адрес трябва да бъде записан някъде, понякога в a
специален регистър на връзките или просто GPR. Някои по-стари архитектури предоставят механизъм за
запазване на много регистри, докато по-новите архитектури изискват компилаторът да
генерирайте магазини и товари за всеки запазен и възстановен регистър.
Има две основни конвенции, които се използват за запазване на регистрите: или на сайта за повикване
или вътре в процедурата, която се извиква. Запазването на повикващия означава, че процедурата за
повикване трябва да запише регистрите, които иска да бъдат запазени за достъп след повикването, и
по този начин извиканата процедура не трябва да се тревожи за регистрите. Спестяването на Callee е
обратното: извиканата процедура трябва да запише регистрите, които иска да използва, оставяйки
обаждащият се необуздан. Има моменти, когато запазването на обаждащия се трябва да се използва поради
модели за достъп до глобално видими променливи в две различни процедури. За
Име Примери Как се тества състоянието Предимства Недостатъци
Код на 80x86, ARM, Тества специални битове, Понякога условието е CC е допълнително състояние.
условието (CC) PowerPC, зададени от ALU операции, безплатно. Кодовете на условия ограничават
SPARC, SuperH вероятно под контрол на програмата. подреждането на инструкциите,
тъй като те предават информация от една
инструкция към разклонение.
Регистър на Алфа, MIPS Тества произволен просто. Използва регистър.

състоянието регистър с резултат
от сравнение.
Сравнете PA-RISC, VAX Compare е част от клона. Често Една инструкция вместо Може да е твърде много работа за
и разклонете сравнението е ограничено две за клон. една инструкция за конвейерно
до подмножество. изпълнение.
Фигура A.16 Основните методи за оценка на условията в бранша, техните предимства и недостатъци.
Въпреки че кодовете на условия могат да бъдат зададени от ALU операции, които са необходими за други цели, измерванията на
програмите показват, че това се случва рядко. Основните проблеми с внедряването на кодовете на условия възникват, когато кодът на
условието е зададен от голямо или произволно избрано подмножество от инструкции, вместо да се контролира от бит в
инструкцията. Компютрите със сравняване и разклоняване често ограничават набора от сравнения и използват регистър на условия за
по-сложни сравнения. Често се използват различни техники за разклонения, базирани на сравнение с плаваща запетая спрямо тези,
базирани на сравнение на цели числа. Тази дихотомия е разумна, тъй като броят на клоновете зависи от
сравненията с плаваща запетая е много по-малък от числото, зависещо от целочислените сравнения.

5%
Не е равно Средно цяло число
2%
16%
Равен
18%
0%
По-голямо или равно 11%
0%
По-велик от
0%
44%
По-малко или равно
33%
34%
По-малко от
35%
0% 10% 20% 30% 40% 50%

Честота на видовете сравнение в клонове
Фигура A.17 Честота на различни видове сравнения в условни разклонения. По-малко от (или
равни) разклонения доминират тази комбинация от компилатор и архитектура.
Тези измервания включват както цяло число, така и сравнение с плаваща запетая в клонове.
Програмите и компютърът, използвани за събиране на тези статистически данни, са същите
като тези на фигура A.8.
Например, да предположим, че имаме процедура P1, която извиква процедура P2 и двете

процедури манипулират глобалната променлива x. Ако P1 е разпределил x към регистър, той
трябва да е сигурен, че записва x на място, известно от P2, преди повикването към P2.
Способността на компилатора да открие кога извикана процедура може да има достъп до
разпределени от регистъра количества се усложнява от възможността за отделна компилация.
Да предположим, че P2 може да не докосва x , но може да извика друга процедура, P3, която
може да има достъп до x, но P2 и P3 се компилират отделно. Поради тези усложнения повечето
компилатори консервативно ще запазят всяка променлива, която може да бъде достъпна по време на повикване.
В случаите, когато може да се използва някоя от конвенциите, някои програми ще бъдат по-
оптимални със запазване на извиквания, а други ще бъдат по-оптимални със запазване на
повикващ. В резултат на това повечето реални системи днес използват комбинация от двата
механизма. Тази конвенция е специфицирана в двоичен интерфейс на приложение (ABI), който
определя основните правила за това кои регистри трябва да бъдат записани на повикващия и
кои трябва да бъдат запазени на извиквания. По-късно в това приложение ще разгледаме
несъответствието между сложни инструкции за автоматично запазване на регистри и нуждите на компилатора.
Резюме: Инструкции за контролен поток
Инструкциите за контролен поток са едни от най-често изпълняваните инструкции.

Въпреки че има много опции за условни разклонения, бихме очаквали адресирането на
разклонения в нова архитектура да може да премине към стотици инструкции
A.7 Кодиране на набор от инструкции A-21
над или под клона. Това изискване предполага изместване на клона спрямо PC от поне 8 бита.
Също така бихме очаквали да видим непряко адресиране на регистъра и свързано с PC
адресиране за инструкции за прескачане, за да поддържаме връщания, както и много други
функции на настоящите системи.
Вече завършихме нашата обиколка на архитектурата на инструкциите на нивото, виждано
от програмист на асемблер или автор на компилатор. Склоняме се към архитектура за
съхранение на зареждане с режими на изместване, незабавно и индиректно адресиране при
регистриране. Тези данни са 8-, 16-, 32- и 64-битови цели числа и 32- и 64-битови данни с
плаваща запетая. Инструкциите включват прости операции, условни разклонения, свързани с
PC, инструкции за прескачане и свързване за извикване на процедура и регистриране на
косвени скокове за връщане на процедура (плюс няколко други приложения).
Сега трябва да изберем как да представим тази архитектура във форма, която прави
лесно за изпълнение от хардуера.
A.7 Кодиране на набор от инструкции
Ясно е, че изборите, споменати по-горе, ще повлияят на начина, по който инструкциите се

кодират в двоично представяне за изпълнение от процесора. Това представяне влияе не само
върху размера на компилираната програма, но и върху изпълнението на процесора, който
трябва да декодира това представяне, за да намери бързо операцията и нейните операнди.
Операцията обикновено се определя в едно поле, наречено код на операцията. Както ще видим,
важното решение е как да кодираме режимите на адресиране с операциите.
Това решение зависи от обхвата на режимите на адресиране и степента на независимост

между кодовете за операции и режимите. Някои по-стари компютри имат от един до пет
операнда с 10 режима на адресиране за всеки операнд (вижте Фигура A.6). За такъв голям брой
комбинации обикновено е необходим отделен спецификатор на адрес за всеки операнд:
Спецификаторът на адреса казва какъв режим на адресиране се използва за достъп до операнда.
На другия полюс са компютрите за съхранение на натоварване само с един операнд на паметта
и само един или два режима на адресиране; очевидно в този случай режимът на адресиране
може да бъде кодиран като част от операционния код.
Когато кодирате инструкциите, броят на регистрите и броят на режимите на адресиране
оказват значително влияние върху размера на инструкциите, тъй като полето за регистър и
полето за режим на адресиране може да се появяват много пъти в една инструкция. Всъщност
за повечето инструкции се изразходват много повече битове в режимите на адресиране на
кодиране и регистрационните полета, отколкото при определянето на кода на операцията.
Архитектът трябва да балансира няколко конкуриращи се сили, когато кодира набора от инструкции:
1. Желанието да има възможно най-много регистри и режими на адресиране.
2. Влиянието на размера на регистъра и полетата за режим на адресиране върху средния

размер на инструкциите и оттам върху средния размер на програмата.
3. Желание да има инструкции, кодирани в дължини, които ще бъдат лесни за обработка в

конвейерна реализация. (Стойността на лесно декодираните инструкции се обсъжда в
Приложение C и Глава 3.) Като минимум архитектът иска
инструкциите да бъдат в кратни байтове, а не в произволна битова дължина.
Много архитекти на настолни компютри и сървъри са избрали да използват инструкции с фиксирана
дължина, за да получат предимства при внедряването, като същевременно жертват средния размер на кода.
Фигура A.18 показва три популярни варианта за кодиране на набора от инструкции. Първият наричаме
променлив, тъй като позволява почти всички режими на адресиране да бъдат с всички операции. Този стил е най-
добър, когато има много режими и операции на адресиране. Вторият избор наричаме фиксиран, тъй като той
комбинира операцията и режима на адресиране в кода на операцията. Често фиксираното кодиране ще има само
един размер за всички инструкции; работи най-добре, когато има малко режими и операции на адресиране.
Компромисът между променливо кодиране и фиксирано кодиране е размерът на програмите спрямо лекотата на
декодиране в процесора. Променливата се опитва да използва възможно най-малко битове, за да представи
програмата, но индивидуалните инструкции могат да варират значително както по размер, така и по обем на
работата, която трябва да бъде извършена.
Нека да разгледаме инструкция 80x86, за да видим пример за кодиране на променливата:
добавете EAX,1000(EBX)
Операция и адрес № на Адресно Адрес Адресно

спецификатор на операнди 1 (a) поле 1 спецификатор n поле n
Променлива (напр. Intel 80x86, VAX)
Операция Адресно Адресно Адресно

поле 1 поле 2 поле 3
(b) Фиксирани (напр. Alpha, ARM, MIPS, PowerPC, SPARC, SuperH)
Операция Адресно
поле
Спецификатор на адрес
Операция Адресно
Спецификатор
Спецификатор на адрес 1 поле
на адрес 2
Операция Адресно Адресно

поле 1 поле 2
Спецификатор на адрес (c) Хибриден (напр. IBM 360/370, MIPS16, Thumb, TI TMS320C54x)
Фигура A.18 Три основни вариации в кодирането на инструкции: променлива дължина, фиксирана
дължина и хибрид. Променливият формат може да поддържа произволен брой операнди, като всеки
спецификатор на адрес определя режима на адресиране и дължината на спецификатора за този
операнд. Обикновено позволява най-малкото представяне на код, тъй като не е необходимо да се
включват неизползвани полета. Фиксираният формат винаги има един и същ брой операнди, като
режимите на адресиране (ако съществуват опции) са посочени като част от кода на операцията.
Обикновено това води до най-големия размер на кода. Въпреки че полетата обикновено не се различават
по местоположението си, те ще бъдат използвани за различни цели чрез различни инструкции.
Хибридният подход има множество формати, определени от кода на операцията, добавяйки едно или
две полета за указване на режима на адресиране и едно или две полета за указване на адреса на операнда.
A.7 Кодиране на набор от инструкции A-23
Името add означава 32-битова инструкция за добавяне на цяло число с два операнда и този код
на операцията отнема 1 байт. Спецификаторът на адрес 80x86 е 1 или 2 байта, определящ
регистъра източник/дестинация (EAX) и режима на адресиране (изместване в този случай) и
основния регистър (EBX) за втория операнд. Тази комбинация отнема 1 байт за указване на
операндите. Когато сте в 32-битов режим (вижте Приложение K), размерът на адресното поле е
1 байт или 4 байта. Тъй като 1000 е по-голямо от 28 , дължината на инструкцията е , общото
1 + 1 + 4 = 6 байта
Дължината на инструкциите 80x86 варира между 1 и 17 байта. Програмите 80x86 обикновено

са по-малки от RISC архитектурите, които използват фиксирани формати (вижте Приложение K).
Предвид тези два полюса на дизайна на набора от инструкции на променлива и фиксирана,

третата алтернатива веднага изниква на ум: Намалете променливостта в размера и работата
на променливата архитектура, но осигурете множество дължини на инструкции, за да намалите
размера на кода. Този хибриден подход е третата алтернатива на кодиране и скоро ще видим
примери.
Намален размер на кода в RISC
Тъй като RISC компютрите започнаха да се използват във вградени приложения, 32-битовият
фиксиран формат се превърна в пасив, тъй като разходите и следователно по-малкият код са
важни. В отговор няколко производители предложиха нова хибридна версия на своите набори
от RISC инструкции, както с 16-битови, така и с 32-битови инструкции. Тесните инструкции
поддържат по-малко операции, по-малък адрес и непосредствени полета, по-малко регистри и
двуадресния формат вместо класическия триадресен формат на RISC компютрите. Приложение
K дава два примера, ARM Thumb и MIPS MIPS16, които и двата претендират за намаляване на
размера на кода до 40%.
За разлика от тези разширения на набора от инструкции, IBM просто компресира своя
стандартен набор от инструкции и след това добавя хардуер за декомпресиране на инструкции,
тъй като те се извличат от паметта при пропуснат кеш на инструкции. По този начин кешът на
инструкциите съдържа пълни 32-битови инструкции, но компресираният код се съхранява в
основната памет, ROM и диска. Предимството на MIPS16 и Thumb е, че кешовете на инструкции
действат така, сякаш са с около 25% по-големи, докато CodePack на IBM означава, че
компилаторите не трябва да се променят, за да обработват различни набори инструкции и
декодирането на инструкции може да остане просто.
CodePack започва с компресия на кодиране по дължина на изпълнение на всяка PowerPC
програма и след това зарежда получените таблици за компресиране в 2 KB таблица на чип.
Следователно всяка програма има свое собствено уникално кодиране. За да обработва
разклонения, които вече не са към подравнена граница на думата, PowerPC създава хеш
таблица в паметта, която картографира компресирани и некомпресирани адреси. Подобно на
TLB (вижте глава 2), той кешира най-скоро използваните адресни карти, за да намали броя на
достъпите до паметта. IBM твърди, че общата цена на производителността е 10%, което води
до намаляване на размера на кода от 35% до 40%.
Hitachi просто изобрети набор от RISC инструкции с фиксиран 16-битов формат, наречен
SuperH, за вградени приложения (вижте Приложение K). Има 16, а не
32 регистъра, за да пасне на по-тесния формат и по-малко инструкции, но иначе изглежда като класическа
RISC архитектура.
Резюме: Кодиране на набор от инструкции
Решенията, взети в компонентите на дизайна на набора от инструкции, разгледани в предишния

секциите определят дали архитектът има избор между променливи и фиксирани
кодиране на инструкции. Предвид избора, архитектът се интересува повече от размера на кода
от производителността ще избере променливо кодиране, а този, който се интересува повече от
производителността, отколкото от размера на кода, ще избере фиксирано кодиране. Приложение E дава 13 примера
от резултатите от избора на архитектите. В Приложение В и Глава 3 въздействието на
Променливостта на производителността на процесора ще бъде обсъдена допълнително.
Почти завършихме полагането на основите за набора от инструкции за MIPS

архитектура, която ще бъде въведена в раздел A.9. Преди да направим това обаче, то
ще бъде полезно да разгледаме накратко технологията на компилатора и нейния ефект върху свойствата на
програмата.
А.8 Междусекторни въпроси: Ролята на компилаторите
Днес почти цялото програмиране се извършва на езици от високо ниво за десктоп и
сървърни приложения. Това развитие означава, че тъй като повечето изпълнени инструкции са резултат от
компилатор, архитектурата на набора от инструкции е по същество
цел на компилатора. В по-ранни времена за тези приложения, архитектурни решения
често се правят за улесняване на програмирането на асемблер или за конкретно ядро. Тъй като компилаторът
ще повлияе значително на производителността на компютъра,
разбирането на технологията на компилатора днес е от решаващо значение за проектирането и ефикасността
внедряване на набор от инструкции.
Някога беше популярно да се опитваме да изолираме технологията на компилатора и нейния ефект върху
производителността на хардуера от архитектурата и нейната производителност, точно както беше
популярен опит за отделяне на архитектурата от нейната реализация. Тази раздяла е
по същество невъзможно с днешните настолни компилатори и компютри. Архитектурният избор влияе върху
качеството на кода, който може да бъде генериран за компютър
и сложността на изграждането на добър компилатор за него, за добро или за лошо.
В този раздел обсъждаме основно критичните цели в набора от инструкции
от гледна точка на компилатора. Започва с преглед на анатомията на тока
компилатори. След това обсъждаме как технологията на компилатора влияе върху решенията на
архитект и как архитектът може да затрудни или улесни компилатора да създаде добър код. Завършваме с
преглед на компилаторите и мултимедийните операции, което за съжаление е лош пример за сътрудничество
между компилаторите
писатели и архитекти.
Структурата на последните компилатори
Като начало, нека да разгледаме какви са оптимизиращите компилатори днес. Фигура A.19
показва структурата на последните компилатори.

A.8 Междусекторни въпроси: Ролята на съставителите A-25
Зависимости функция
Зависи от езика; независима Преобразувайте езика в обща

Преден край на
от машината междинна форма
език
Междинно
представителство
Донякъде зависим от Например

Оптимизации трансформации на цикъл
езика; до голяма степен независими
на високо ниво
от машината и вграждане на
процедури
(наричано още интегриране на процедури)
Малки езикови зависимости; машинни Включително глобални и локални

зависимости леки (напр. брой/типове Глобален оптимизации + разпределение
регистри) на регистър
оптимизатор
Силно зависим от машината; Подробен избор на инструкции и

Генератор на кодове
езиково независим машинно-зависими оптимизации;
може да включва или да бъде
последван от асемблер
Фигура A.19 Компилаторите обикновено се състоят от две до четири преминавания, като по-
високо оптимизиращите компилатори имат повече преминавания. Тази структура максимизира
вероятността програма, компилирана на различни нива на оптимизация, да произведе един и
същ изход, когато се даде същия вход. Оптимизиращите пропуски са предназначени да бъдат
незадължителни и могат да бъдат пропуснати, когато целта е по-бърза компилация и кодът с по-
ниско качество е приемлив. Преминаването е просто една фаза, в която компилаторът чете и
трансформира цялата програма. (Терминът фаза често се използва взаимозаменяемо с пропуск.)
Тъй като проходите за оптимизиране са разделени, множество езици могат да използват едни и
същи проходи за оптимизиране и генериране на код. За нов език е необходим само нов преден край.
Първата цел на автора на компилатор е коректността - всички валидни програми трябва да

бъдат компилирани правилно. Втората цел обикновено е скоростта на компилирания код.
Обикновено цял набор от други цели следва тези две, включително бърза компилация, поддръжка
за отстраняване на грешки и оперативна съвместимост между езиците. Обикновено пропуските в
компилатора трансформират по-високо ниво, по-абстрактни представяния в прогресивно
представяния на по-ниско ниво. В крайна сметка достига набора от инструкции.
Тази структура помага да се управлява сложността на трансформациите и улеснява писането на
компилатор без грешки.
Сложността на писането на правилен компилатор е основно ограничение за количеството
оптимизация, което може да се направи. Въпреки че многопроходната структура помага за
намаляване на сложността на компилатора, това също означава, че компилаторът трябва да
нареди и извърши някои трансформации преди други. В диаграмата на оптимизиращия компилатор
на фигура A.19 можем да видим, че някои оптимизации на високо ниво се извършват много преди
да е известно как ще изглежда полученият код. След като бъде направена такава трансформация,
компилаторът не може да си позволи да се върне назад и да преразгледа всички стъпки, евентуално
да отмени трансформациите. Такава итерация би била непосилна, както по отношение на времето
за компилиране, така и по отношение на сложността. По този начин компилаторите правят
предположения за способността на по-късните стъпки да се справят с определени проблеми.
Например, компилаторите обикновено трябва да изберат кои извиквания на процедурите да разширят вграде
знаете точния размер на извикваната процедура. Авторите на компилаторите наричат това
проблем с проблема с подреждането на фазите.
Как това подреждане на трансформации взаимодейства с набора от инструкции
архитектура? Добър пример е с оптимизацията, наречена елиминиране на глобален общ подизраз. Тази
оптимизация намира два екземпляра на an
израз, който изчислява същата стойност и записва стойността от първото изчисление във временен. След това
използва временната стойност, елиминирайки второто изчисление на общия израз.
За да бъде тази оптимизация значителна, временното трябва да бъде разпределено на a
регистрирам. В противен случай разходите за съхраняване на временното в паметта и по-късното му
презареждане може да отменят спестяванията, постигнати от неизчисляването на израза отново. Там
всъщност са случаи, в които тази оптимизация всъщност забавя кода, когато
временно не е разпределен регистър. Подреждането на фазите усложнява този проблем
тъй като разпределението на регистъра обикновено се извършва близо до края на преминаването за глобална
оптимизация, точно преди генерирането на код. По този начин, оптимизаторът, който извършва тази
оптимизация, трябва да приеме , че разпределителят на регистър ще разпредели временното на
регистрирам.
Оптимизациите, извършвани от съвременните компилатори, могат да бъдат класифицирани по стил

на трансформацията, както следва:
Оптимизации на високо ниво често се правят на източника, като изходът се предава по-късно
пропуски за оптимизация.
Локалните оптимизации оптимизират кода само в рамките на кодов фрагмент с права линия
(наречен основен блок от компилаторите).
Глобалните оптимизации разширяват локалните оптимизации в клонове и
въведе набор от трансформации, насочени към оптимизиране на цикли.
Регистри за разпределение асоциират регистри с операнди.
Зависещите от процесора оптимизации се опитват да се възползват от специфични
архитектурни познания.
Регистрирайте Разпределение
Поради централната роля, която играе разпределението на регистъра, както за ускоряване на
код и за правенето на други оптимизации полезни, това е едно от най-важните — if
не най-важното-от оптимизациите. Регистрирайте алгоритми за разпределение
днес се основават на техника, наречена оцветяване на графики. Основната идея зад
оцветяването на графиката е да се конструира графика, представяща възможните кандидати за
разпределение към регистър и след това да използвате графиката за разпределяне на регистри. Приблизително
казано, проблемът е как да се използва ограничен набор от цветове, така че да няма два съседни
възлите в графика на зависимост имат един и същ цвят. Акцентът в подхода
е да се постигне 100% разпределение на регистъра на активните променливи. Проблемът с оцветяването на
графика като цяло може да отнеме експоненциално време като функция на размера на
графика (NP-пълна). Има обаче евристични алгоритми, които работят добре
практика, давайки близки разпределения, които се изпълняват в почти линейно време.

Оцветяването на графиките работи най-добре, когато има поне 16 (и за предпочитане повече)

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

зависещи от процесора оптимизации - от трансформации, направени в генератора на код. Примери за
типични оптимизации са дадени на фигура A.20. Последната колона на фигура A.20 показва честотата, с
която изброеното оптимизиране
трансформациите са приложени към изходната програма.
Фигура A.21 показва ефекта от различни оптимизации върху инструкциите, изпълнени за две
програми. В този случай оптимизираните програми са изпълнили приблизително 25%
до 90% по-малко инструкции от неоптимизираните програми. Фигурата илюстрира
важността на прегледа на оптимизирания код, преди да предложите нов набор от инструкции
функции, тъй като компилаторът може напълно да премахне инструкциите на архитекта
се опитваше да се подобри.
Влиянието на технологията на компилатора върху архитекта

Решения
Взаимодействието на компилатори и езици от високо ниво значително влияе върху това как
програмите използват архитектура на набор от инструкции. Има два важни въпроса:
Как се разпределят и адресират променливите? Колко регистъра са необходими за
разпределете променливите по подходящ начин? За да отговорим на тези въпроси, трябва да разгледаме
три отделни области, в които текущите езици на високо ниво разпределят своите данни:
Стекът се използва за разпределяне на локални променливи . Стекът се увеличава или намалява

съответно извикване или връщане на процедурата. Обектите в стека се адресират по отношение
на указателя на стека и са предимно скалари (единични променливи), а не
масиви. Стекът се използва за записи за активиране, а не като стек за оценка
изрази. Следователно стойностите почти никога не се избутват или изскачат в стека.
Зоната за глобални данни се използва за разпределяне на статично декларирани обекти, като напр
глобални променливи и константи. Голям процент от тези обекти са масиви
или други структури от обобщени данни.
Купчината се използва за разпределяне на динамични обекти, които не се придържат към стекова

дисциплина. Обектите в купчината са достъпни с указатели и обикновено не са
скалари.
Разпределението на регистър е много по-ефективно за обекти, разпределени в стека, отколкото за

глобални променливи и разпределянето на регистрите е по същество невъзможно за обекти,
разпределени в купчина, тъй като те са достъпни с указатели. Глобални променливи и
някои стекови променливи е невъзможно да се разпределят, защото са псевдоними - там
Процент от общия брой оптимизиращи

Име на оптимизацията Обяснение трансформации
Високо ниво На или близо до нивото на източника; независим

от процесора
Процедурна интеграция Замяна на извикването на процедура с тялото на процедурата NM
Местен В рамките на праволинейния код
Елиминиране на общ подизраз Заменете две копия на едно и също 18%

изчисление с едно копие
Постоянно размножаване Заменете всички екземпляри на променлива, 22%

на която е присвоена константа, с константата
Намаляване на височината на стека Пренаредете дървото на израза, за да NM

минимизирате ресурсите, необходими за оценка на израза
Глобален През един клон
Елиминиране на глобален общ Същото като локалното, но тази версия 13%

подизраз пресича клонове
Копиране на разпространение Заменете всички екземпляри на променлива A , на 11%
която е присвоено X (т.е. A = X) с X
Кодово движение Премахване на код от цикъл, който изчислява една 16%
и съща стойност при всяка итерация на цикъла
Елиминиране на индукционна променлива Опростете/елиминирайте изчисленията за 2%
адресиране на масиви в рамките на цикли
Зависи от процесора Зависи от познанията за процесора
Намаляване на силата Много примери, като замяна на умножение по NM

константа с добавяне и изместване
График на тръбопровода Пренаредете инструкциите, за да подобрите производителността NM

на тръбопровода
Оптимизиране на отместването на клонове Изберете най-краткото изместване на клона, което NM

достига целта
Фигура A.20 Основни типове оптимизации и примери във всеки клас. Тези данни ни казват за относителната честота на възникване на различни
оптимизации. Третата колона изброява статичната честота, с която някои от
общи оптимизации се прилагат в набор от 12 малки програми Fortran и Pascal. Има девет местни и глобални
оптимизации, направени от компилатора, включен в измерването. Шест от тези оптимизации са обхванати във фигурата, а останалите три
представляват 18% от общите статични събития. Съкращението NM означава, че
броят на случаите на тази оптимизация не е измерен. Обикновено се правят оптимизации в зависимост от процесора
в генератор на кодове и нито едно от тях не е измерено в този експеримент. Процентът е частта от статиката
оптимизации, които са от посочения тип. Данни от Chow [1983] (събрани с помощта на компилатора Stanford UCODE).
са множество начини за препращане към адреса на променлива, което прави поставянето й незаконно
в регистър. (Повечето променливи на купчина са ефективно псевдоними за днешния компилатор
технология.)
Например, разгледайте следната кодова последователност, където & връща
адрес на променлива и * дереферира указател:
Клонове/обаждания
Лукас, ниво 3 11%
ALU операции с плаваща запетая
Лукас, ниво 2 12% Товари-магазини
Цяло число ALU операции

рц
яаи зи
о,атм
а рп
м
лаи о аоП
п
и
втр
м
гио н
о
к
mcf, ниво 3 76%
mcf, ниво 2 76%
mcf, ниво 1 84%
mcf, ниво 0 100%
0% 20% 40% 60% 80% 100%
Процент на изпълнените неоптимизирани инструкции
Фигура A.21 Промяна в броя на инструкциите за програмите lucas и mcf от

SPEC2000, тъй като нивата на оптимизация на компилатора варират. Ниво 0 е същото като неоптимизирано
код. Ниво 1 включва локални оптимизации, програмиране на кодове и разпределение на локални регистри.
Ниво 2 включва глобални оптимизации, трансформации на цикъл (конвейер на софтуера),
и глобално разпределение на регистъра. Ниво 3 добавя интеграция на процедура. Тези експерименти
бяха изпълнени на Alpha компилатори.
p = &a-- получава адреса на a в p

а= ...-- присвоява директно на a
*p = ...-- използва p за присвояване на a
...a...-- достъп до a
Променливата a не може да бъде регистрирана, разпределена в присвояването на *p без

генериране на неправилен код. Псевдонимите причиняват съществен проблем, защото е така
често е трудно или невъзможно да се реши към какви обекти може да се отнася показалецът. А
компилаторът трябва да е консервативен; някои компилатори няма да разпределят никакви
локални променливи на процедура в регистър, когато има указател, който може да препраща към един от
локалните променливи.
Как архитектът може да помогне на автора на компилатора
Днес сложността на компилатора не идва от превода на прости изрази като A = B + C. Повечето

програми са локално прости и прости преводи
работи добре. По-скоро сложността възниква, защото програмите са големи и глобални
сложни в техните взаимодействия и тъй като структурата на компилаторите означава, че
решенията се вземат стъпка по стъпка за това коя кодова последователност е най-добра.
Писателите на компилатори често работят според собственото си следствие от основен
принцип в архитектурата: Направете честите случаи бързи и редките случаи правилни. Че
е, ако знаем кои случаи са чести и кои редки и ако генерираме
кодът и за двете е ясен, тогава качеството на кода за редките случаи може
не е много важно - но трябва да е правилно!
Някои свойства на набора от инструкции помагат на автора на компилатора. Тези свойства
не трябва да се смятат за твърди и бързи правила, а по-скоро като насоки, които ще
улесняват писането на компилатор, който ще генерира ефективен и правилен код.
Осигурете редовност – когато има смисъл, трите основни компонента
на набор от инструкции – операциите, типовете данни и адресирането
режими - трябва да са ортогонални. Твърди се, че има два аспекта на една архитектура
ортогонални, ако са независими. Например, операциите и режимите на адресиране са ортогонални,
ако за всяка операция, към която се адресира
може да се приложи режим, приложими са всички режими на адресиране. Тази закономерност
помага за опростяване на генерирането на код и е особено важно, когато решението за това какъв код
да се генерира е разделено на два прохода в компилатора. А
добър контрапример за това свойство е ограничаването на това какви регистри могат да се използват
за определен клас инструкции. Компилатори за регистър със специално предназначение
архитектурите обикновено се забиват в тази дилема. Това ограничение може да доведе до
компилаторът се оказва с много налични регистри, но нито един от
правилен вид!
Осигурете примитиви, а не решения—специални функции, които „съвпадат“ с език
конструкция или функция на ядрото често са неизползваеми. Опитите за поддръжка на езици от високо
ниво може да работят само с един език или да направят повече или по-малко, отколкото е
необходими за правилното и ефективно изпълнение на езика. Пример за това как подобни опити са
се провалили е даден в раздел A.10.
Опростете компромисите между алтернативите – една от най-трудните задачи за компилатор
писателят трябва да разбере каква последователност от инструкции ще бъде най-добра за всеки
сегмент от кода, който възниква. В по-ранните дни инструкцията се брои или общият размер на кода
може да са добри показатели, но – както видяхме в глава 1 – това вече не е вярно. С кеш паметта и
конвейера компромисите станаха много сложни. Всичко, което дизайнерът може да направи, за да
помогне на автора на компилатора да разбере
разходите за алтернативни кодови последователности биха помогнали за подобряване на кода. Един от
най-трудните случаи на сложни компромиси се случват в регистър-памет
архитектура при решаването колко пъти трябва да се реферира дадена променлива
преди да е по-евтино да го заредите в регистър. Този праг е труден за изчисляване
и всъщност може да варира между моделите с една и съща архитектура.
Осигурете инструкции, които обвързват количествата, известни по време на компилиране като константи
– Писателят на компилатор мрази мисълта, че процесорът интерпретира
runtime стойност, която е била известна по време на компилиране. Добри контрапримери за
този принцип включва инструкции, които интерпретират стойности, които са били фиксирани по
време на компилиране. Например инструкцията за извикване на процедурата VAX (повиквания)
динамично интерпретира маска, казваща какво регистрира, за да запазите при повикване, но маската е
фиксирани по време на компилиране (вижте раздел A.10).

Поддръжка на компилатор (или липса на такава) за мултимедия

Уви, дизайнерите на SIMD инструкциите (вижте Раздел 4.3 в Глава 4) основно игнорират предишния
подраздел. Тези инструкции обикновено са решения, а не примитиви; липсват им регистри; и
типовете данни не съответстват на съществуващите езици за програмиране. Архитектите се
надяваха да намерят евтино решение, което да помогне на някои потребители, но често само
няколко рутинни графични библиотеки на ниско ниво ги използват.
Инструкциите SIMD всъщност са съкратена версия на елегантен стил на архитектура, който
има своя собствена технология за компилиране. Както е обяснено в раздел 4.2, векторните
архитектури оперират с вектори от данни. Изобретени първоначално за научни кодове,
мултимедийните ядра често също могат да бъдат векторизирани, макар и често с по-къси вектори.
Както подсказва раздел 4.3 , можем да мислим за MMX и SSE на Intel или AltiVec на PowerPC като
просто кратки векторни компютри: MMX с вектори от осем 8-битови елемента, четири 16-битови
елемента или два 32-битови елемента и AltiVec с вектори два пъти тази дължина. Те се изпълняват
като просто съседни, тесни елементи в широки регистри.
Тези микропроцесорни архитектури вграждат размера на векторния регистър в архитектурата:

сумата от размерите на елементите е ограничена до 64 бита за MMX и 128 бита за AltiVec. Когато
Intel реши да разшири до 128-битови вектори, той добави изцяло нов набор от инструкции, наречен
Streaming SIMD Extension (SSE).
Основно предимство на векторните компютри е скриването на латентността на достъпа до
паметта чрез зареждане на много елементи наведнъж и след това припокриване на изпълнението
с прехвърляне на данни. Целта на режимите на векторно адресиране е да събират данни,
разпръснати в паметта, да ги поставят в компактна форма, така че да могат да се оперират
ефективно, и след това да поставят резултатите обратно, където им е мястото.
Векторните компютри включват последователно адресиране и събиране/разпръснато
адресиране (вижте раздел 4.2), за да се увеличи броят на програмите, които могат да бъдат векторизирани.
При последователното адресиране се пропуска фиксиран брой думи между всеки достъп, така че
последователното адресиране често се нарича адресиране с единична стъпка. Съберете и
разпръснете, намерете техните адреси в друг векторен регистър: Мислете за това като за
индиректно адресиране на регистъра за векторни компютри. От векторна гледна точка, за разлика
от тях, тези SIMD компютри с къс вектор поддържат само еднократен достъп: достъпът до паметта
зарежда или съхранява всички елементи наведнъж от едно място с широка памет.
Тъй като данните за мултимедийни приложения често са потоци, които започват и завършват в паметта,
режимите на стъпаловидно и събиране/разпръснато адресиране са от съществено значение за
успешното векторизиране (вижте раздел 4.7).
Пример Като пример, сравнете векторен компютър с MMX за преобразуване на цветово представяне на пиксели
от RGB (червено, зелено, синьо) към YUV (цветност на осветеността), като всеки пиксел е представен
от 3 байта. Преобразуването е само три реда C код, поставени в цикъл:
Y = (9798*R + 19235*G + 3736*B) / 32768;

U = (-4784*R - 9437*G + 4221*B) / 32768 + 128;
V = (20218*R - 16941*G - 3277*B) / 32768 + 128;
64-битов векторен компютър може да изчисли 8 пиксела едновременно. Един вектор
компютър за медии с разкрачени адреси отнема
3 векторни зареждания (за получаване на
RGB) 3 векторни умножения (за преобразуване на R)
6 векторни умножени добавяния (за преобразуване на G и B) 3
векторни измествания (за разделяне на 32 768)
2 векторни добавяния (за добавяне на 128)
3 векторни магазина (за съхраняване на YUV)
Общо са 20 инструкции за изпълнение на 20-те операции в предишния C код
конвертиране на 8 пиксела [Kozyrakis 2000]. (Тъй като един вектор може да има 32 64-битови елемента, този
код всъщност преобразува до 32 × 8 или 256 пиксела.)
За разлика от това, уеб сайтът на Intel показва, че рутинната библиотека изпълнява същото
изчислението на 8 пиксела отнема 116 инструкции MMX плюс 6 инструкции 80x86
[Intel 2001]. Това шесткратно увеличение на инструкциите се дължи на големия брой
инструкции за зареждане и разопаковане на RGB пиксели и за опаковане и съхраняване на YUV пиксели,
тъй като няма кратки достъпи до паметта.
Има кратки, ограничени от архитектурата вектори с малко регистри и прости
режимите на адресиране на паметта правят по-трудно използването на векторизиращ компилатор
технология. Следователно е по-вероятно тези SIMD инструкции да бъдат намерени в ръчно кодирани
библиотеки, отколкото в компилиран код.
Резюме: Ролята на компилаторите
Този раздел води до няколко препоръки. Първо, очакваме нова инструкция
задайте архитектурата да има най-малко 16 регистъра с общо предназначение - без да броите отделните
регистри за числа с плаваща запетая - за да опростите разпределението на регистрите
с помощта на оцветяване на графики. Съветът за ортогоналност предполага, че всички се поддържат
режимите на адресиране се прилагат за всички инструкции, които прехвърлят данни. И накрая, последните три
съвети - предоставяйте примитиви вместо решения, опростете компромисите
между алтернативите, не свързвайте константи по време на изпълнение - всички предполагат, че е по-добре
да греши от страна на простотата. С други думи, разберете, че по-малкото е повече в
дизайн на набор от инструкции. Уви, SIMD разширенията са по-скоро пример за добро
маркетинг, отколкото на изключителното постижение на съвместното проектиране на хардуер и софтуер.
А.9 Обединяване на всичко: Архитектурата MIPS
В този раздел ние описваме проста 64-битова архитектура за съхранение на данни, наречена MIPS. The
Архитектурата на набора от инструкции на роднините на MIPS и RISC се основава на наблюдения
подобни на тези, разгледани в последните раздели. (В раздел L.3 обсъждаме как и

A.9 Събиране на всичко заедно: Архитектурата на MIPS A-33
защо тези архитектури станаха популярни.) Преглед на нашите очаквания от всеки раздел за настолни
приложения:
Раздел A.2—Използване на регистри с общо предназначение с архитектура за съхранение на
зареждане. Раздел A.3—Поддържа тези режими на адресиране: изместване (с размер на изместване на
адреса от 12 до 16 бита), незабавно (размер 8 до 16 бита) и индиректен регистър.
Раздел A.4—Поддържа тези размери и типове данни: 8-, 16-, 32- и 64-битови цели числа и 64-битови IEEE
754 числа с плаваща запетая. Раздел A.5—Поддържайте тези
прости инструкции, тъй като те ще доминират в броя на изпълнените инструкции: зареждане, съхраняване,
добавяне, изваждане, преместване регистър-регистър и преместване.
Раздел A.6—Сравнете равно, сравнете неравно, сравнете по-малко, разклоняване (с относителен към PC
адрес с дължина най-малко 8 бита), прескачане, извикване и връщане. Раздел A.7—
Използвайте кодиране на фиксирани инструкции, ако се интересувате от производителност, и използвайте
кодиране на променливи инструкции, ако се интересувате от размера на кода.
Раздел A.8—Осигурете най-малко 16 регистъра с общо предназначение, уверете се, че всички режими на
адресиране се прилагат за всички инструкции за прехвърляне на данни и се стремете към
минималистичен набор от инструкции. Този раздел не обхваща програми с плаваща запетая, но те
често използват отделни регистри с плаваща запетая. Обосновката е да се увеличи общият брой на
регистрите, без да се създават проблеми във формата на инструкциите или в скоростта на регистровия
файл с общо предназначение. Този компромис обаче не е ортогонален.
Представяме MIPS, като показваме как той следва тези препоръки. Подобно на най-новите компютри,
MIPS подчертава
Прост набор от инструкции за зареждане и
съхраняване Проектиране за ефективност на конвейера (обсъдено в Приложение C), включително
кодиране на фиксиран набор от инструкции
Ефективност като цел на компилатора
MIPS предоставя добър архитектурен модел за изучаване не само поради популярността на този тип
процесор, но и защото е лесна за разбиране архитектура. Ще използваме тази архитектура отново в
Приложение C и в Глава 3 и тя формира основата за редица упражнения и проекти за програмиране.
В годините след първия MIPS процесор през 1985 г. имаше много версии на MIPS (вижте Приложение
K). Ще използваме подмножество от това, което сега се нарича MIPS64, което често ще се съкращава само
до MIPS, но пълният набор от инструкции се намира в Приложение К.

Регистрира за MIPS
MIPS64 има 32 64-битови регистъра с общо предназначение (GPR), наречени R0, R1, . . . , R31.
GPR понякога са известни и като цели числа. Освен това има набор от 32 регистъра с плаваща
запетая (FPR), наречени F0, F1, . . . , F31, който може да
съдържа 32 стойности с единична точност (32 бита) или 32 стойности с двойна точност (64 бита).
(Когато се съхранява едно число с единична точност, другата половина от FPR не се използва.)
Предоставят се както операции с плаваща запетая с единична, така и с двойна точност (32-
битови и 64-битови). MIPS също така включва инструкции, които работят с два операнда с
единична точност в един 64-битов регистър с плаваща запетая.
Стойността на R0 винаги е 0. Ще видим по-късно как можем да използваме този регистър за
синтезирайте различни полезни операции от прост набор от инструкции.
Няколко специални регистъра могат да бъдат прехвърлени към и от регистрите с общо
предназначение. Пример е регистърът за състояние с плаваща запетая, използван за
съхраняване на информация за резултатите от операциите с плаваща запетая. Има също
инструкции за преминаване между FPR и GPR.
Типове данни за MIPS
Типовете данни са 8-битови байтове, 16-битови половин думи, 32-битови думи и 64-битови
двойни думи за целочислени данни и 32-битова единична точност и 64-битова двойна точност
за плаваща запетая. Бяха добавени половин думи, защото се намират в езици като C и са
популярни в някои програми, като операционните системи, загрижени за размера на структурите
от данни. Те също ще станат по-популярни, ако Unicode стане широко използван. Операндите с
плаваща запетая с единична точност бяха добавени по подобни причини. (Запомнете ранното
предупреждение, че трябва да измервате много повече програми, преди да проектирате набор
от инструкции.)
Операциите MIPS64 работят с 64-битови цели числа и 32- или 64-битова плаваща запетая.
Байтове, полудуми и думи се зареждат в регистрите с общо предназначение или с нули, или със
знаковия бит, репликиран за запълване на 64-те бита на GPR. Веднъж заредени, те се оперират
с 64-битови цели числа.
Режими на адресиране за MIPS трансфер на данни
Единствените режими на адресиране на данни са незабавно и изместване, и двата с 16-битови

полета. Непрякото регистриране се осъществява просто чрез поставяне на 0 в 16-битовото
поле за изместване, а абсолютното адресиране с 16-битово поле се осъществява чрез използване
на регистър 0 като основен регистър. Приемането на нула ни дава четири ефективни режима,
въпреки че само два се поддържат в архитектурата.
MIPS паметта е байтово адресируема с 64-битов адрес. Има бит за режим, който позволява
на софтуера да избере Big Endian или Little Endian. Тъй като това е архитектура със зареждане,
всички препратки между паметта и GPR или FPR са чрез зареждания или запаметявания.
Поддържайки типовете данни, споменати по-горе, достъпите до паметта, включващи GPR, могат
да бъдат до байт, половин дума, дума или двойна дума. FPR могат да се зареждат и съхраняват с
числа с единична или двойна точност. Всички достъпи до паметта трябва да бъдат подравнени.
I-тип инструкция
6 5 5 16
Операционен код rs rt Незабавно
Кодира: Зарежда и съхранява байтове, половин думи, думи,

двойни думи. Всички незабавни (rt rs op незабавно)
Инструкции за условно разклоняване (rs е регистър, rd не се използва)

Регистър за скок, регистър за скок и връзка
(rd = 0, rs = дестинация, незабавно = 0)
Инструкция тип R
6 55 5 5 6
Операционен код rs rt rd шамт функция
Регистър-регистър ALU операции: rd rs funct rt

Функцията кодира операцията по пътя на данните: Add, Sub, . . .
Четене/запис на специални регистри и ходове
Инструкция тип J
6 26
Операционен код Отместването е добавено към компютъра
Скок и скок и връзка

Прихващане и връщане от изключение
Фигура A.22 Оформление на инструкции за MIPS. Всички инструкции са кодирани в един от трите
типове, с общи полета на едно и също място във всеки формат.
MIPS формат на инструкции
Тъй като MIPS има само два режима на адресиране, те могат да бъдат кодирани в
операционен код. Следвайки съветите за улесняване на конвейера на процесора и
декодиране, всички инструкции са 32 бита с 6-битов основен код на операцията. Фигура А.22
показва оформлението на инструкциите. Тези формати са прости, като същевременно осигуряват 16 бита
полета за адресиране на изместване, непосредствени константи или PC-относително разклонение
адреси.
Приложение K показва вариант на MIPS – наречен MIPS16 – който има 16-битов

и 32-битови инструкции за подобряване на плътността на кода за вградени приложения. Ние
ще се придържаме към традиционния 32-битов формат в тази книга.
MIPS операции
MIPS поддържа списъка с прости операции, препоръчани по-горе, плюс няколко други. Има четири
широки класа инструкции: зареждания и съхранявания, ALU операции, разклонения и скокове и
операции с плаваща запетая.
Всеки от регистрите с общо предназначение или с плаваща запетая може да бъде зареден или
се съхранява, с изключение на това, че зареждането на R0 няма ефект. Фигура А.23 дава примери за
инструкции за зареждане и съхранение. Числата с плаваща запетая с единична точност заемат половината
регистър с плаваща запетая. Преобразувания между единична и двойна точност трябва
да се направи изрично. Форматът с плаваща запетая е IEEE 754 (вижте Приложение J). Списък
на всички MIPS инструкции в нашия поднабор се появява на фигура A.26 (страница A-40).
За да разберем тези цифри, трябва да въведем няколко допълнителни разширения
към нашия C език за описание, използван първоначално на страница A-9:
Долен индекс се добавя към символа винаги, когато дължината на базата данни
прехвърлянето може да не е ясно. Така n означава прехвърляне на n-битово количество.
Използваме x, y z , за да посочим, че z трябва да се прехвърли към x и y.
Долен индекс се използва за обозначаване на избор на бит от поле. Битовете са етикетирани

от най-значимия бит, започващ от 0. Долният индекс може да бъде една цифра
(напр. Regs[R4]0 дава знаковия бит на R4) или поддиапазон (напр. Regs[R3]56..63
дава най-малко значимия байт на R3).
Променливата Mem, използвана като масив, който означава основна памет, се индексира от
байтов адрес и може да прехвърля произволен брой байтове.
Горен индекс се използва за репликиране на поле (напр. 048 дава поле от нули на
дължина 48 бита).
Символът ## се използва за свързване на две полета и може да се появи на всяко от тях

страна на трансфер на данни.
Примерна инструкция Име на инструкцията Значение
LD R1,30(R2) Зареждане на двойна дума Regs[R1] 64 Mem[30+Regs[R2]]

LD R1,1000(R0) Зареждане на двойна дума Regs[R1] 64 Mem[1000+0]
LW R1,60(R2) Зареди дума Regs[R1] 64 (Mem[60+Regs[R2]]0)32 ## Mem[60+Regs[R2]]
LB R1,40(R3) Заредете байт Regs[R1] 64 (Mem[40+Regs[R3]]0)56 ##
Mem[40+Regs[R3]]
LBU R1,40(R3) Зареждане на байт без знак Regs[R1] 64 056 ## Mem[40+Regs[R3]]

LH R1,40(R3) Зареди половин дума Regs[R1] 64 (Mem[40+Regs[R3]]0)48 ##
Mem[40+Regs[R3]] ## Mem[41+Regs[R3]]
LS F0,50(R3) Заредете FP единично Regs[F0] 64 Mem[50+Regs[R3]] ## 032

LD F0,50(R2) Заредете FP двойно Regs[F0] 64 Mem[50+Regs[R2]]
SD R3500 (R4) Съхранявайте двойна дума Мем[500+рег.[R4]] 64 регламента[R3]
SW R3500 (R4) Съхранявайте дума
Mem[500+Regs[R4]] 32 Regs[R3]32..63
SS F0,40(R3) Съхранявайте FP единичен Mem[40+Regs[R3]] 32 Regs[F0]0..31
SD F0,40(R3) Съхранявайте FP двойно Mem[40+Regs[R3]] 64 Regs[F0]
SH R3,502(R2) Съхранявайте половината
Mem[502+Regs[R2]] 16 Regs[R3]48..63
SB R2,41(R3) Запазете байт Mem[41+Regs[R3]] Regs[R2]
8 56..63
Фигура A.23 Инструкциите за зареждане и съхраняване в MIPS. Всички използват един режим на адресиране и изискват стойността на паметта да
бъде подравнена. Разбира се, както зарежданията, така и съхраняванията са налични за всички показани типове данни.
Примерна инструкция Име на инструкция Значение
DADDU R1,R2,R3 Добавете неподписан Регламенти [R1] Регламенти [R2] + Регламенти [R3]
DADDIU R1,R2,#3 Добавете незабавни неподписани Regs[R1] Regs[R2]+3

LUI R1, #42 Заредете горните непосредствени регулации [R1] 032##42##016
DSLL R1, R2, #5 Изместване наляво логично Regs[R1] Regs[R2]<<5
SLT R1,R2,R3 Задайте по-малко от if (Regs[R2]<Regs[R3])

Regs [R1] 1 else Regs [R1] 0
Фигура A.24 Примери за аритметични/логически инструкции на MIPS, както с, така и с

без незабавни.
Като пример, ако приемем, че R8 и R10 са 64-битови регистри:
Regs[R10]32..63 32(Mem[Regs[R8]]0)24 ## Mem[Regs[R8]]
означава, че байтът в мястото на паметта, адресирано от съдържанието на регистъра

R8 е разширен със знак, за да формира 32-битово количество, което се съхранява в долната половина на
регистър R10. (Горната половина на R10 е непроменена.)
Всички ALU инструкции са регистър-регистр инструкции. Фигура A.24 показва
някои примери за аритметични/логически инструкции. Операциите включват
прости аритметични и логически операции: събиране, изваждане, И, ИЛИ, XOR и смени.
Незабавните форми на всички тези инструкции се предоставят с помощта на 16-битов незабавен
разширен знак. Операцията LUI (зареждане на горния непосредствен) зарежда битове 32
през 47 на регистър, докато задавате останалата част от регистъра на 0. LUI позволява a
32-битова константа, която да бъде вградена в две инструкции, или прехвърляне на данни, използвайки всеки
постоянен 32-битов адрес в една допълнителна инструкция.
Както бе споменато по-горе, R0 се използва за синтезиране на популярни операции. Зареждане на a

константа е просто незабавно добавяне, където операндът източник е R0 и a
преместването регистър-регистър е просто добавяне, където един от източниците е R0. (Ние
понякога използвайте мнемониката LI, означаваща load immediate, за представяне на
първия и мнемоничния MOV за втория.)
Инструкции за MIPS контролен поток
MIPS предоставя инструкции за сравнение, които сравняват два регистъра, за да видят дали
първото е по-малко от второто. Ако условието е вярно, тези инструкции поставят 1 в
дестинационният регистър (за представяне на истината); в противен случай те поставят стойността 0.
Тъй като тези операции „задават“ регистър, те се наричат set-equal, set-not-equal,
набор-по-малко-от и т.н. Има и непосредствени форми на тези сравнения.
Контролът се управлява чрез набор от скокове и набор от разклонения. Фигура A.25
дава някои типични инструкции за разклоняване и прескачане. Четирите инструкции за скок са
разграничени от двата начина за указване на адреса на местоназначението и от това дали
или не е направена връзка. Два скока използват 26-битово отместване, изместено с 2 бита и след това заместват
Пример
инструкция Име на инструкция Значение
Дж име скочи PC36..63 име

JAL име Направо и връзка Regs[R31] PC+8; PC36..63 име; ((PC + 4)–
227) име < ((PC+4)+227)
JALR R2 Регистър за прескачане и връзка Regs[R31] PC+8; PC Regs[R2]

JR R3 Прескачащ регистър PC Regs [R3]
BEQZ R4, име Разклонение е равно на нула if (Regs[R4]==0) Име на компютър ;

((PC+4)–217) име < ((PC+4)+217)
BNE R3,R4,име Разклонение не е равно на нула ако (Regs[R3]!= Regs[R4]) PC name; ((PC+4)–217)
име < ((PC+4)+217)
MOVZ R1,R2,R3 Условно движение, ако е нула if (Regs[R3]==0) Regs[R1] Regs[R2]
Фигура A.25 Типични инструкции за контролен поток в MIPS. Всички инструкции за контрол, с изключение на
прескачане на адрес в регистър, са свързани с PC. Обърнете внимание, че разстоянията на клоновете са
по-дълъг, отколкото предполага полето за адрес; тъй като MIPS инструкциите са дълги 32 бита,
адресът на клона на байта се умножава по 4, за да се получи по-голямо разстояние.
долните 28 бита на програмния брояч (на инструкцията, следваща последователно

скокът), за да определите адреса на местоназначението. Другите две скачат инструкции
укажете регистър, който съдържа адреса на местоназначение. Има два вкуса на
скокове: обикновен скок и скок и връзка (използвани за извиквания на процедури). Последните места
обратният адрес—адресът на следващата последователна инструкция—в R31.
Всички клонове са условни. Състоянието на клона се определя от
инструкция, която може да тества източника на регистъра за нула или ненула; регистъра
може да съдържа стойност на данни или резултат от сравнение. Има и условни
инструкции за разклоняване за тестване дали даден регистър е отрицателен и за равенство
между два регистъра. Целевият адрес на клона е посочен с 16-битов знак
отместване, което се измества наляво на две места и след това се добавя към програмния брояч, който
сочи към следващата последователна инструкция. Има и клон за тестване
регистър за състояние с плаваща запетая за условни разклонения с плаваща запетая, описано
по късно.
Приложение C и Глава 3 показват, че условните разклонения са голямо предизвикателство пред

конвейерното изпълнение; следователно много архитектури имат добавени инструкции
за преобразуване на просто разклонение в условна аритметична инструкция. MIPS
включен условен ход на нула или не на нула. Стойността на целевия регистър или остава непроменена,
или се заменя с копие на един от регистрите източник
в зависимост от това дали стойността на другия регистър източник е нула или не.
MIPS операции с плаваща запетая
Инструкциите с плаваща запетая манипулират регистрите с плаваща запетая и показват

дали операцията, която трябва да се извърши, е с единична или двойна точност. The
операции MOV.S и MOV.D копират единична точност (MOV.S) или двойна точност
A.10 Заблуди и клопки A-39
(MOV.D) регистър с плаваща запетая към друг регистър от същия тип. Операциите MFC1, MTC1, DMFC1
и DMTC1 преместват данни между единичен или двоен регистър с плаваща запетая и регистър на
цели числа. Осигурени са и преобразувания от цяло число към плаваща запетая и обратно.
Операциите с плаваща запетая са събиране, изваждане, умножение и деление; суфикс D се

използва за двойна точност, а суфикс S се използва за единична точност (напр. ADD.D, ADD.S, SUB.D,
SUB.S, MUL.D, MUL.S, DIV.D, DIV .С). Сравненията с плаваща запетая задават малко в специалния регистър
за състояние на плаваща запетая, който може да бъде тестван с чифт разклонения: BC1T и BC1F,
разклонение с плаваща запетая вярно и разклонение с плаваща запетая невярно.
За да получите по-голяма производителност за графични процедури, MIPS64 има инструкции,

които изпълняват две 32-битови операции с плаваща запетая на всяка половина от 64-битовия регистър
с плаваща запетая. Тези сдвоени единични операции включват ADD.PS, SUB.PS, MUL.PS и DIV.PS. (Те се
зареждат и съхраняват чрез зареждане и съхраняване с двойна точност.)
Давайки намигване към важността на мултимедийните приложения, MIPS64 също включва

инструкции за добавяне на умножение с цели числа и с плаваща запетая: MADD, MADD.S, MADD.D и
MADD.PS. Всички регистри са с еднаква ширина при тези комбинирани операции. Фигура A.26 съдържа
списък на подмножество от MIPS64 операции и техните значения.
Използване на MIPS набор от инструкции
За да се даде представа кои инструкции са популярни, Фигура A.27 показва честотата на инструкциите
и класовете инструкции за пет SPECint2000 програми, а Фигура A.28 показва същите данни за пет
SPECfp2000 програми.
A.10 Заблуди и клопки
Архитектите многократно са се спъвали в общи, но погрешни вярвания. В този раздел разглеждаме

няколко от тях.
Клопка Проектиране на функция за набор от инструкции на „високо ниво“, специално ориентирана към поддръжка
езикова структура на високо ниво.
Опитите за включване на езикови функции от високо ниво в набора от инструкции накараха архитектите
да осигурят мощни инструкции с широк диапазон от гъвкавост.
Често обаче тези инструкции вършат повече работа, отколкото се изисква в честите случаи, или не
отговарят точно на изискванията на някои езици. Много подобни усилия бяха насочени към премахване
на това, което през 70-те години на миналия век се наричаше семантична празнина. Въпреки че идеята
е да се допълни наборът от инструкции с допълнения, които издигат хардуера до нивото на езика,
допълненията
Тип на инструкцията/операционен код Значение на инструкцията
Трансфери на данни Преместване на данни между регистри и памет или между цяло число и FP или специални регистри; единственият
режим на адрес на паметта е 16-битово изместване + съдържание на GPR
LB,LBU,SB Зареждане на байт, зареждане на байт без знак, съхраняване на байт (към/от целочислени регистри)
LH,LHU,SH Зареждане на половин дума, зареждане на половин дума без знак, съхраняване на половин дума (към/от целочислени регистри)
LW,LWU,SW Зареждане на дума, зареждане на неподписана дума, съхраняване на дума (към/от целочислени регистри)
LD,SD Зареждане на двойна дума, съхраняване на двойна дума (към/от целочислени регистри)
LS,LD,SS,SD MFC0,MTC0 Заредете SP float, заредете DP float, запазете SP float, запазете DP float
MOV.S,MOV.D Копиране от/в GPR към/от специален регистър
MFC1,MTC1 Копирайте един SP или DP FP регистър в друг FP регистър
Аритметично/ Копирайте 32 бита към/от FP регистри от/към цели числа
логическо Операции с целочислени или логически данни в GPR; аритметично прихващане със знак при препълване
DADD,DADDI,DADDU,DADDIU Добавяне , незабавно добавяне (всички непосредствени са 16 бита); подписани и неподписани
DSUB,DSUBU Изваждане; подписани и неподписани
DMUL,DMULU,DDIV, Умножение и деление, със знак и без знак; умножение-събиране; всички операции вземат и дават 64-
ДДИВУ,МАДД битови стойности
И,ANDI И, и незабавно
ИЛИ,ORI,XOR,XORI LUI Или, или незабавно, изключително или, изключително или незабавно
Заредете горната част незабавно; зарежда битове от 32 до 47 от регистъра с незабавно, след което разширява знака
DSLL, DSRL, DSRA, DSLLV, Промени: незабавни (DS__) и променлива форма (DS__V); отместванията са отместване наляво логическо, дясно
DSRLV, DSRAV логическо, дясно аритметично
SLT,SLTI,SLTU,SLTIU Задайте по-малко от, задайте по-малко от незабавно; подписани и неподписани
контрол Условни разклонения и скокове; PC-роднина или чрез регистър
BEQZ,BNEZ GPR на разклонения са равни/не равни на нула; 16-битово отместване от PC + 4
BEQ,BNE Клон GPR равен/не е равен; 16-битово отместване от PC + 4
BC1T, BC1F Бит за тестово сравнение в регистъра на състоянието на FP и разклонението; 16-битово отместване от PC + 4
MOVN,MOVZ Копирайте GPR в друг GPR, ако третият GPR е отрицателен, нула
J,JR Скокове: 26-битово отместване от PC + 4 (J) или цел в регистър (JR)
ДЖАЛ, ДЖАЛР Прескачане и връзка: запазване на PC + 4 в R31, целта е свързана с PC (JAL) или регистър (JALR)
КАПАН Прехвърляне към операционна система на векторизиран адрес
ERET Връщане към потребителски код от изключение; възстановяване на потребителския режим
С плаваща запетая FP операции върху DP и SP формати
ADD.D,ADD.S,ADD.PS Добавете DP, SP номера и двойки SP номера
SUB.D,SUB.S,SUB.PS Извадете DP, SP числа и двойки SP числа
MUL.D,MUL.S,MUL.PS Умножете DP, SP с плаваща запетая и двойки SP числа
MADD.D,MADD.S,MADD.PS DIV.D, Умножение-събиране на DP, SP числа и двойки SP числа
DIV.S,DIV.PS CVT._._ Разделете DP, SP с плаваща запетая и двойки SP числа
Инструкции за преобразуване: CVT.xy преобразува от тип x в тип y, където x и y са L

(64-битово цяло число), W (32-битово цяло число), D (DP) или S (SP). И двата операнда са FPR.
C.__.D,C.__.S DP и SP сравнява: “__” = LT,GT,LE,GE,EQ,NE; задава бит в регистъра на състоянието на FP
Фигура A.26 Поднабор от инструкции в MIPS64. Фигура A.22 изброява форматите на тези инструкции. SP = единичен
прецизност; DP = двойна точност. Този списък може да се намери и на задната вътрешна корица.
Цяло число
Инструкция празнина gcc gzip mcf perlbmk средно аритметично
натоварване 26,5% 25,1% 20,1% 30,3% 28,7% 26%
магазин 10,3% 13,2% 5,1% 4,3% 16,2% 10%
добавете 21,1% 19,0% 26,9% 10,1% 16,7% 19%
суб 1,7% 2,2% 5,1% 3,7% 2,5% 3%
мул 1,4% 0,1% 0%
сравнявам 2,8% 6,1% 6,6% 6,3% 3,8% 5%
натоварване имм 4,8% 2,5% 1,5% 0,1% 1,7% 2%
cond клон 9,3% 12,1% 11,0% 17,5% 10,9% 12%
cond ход 0,4% 0,6% 1,1% 0,1% 1,9% 1%
скок 0,8% 0,7% 0,8% 0,7% 1,7% 1%
обадете се 1,6% 0,6% 0,4% 3,2% 1,1% 1%
връщане 1,6% 0,6% 0,4% 3,2% 1,1% 1%
смяна 3,8% 1,1% 2,1% 1,1% 0,5% 2%
И 4,3% 4,6% 9,4% 0,2% 1,2% 4%
ИЛИ 7,9% 8,5% 4,8% 17,6% 8,7% 9%
XOR 1,8% 2,1% 4,4% 1,5% 2,8% 3%
друго логично 0,1% 0,4% 0,1% 0,1% 0,3% 0%
натоварване FP 0%
магазин FP 0%
добавете FP 0%
под FP 0%
mul FP 0%
div FP 0%
mov reg-reg FP 0%
сравнете FP 0%
cond mov FP 0%
други FP 0%
Фигура A.27 MIPS динамичен микс от инструкции за пет SPECint2000 програми. Обърнете внимание, че целочислен регистър-регистър
инструкциите за преместване са включени в инструкцията ИЛИ . Празните записи имат стойност 0,0%.
може да генерира това, което Wulf, Levin и Harbison [1981] наричат семантика
сблъсък:
. . . като придава твърде много семантично съдържание на инструкцията, компютъра

дизайнерът направи възможно използването на инструкцията само в ограничен контекст. [стр. 43]
По-често инструкциите са просто пресилени - те са твърде общи за

най-честият случай, което води до ненужна работа и по-бавно обучение. Отново,
VAX CALLS е добър пример. CALLS използва стратегия за запазване на callee (регистрите
Инструкция приложение изкуство

изравнявам се Лукас плувам FP средно
натоварване 13,8% 18,1% 22,3% 10,6% 9,1% 15%
магазин 2,9% 0,8% 3,4% 1,3% 2%
добавете 30,4% 30,1% 17,4% 11,1% 24,4% 23%
суб 2,5% 0,1% 2,1% 3,8% 2%
мул 2,3% 1,2% 1%
сравнявам 7,4% 2,1% 2%
натоварване имм 13,7% 1,0% 1,8% 9,4% 5%
cond клон 2,5% 11,5% 2,9% 0,6% 1,3% 4%
cond mov 0,3% 0,1% 0%
скок 0,1% 0%
обадете се 0,7% 0%
връщане 0,7% 0%
смяна 0,7% 0,2% 1,9% 1%
И 0,2% 1,8% 0%
ИЛИ 0,8% 1,1% 2,3% 1,0% 7,2% 2%
XOR 3,2% 0,1% 1%
друго логично 0,1% 0%
натоварване FP 11,4% 12,0% 19,7% 16,2% 16,8% 15%
магазин FP 4,2% 4,5% 2,7% 18,2% 5,0% 7%
добавете FP 2,3% 4,5% 9,8% 8,2% 9,0% 7%
под FP 2,9% 1,3% 7,6% 4,7% 3%
mul FP 8,6% 4,1% 12,9% 9,4% 6,9% 8%
div FP 0,3% 0,6% 0,5% 0,3% 0%
mov reg-reg FP 0,7% 0,9% 1,2% 1,8% 0,9% 1%
сравнете FP 0,9% 0,6% 0,8% 0%
cond mov FP 0,6% 0,8% 0%
други FP 1,6% 0%
Фигура A.28 MIPS динамична комбинация от инструкции за пет програми от SPECfp2000. Обърнете внимание, че целочислен регистър-регистър
инструкциите за преместване са включени в инструкцията ИЛИ . Празните записи имат стойност 0,0%.
за записване са посочени от извиквания), но записването се извършва от инструкцията за повикване в
повикващия. Инструкцията CALLS започва с аргументите, поставени на
стека и след това предприема следните стъпки:
1. Подравнете стека, ако е необходимо.
2. Избутайте броя на аргументите в стека.
3. Запазете регистрите, посочени от маската за извикване на процедура в стека (както е споменато в раздел
A.8). Маската се съхранява в кода на извиканата процедура—това

позволява на повикващия да посочи регистрите, които да бъдат запазени от повикващия дори с
отделна компилация.
4. Натиснете адреса за връщане в стека и след това натиснете горната и основата на стека
указатели (за записа за активиране).
5. Изчистете кодовете на условия, което настройва разрешаването на прихващане в известно състояние.
6. Натиснете дума за информация за състоянието и нула дума в стека.
7. Актуализирайте двата указателя на стека.
8. Разклоняване към първата инструкция на процедурата.
По-голямата част от обажданията в реални програми не изискват това количество
отгоре. Повечето процедури знаят своя брой аргументи и може да се установи много по-бърза конвенция за
възрастта на връзката, като се използват регистри за предаване на аргументи, вместо
стека в паметта. Освен това, инструкцията CALLS принуждава два регистъра да
да се използва за свързване, докато много езици изискват само един регистър за свързване.
Има много опити за поддръжка на извикване на процедури и управление на стека за активиране
не са били полезни или защото не отговарят на езиковите нужди, или
тъй като те са твърде общи и следователно твърде скъпи за използване.
Дизайнерите на VAX предоставиха по-проста инструкция, JSB, която е много по-бърза
тъй като само избутва компютъра за връщане в стека и прескача към процедурата.
Повечето VAX компилатори обаче използват по-скъпите CALLS инструкции. Повикването
в архитектурата бяха включени инструкции за стандартизиране на конвенцията за възрастта на връзката на
процедурата. Други компютри са стандартизирали своята конвенция за повикване чрез
споразумение между авторите на компилатора и без да се изискват допълнителни разходи за сложна, много
обща инструкция за извикване на процедура.
Заблуда Има такова нещо като типична програма.
Много хора биха искали да вярват, че има една единствена „типична“ програма, която
може да се използва за проектиране на оптимален набор от инструкции. Например, вижте синтетика
бенчмаркове, разгледани в глава 1. Данните в това приложение ясно показват това
програмите могат да се различават значително по начина, по който използват набор от инструкции. Например,
Фигура A.29 показва комбинацията от размери на трансфер на данни за четири от програмите SPEC2000: Би
било трудно да се каже какво е типично за тези четири програми. The
вариациите са още по-големи при набор от инструкции, който поддържа клас приложения, като десетични
инструкции, които не се използват от други приложения.
Клопка Иновации в архитектурата на набора от инструкции за намаляване на размера на кода без отчитане на компилатора.
Фигура A.30 показва относителните размери на кода за четири компилатора за MIPS
набор от инструкции. Докато архитектите се борят да намалят размера на кода с 30% до 40%,
различните стратегии на компилатора могат да променят размера на кода с много по-големи фактори. Подобен
към техниките за оптимизиране на производителността, архитектът трябва да започне с най-строгия код,
който компилаторите могат да произведат, преди да предложи хардуерни иновации на
спестете място.
60%
Двойна дума 94%
(64 бита) 31%
62%
40%
Слово 6%
(32 бита) 28%
18% приложение
0%
Половин дума 0% gzip
(16 бита) 19% perl

3%
0%
Байт 0%
(8 бита) 22%
18%
0% 20% 40% 60% 80% 100%
Фигура A.29 Референтен размер на данни на четири програми от SPEC2000. Въпреки че можете
изчислете среден размер, би било трудно да се твърди, че средният размер е типичен за програмите.
Зелени хълмове
Софтуер Apogee Multi2000 Алгоритмика

Компилатор Версия 4.1 Версия 2.0 SDE4.0B IDT/c 7.2.1
Архитектура MIPS IV MIPS IV MIPS 32 MIPS 32
Процесор NEC VR5432 NEC VR5000 IDT 32334 IDT 79RC32364
Автокорелационно ядро 1.0 2.1 1.1 2.7
Ядрото на конволюционния енкодер 1.0 1.9 1.2 2.4
Ядро за разпределение на битове с фиксирана точка 1.0 2.0 1.2 2.3
Сложно FFT ядро с фиксирана точка 1.0 1.1 2.7 1.8
Viterbi GSM декодер ядро 1.0 1.7 0,8 1.1
Средно геометрично от пет ядра 1.0 1.7 1.4 2.0
Фигура A.30 Размер на кода спрямо Apogee Software Version 4.1 C компилатор за Telecom приложение на EEMBC
бенчмаркове. Архитектурите на набора от инструкции са почти идентични, но размерите на кода варират с коефициенти 2. Тези
резултатите бяха докладвани февруари-юни 2000 г.
Заблуда Архитектура с недостатъци не може да бъде успешна.
80x86 предоставя драматичен пример: Архитектурата на набора от инструкции е една

само неговите създатели биха могли да обичат (вижте Приложение К). Следващите поколения на Intel
инженерите се опитаха да коригират непопулярните архитектурни решения, направени при
проектирането на 80x86. Например 80x86 поддържа сегментиране, докато всички останали
избрано страниране; той използва разширени акумулатори за целочислени данни, но други
процесори използват регистри с общо предназначение; и използва стек за данни с плаваща запетая,
когато всички останали изоставиха стекове за изпълнение много преди това.
A.11 Заключителни бележки A-45
Въпреки тези големи трудности, архитектурата 80x86 беше изключително успешна. Причините са
три: Първо, изборът му като микропроцесор в първоначалния IBM PC прави двоичната съвместимост
80x86 изключително ценна. Второ, законът на Мур осигурява достатъчно ресурси за микропроцесорите
80x86, за да се преобразуват във вътрешен набор от RISC инструкции и след това да изпълняват
подобни на RISC инструкции. Тази комбинация позволява двоична съвместимост с ценната
компютърна софтуерна база и производителност, равна на RISC процесорите. Трето, много големите
обеми микропроцесори за персонални компютри означават, че Intel може лесно да плати увеличените
разходи за проектиране на хардуерен превод. В допълнение, големите обеми позволяват на
производителя да върви нагоре по кривата на обучение, което намалява цената на продукта.
По-големият размер на матрицата и увеличената мощност за превод може да са недостатък за

вградените приложения, но има огромен икономически смисъл за настолния компютър.
И неговата цена-производителност в десктопа също го прави привлекателен за сървъри, като основната
му слабост за сървърите са 32-битовите адреси, което беше разрешено с 64-битовите адреси на AMD64
(вижте Глава 2 ) .
Заблуда Можете да проектирате безупречна архитектура.
Целият дизайн на архитектурата включва компромиси, направени в контекста на набор от хардуерни

и софтуерни технологии. С течение на времето тези технологии вероятно ще се променят и решенията,
които може да са били правилни по времето, когато са били взети, изглеждат като грешки. Например,
през 1975 г. дизайнерите на VAX подчертаха прекалено важността на ефективността на размера на
кода, подценявайки колко важна ще бъде лекотата на декодиране и конвейериране пет години по-
късно. Пример в лагера RISC е забавено разклоняване (вижте Приложение K). Беше лесно да се
контролират опасностите от конвейера с петстепенни конвейери, но предизвикателство за процесори
с по-дълги конвейери, които издават множество инструкции на такт. В допълнение, почти всички
архитектури в крайна сметка се поддават на липсата на достатъчно адресно пространство.
Като цяло, избягването на такива недостатъци в дългосрочен план вероятно би означавало

компрометиране на ефективността на архитектурата в краткосрочен план, което е опасно, тъй като
новата архитектура на набора от инструкции трябва да се бори да оцелее през първите няколко години.
A.11 Заключителни бележки

Най-ранните архитектури бяха ограничени в своите набори от инструкции от хардуерната технология
от онова време. Веднага след като хардуерната технология позволи, компютърните архитекти
започнаха да търсят начини за поддръжка на езици от високо ниво. Това търсене доведе до три
различни периода на мислене за това как да се поддържат програмите ефективно.
През 60-те години стековите архитектури стават популярни. Те бяха разглеждани като подходящи за
езици от високо ниво - и вероятно бяха, като се има предвид технологията на компилатора на деня.
През 70-те години основната грижа на архитектите беше как да намалят разходите за софтуер. Тази
загриженост беше посрещната предимно чрез замяна на софтуера с хардуер или чрез предоставяне на
архитектури от високо ниво, които биха могли да опростят задачата на софтуерните дизайнери.
Резултатът беше както движението за езикова компютърна архитектура на високо ниво, така и мощни
архитектури като VAX, която има
голям брой режими на адресиране, множество типове данни и силно ортогонален
архитектура. През 80-те години на миналия век се появиха по-сложни компилаторни технологии и a
подновеният акцент върху производителността на процесора доведе до връщане към по-опростени
архитектури, базирани главно на стила на зареждане на компютъра.
Следните промени в архитектурата на набора от инструкции са настъпили през 90-те години:
Размерът на адреса се удвоява – 32-битовите набори от адресни инструкции за повечето настолни компютри
и сървърните процесори бяха разширени до 64-битови адреси, разширявайки ширината
на регистрите (между другото) до 64 бита. Приложение К дава три
примери за архитектури, които са преминали от 32 бита на 64 бита.
Оптимизиране на условни разклонения чрез условно изпълнение—В глава 3,
виждаме, че условните разклонения могат да ограничат производителността на агресивните компютърни
дизайни. Следователно имаше интерес към замяна на условни разклонения с
условно завършване на операции, като условно преместване (вижте Приложение

H), който беше добавен към повечето набори инструкции.
Оптимизиране на производителността на кеша чрез предварително извличане—Глава 2 обяснява
нарастваща роля на йерархията на паметта в производителността на компютрите, с a
пропуск в кеша на някои компютри, които отнемат толкова време на инструкции, колкото страница
грешки, възникнали на по-ранни компютри. Следователно бяха добавени инструкции за предварително извличане
опитайте се да скриете цената на пропуските в кеша чрез предварително извличане (вижте Глава 2).
Поддръжка на мултимедия—Повечето настолни и вградени набори инструкции бяха
разширен с поддръжка за мултимедийни приложения.
По-бързи операции с плаваща запетая—Приложение J описва добавените операции към
подобряване на производителността с плаваща запетая, като например операции, които извършват
многослойно и добавяне и сдвояване единично изпълнение. (Включваме ги в MIPS.)
Между 1970 и 1985 г. мнозина смятаха, че основната работа на компютърния архитект е проектирането
на набори от инструкции. В резултат на това учебниците от онази епоха подчертават размера на набора от
инструкции, подобно на учебниците по компютърна архитектура от 50-те години
и 1960-те наблягаха на компютърната аритметика. Очакваше се образованият архитект
да има твърдо мнение относно силните и особено слабите страни на
популярни компютри. Значението на бинарната съвместимост за премахването на иновациите в дизайна на
набора от инструкции не беше оценено от много изследователи и автори на учебници, създавайки
впечатлението, че много архитекти ще получат шанс да
проектирайте набор от инструкции.
Определението за компютърна архитектура днес е разширено, за да включва
проектиране и оценка на пълната компютърна система - не само дефиницията на
набор от инструкции, а не само процесор - и следователно има много теми
за да учи архитектът. Всъщност материалът в това приложение беше централна точка
на книгата в първото й издание през 1990 г., но сега е включена в приложение предимно като справочен
материал!
Приложение K може да задоволи читателите, интересуващи се от архитектурата на набора от инструкции; то
описва различни набори от инструкции, които са или важни на пазара днес, или исторически важни, и
сравнява девет популярни зареждащи хранилища
компютри с MIPS.
Упражнения от Грегъри Д. Питърсън A-47
A.12 Историческа перспектива и препратки

Раздел L.4 (достъпен онлайн) включва дискусия относно еволюцията на обучението
комплекти и включва препратки за по-нататъшно четене и изследване на свързани теми.
Упражнения от Грегъри Д. Питърсън
A.1 [15] <A.9> Изчислете ефективния CPI за MIPS, като използвате фигура A.27. Да предположим, че ние
са направили следните измервания на средния CPI за типове инструкции:
Инструкция Цикли на часовника
Всички ALU инструкции 1.0
Товари-магазини 1.4
Условни клонове
Взета 2.0
Не е взето 1.5
скокове 1.2
Да приемем, че 60% от условните разклонения са взети и че всички инструкции в категорията
„други“ на фигура A.27 са ALU инструкции. Осреднете

честоти на инструкциите на gap и gcc за получаване на микса от инструкции.
A.2 [15] <A.9> Изчислете ефективния CPI за MIPS, като използвате Фигура A.27 и таблицата
по-горе. Осреднете честотите на инструкциите на gzip и perlbmk, за да получите
микс от инструкции.
A.3 [20] <A.9> Изчислете ефективния CPI за MIPS, като използвате фигура A.28. Да предположим, че ние
са направили следните измервания на средния CPI за типове инструкции:
Инструкция Цикли на часовника
Всички ALU инструкции 1.0
Товари-магазини 1.4
Условни разклонения:
Взета 2.0
Не е взето 1.5
скокове 1.2
FP умножение 6.0
FP доп 4.0
FP разделение 20.0
Заредете FP 1.5
Други FP 2.0
Да приемем, че 60% от условните разклонения са взети и че всички инструкции в

категорията „други“ на фигура A.28 са ALU инструкции. Осреднете честотите на инструкциите
на lucas и плувайте, за да получите микса от инструкции.
A.4 [20] <A.9> Изчислете ефективния CPI за MIPS, като използвате фигура A.28 и таблицата по-горе.
Осреднете честотите на инструкциите на applu и art, за да получите микса от инструкции.
A.5 [10] <A.8> Разгледайте тази кодова последователност на високо ниво от три израза:
A = B + C;
B = A + C;
D = A – B;
Използвайте техниката на копиране на разпространение (вижте Фигура A.20) , за да

трансформирате кодовата последователност до точката, в която нито един операнд не е изчислена
стойност. Обърнете внимание на случаите, в които преобразуването е намалило изчислителната
работа на израз и онези случаи, в които работата се е увеличила. Какво подсказва това за
техническото предизвикателство, с което се сблъскваме в опитите да се задоволи желанието за
оптимизиране на компилатори?
A.6 [30] <A.8> Оптимизациите на компилатора могат да доведат до подобрения в размера на кода
и/или производителността. Помислете за една или повече от програмите за сравнение от
пакета SPEC CPU2006. Използвайте достъпен за вас процесор и GNU C компилатора, за да
оптимизирате програмата без оптимизация, –O1, –O2 и –O3. Сравнете производителността
и размера на получените програми. Също така сравнете вашите резултати с фигура A.21.
A.7 [20/20] <A.2, A.9> Разгледайте следния фрагмент от C код:
за (i = 0; i <= 100; i++)

{ A[i] = B[i] + C; }
Да приемем, че A и B са масиви от 64-битови цели числа, а C и i са 64-битови цели

числа. Да приемем, че всички стойности на данните и техните адреси се съхраняват в
паметта (съответно на адреси 1000, 3000, 5000 и 7000 за A, B, C и i), освен когато върху тях
се работи. Да приемем, че стойностите в регистрите се губят между повторенията на
цикъла. а. [20] <A.2,
A.9> Напишете кода за MIPS. Колко инструкции се изискват динамично? Колко препратки
към данни от паметта ще бъдат изпълнени?
Какъв е размерът на кода в байтове?
b. [20] <A.2> Напишете кода за x86. Колко инструкции се изискват динамично? Колко
препратки към данни от паметта ще бъдат изпълнени? Какъв е размерът на кода в
байтове?
A.8 [10/10/10] <A.2, A.7> За следното разглеждаме кодиране на инструкции за

архитектури на набори от инструкции.
а. [10] <A.2, A.7> Да разгледаме случая на процесор с дължина на инструкцията 12 бита и с 32

регистъра с общо предназначение, така че размерът на адресните полета да е 5 бита.
Възможно ли е да има кодирани инструкции за следното?
3 двуадресни инструкции
30 едноадресни инструкции
45 инструкции с нулев адрес
b. [10] <A.2, A.7> Приемане на една и съща дължина на инструкциите и размери на адресните полета
както по-горе, определете дали е възможно да имате
3 двуадресни инструкции
31 едноадресни инструкции
35 инструкции с нулев адрес
Обяснете отговора си.
° С. [10] <A.2, A.7> Да приемем същата дължина на инструкцията и размери на адресното

поле, както по-горе. Освен това приемете, че вече има 3 инструкции с два адреса и 24
инструкции с нулев адрес. Какъв е максималният брой едноадресни инструкции, които
могат да бъдат кодирани за този процесор?
A.9 [10/15] <A.2> За следното приемем, че стойностите A, B, C, D, E и F се намират в паметта. Също

така приемете, че кодовете на операциите с инструкции са представени в 8 бита, адресите на
паметта са 64 бита, а адресите на регистрите са 6 бита. а. [10] <A.2> За
всяка архитектура на набор от инструкции, показана на фигура A.2, колко адреса или имена
се появяват във всяка инструкция за кода за изчисляване на C = A + B и какъв е общият
размер на кода?
b. [15] <A.2> Някои от архитектурите на набора от инструкции на фигура A.2 унищожават

операндите в хода на изчислението. Тази загуба на стойности на данни от вътрешната
памет на процесора има последици за производителността. За всяка архитектура на
фигура A.2 напишете кодовата последователност за изчисляване:
C=A+B
D=A–E
F=C+D
Във вашия код маркирайте всеки операнд, който е унищожен по време на

изпълнение, и маркирайте всяка „режимна“ инструкция, която е включена, само за да
преодолеете тази загуба на данни от вътрешната памет на процесора. Какъв е общият
размер на кода, броят на байтовете инструкции и данни, преместени към или от паметта,
броят на командните инструкции и броят на байтовете на служебните данни за всяка от
вашите кодови последователности?
A.10 [20] <A.2, A.7, A.9> Дизайнът на MIPS предвижда 32 регистъра с общо предназначение и 32
регистъра с плаваща запетая. Ако регистрите са добри, по-добри ли са повече регистри?
Избройте и обсъдете възможно най-много компромиси, които трябва да бъдат взети под
внимание от дизайнерите на архитектурата на набора от инструкции, които проучват дали и
колко да увеличат броя на MIPS регистрите.
A.11 [5] <A.3> Да разгледаме C структура, която включва следните членове: struct foo
{ char a; bool b;
int c;
двойно d;
кратко
е; поплавък
f; двойно
g; char *
cptr; float *
fptr; int x;
};
За 32-битова машина какъв е размерът на структурата foo? Какъв е минималният размер,

необходим за тази структура, ако приемем, че можете да подредите реда на членовете на
структурата, както желаете? Какво ще кажете за 64-битова машина?
A.12 [30] <A.7> Много производители на компютри сега включват инструменти или симулатори, които
ви позволяват да измервате използването на набора от инструкции на потребителска
програма. Сред използваните методи са машинна симулация, хардуерно поддържано
прихващане и техника на компилатор, която инструментира модула на обектния код чрез вмъкване на броячи.
Намерете достъпен за вас процесор, който включва такъв инструмент. Използвайте го, за да
измерите набора от инструкции за един от тестовете за сравнение на SPEC CPU2006. Сравнете
резултатите с показаните в тази глава.
A.13 [30] <A.8> По-новите процесори като i7 Sandy Bridge на Intel включват поддръжка за AVX векторни/
мултимедийни инструкции. Напишете функция за умножение с плътна матрица, като
използвате стойности с единична точност и я компилирайте с различни компилатори и
флагове за оптимизация. Кодовете за линейна алгебра, използващи подпрограма за основна
линейна алгебра (BLAS), като SGEMM, включват оптимизирани версии на плътно матрично
умножение. Сравнете размера на кода и производителността на вашия код с този на BLAS
SGEMM. Разгледайте какво се случва, когато използвате стойности с двойна точност и DGEMM.
A.14 [30] <A.8> За SGEMM кода, разработен по-горе за i7 процесора, включете използването на AVX
intrinsics за подобряване на производителността. По-специално, опитайте да векторизирате
кода си, за да използвате по-добре хардуера на AVX. Сравнете размера на кода и
производителността с оригиналния код.
A.15 [30] <A.7, A.9> SPIM е популярен симулатор за симулиране на MIPS процесори.
Използвайте SPIM за измерване на набора от инструкции за някои SPEC CPU2006 бенчмарк
програми.
A.16 [35/35/35/35] <A.2–A.8> gcc е насочен към повечето модерни архитектури на набори от инструкции
(вижте www.gnu.org/software/gcc/). Създайте версия на gcc за няколко архитектури, до които
имате достъп, като x86, MIPS, PowerPC и ARM. а. [35] <A.2–A.8> Компилирайте
подмножество от целочислени бенчмаркове SPEC CPU2006 и създайте таблица с размери на

кода. Коя архитектура е най-добра за всяка програма?
b. [35] <A.2–A.8> Компилирайте подмножество от SPEC CPU2006 бенчмаркове с плаваща запетая и

създайте таблица с размери на кода. Коя архитектура е най-добра за всеки
програма?
° С. [35] <A.2–A.8> Компилирайте подмножество от EEMBC AutoBench бенчмаркове (вж.

www.eembc.org/home.php) и създайте таблица с размери на кодове. Коя архитектура е най-добра
за всяка програма?
д. [35] <A.2–A.8> Компилирайте подмножество от EEMBC FPBench бенчмаркове с плаваща запетая и

създайте таблица с размери на кода. Коя архитектура е най-добра за всеки
програма?
A.17 [40] <A.2–A.8> Енергийната ефективност стана много важна за съвременните процесори, особено за
вградените системи. Създайте версия на gcc за две архитектури, до които имате достъп, като x86, MIPS,
PowerPC и ARM. Компилирайте
подмножество от EEMBC бенчмаркове, докато използвате EnergyBench за измерване на енергия
използване по време на изпълнение. Сравнете размера на кода, производителността и потреблението на енергия за
процесорите. Кое е най-доброто за всяка програма?
A.18 [20/15/15/20] Вашата задача е да сравните ефективността на паметта на четири различни

стилове архитектури на набори от инструкции. Архитектурните стилове са
Акумулатор—Всички операции се извършват между единичен регистър и памет-

или местоположение.
Памет-памет—всички адреси на инструкции се отнасят само до местоположението на паметта

ции.
Стек—Всички операции се извършват в горната част на стека. Push и pop са единствените

инструкции за достъп до паметта; всички останали премахват своите операнди от
стек и ги заменете с резултата. Внедряването използва твърдо свързан стек само за горните
два записа в стека, което запазва процесора
верига много малка и ниска цена. Допълнителните позиции на стека се запазват
местоположения в паметта и достъпът до тези позиции в стека изисква памет
препратки.
Load-store—Всички операции се извършват в регистри и от регистър към регистър в

инструкциите имат три имена на регистър на инструкция.
За да измерите ефективността на паметта, направете следните допускания за всички

четири набора инструкции:
Всички инструкции са цял брой байтове по дължина.
Операционният код винаги е един байт (8 бита).
Достъпите до паметта използват директно или абсолютно адресиране.
Променливите A, B, C и D първоначално са в паметта.
а. [20] <A.2, A.3> Измислете своя собствена мнемоника на асемблерния език (Фигура A.2
предоставя полезна извадка за обобщаване) и за всяка архитектура напишете
най-добрият еквивалентен асемблерен езиков код за тази последователност от езикови кодове на

високо ниво:
A = B + C;
B = A + C;
D = A – B;
b. [15] <A.3> Етикетирайте всеки екземпляр във вашите асемблиращи кодове за част (a), където
дадена стойност се зарежда от паметта, след като е била заредена веднъж. Също така
маркирайте всеки екземпляр във вашия код, където резултатът от една инструкция се
предава на друга инструкция като операнд, и допълнително класифицирайте тези събития
като включващи съхранение в процесора или съхранение в паметта.
° С. [15] <A.7> Да приемем, че дадената кодова последователност е от малко, вградено

компютърно приложение, като например контролер за микровълнова фурна, което
използва 16-битов адрес на паметта и операнди с данни. Ако се използва архитектура
за зареждане, приемете, че има 16 регистъра с общо предназначение. За всяка
архитектура отговорете на следните въпроси: Колко байта инструкции се извличат?
Колко байта данни се прехвърлят от/към паметта? Коя архитектура е най-ефективна,
измерена чрез общия трафик на паметта (код + данни)?
д. [20] <A.7> Сега приемете процесор с 64-битови адреси на паметта и операнди за данни.
За всяка архитектура отговорете на въпросите от част (c). Как са се променили
относителните предимства на архитектурите за избраните показатели?
A.19 [30] <A.2, A.3> Използвайте четирите различни стила на архитектура на набора от инструкции
от по-горе, но приемете, че поддържаните операции с памет включват индиректно и
директно адресиране на регистъра. Измислете своя собствена мнемоника на асемблерния
език (Фигура A.2 предоставя полезна проба за обобщаване) и за всяка архитектура
напишете най-добрия еквивалентен код на асемблерния език за този фрагмент от C код:
за (i = 0; i <= 100; i++)

{ A[i] = B[i] + C; }
Да приемем, че A и B са масиви от 64-битови цели числа, а C и i са 64-битови цели

числа.
Втората и третата колона съдържат кумулативния процент на препратките към данни
и съответно разклоненията, които могат да бъдат приспособени със съответния брой
битове на величината в изместването. Това са средните разстояния на всички програми с
цели числа и с плаваща запетая на фигури A.8 и A.15.
A.20 [20/20/20] <A.3> Ние проектираме формати на набор от инструкции за архитектура за

зареждане и се опитваме да решим дали си струва да имаме множество дължини на
отместване за разклонения и препратки към паметта. Дължината на една инструкция ще
бъде равна на 16 бита + дължина на отместването в битове, така че ALU инструкциите ще бъдат 16 бита.
Фигура A.31 съдържа данни за размера на отместването за Alpha архитектурата с пълна
оптимизация за SPEC CPU2000. За честоти на набор от инструкции използвайте данните
за MIPS от средната стойност на петте показателя за машината за зареждане и съхранение
на фигура A.27. Да приемем, че различните инструкции са всички ALU инструкции, които
използват само регистри.
Брой битове на Препратки към
величината на отместването кумулативни данни Кумулативни клонове
0 30,4% 0,1%
1 33,5% 2,8%
2 35,0% 10,5%
3 40,0% 22,9%
4 47,3% 36,5%
5 54,5% 57,4%
6 60,4% 72,4%
7 66,9% 85,2%
8 71,6% 90,5%
9 73,3% 93,1%
10 74,2% 95,1%
11 74,9% 96,0%
12 76,6% 96,8%
13 87,9% 97,4%
14 91,9% 98,1%
15 100% 98,5%
16 100% 99,5%
17 100% 99,8%
18 100% 99,9%
19 100% 100%
20 100% 100%
21 100% 100%
Фигура A.31 Данни за размера на отместването за Alpha архитектурата с пълна оптимизация за

SPEC CPU2000.
а. [20] <A.3> Да предположим, че отместванията са разрешени да бъдат с дължина 0, 8, 16 или 24 бита,
включително знаковия бит. Каква е средната дължина на една изпълнена инструкция?
b. [20] <A.3> Да предположим, че искаме инструкция с фиксирана дължина и сме избрали 24-битова
дължина на инструкцията (за всичко, включително ALU инструкции). За всеки
отместване по-дълго от 8 бита, са необходими допълнителни инструкции. Определи
броя на байтовете инструкции, извлечени в тази машина с фиксирана инструкция
размер спрямо тези, извлечени с инструкция за размер на байт-променлива, както е дефинирано в
част (а).
° С. [20] <A.3> Сега да предположим, че използваме фиксирана дължина на отместването от 24 бита, така че не
винаги са необходими допълнителни инструкции. Колко байта инструкции биха били
изисква се? Сравнете този резултат с вашия отговор на част (b).
A.21 [20/20] <A.3, A.6, A.9> Размерът на стойностите на изместване, необходими за режима на адресиране с изместване
или за PC-относително адресиране, може да бъде извлечен от ком.

натрупани приложения. Използвайте разглобяващ инструмент с един или повече от SPEC CPU2006
бенчмаркове, компилирани за MIPS процесора. а. [20]
<A.3, A.9> За всяка инструкция, използваща адресиране на изместване, запишете използваната

стойност на изместване. Създайте хистограма на стойностите на изместване.
Сравнете резултатите с тези, показани в тази глава на фигура A.8. b. [20] <A.6,
A.9> За всяка инструкция за разклоняване, използваща PC-относително адресиране, запишете

използваната стойност на изместване. Създайте хистограма на стойностите на изместване.
Сравнете резултатите с тези, показани в тази глава на фигура A.15.
A.22 [15/15/10/10] <A.3> Стойността, представена от шестнадесетичното число 434F

4D50 5554 4552 трябва да се съхранява в подравнена 64-битова двойна дума. а.
[15] <A.3> Използвайки физическото подреждане на първия ред на фигура A.5, запишете стойността,
която трябва да се съхрани, като използвате реда на байтовете Big Endian. След това
интерпретирайте всеки байт като ASCII знак и под всеки байт напишете съответния знак-
актер, образувайки символния низ, както би бил съхранен в Big Endian ред.
b. [15] <A.3> Използвайки същата физическа подредба като в част (a), напишете стойността, която
да бъде съхранена, като използвате Little Endian ред на байтовете и под всеки байт напишете
съответния ASCII знак.
° С. [10] <A.3> Какви са шестнадесетичните стойности на всички неподравнени 2-байтови думи,

които могат да бъдат прочетени от дадената 64-битова двойна дума, когато се съхраняват в
ред на байтовете Big Endian?
д. [10] <A.3> Какви са шестнадесетичните стойности на всички неподравнени 4-байтови думи, които
могат да бъдат прочетени от дадената 64-битова двойна дума, когато се съхраняват в Little
Endian ред на байтовете?
A.23 [Дискусия] <A.2–A.12> Помислете за типични приложения за десктоп, сървър, облак и вградени
компютри. Как ще се отрази архитектурата на набора от инструкции за машини, насочени към
всеки от тези пазари?

Б.1 Въведение Б-2
Б.2 Ефективност на кеша Б-16
Б.3 Шест основни оптимизации на кеша Б-22
Б.4 Виртуална памет Б-40

Б.5 Защита и примери за виртуална памет Б-49
B.6 Заблуди и клопки Б-57
Б.7 Заключителни бележки Б-59

Б.8 Историческа перспектива и препратки Б-59
Упражнения от Амр Заки Б-60

б
Преглед на йерархията на паметта 1
Кеш: безопасно място за скриване или съхранение на неща.
Webster's New World Dictionary of the

американски език
Второ колежско издание (1976)
B-2 Приложение B Преглед на йерархията на паметта
Б.1 Въведение
Това приложение е бързо опресняване на йерархията на паметта, включително основите
на кеш и виртуална памет, уравнения за производителност и прости оптимизации.
Този първи раздел разглежда следните 36 термина:
кеш памет напълно асоциативно напишете разпределете
виртуална памет отместване унифициран кеш
цикъл на спиране на паметта на мръсен битов блок пропуски на инструкция
директно картографиран пиша в отговор на писмо блок
валиден бит кеш данни местност
блок адрес хитово време следа на адреса
презаписване кеш пропуск комплект
кеш инструкции страница грешка произволна замяна
среден процент на пропуски при време за достъп до паметта индексно поле
кеш хит n-way set асоциативно разпределение без запис
страница най-скоро използвано буфер за запис
пропуск дузпа поле за етикет пишете срив
Ако този преглед върви твърде бързо, може да искате да погледнете Глава 7 в Компютър
Организация и дизайн, който написахме за читатели с по-малко опит.
Кешът е името, дадено на най-високото или първо ниво на йерархията на паметта
се среща, след като адресът напусне процесора. Тъй като принципът на местността
се прилага на много нива и се възползва от локалността за подобряване на производителността
е популярен, терминът кеш сега се прилага винаги, когато се използва буфериране
повторно използване на често срещани елементи. Примерите включват файлови кешове, кешове на имена,
и така нататък.
Когато процесорът намери искан елемент от данни в кеша, той се нарича a
кеш хит. Когато процесорът не намери елемент от данни, от който се нуждае в кеша, a
възниква пропуск в кеша . Колекция от данни с фиксиран размер, съдържаща исканата дума,
наречен блок или ред, се извлича от основната памет и се поставя в
кеш памет. Темпоралното местоположение ни казва, че е вероятно да имаме нужда от тази дума отново в
близко бъдеще, така че е полезно да го поставите в кеша, където може да бъде достъпен
бързо. Поради пространствената локализация има голяма вероятност другите данни

в блока скоро ще са необходими.
Времето, необходимо за пропуск на кеша, зависи както от латентността, така и от честотната лента на
паметта. Латентността определя времето за извличане на първата дума от

блок, а честотната лента определя времето за извличане на останалата част от този блок. А
пропуснатият кеш се обработва от хардуер и кара процесорите да използват изпълнение в ред
за пауза или спиране, докато данните са налични. С извънредно изпълнение ан

B.1 Въведение B-3
Ниво 1 2 3 4
Име Регистри Кеш памет Главна памет Дисково съхранение
Типичен размер <1 KB 32 KB–8 MB <512 GB >1 TB
Технология на изпълнение Персонализирана памет с Вграден CMOS CMOS DRAM Магнитен диск
множество портове, CMOS SRAM
Време за достъп (ns) 0,15–0,30 0,5–15 30–200 5 000 000
Честотна лента (MB/сек) 100 000–1 000 000 10 000–40 000 5000–20 000 50–500
Управляван от Компилатор Хардуер Операционна система

система/
оператор
Подкрепен от Кеш памет Главна памет диск Други

дискове и DVD
Фигура B.1 Типичните нива в йерархията се забавят и стават по-големи, докато се отдалечаваме от процесора за
голяма работна станция или малък сървър. Вградените компютри може да нямат дисково съхранение и много по-малки памети
и кешове. Времето за достъп се увеличава с преминаването към по-ниските нива на йерархията, което го прави възможно за управление
трансферът е по-малко отзивчив. Технологията на изпълнение показва типичната технология, използвана за тези функции. Времето за достъп
е дадено в наносекунди за типични стойности през 2006 г.; тези времена ще намалеят с времето. Ширината на лентата е дадена в мегабайти в
секунда между нивата в йерархията на паметта. Честотна лента за съхранение на диск
включва както медиите, така и буферираните интерфейси.
инструкцията, използваща резултата, все още трябва да чака, но други инструкции могат да продължат по
време на пропуска.
По същия начин не всички обекти, посочени от програма, трябва да се намират в main
памет. Виртуалната памет означава, че някои обекти могат да се намират на диска. Адресът
пространството обикновено се разделя на блокове с фиксиран размер, наречени страници. По всяко време, всеки
страницата се намира или в основната памет, или на диска. Когато процесорът препраща към an
елемент в рамките на страница, който не присъства в кеша или основната памет, се появява грешка ,
и цялата страница се премества от диска в основната памет. От грешка на страницата
отнемат толкова време, обработват се софтуерно и процесорът не спира. The
процесорът обикновено превключва към някаква друга задача, докато има достъп до диска. от
гледна точка от високо ниво, разчитането на локалността на препратките и относителното
взаимоотношенията в размера и относителната цена на бит кеш спрямо основната памет са
подобни на тези на основната памет срещу диска.
Фигура B.1 показва диапазона от размери и времена за достъп на всяко ниво в
йерархия на паметта за компютри, вариращи от настолни компютри от висок клас до нисък клас
сървъри.
Преглед на ефективността на кеша
Поради локалността и по-високата скорост на по-малките памети, йерархията на паметта може значително
да подобри производителността. Един метод за оценка на производителността на кеша е да разширим
нашето уравнение за времето за изпълнение на процесора от глава 1.

Сега отчитаме броя на циклите, през които процесорът е спрял

изчакване за достъп до паметта, което наричаме цикли на спиране на паметта. След това
производителността е произведение от времето на тактовия цикъл и сумата на процесора
цикли и цикли на спиране на паметта:
= Тактови
Време за изпълнение на CPU ( + на спиране на паметта) × Време на тактовия цикъл
цикли на CPU Цикли
Това уравнение предполага, че тактовите цикли на процесора включват времето за обработка на a

попадение в кеша и че процесорът е спрял по време на пропуск в кеша. Раздел B.2 reex-амини това
опростяващо предположение.
Броят на циклите на спиране на паметта зависи както от броя на пропуските
и цената на пропуск, която се нарича наказание за пропуск:
=
Цикли на спиране на паметта ×
Брой пропуски Пропуснете наказание
Госпожици
= IC × ------------------------ Пропусната
× дузпа
= Достъп до паметта ×
IC × ------------------------------------------------ Пропуснат процент × Пропуснато наказание
Предимството на последната форма е, че компонентите могат лесно да бъдат измерени.

Вече знаем как да измерваме броя на инструкциите (IC). (За спекулативните процесори ние броим само
инструкции, които се ангажират.) Измерване на броя на
препратките към памет за инструкция могат да бъдат направени по същия начин; всеки
инструкцията изисква достъп до инструкция и е лесно да решите дали също
изисква достъп до данни.
Обърнете внимание, че изчислихме наказанието за пропуск като средно, но ще го използваме по-долу
като че ли е константа. Паметта зад кеша може да е заета по време на
пропуска поради предишни заявки за памет или опресняване на паметта. Броят на
тактовите цикли също варират в интерфейсите между различните часовници на процесора,
шина и памет. Затова, моля, не забравяйте, че използвате едно число за пропуск
дузпата е опростяване.
Процентът на пропуски на компонента е просто частта от достъпите до кеша, които водят до
пропуск (т.е. брой достъпи, които пропускат, разделен на брой достъпи). Мис
скоростите могат да бъдат измерени с кеш симулатори, които вземат адресна следа на
инструкции и препратки към данни, симулирайте поведението на кеша, за да определите кое
референтни хитове и кои пропуски и след това докладвайте общите хитове и пропуски. Много
микропроцесори днес осигуряват хардуер за отчитане на пропуските и паметта
препратки, което е много по-лесен и по-бърз начин за измерване на процента на пропуски.
Формулата по-горе е приблизителна, тъй като честотата на пропуски и наказанията за пропуски
често са различни за четене и запис. Тактовите цикли на паметта биха могли
след това се дефинира от гледна точка на броя на достъпите до паметта на инструкция,
наказание за пропуски (в тактови цикли) за четения и записи и процент на пропуски за четения и
пише:
Тактови цикли на закъснение на паметта = IC × Четения на инструкция × Процент на пропуски при четене × Наказание за пропуски при четене
+ IC × Записва по инструкция × Процент на пропускане на запис × Наказание за пропускане на запис

Обикновено опростяваме цялата формула чрез комбиниране на четене и запис

и намиране на средните нива на пропуски и наказание за пропуски за четене и запис:
Достъп до паметта
----------------------------------------------
Тактови цикли на задържане на паметта = IC × × Пропусната ставка × Пропусната дузпа
Степента на пропуски е една от най-важните мерки за проектиране на кеша, но като

ще видим в следващите раздели, не е единствената мярка.
Пример Да приемем, че имаме компютър, където циклите на инструкция (CPI) са 1,0, когато
всички достъпи до паметта попадат в кеша. Единственият достъп до данни е зареждане и съхраняване,
и те общо 50% от инструкциите. Ако наказанието за пропуск е 25 тактови цикъла и
процентът на пропуски е 2%, колко по-бърз би бил компютърът, ако всички инструкции
кеш хитове ли бяха?
Отговор Първо изчислете производителността за компютъра, който винаги удря:
=
(Време за изпълнение на процесора, +
тактови цикли на процесора, цикли на спиране на паметта) × тактов цикъл
= ( ) IC CPI × + 0 × Тактов цикъл
= IC 1.0×Тактов
× цикъл
Сега за компютъра с истинския кеш, първо изчисляваме циклите на спиране на паметта:
= Достъп до паметта
× на пропуск × Пропусната дузпа
Цикли на спиране на паметта IC × ------------------------------------------ Честота
( = IC 1×0,5 ) +0,02
× 25 ×
= IC 0,75 ×
където средният член (1 + 0,5) представлява един достъп до инструкция и 0,5 данни
достъпи по инструкция. Общото представяне е така
Кеширане на времето за изпълнениена CPU = (IC 1.0 × + IC 0.75 ×) × Тактов цикъл
= 1,75 IC × ×
тактов цикъл
Коефициентът на производителност е обратен на времето за изпълнение:
Кеширане на времето за изпълнение на процесора ××

1.75 IC Тактов цикъл --------
-------------------------------------------------- --------- = --------------------------------------------------
Време за изпълнение на процесора × ×Тактов цикъл
1.0 IC
= 1,75
Компютърът без пропуски в кеша е 1,75 пъти по-бърз.
Някои дизайнери предпочитат измерването на процента на пропуски по-скоро като пропуски на инструкция
отколкото пропуски за справка в паметта. Тези две са свързани:
Госпожици × Достъп до паметта

------------------------ = Пропуснат процент на достъп до паметта =
-------------------------------------------------- --------------------
Пропуснат процент × ------------------------------------------------
Инструкция Брой инструкции Инструкция
Последната формула е полезна, когато знаете средния брой памет

достъпи на инструкция, тъй като ви позволява да преобразувате процент на пропуски в пропуски на
инструкция и обратно. Например, можем да обърнем процента на пропуски за памет
справка в предишния пример в пропуски на инструкция:
Госпожици Достъп до паметта

------------------------
процент
Пропуснат
= == × ------------------- -----------------------0,02 1,5 × ( ) 0,030
Инструкция Инструкция
Между другото, пропуските на инструкция често се отчитат като пропуски на 1000
инструкции за показване на цели числа вместо дроби. Следователно отговорът по-горе би могъл
също се изразява като 30 пропуска на 1000 инструкции.
Предимството на пропуските на инструкция е, че е независимо от хардуерната реализация. Например,
спекулативните процесори извличат около два пъти повече
много инструкции, както са действително ангажирани, което може изкуствено да намали
честота на пропуски, ако се измерва като пропуски на препратка към паметта, а не на инструкция.
Недостатъкът е, че пропуските на инструкция зависят от архитектурата; например, средният брой достъпи
до паметта на инструкция може да бъде много различен
за 80x86 срещу MIPS. По този начин пропуските на инструкция са най-популярни
архитекти, работещи с едно компютърно семейство, въпреки сходството на RISC
архитектурите позволяват да се даде представа за другите.
Пример За да покажем еквивалентността между двете уравнения за процент на пропуски, нека повторим примера
по-горе, като този път се приема, че процентът на пропуски на 1000 инструкции е 30. Какво е времето за
спиране на паметта по отношение на броя на инструкциите?
Отговор Повторно изчисляване на циклите на спиране на паметта:
=
Госпожици
= × ------------------------ Пропусната дузпа ×
интегрална схема
Госпожици
= IC ⁄ 1000 × -------------------------------------------- Пропуснато
× наказание
Инструкция 1000 ×
= IC ⁄ 1000 30 25 × ×
= IC ⁄ 1000 750 ×
= IC 0,75 ×
Получаваме същия отговор като на страница B-5, показващ еквивалентността на двете уравнения.
Четири въпроса за йерархията на паметта
Продължаваме нашето запознаване с кешовете, като отговаряме на четирите често срещани въпроса
за първото ниво на йерархията на паметта:
Q1: Къде може да се постави блок в горното ниво? (блоково разположение)
Q2: Как се намира блок, ако е в горното ниво? (идентификация на блок)
Q3: Кой блок трябва да бъде заменен при пропуск? (смяна на блок)
Q4: Какво се случва при запис? (напишете стратегия)

Отговорите на тези въпроси ни помагат да разберем различните компромиси на спомените на

различните нива на йерархията; следователно задаваме тези четири въпроса за всеки пример.
Q1: Къде може да се постави блок в кеш?
Фигура B.2 показва, че ограниченията върху мястото, където се поставя блокът, създават три категории
организация на кеша:
Ако всеки блок има само едно място, то може да се появи в кеша, казва се, че кешът
да бъдат директно картографирани. Картографирането обикновено е
(Адрес на блок) MOD (Брой блокове в кеша)
Ако блок може да бъде поставен навсякъде в кеша, се казва, че кешът е пълен
асоциативен.
Ако даден блок може да бъде поставен в ограничен набор от места в кеша, кешът се задава
асоциативно. Наборът е група от блокове в кеша . Един блок първо се нанася върху набор и след
това блокът може да бъде поставен навсякъде в този набор.
Наборът обикновено се избира чрез избор на битове; това е,
(Блокиране на адрес) MOD (Брой набори в кеша)
Ако има n блока в набор, разположението на кеша се нарича асоциативно на n-way set.
Обхватът на кешовете от директно картографирани до напълно асоциативни е наистина континуум от

нива на асоциативност на набора. Директното картографиране е просто еднопосочен набор
асоциативен, а напълно асоциативен кеш с m блока може да се нарече „m-way set асоциативен“.
Еквивалентно, директно картографираните могат да се разглеждат като притежаващи m набора, а
напълно асоциативните като притежаващи един набор.
По-голямата част от кеша на процесора днес са директно картографирани, двупосочни
асоциативен, или четирипосочен набор асоциативен, по причини, които ще видим скоро.
Q2: Как се намира блок, ако е в кеша?
Кешовете имат адресен таг на всеки блоков кадър, който дава адреса на блока. Етикетът на всеки кеш
блок, който може да съдържа желаната информация, се проверява, за да се види дали съвпада с адреса
на блока от процесора. По правило всички възможни етикети се търсят паралелно, защото скоростта
е критична.
Трябва да има начин да разберете, че кеш блокът няма валидна информация. Най-честата
процедура е да добавите валиден бит към тага, за да кажете дали този запис съдържа или не валиден
адрес. Ако битът не е зададен, не може да има съвпадение на този адрес.
Преди да преминем към следващия въпрос, нека проучим връзката на адреса на процесора с
кеша. Фигура B.3 показва как се разделя адрес.
Първото разделение е между адреса на блока и отместването на блока. Блокът
Напълно асоциативен: Директно нанесено: Задайте асоциативно:
блок 12 може да блок 12 може да блок 12 може да

отиде навсякъде влезе само в блок 4 отиде навсякъде в набор 0
(12 MOD 8) (12 MOD 4)
Блок 01234567 Блокирайте 01234567 Блокирайте 01234567

не. не. не.
Кеш памет
Комплект Задайте Комплект Комплект
01 2 3
Адрес на блокова рамка

Блокирайте 111111111122222222223301234567890123456
не. 789012345678901
памет
Фигура B.2 Този примерен кеш има осем блокови кадъра, а паметта има 32 блока.
Трите опции за кешове са показани отляво надясно. В напълно асоциативен блок 12 от по-
ниското ниво може да влезе във всеки от осемте блокови кадъра на кеша. При директно
картографиране блок 12 може да бъде поставен само в блоков кадър 4 (12 по модул 8).
Асоциативният набор, който има някои от двете функции, позволява блокът да бъде поставен
навсякъде в набор 0 (12 по модул 4). С два блока на комплект, това означава, че блок 12 може да
бъде поставен или в блок 0, или в блок 1 на кеша. Реалните кешове съдържат хиляди блокови
кадри, а реалните спомени съдържат милиони блокове. Асоциативната организация на
множеството има четири комплекта с два блока на комплект, наречени двупосочни асоциативни
набори. Да приемем, че няма нищо в кеша и че въпросният адрес на блок идентифицира блок 12 от по-ниско ниво.
адресът на рамката може да бъде допълнително разделен на поле за етикет и поле за

индекс. Полето за отместване на блок избира желаните данни от блока, полето за
индекс избира набора и полето за етикет се сравнява с него за попадение. Въпреки
че сравнението може да се направи на повече от адреса, отколкото на етикета, няма
нужда поради следното:
Отместването не трябва да се използва при сравнението, тъй като целият блок присъства
или не, и следователно всички блокови отмествания водят до съвпадение по
дефиниция. Проверката на индекса е излишна, тъй като той е бил използван за избор на
набора за проверка. Адрес, съхранен в набор 0, например, трябва да има 0 в полето за
индекс или не може да бъде съхранен в набор 0; набор 1 трябва да има стойност на
индекс 1; и така нататък. Тази оптимизация спестява хардуер и енергия чрез намаляване
на ширината на размера на паметта за кеша.
Блокиране на адрес Блок
Етикет Индекс офсет
Фигура B.3 Трите части на адрес в асоциативен или директно картографиран кеш. Тагът
се използва за проверка на всички блокове в набора, а индексът се използва за избор на
набора. Отместването на блока е адресът на желаните данни в блока. Напълно
асоциативните кешове нямат индексно поле.
Ако общият размер на кеша се запази същият, увеличаването на асоциативността увеличава броя
на блоковете на набор, като по този начин намалява размера на индекса и увеличава размера на
етикета. Това означава, че границата на индекса на етикета на фигура B.3 се премества надясно с
нарастваща асоциативност, като крайната точка на напълно асоциативните кешове няма поле за
индекс.
Въпрос 3: Кой блок трябва да бъде заменен при пропуск в кеша?
Когато възникне пропуск, кеш контролерът трябва да избере блок, който да бъде заменен с
желаните данни. Предимството на директно картографираното разположение е, че хардуерните
решения са опростени – всъщност толкова прости, че няма избор: само един блоков кадър се
проверява за попадение и само този блок може да бъде заменен. При напълно асоциативно или
зададено асоциативно разположение има много блокове, от които да избирате при пропуск. Има
три основни стратегии, използвани за избор кой блок да бъде заменен:
Случайно—За да се разпредели равномерно разпределението, кандидат блоковете се избират на

случаен принцип. Някои системи генерират псевдослучайни номера на блокове, за да получат
възпроизводимо поведение, което е особено полезно при отстраняване на грешки в
хардуера. Най-малко използвано наскоро (LRU)—За да се намали вероятността от изхвърляне на

информация, която скоро ще бъде необходима, достъпите до блокове се записват. Разчитайки
на миналото за предсказване на бъдещето, замененият блок е този, който е бил неизползван
най-дълго време. LRU разчита на следствие от местоположението: Ако има вероятност наскоро
използвани блокове да бъдат използвани отново, тогава добър кандидат за изхвърляне е най-
малко използваният наскоро блок.
Първи влязъл, първи излязъл (FIFO)—Тъй като LRU може да бъде сложен за изчисляване, това
приближава LRU чрез определяне на най-стария блок, а не на LRU.
Добродетелта на произволната подмяна е, че е лесно да се вгради хардуер. Тъй като броят на

блоковете за проследяване се увеличава, LRU става все по-скъп и обикновено е само приблизителен.
Общата апроксимация (често наричана псевдо-LRU) има набор от битове за всеки набор в кеша,
като всеки бит съответства на един начин (пътят е банка в асоциативен кеш на набор; има четири
начина в четирипосочния задаване на асоциативен кеш) в кеша. Когато се осъществи достъп до
набор, битът, съответстващ на начина, съдържащ желания блок, се включва; ако всички битове,
свързани с набор, са включени, те се нулират с изключение на последния включен бит. Когато
трябва да се смени блок,
Асоциативност
Двупосочен Четирипътен Осемпосочен
Размер LRU Произволен FIFO LRU Случаен FIFO LRU Случаен FIFO
16 KB 114.1 117.3 115.5 111.7 115.1 113.3 109,0 111.8 110.4
64 KB 103.4 104.3 103.9 102.4 102.3 103.1 99.7 100.5 100.3
256 KB 92.2 92.1 92.5 92.1 92.1 92.5 92.1 92.1 92.5
Фигура B.4 Пропуски в кеша на данни на 1000 инструкции, сравняващи най-малко използвани, произволни и първи влезли, първи излезли
замяна на няколко размера и асоциативности. Има малка разлика между LRU и случаен за най-големия
размер на кеша, като LRU превъзхожда останалите за по-малки кешове. FIFO обикновено превъзхожда произволните в по-малките
размери на кеша. Тези данни бяха събрани за размер на блок от 64 байта за архитектурата Alpha, използвайки 10 SPEC2000
бенчмаркове. Пет са от SPECint2000 (gap, gcc, gzip, mcf и perl) и пет са от SPECfp2000 (applu, art,
равнявай се, Лукас и плувай). Ще използваме този компютър и тези бенчмаркове в повечето фигури в това приложение.
процесорът избира блок от пътя, чийто бит е изключен, често произволно

ако има повече от един избор. Това се доближава до LRU, тъй като блокът
който е заменен, няма да има достъп от последния път, когато всички блокове
в комплекта бяха достъпни. Фигура B.4 показва разликата в процентите на пропуски между
LRU, произволна и FIFO замяна.
Q4: Какво се случва при запис?
Четенето доминира при достъпа до кеша на процесора. Всички достъпи до инструкции са четене и
повечето инструкции не записват в паметта. Фигури A.32 и A.33 в Приложение A
предлага микс от 10% съхранява и 26% зареждания за MIPS програми, правейки записи
10%/(100% + 26% + 10%) или около 7% от общия трафик на паметта. От
трафик на кеш данни , записите са 10%/(26% + 10%) или около 28%. Ускоряването на общия случай
означава оптимизиране на кеш паметта за четене, особено след като процесорите традиционно чакат
четенията да завършат, но не е необходимо да чакат записите. Законът на Амдал
(Раздел 1.9) обаче ни напомня, че дизайните с висока производителност не могат да бъдат пренебрегнати
скоростта на писане.
За щастие, обикновеният случай е и лесният случай за бързо приготвяне. Блокът
може да се чете от кеша едновременно с четенето и сравняването на етикета, така че
четенето на блока започва веднага щом адресът на блока е наличен. Ако прочетеното е хит,
исканата част от блока се предава незабавно на процесора. Ако е а
госпожице, няма полза, но също така и няма вреда, освен повече мощност в работния плот и
сървърни компютри; просто игнорирайте прочетената стойност.
Такъв оптимизъм не е позволен за писане. Модифицирането на блок не може да започне

докато етикетът не бъде проверен, за да се види дали адресът е хит. Тъй като проверката на тагове не може
се случват паралелно, записите обикновено отнемат повече време от четенията. Друга сложност е
че процесорът също определя размера на записа, обикновено между 1 и 8
байтове; само тази част от блок може да бъде променена. За разлика от това, четенето има достъп
повече байтове от необходимото без страх.
Политиките за запис често разграничават дизайна на кеша. Има две основни

опции при запис в кеша:
Записване – информацията се записва както в блока в кеша, така и в

към блока в паметта от по-ниско ниво.
Обратно записване— Информацията се записва само в блока в кеша. Модифицираният кеш блок се
записва в основната памет само когато бъде заменен.
За да се намали честотата на обратно записване на блокове при замяна, обикновено се използва

функция, наречена мръсен бит . Този бит за състояние показва дали блокът е мръсен (променен,
докато е в кеша) или чист (не е модифициран). Ако е чист, блокът не се записва обратно при пропуск,
тъй като в по-ниските нива се намира идентична информация за кеша.
Както обратното записване, така и повторното записване имат своите предимства. При обратното
записване записите се извършват със скоростта на кеш паметта, а многократните записи в рамките на
блок изискват само едно записване в паметта от по-ниско ниво. Тъй като някои записи не отиват в
паметта, обратното записване използва по-малко честотна лента на паметта, което прави обратното
записване привлекателно в мултипроцесорите. Тъй като обратното записване използва останалата част
от йерархията на паметта и свързването на паметта по-малко от записването, то също така пести
енергия, което го прави привлекателен за вградени приложения.
Записването е по-лесно за изпълнение от обратното записване. Кешът винаги е чист, така че за
разлика от пропуските при четене при обратно записване никога не водят до записи на по-ниско ниво.
Записването също има предимството, че следващото по-ниско ниво има най-актуалното копие на
данните, което опростява кохерентността на данните. Кохерентността на данните е важна за
мултипроцесорите и за I/O, което разглеждаме в Глава 4 и Приложение D.
Многостепенните кешове правят записа по-жизнеспособен за кешовете от по-високо ниво, тъй като
записите трябва да се разпространяват само до следващото по-ниско ниво, а не чак до основната
памет.
Както ще видим, входно-изходните и мултипроцесорите са непостоянни: те искат обратно
записване за кеш паметта на процесора, за да намалят трафика на паметта, и записване, за да
поддържат кеша в съответствие с по-ниските нива на йерархията на паметта.
Когато процесорът трябва да изчака записите да завършат по време на записа, се казва, че
процесорът записва в застой. Обща оптимизация за намаляване на спиранията при запис е буфер за
запис, който позволява на процесора да продължи веднага щом данните се запишат в буфера, като
по този начин припокрива изпълнението на процесора с актуализирането на паметта. Както ще
видим скоро, може да възникне спиране на запис дори при буфери за запис.
Тъй като данните не са необходими при запис, има две опции при a
пишете мис:
Разпределяне на запис— Блокът се разпределя при пропуск на запис, последван от действията за

попадение при запис по-горе. В тази естествена опция пропуските при запис действат като
пропуски при четене. Разпределение без запис—Тази очевидно необичайна алтернатива е, че

пропуските при запис не засягат кеша. Вместо това блокът се модифицира само в паметта от по-ниско ниво.
По този начин блоковете остават извън кеша при разпределение без запис, докато програмата не се
опита да прочете блоковете, но дори блокове, които са само записани, все още ще бъдат в кеша с
разпределение за запис. Нека разгледаме един пример.
Пример Да приемем напълно асоциативен кеш за обратно записване с много записи в кеша, който започва празен. По-
долу е поредица от пет операции с памет (адресът е в квадратни скоби):
Напишете Mem[100];
Напишете Mem[100];
Прочетете Mem [200];
Напишете Mem [200];
Напишете Mem[100].
Какъв е броят на попаденията и пропуските при използване на разпределение без запис спрямо
разпределение на запис?
Отговор За разпределение без запис, адресът 100 не е в кеша и няма разпределение при запис, така че първите две
записвания ще доведат до пропуски. Адрес 200 също не е в кеша, така че четенето също е пропуск.
Последващото записване на адрес 200 е хит. Последният запис до 100 все още е пропуск. Резултатът за
разпределение без запис е четири пропуска и едно попадение.
За разпределяне на запис, първите достъпи до 100 и 200 са пропуски, а останалите са хитове, тъй
като и 100, и 200 са открити в кеша. По този начин резултатът за разпределение на запис е две пропуски
и три попадения.
Или политиката за пропускане на запис може да се използва с запис чрез или обратно запис.
Обикновено кешовете за обратно записване използват разпределение за запис, надявайки се, че
следващите записи в този блок ще бъдат уловени от кеша. Кешовете за запис често използват
разпределение без запис. Причината е, че дори ако има последващи записи в този блок, записите все
още трябва да отиват в паметта от по-ниско ниво, така че какво ще спечелите?
Пример: Кешът за данни на Opteron
За да даде съдържание на тези идеи, Фигура B.5 показва организацията на кеша за данни в
микропроцесора AMD Opteron. Кешът съдържа 65 536 (64 K) байта данни в 64-байтови блокове с
двупосочно зададено асоциативно разположение, най-малко използвана замяна, обратно записване
и разпределяне на запис при пропуск на запис.
Нека проследим попадение в кеша през стъпките на попадение, както е обозначено на фигура B.5.
(Четирите стъпки са показани като оградени числа.) Както е описано в Раздел B.5, Opteron представя 48-
битов виртуален адрес на кеша за сравнение на тагове, който едновременно се транслира в 40-битов
физически адрес.
Причината Opteron да не използва всичките 64 бита виртуален адрес е, че неговите дизайнери
не смятат, че някой все още има нужда от толкова голямо виртуално адресно пространство и
1
Блокиране на адрес
адрес <25> <9> Отместване на блок <6>

на процесора
Етикет Индекс Данни Данни

в навън
Данни
Етикет <25>
Валиден <1> <64>
2
(512
блока)
3
=?
2
(512
блока)
3 2:1 мултиплексор
=?
Буфер
за жертви
Памет от по-ниско ниво
Фигура B.5 Организацията на кеша за данни в микропроцесора Opteron. Кешът от 64 KB е двупосочен, асоциативен с 64-байтови
блокове. 9-битовият индекс избира между 512 комплекта. Четирите стъпки на прочетено попадение, показани като оградени
числа в реда на възникване, обозначават тази организация. Три бита от блоковото отместване се присъединяват към индекса, за
да предоставят RAM адреса за избор на правилните 8 байта. По този начин кешът съдържа две групи от 4096 64-битови думи, като
всяка група съдържа половината от 512 комплекта. Въпреки че не е упражнено в този пример, линията от паметта на по-ниско
ниво към кеша се използва при пропуск за зареждане на кеша. Размерът на адреса, напускащ процесора, е 40 бита, защото това
е физически адрес, а не виртуален адрес. Фигура B.24 на страница B-47 обяснява как Opteron се преобразува от виртуален във
физически за достъп до кеша.
по-малкият размер опростява съпоставянето на виртуални адреси на Opteron. Дизайнерите

планират да разширят виртуалния адрес в бъдещите микропроцесори.
Физическият адрес, идващ в кеша, е разделен на две полета: 34-битов адрес на блок
и 6-битово отместване на блок (64 = 26 и 34 + 6 = 40). Адресът на блока е допълнително
разделен на адресен таг и индекс на кеша. Стъпка 1 показва това разделение.
Индексът на кеша избира етикета, който да бъде тестван, за да види дали желаният
блок е в кеша. Размерът на индекса зависи от размера на кеша, размера на блока и набора
асоциативност. За кеша на Opteron зададената асоциативност е зададена на две и ние

изчислете индекса, както следва:
Индекс
=
Размер на кеша 65,536
= ==----------------
2 -------------------------------------------------- --------------------
512 29
× Задайте асоциативност
Размер на блока 64 2 ×
Следователно индексът е с ширина 9 бита, а етикетът е с ширина 34 – 9 или 25 бита. Макар че

това е индексът, необходим за избор на правилния блок, 64 байта е много повече от
процесорът иска да консумира наведнъж. Следователно има по-голям смисъл да се организира
част от данните на кеш паметта с ширина 8 байта, което е естествената дума за данни на
64-битовият процесор Opteron. По този начин, в допълнение към 9 бита за индексиране на правилния кеш
блок, още 3 бита от отместването на блока се използват за индексиране на правилните 8 байта.
Изборът на индекс е стъпка 2 на фигура B.5.
След прочитане на двата тагова от кеша, те се сравняват с частта от етикета на адреса на блока от
процесора. Това сравнение е стъпка 3 на фигурата. За да сте сигурни, че етикетът съдържа валидна
информация, валидният бит трябва да бъде зададен или иначе
резултатите от сравнението се игнорират.
Ако приемем, че един таг съвпада, последната стъпка е да се сигнализира на процесора
заредете правилните данни от кеша, като използвате печелившия вход от 2:1 мултиплексор. Opteron
позволява 2 тактови цикъла за тези четири стъпки, така че инструкциите в следващите 2 тактови цикъла
ще изчакат, ако се опитат да използват резултата от
натоварването.
Обработката на записи е по-сложна от обработката на четения в Opteron, тъй като

е във всеки кеш. Ако думата, която трябва да бъде написана, е в кеша, първите три стъпки са
същото. Тъй като Opteron се изпълнява неправилно, само след като сигнализира, че
инструкцията е ангажирана и сравнението на кеш тагове показва, че хит са
данни, записани в кеша.
Досега приемахме обичайния случай на попадение в кеша. Какво се случва на a

мис? При пропуснато четене кешът изпраща сигнал до процесора, като му съобщава данните
все още не са налични и 64 байта се четат от следващото ниво на йерархията.
Забавянето е 7 тактови цикъла до първите 8 байта на блока и след това 2 тактови цикъла
цикли на 8 байта за останалата част от блока. Тъй като кешът за данни е зададен асоциативно,
има избор кой блок да бъде заменен. Opteron използва LRU, който избира
блок, който е споменаван най-отдавна, така че всеки достъп трябва да актуализира LRU бита.
Подмяната на блок означава актуализиране на данните, адресния таг, валидния бит и
LRU бит.
Тъй като Opteron използва обратно записване, старият блок от данни може да е бил модифициран и
следователно не може просто да бъде изхвърлен. Opteron запазва 1 мръсен бит на
блок за записване дали блокът е записан. Ако „жертвата“ е била променена, нейните данни
и адрес се изпращат до буфера на жертвата. (Тази структура е подобна на буфер за запис в други
компютри.) Opteron има място за осем жертвени блока. Успоредно с други действия в кеша, той записва
жертвени блокове на следващото ниво на
йерархия. Ако буферът на жертвата е пълен, кешът трябва да изчака.

Пропуск при запис е много подобен на пропуск при четене, тъй като Opteron разпределя a
блокиране при пропуск при четене или запис.
Видяхме как работи, но кеш паметта не може да задоволи всички нужди от памет на процесора:
Процесорът също се нуждае от инструкции. Въпреки че а
единичен кеш може да се опита да предостави и двете, това може да е тясно място. Например, когато
се изпълни инструкция за зареждане или съхраняване, конвейерният процесор ще поиска едновременно
както дума с данни, така и дума с инструкция. Следователно, единичен кеш
би представлявало структурна опасност за товари и складове, водещо до сергии. един
лесен начин за преодоляване на този проблем е да го разделите: един кеш е посветен на
инструкции и друг към данни. Отделни кеши се намират в най-новите процесори, включително Opteron.
Следователно той има и 64 KB кеш за инструкции
като 64 KB кеш за данни.
Процесорът знае дали издава адрес на инструкция или данни

адрес, така че може да има отделни портове и за двата, като по този начин се удвоява честотната лента
между йерархията на паметта и процесора. Отделни кешове също предлагат
възможност за оптимизиране на всеки кеш поотделно: Различни капацитети, блок
размери и асоциации могат да доведат до по-добра производителност. (За разлика от
кешове за инструкции и кешове за данни на Opteron, термините унифицирани или смесени са
приложен към кешове, които могат да съдържат или инструкции, или данни.)
Фигура B.6 показва, че кешовете на инструкции имат по-ниски проценти на пропуски от данните
тайници. Разделянето на инструкции и данни премахва пропуските, дължащи се на конфликти между
блокове с инструкции и блокове с данни, но разделянето също така фиксира кеш пространството
посветен на всеки тип. Кое е по-важно за пропуснати ставки? Справедливо сравнение
на отделни кешове за инструкции и данни към унифицирани кешове изисква целия кеш
размерът да е същият. Например, отделен 16 KB кеш инструкции и 16 KB
кешът за данни трябва да се сравнява с 32 KB унифициран кеш. Изчисляване на средната стойност
честота на пропуски с отделни кешове за инструкции и данни налага да се знае процентът на препратките
към паметта към всеки кеш. От данните в Приложение А ние
установете, че разделянето е 100%/(100% + 26% + 10%) или около 74% препратки към инструкции
до (26% + 10%)/(100% + 26% + 10%) или около 26% препратки към данни. Разделяне
засяга производителността над това, което е посочено от промяната в процентите на пропуски, както ние
ще видим след малко.
Кеш за
Размер (KB) инструкции Кеш данни Унифициран кеш
8 8.16 44,0 63,0
16 3.82 40.9 51,0
32 1.36 38.4 43.3
64 0,61 36.9 39.4
128 0,30 35.3 36.2
256 0,02 32.6 32.9
Фигура B.6 Мис на 1000 инструкции за инструкции, данни и унифицирани кешове с различни
размери. Процентът на препратките към инструкции е около 74%. Данните са за
двупосочни асоциативни кешове с 64-байтови блокове за същия компютър и бенчмаркове като
Фигура B.4.
Б.2 Ефективност на кеша
Тъй като броят на инструкциите не зависи от хардуера, е изкушаващо да се оцени производителността на процесора,
като се използва това число. Такива индиректни мерки за ефективност са препятствали много компютърни дизайнери.
Съответното изкушение за оценка на производителността на йерархията на паметта е да се концентрираме върху
честотата на пропуски, тъй като тя също не зависи от скоростта на хардуера. Както ще видим, процентът на пропуски
може да бъде също толкова подвеждащ, колкото и броят на инструкциите. По-добра мярка за производителността на
йерархията на паметта е средното време за достъп до паметта:
където времето за попадение е времето за попадение в кеша; видяхме другите два термина преди. Компонентите на
средното време за достъп могат да бъдат измерени или в абсолютно време - да речем, 0,25 до 1,0 наносекунди при
попадение - или в броя на тактовите цикли, които процесорът чака за паметта - като наказание за пропуск от 150 до
200 тактови цикли. Не забравяйте, че средното време за достъп до паметта все още е косвена мярка за производителност;
въпреки че е по-добра мярка от степента на пропуски, тя не е заместител на времето за изпълнение.
Тази формула може да ни помогне да решим между разделени кешове и обединен кеш.
Пример Кое има по-нисък процент пропуски: 16 KB кеш за инструкции с 16 KB кеш за данни или 32 KB унифициран кеш? Използвайте
процентите на пропуски на фигура B.6 , за да помогнете за изчисляването на правилния отговор, като приемем, че
36% от инструкциите са инструкции за прехвърляне на данни. Да приемем, че попадението отнема 1 тактов цикъл и
наказанието за пропуск е 100 тактови цикъла. Попадението при зареждане или съхраняване отнема 1 допълнителен
тактов цикъл на унифициран кеш, ако има само един кеш порт за удовлетворяване на две едновременни заявки.
Използвайки терминологията на конвейера от глава 3, унифицираният кеш води до структурна опасност. Какво е
средното време за достъп до паметта във всеки случай? Да приемем кешове за запис с буфер за запис и игнорирайте
спиранията поради буфера за запис.
Отговор Първо нека преобразуваме пропуските на 1000 инструкции в проценти на пропуски. Решаване на ген.
по формула от по-горе процентът на пропуски е
Пропуска
---------------------------------------------- 1000 ⁄
1000 инструкции
Miss rate = -------------------------------------------------- --------
Достъп до паметта
----------------------------------------------
Тъй като всеки достъп до инструкция има точно един достъп до паметта за извличане на инструкцията, процентът на
пропуснати инструкции е
3,82 1000 ⁄
Miss rate16 KB инструкция = -------------------------- 0,004 = 1,00
Тъй като 36% от инструкциите са прехвърляне на данни, процентът на пропускане на данни е такъв
40.9 1000 ⁄
Miss rate16 KB данни = --------------------------
0.36 0.114 =
B.2 Производителност на кеша B-17
Унифицираният процент на пропуски трябва да отчита достъпа до инструкции и данни:
43.3 1000 ⁄
Miss rate32 KB унифициран
= -------------------------- 0,0318 =
1,00 0,36 +
Както беше посочено по-горе, около 74% от достъпите до паметта са препратки към инструкции.
По този начин общият процент на пропуски за разделените кешове е
(74% × 0,004) + (26% × 0,114) = 0,0326
По този начин унифициран кеш от 32 KB има малко по-нисък ефективен процент на пропуски от два
16 KB кеш памет.
Формулата за средно време за достъп до паметта може да бъде разделена на инструкции и

достъп до данни:
Средно време за достъп до паметта
×(=
% инструкции Време на попадение Процент ×
+ на пропуски на инструкции Пропуснато наказание )
% данни Време ×на( +попадение Степен ×

+ на пропуск на данни Пропуснато наказание )
Следователно времето за всяка организация е
Средно време за достъп до паметта

( = 74% 1×0,004 200 ) × ( + 26% 1200
0,114
)+×+×
74% 1,80 × ) + ( 26% 23,80 × ) 1,332 6,188 = == ( + 7.52
Унифицирано средно време за достъп до паметта
( = 74% 1×0,0318
( 26% ) × (××+)26%
2008,36 = ==1200
(1
+ 0,0318 ×
+) + + + 5,446 2,174 74% 7,36 ×)
7.62
Следователно, разделените кеши в този пример, които предлагат два порта за памет на такт
цикъл, като по този начин избягвате структурната опасност - имате по-добър среден достъп до паметта
време в сравнение с унифицирания кеш с един порт, въпреки че има по-лош ефективен процент пропуски.
Средно време за достъп до паметта и производителност на процесора
Очевиден въпрос е дали средното време за достъп до паметта поради кеш пропуска
прогнозира производителността на процесора.
Първо, има други причини за забавяне, като спорове поради I/O устройства
използване на паметта. Дизайнерите често приемат, че всички забавяния на паметта се дължат на кеша
пропуски, тъй като йерархията на паметта обикновено доминира над други причини за забавяне.
Тук използваме това опростяващо предположение, но не забравяйте да вземете предвид цялата памет
спира при изчисляване на крайната производителност.
Второ, отговорът зависи и от процесора. Ако имаме процесор за изпълнение в ред (вижте Глава 3), тогава
отговорът е основно да. Процесорът
спира по време на пропуски и времето за спиране на паметта е силно свързано със средното
време за достъп до паметта. Нека направим това предположение засега, но ще се върнем към неработещите
процесори в следващия подраздел.

Както беше посочено в предишния раздел, можем да моделираме процесорното време като:
Време на процесора = (тактови цикли на изпълнение на процесора + часовникови цикли на застой на паметта) × време на тактовия цикъл
Тази формула повдига въпроса дали часовникът циклира за попадение в кеша
трябва да се счита за част от тактовите цикли на изпълнение на процесора или за част от застой на паметта
тактови цикли. Въпреки че и двете конвенции са защитими, най-широко приетите
е да се включат тактовите цикли на попадение в тактовите цикли на изпълнение на процесора.
Вече можем да изследваме влиянието на кеш паметта върху производителността.
Пример Нека използваме компютър за изпълнение в ред за първия пример. Да приемем, че
наказанието за пропуск на кеша е 200 тактови цикъла и всички инструкции обикновено приемат 1.0
тактови цикли (игнорирайки застой на паметта). Да приемем, че средният процент пропуски е 2%,
има средно 1,5 препратки към памет на инструкция и средната
броят пропуски в кеша на 1000 инструкции е 30. Какво е въздействието върху производителността, когато се
включи поведението на кеша? Изчислете въздействието, като използвате и двете
пропуски на инструкция и процент на пропуски.
Отговор Тактови цикли на паметта

× + ------------------------------------------------- -------------
CPU време = IC CPI изпълнение × Време на цикъла на часовника
Производителността, включително пропуските в кеша, е
Процесорно време с кеш = IC × [1,0 + (30/1000 × 200)] × време на цикъла на часовника

= IC × 7,00 × време на цикъла на часовника
Сега изчисляване на ефективността с помощта на процент на пропуски:
= Достъп до паметта
× ×
CPU време IC CPIизпълнение + Пропуснат процент × ------------------------------------------------ Пропусната дузпа × Време на цикъла на часовника
Процесорно време с кеш = IC × [1,0 + (1,5 × 2% × 200)] × време на цикъла на часовника

= IC × 7,00 × време на цикъла на часовника
Времето на тактовия цикъл и броят на инструкциите са еднакви, със или без a
кеш памет. По този начин процесорното време се увеличава седемкратно, с CPI от 1,00 за „перфектно
кеш” до 7.00 с кеш, който може да пропусне. Без никаква йерархия на паметта
CPI ще се увеличи отново до 1,0 + 200 × 1,5 или 301 - коефициент повече от 40
пъти по-дълго от система с кеш!
Както илюстрира този пример, поведението на кеша може да има огромно влияние върху
производителността. Освен това пропуските в кеша имат двойно въздействие върху процесор с нисък CPI и
бърз часовник:
1. Колкото по-ниско е изпълнението на CPI, толкова по-голямо е относителното въздействие на фиксиран брой
кеширане на пропуснати тактови цикли.
2. При изчисляване на CPI, наказанието за пропуск на кеша се измерва в часовника на процесора
цикли за пропуск. Следователно, дори ако памет йерархии за два компютъра

са идентични, процесорът с по-висока тактова честота има по-голям брой
тактови цикли на пропуск и следователно по-висока част от паметта на CPI.
Важността на кеша за процесори с нисък CPI и високи тактови честоти е
по този начин по-голяма и, следователно, по-голяма е опасността от пренебрегване на кеша
поведение при оценяване на производителността на такива компютри. Законът на Амдал поразява
отново!
Въпреки че минимизирането на средното време за достъп до паметта е разумна цел -
и ще го използваме в голяма част от това приложение – имайте предвид, че крайната цел е
за намаляване на времето за изпълнение на процесора. Следващият пример показва как тези две
може да се различава.
Пример Какво е въздействието на две различни организации на кеша върху производителността на a
процесор? Да приемем, че CPI с перфектен кеш е 1,6, времето на тактовия цикъл
е 0,35 ns, има 1,4 препратки към памет за инструкция, размерът и на двете
кеша е 128 KB и двата имат размер на блока от 64 байта. Един кеш е директен
картографиран, а другият е двупосочен набор асоциативен. Фигура B.5 показва това за set
асоциативни кешове трябва да добавим мултиплексор за избор между блоковете в
задайте в зависимост от съвпадението на етикета. Тъй като скоростта на процесора може да бъде вързана
директно към скоростта на попадение в кеша, приемете, че времето на тактовия цикъл на процесора трябва
да бъде разтегната 1,35 пъти, за да побере мултиплексора за избор на зададения асоциативен кеш. При
първото приближение наказанието за пропуск на кеша е 65 ns за
или организация на кеша. (На практика обикновено се закръгля нагоре или надолу до an
цял брой тактови цикли.) Първо, изчислете средното време за достъп до паметта
и след това производителност на процесора. Да приемем, че времето за попадение е 1 тактов цикъл, пропускът
процентът на директно картографиран 128 KB кеш е 2,1%, а процентът на пропуски за двупосочен

зададеният асоциативен кеш със същия размер е 1,9%.
По този начин времето за всяка организация е
Средно време за достъп до паметта 1-посочен = 0,35 + (.021 × 65) = 1,72 ns

Средно време за двупосочен достъп до паметта = 0,35 × 1,35 + (.019 × 65) = 1,71 ns
Средното време за достъп до паметта е по-добро за двупосочния набор-асоциативен кеш.
Производителността на процесора е
Госпожици
CPU време IC=CPIизпълнение
× × Мис дузпа +
------------------------
× Време на цикъла на часовника
= × IC Изпълнение на CPI × време на цикъла на часовника
+ Достъп до паметта × Пропуснато наказание Време

Пропуснат процент × ------------------------------------------------ × на цикъла на часовника
Замествайки 65 ns за (наказание за пропуск × време на часовников цикъл), производителността на всеки
организацията на кеша е
IC 1,6 ×
× [0,35 0,021 1,4 +× (× 65 )] = 2,47 IC ×
CPU time1-way =
[ IC ×1.6 0.35 1.35 × +1.4

( 0.019
× × 65 ) ]× = 2,49 IC ×
CPU time2-way =
и относителната производителност е
CPU time2-way 2.49 Брой инструкции × 2.49

---------------------------------- = -------------------------------------------------- ------- = = ---------- 1.01
2.47 Брой инструкции × 2.47
Процесорно време1-посочно
За разлика от резултатите от сравнението на средното време за достъп до паметта, директно картографираният
кеш води до малко по-добра средна производителност, тъй като часовникът
цикълът се разтяга за всички инструкции за двупосочен набор асоциативен случай, дори ако
има по-малко пропуски. Тъй като процесорното време е нашата крайна оценка и оттогава
директното картографиране е по-лесно за изграждане, предпочитаният кеш е директно картографиран в това
пример.
Miss Penalty и процесори за изпълнение извън ред

За процесор за изпълнение извън реда, как определяте „наказание за пропуск“? Така ли
пълната латентност на липсата на памет, или това е просто „изложената“ или незапокрита латентност, когато
процесорът трябва да спре? Този въпрос не възниква при процесори, които спират, докато пропускът на данни
завърши.
Нека предефинираме забавянията на паметта, за да доведем до нова дефиниция на наказание за пропуск като
латентност без припокриване:
Цикли на спиране на паметта Госпожици

------------------------------------------------ –
× (пропускане на латентност Припокриване на пропускане на забавяне )
= ------------------------ Общо
По същия начин, тъй като някои неработещи процесори удължават времето за попадение, тази част от
уравнението за производителност може да бъде разделено на общата латентност на попадението минус припокритото попадение
латентност. Това уравнение може да бъде допълнително разширено, за да отчете спора за
ресурси на паметта в неправилен процесор чрез разделяне на общата латентност на пропуските на
латентност без конкуренция и латентност поради конкуренция. Нека просто се концентрираме
при липса на латентност.
Сега трябва да решим следното:
Продължителност на латентността на паметта—Какво да се счита за начало и край на a
работа на паметта в неработещ процесор
Дължина на припокриването на латентността—Какво е началото на припокриването с процесора (или,
еквивалентно, кога казваме, че операция с памет спира процесора)

Като се има предвид сложността на процесорите за изпълнение извън реда, няма единичен
правилно определение.
Тъй като на етапа на пенсиониране се виждат само ангажирани операции, ние
да кажем, че процесорът е спрял в тактов цикъл, ако не оттегли максималния възможен брой инструкции
в този цикъл. Приписваме това забавяне на първата инструкция, която не може да бъде оттеглена. Това
определение в никакъв случай не е безпогрешно. За
Например, прилагането на оптимизация за подобряване на определено време на спиране може да не е винаги
подобряване на времето за изпълнение, тъй като друг тип срив— скрит зад целта
сергия - сега може да бъде изложена.
За латентността можем да започнем да измерваме от момента, в който е инструкцията за паметта
на опашка в прозореца с инструкции, или когато адресът е генериран, или когато
инструкцията всъщност се изпраща до паметта на системата. Всяка опция работи, стига да

се използва по последователен начин.
Пример Нека повторим примера по-горе, но този път приемаме процесора с
по-дълго време на тактовия цикъл поддържа изпълнение извън реда, но все още има директно картографиран
кеш. Да приемем, че 30% от наказанието за пропуск от 65 ns може да бъде припокрито; това е,
средното време за спиране на паметта на процесора вече е 45,5 ns.
Отговор Средното време за достъп до паметта за компютъра извън строя (OOO) е
Средно време за достъп до паметта 1-way,OOO = 0,35 × 1,35 + (0,021 × 45,5) = 1,43 ns
Производителността на кеша на OOO е
× = 2.09 IC ×
CPU time1-way,OOO = [ IC×1.6 0.35 1.35 (×0.021
+ 1.4 × × 45.5 ) ]
Следователно, въпреки много по-бавното време на тактовия цикъл и по-високия процент пропуски на a
директен картографиран кеш, неработещият компютър може да бъде малко по-бърз, ако може
скрий 30% от наказанието за пропуск.
В обобщение, въпреки че състоянието на техниката в дефинирането и измерването на паметта
сергии за процесори извън ред е сложно, имайте предвид проблемите, защото те
влияят значително на производителността. Сложността възниква, защото неправилните процесори
толерират известна латентност поради пропуски в кеша, без да навредят на производителността.
Следователно дизайнерите обикновено използват симулатори на неработещия процесор
и памет, когато оценявате компромисите в йерархията на паметта, за да сте сигурни, че
подобрение, което помага на средната латентност на паметта, всъщност помага на програмата
За да помогнете за обобщаването на този раздел и да служите като полезна справка, Фигура B.7
изброява уравненията на кеша в това приложение.

индекс Размер на кеша

2 = -------------------------------------------------- ---------------------
Размер на блока Задайте асоциативност
Време за изпълнение на CPU× Тактови

=( + на спиране на паметта) × Време на тактовия цикъл
цикли на CPU Цикли
=
Госпожици
Цикли на спиране на паметта IC
= × ------------------------ Пропуснато
× наказание
Госпожици Достъп до паметта

=
------------------------ Пропусната ставка × ---------------------- --------------------
+
Средно време за достъп до паметта Време за попадение Процент
= ×
на пропуск Наказание за пропуск
Тактови цикли на паметта

= × IC CPIexecution
Време за изпълнение на CPU + ------------------------------------------------- ------------- × Време на цикъла на часовника
Госпожици
= × IC CPIexecution
Време за изпълнение на CPU + ------------------------×Пропусната дузпа × Време на цикъла на часовника
=× Достъп до паметта
+
Време за изпълнение на CPU IC CPIexecution Miss rate × ------------------------------------------------ × Пропуснато наказание × Време на цикъла на часовника
Цикли на спиране на паметта Госпожици

------------------------------------------------ –
× пропускане
= ------------------------ Общо ( на латентност Припокриване на пропускане на забавяне )
= + × ( rateL2 + × Пропусната дузпа L2 )

Средно време за достъп до паметта Hit timeL1 Miss rateL1 Miss rateL2 Miss
Цикли на спиране на паметта Пропуска L1 Пропуска L2

------------------------------------------------ = × + ------------------------× Пропусната дузпа L2
------------------------ Време за попадение L2
Инструкция Инструкция Инструкция
Фигура B.7 Обобщение на уравненията за ефективност в това приложение. Първото уравнение изчислява индекса на кеша
размер, а останалите помагат за оценка на ефективността. Последните две уравнения се занимават с многостепенни кешове, които са
обяснено в началото на следващия раздел. Те са включени тук, за да направят фигурата полезна справка.
Б.3 Шест основни оптимизации на кеша
Формулата за средно време за достъп до паметта ни даде рамка за представяне на кеша
оптимизации за подобряване на производителността на кеша:
Следователно ние организираме шест оптимизации на кеша в три категории:
Намаляване на честотата на пропуски - по-голям размер на блока, по-голям размер на кеша и по-висока асо-
циативност
Намаляване на наказанието за пропуски — многостепенни кешове и даване на приоритет на четенията

пише
Намаляване на времето за попадение в кеша— избягване на превод на адрес, когато
индексиране на кеша
Фигура B.18 на страница B-40 завършва този раздел с обобщение на сложността на внедряване и ползите
от тези шест техники.

B.3 Шест основни оптимизации на кеша B-23
Класическият подход за подобряване на поведението на кеша е да се намалят процентите на пропуски
и ние представяме три техники за това. За да придобием по-добра представа за причините за
пропуските, първо започваме с модел, който сортира всички пропуски в три прости категории:
Задължително— първият достъп до блок не може да бъде в кеша, така че блокът трябва да бъде пренесен
в кеша. Те се наричат още пропуски при студен старт или пропуски при първи референтен сигнал.
Капацитет— Ако кешът не може да съдържа всички блокове, необходими по време на изпълнение на
програма, пропуски на капацитет (в допълнение към задължителните пропуски) ще възникнат поради
отхвърляне на блокове и по-късно извличане.
Конфликт— Ако стратегията за поставяне на блокове е зададена асоциативно или директно
картографирана, ще възникнат конфликтни пропуски (в допълнение към задължителните пропуски и
пропуски на капацитет), тъй като блок може да бъде отхвърлен и по-късно извлечен, ако твърде много
блокове се картографират към неговия набор. Тези пропуски се наричат още пропуски при сблъсък.
Идеята е, че попаденията в напълно асоциативен кеш, които се превръщат в пропуски в n-посочен
набор-асоциативен кеш, се дължат на повече от n заявки за някои популярни набори.
(Глава 5 добавя четвърто C, за пропуски на кохерентност , дължащи се на промиване на кеша, за да поддържа
множество кеши кохерентни в мултипроцесор; ние няма да ги разглеждаме тук.)
Фигура B.8 показва относителната честота на пропуски в кеша, разбита по трите C. Задължителните
пропуски са тези, които се случват в безкраен кеш.
Липсите на капацитет са тези, които възникват в напълно асоциативен кеш. Конфликтните пропуски са
тези, които възникват, преминавайки от напълно асоциативен към осемпосочен асоциативен,
четирипосочен асоциативен и т.н. Фигура B.9 представя същите данни графично. Горната графика
показва абсолютни проценти на пропуски; долната графика изобразява процента на всички пропуски по
тип пропуски като функция от размера на кеша.
За да се покаже ползата от асоциативността, конфликтните пропуски се разделят на пропуски,
причинени от всяко намаляване на асоциативността. Ето четирите подразделения на конфликтните
пропуски и как се изчисляват:
Осемпосочност – пропуски на конфликт поради преминаване от напълно асоциативен (без конфликти)
към осемпосочен асоциативен
Четирипосочен — пропуски на конфликт поради преминаване от осемпосочен асоциативен към
четирипосочен асоциативен
Двупосочно — пропуски на конфликт поради преминаване от четирипосочна асоциативна към двупосочна
асоциативна
Еднопосочно— Пропускане на конфликт поради преминаване от двупосочна асоциативна към еднопосочна
асоциативна (директно картографирано)
Както можем да видим от цифрите, задължителният процент пропуски на SPEC2000
програми е много малък, както е за много дълго работещи програми.
След като идентифицира трите C, какво може да направи един компютърен дизайнер за тях?
Концептуално, конфликтите са най-лесни: Напълно асоциативното разположение избягва всички пропуски
на конфликти. Пълната асоциативност обаче е скъпа за хардуера и може да забави тактовата честота на
процесора (вижте примера на страница B-29), което води до по-ниска обща производителност.
Компоненти на процент на пропуски (относителен процент)

(сума = 100% от общия процент на пропуски)
Степен Общ процент
Размер на кеша (KB) асоциативен пропуски Задължително Капацитет Конфликт
4 1-посочен 0,098 0,0001 0,1% 0,070 72% 0,027 28%

4 2-посочен 0,076 0,0001 0,1% 0,070 93% 0,005 7%
4 4-посочен 0,071 0,0001 0,1% 0,070 99% 0,001 1%
4 8-посочен 0,071 0,0001 0,1% 0,070 100% 0,000 0%
8 1-посочен 0,068 0,0001 0,1% 0,044 65% 0,024 35%
8 2-посочен 0,049 0,0001 0,1% 0,044 90% 0,005 10%
8 4-посочен 0,044 0,0001 0,1% 0,044 99% 0,000 1%
8 8-посочен 0,044 0,0001 0,1% 0,044 100% 0,000 0%
16 1-посочен 0,049 0,0001 0,1% 0,040 82% 0,009 17%
16 2-посочен 0,041 0,0001 0,2% 0,040 98% 0,001 2%
16 4-посочен 0,041 0,0001 0,2% 0,040 99% 0,000 0%
16 8-посочен 0,041 0,0001 0,2% 0,040 100% 0,000 0%
32 1-посочен 0,042 0,0001 0,2% 0,037 89% 0,005 11%
32 2-посочен 0,038 0,0001 0,2% 0,037 99% 0,000 0%
32 4-посочен 0,037 0,0001 0,2% 0,037 100% 0,000 0%
32 8-посочен 0,037 0,0001 0,2% 0,037 100% 0,000 0%
64 1- начин 0,037 0,0001 0,2% 0,028 77% 0,008 23%
64 2-посочен 0,031 0,0001 0,2% 0,028 91% 0,003 9%
64 4-посочен 0,030 0,0001 0,2% 0,028 95% 0,001 4%
64 8-посочен 0,029 0,0001 0,2% 0,028 97% 0,001 2%
128 1-посочен 0,021 0,0001 0,3% 0,019 91% 0,002 8%
128 2-посочен 0,019 0,0001 0,3% 0,019 100% 0,000 0%
128 4-посочен 0,019 0,0001 0,3% 0,019 100% 0,000 0%
128 8-посочен 0,019 0,0001 0,3% 0,019 100% 0,000 0%
256 1-посочен 0,013 0,0001 0,5% 0,012 94% 0,001 6%
256 2-посочен 0,012 0,0001 0,5% 0,012 99% 0,000 0%
256 4-посочен 0,012 0,0001 0,5% 0,012 99% 0,000 0%
256 8-посочен 0,012 0,0001 0,5% 0,012 99% 0,000 0%
512 1-посочен 0,008 0,0001 0,8% 0,005 66% 0,003 33%
512 2-посочен 0,007 0,0001 0,9% 0,005 71% 0,002 28%
512 4-посочен 0,006 0,0001 1,1% 0,005 91% 0,000 8%
512 8-посочен 0,006 0,0001 1,1% 0,005 95% 0,000 4%
Фигура B.8 Общ процент на пропуски за всеки размер на кеша и процент на всеки според трите C. Задължително
пропуските са независими от размера на кеша, докато пропуските на капацитета намаляват с увеличаването на капацитета и конфликтните пропуски
намаляват с увеличаване на асоциативността. Фигура B.9 показва същата информация графично. Имайте предвид, че директно картографиран
кешът с размер N има приблизително същия процент пропуски като двупосочен набор-асоциативен кеш с размер N/2 до 128 K. Кешове
по-големи от 128 KB не доказват това правило. Обърнете внимание, че колоната Капацитет също е напълно асоциативна степен на пропуски. Данни
бяха събрани, както е показано на Фигура B.4, като се използва замяна на LRU.
0,10
0,09
0,08
0,07 1-посочен
2-посочен
0,06 4-посочен
8-посочен
0,05 Капацитет
уц
татннсе ат
р
р
ппоои П
з
п
0,04
0,03
0,02
0,01
0,00
4 8 16 32 64 128 256 512 1024
100%
80%
60%
уц
татннсе ат
р
р
ппоои П
з
п
1-посочен
40% 2-посочен
4-посочен
8-посочен
20% Капацитет
0%
4 8 16 32 64 128 256 512 1024
Фигура B.9 Общ процент на пропуски (отгоре) и разпределение на процент на пропуски (отдолу) за всеки размер
кеш според трите C за данните на фигура B.8. Горната диаграма показва
действителните нива на пропуски в кеша на данни, докато долната диаграма показва процента в
всяка категория. (Интервалът позволява на графиките да показват един допълнителен размер на кеша, отколкото може да се побере
Фигура B.8.)
Има малко какво да се направи относно капацитета, освен да се увеличи кеша. Ако
паметта от горно ниво е много по-малка от това, което е необходимо за една програма, и a
значителен процент от времето се изразходва за преместване на данни между две нива в
йерархия, йерархията на паметта се казва, че се бие. Защото толкова много замени
са необходими, разбиване означава, че компютърът работи близка до скоростта на паметта
от по-ниско ниво или може би дори по-бавно поради пропускане.
Друг подход за подобряване на трите C е да се направят блоковете по-големи, за да се намали броят на
задължителните пропуски, но, както ще видим скоро, големите блокове могат да увеличат други видове пропуски.
Трите C дават представа за причината за пропуските, но този прост модел има своите граници; дава ви
представа за средното поведение, но може да не обясни индивидуална грешка. Например промяната на размера на
кеша променя конфликтните пропуски, както и пропуските на капацитета, тъй като по-големият кеш разпределя
препратки към повече блокове. По този начин пропускът може да премине от пропуск на капацитет към пропуск на
конфликт, когато размерът на кеша се промени. Имайте предвид, че трите C също игнорират политиката за
заместване, тъй като е трудно да се моделира и тъй като като цяло е по-малко значима. При специфични обстоятелства
политиката за заместване може действително да доведе до аномално поведение, като например по-ниски нива на
пропуски за по-голяма асоциативност, което противоречи на модела на трите C. (Някои предложиха да се използва
проследяване на адреси, за да се определи оптималното разположение в паметта, за да се избегнат пропуски на
разположение от модела на трите C; ние не последвахме този съвет тук.)
Уви, много от техниките, които намаляват процента на пропуски, също увеличават времето за попадение или
наказанието за пропуск. Желанието за намаляване на процентите на пропуски с помощта на трите оптимизации трябва
да бъде балансирано спрямо целта да се направи цялата система бърза. Този първи пример показва важността на
балансираната гледна точка.
Първа оптимизация: По-голям размер на блока за намаляване на честотата на пропускане
Най-простият начин за намаляване на процента на пропуски е да се увеличи размерът на блока. Фигура B.10 показва
компромиса между размера на блока и процента на пропуски за набор от програми и размери на кеша. По-големите
размери на блоковете ще намалят и задължителните пропуски. Това намаление се случва, защото принципът на
локалност има два компонента: времева локалност и пространствена локалност. По-големите блокове се възползват
от пространствената локалност.
В същото време по-големите блокове увеличават наказанието за пропуск. Тъй като намаляват броя на блоковете
в кеша, по-големите блокове могат да увеличат пропуските на конфликти и дори пропуските на капацитета, ако
кешът е малък. Ясно е, че няма голяма причина да се увеличи размерът на блока до такъв размер, че да увеличи
процента на пропуски. Също така няма полза от намаляването на честотата на пропуски, ако увеличава средното време
за достъп до паметта.
Увеличаването на наказанието за пропуски може да надвиши намаляването на процента на пропуски.
Пример Фигура B.11 показва действителните нива на пропуски, нанесени на фигура B.10. Да приемем, че системата на паметта
отнема 80 тактови цикъла и след това доставя 16 байта на всеки 2 тактови цикъла. По този начин той може да
предостави 16 байта за 82 тактови цикъла, 32 байта за 84 тактови цикъла и т.н. Кой размер на блока има най-малкото
средно време за достъп до паметта за всеки размер на кеша на Фигура B.11?
10%
4K
5%
sestiaMr
16K
64K
256K
0%
16 32 64 128 256
Размер на блока
Фигура B.10 Степента на пропуск спрямо размера на блока за пет кеша с различни размери. Забележете, че пропуснете
скоростта всъщност се повишава, ако размерът на блока е твърде голям спрямо размера на кеша. Всеки ред
представлява кеш с различен размер. Фигура B.11 показва данните, използвани за начертаване на тези линии.
За съжаление, следите на SPEC2000 биха отнели твърде много време, ако размерът на блока беше включен, така че
тези данни са базирани на SPEC92 на DECstation 5000 [Gee et al. 1993].
Ако приемем, че времето за попадение е 1 тактов цикъл, независимо от размера на блока, тогава
времето за достъп за 16-байтов блок в 4 KB кеш е
Средно време за достъп до паметта = 1 + (8,57% × 82) = 8,027 тактови цикъла
и за 256-байтов блок в 256 KB кеш средното време за достъп до паметта е
Средно време за достъп до паметта = 1 + (0,49% × 112) = 1,549 тактови цикъла
Размер на блока 4K 16K 64K 256K
16 8,57% 3,94% 2,04% 1,09%
32 7,24% 2,87% 1,35% 0,70%
64 7,00% 2,64% 1,06% 0,51%
128 7,78% 2,77% 1,02% 0,49%
256 9,51% 3,29% 1,15% 0,49%
Фигура B.11 Действителен процент пропуски спрямо размера на блока за петте кеша с различен размер
Фигура B.10. Имайте предвид, че за 4 KB кеш, 256-байтовите блокове имат по-висок процент пропуски от
32-байтови блокове. В този пример кешът трябва да бъде 256 KB, за да може a
256-байтов блок за намаляване на пропуските.
Размер на блока Пропусната дузпа 4K 16K 64K 256K
16 82 8,027 4.231 2,673 1,894
32 84 7,082 3,411 2.134 1,588
64 88 7,160 3,323 1,933 1,449
128 96 8,469 3,659 1,979 1,470
256 112 11,651 4,685 2,288 1,549
Фигура B.12 Средно време за достъп до паметта спрямо размера на блока за пет различни размера
кешове на фигура B.10. Доминират блоковите размери от 32 и 64 байта. Най-малката средна стойност
времето за размер на кеша е удебелено.
Фигура B.12 показва средното време за достъп до паметта за всички размери на блок и кеш
между тези две крайности. Записите с удебелен шрифт показват най-бързия размер на блока
за даден размер на кеша: 32 байта за 4 KB и 64 байта за по-големите кеши.
Тези размери всъщност са популярни размери на блокове за кеш паметта на процесора днес.
Както при всички тези техники, дизайнерът на кеша се опитва да минимизира и двете
степента на пропуски и наказанието за пропуски. Изборът на размер на блок зависи и от двете
латентността и честотната лента на паметта от по-ниско ниво. Висока латентност и висока
честотната лента насърчава големия размер на блока, тъй като кешът получава много повече байтове на
пропуск за малко увеличение на наказанието за пропуск. Обратно, ниското забавяне и ниската честотна
лента насърчават по-малки размери на блокове, тъй като има малко спестено време от по-голям
блок. Например двойното наказание за пропуск на малък блок може да бъде близо до
наказание от блок два пъти по-голям размер. По-големият брой малки блокове също може
намаляване на конфликтните пропуски. Имайте предвид, че фигури B.10 и B.12 показват разликата
между избора на размер на блок въз основа на минимизиране на честотата на пропуски срещу минимизиране
средно време за достъп до паметта.
След като видяхме положителното и отрицателното въздействие на по-големия размер на блока върху
задължителните пропуски и пропуските на капацитет, следващите два подраздела разглеждат потенциала за по-високи
капацитет и по-висока асоциативност.
Втора оптимизация: По-големи кешове за намаляване на честотата на пропуски
Очевидният начин за намаляване на пропуските в капацитета на фигури B.8 и B.9 е да се увеличи
капацитет на кеша. Очевидният недостатък е потенциално по-дългото време за попадение и
по-висока цена и мощност. Тази техника е особено популярна в извън чипа

тайници.
Трета оптимизация: По-висока асоциативност за намаляване на процента на пропуски
Фигури B.8 и B.9 показват как нивата на пропуски се подобряват с по-висока асоциативност. Там
са две общи правила, които могат да бъдат извлечени от тези цифри. Първият е
този асоциативен набор от осем посоки е за практически цели толкова ефективен при намаляване
пропуска за тези оразмерени кешове като напълно асоциативни. Можете да видите разликата от
сравнявайки осемпосочните записи с колоната за пропуск на капацитет на Фигура B.8, тъй като
пропуските на капацитет се изчисляват с помощта на напълно асоциативни кешове.
Второто наблюдение, наречено основно правило за кеша 2:1, е, че директно картографиран кеш с размер N има
приблизително същата честота на пропуски като асоциативен двупосочен набор
кеш с размер N/2. Това се поддържаше в три цифри C за размери на кеша под 128 KB.
Подобно на много от тези примери, подобряване на един аспект на средната памет
времето за достъп идва за сметка на друго. Увеличаването на размера на блока намалява пропуските
скорост, като същевременно увеличава наказанието за пропуски, а по-голямата асоциативност може да дойде на цената
на увеличено време за попадение. Следователно натискът от бързия тактов цикъл на процесора насърчава прости
дизайни на кеша, но нарастващото наказание за пропуск възнаграждава асоциативността,
както подсказва следният пример.
Пример Да приемем, че по-високата асоциативност би увеличила времето на тактовия цикъл, както е посочено
По-долу:
Време на часовниковия цикъл 2-посочен = 1,36 × Време на часовников цикъл 1-посочен
Време на тактовия цикъл 4-посочен = 1,44 × Време на тактовия цикъл 1-посочен
Време на тактовия цикъл 8-посочно = 1,52 × Време на тактовия цикъл 1-посочно
Да приемем, че времето за попадение е 1 тактов цикъл, че наказанието за пропуск за случая с директно
картографиране е 25 тактови цикъла към кеш ниво 2 (вижте следващия подраздел), който никога
пропуски и че наказанието за пропуск не е необходимо да се закръгля до цяло число от
тактови цикли. Използване на Фигура B.8 за проценти на пропуски, за които размерите на кеша са всеки от
тези три твърдения верни ли са?
Средно време за 8-посочен достъп до паметта < Средно време за 4-посочен достъп до паметта
Средно време за 4-посочен достъп до паметта < Средно време за 2-посочен достъп до паметта
Средно време за двупосочен достъп до памет < Средно време за еднопосочен достъп до паметта
Асоциативност
Размер на кеша (KB) 1-посочен 2-посочен 4-посочен 8-посочен
4 3.44 3.25 3.22 3.28
8 2,69 2.58 2.55 2.62
16 2.23 2.40 2.46 2.53
32 2.06 2.30 2.37 2.45
64 1.92 2.14 2.18 2.25
128 1.52 1,84 1.92 2.00
256 1.32 1,66 1.74 1.82
512 1.20 1.55 1.59 1,66
Фигура B.13 Средно време за достъп до паметта, като се използват проценти на пропуски във Фигура B.8
за параметри в примера. Удебелен шрифт означава, че това време е по-високо от числото до
отляво, тоест по-високата асоциативност увеличава средното време за достъп до паметта.
Отговор Средното време за достъп до паметта за всяка асоциативност е
Средно време за достъп до паметта 8 пъти = Време за попадение 8 пъти + Пропусната степен 8 пъти × Пропуснато наказание 8 начина
= 1,52 + пропуск 8-посочен × 25
Средно време за достъп до паметта 4-посочен = 1,44 + Miss rate 4-посочен × 25
Средно време за двупосочен достъп до паметта = 1,36 + Miss rate 2-посочен × 25
Средно време за достъп до паметта 1-посочен = 1,00 + Пропусната скорост 1-посочен × 25
Наказанието за пропуск е едно и също време във всеки случай, така че го оставяме като 25 тактови цикъла.
Например, средното време за достъп до паметта за 4 KB директно картографиран кеш е
Средно време за достъп до паметта 1-посочен = 1,00 + (0,098 × 25) = 3,44
и времето за 512 KB, осемпосочен асоциативен кеш е
Средно време за достъп до паметта 8 пъти = 1,52 + (0,006 × 25) = 1,66
Използвайки тези формули и процентите на пропуски от Фигура B.8, Фигура B.13 показва
средно време за достъп до паметта за всеки кеш и асоциативност. Фигурата показва
че формулите в този пример държат за кешове, по-малки или равни на 8 KB за нагоре
към четиристранната асоциативност. Започвайки с 16 KB, по-голямото време за попадение на по-голямата
асоциативност превишава спестеното време поради намаляването на пропуските.
Обърнете внимание, че не отчитаме по-бавната тактова честота на останалата част от програмата
в този пример, като по този начин се подценява предимството на директно картографирания кеш.
Четвърта оптимизация: Многостепенни кешове за
Намаляване на наказанието за пропуск
Намаляването на пропуските в кеша беше традиционният фокус на изследването на кеша, но
Формулата за производителност на кеша ни уверява, че може да има подобрения в наказанието за пропуски
също толкова полезни, колкото и подобренията в процента на пропуски. Освен това Фигура 2.2 на страница 74
показва, че технологичните тенденции са подобрили скоростта на процесорите по-бързо от
DRAM, което води до увеличаване на относителната цена на наказанията за пропуски с времето.
Тази разлика в производителността между процесорите и паметта води архитекта до
този въпрос: Трябва ли да направя кеша по-бърз, за да върви в крак със скоростта на процесорите, или да
направя кеша по-голям, за да преодолея разширяващата се разлика между процесора и основната памет?
Един отговор е, правете и двете. Добавяне на друго ниво на кеш между оригинала
кеш и памет опростява решението. Кешът от първо ниво може да бъде малък
достатъчно, за да съответства на времето на тактовия цикъл на бързия процесор. Все пак второто ниво
кешът може да бъде достатъчно голям, за да улови много достъпи, които биха отишли до главната памет, като
по този начин се намали ефективното наказание за пропуск.
Въпреки че концепцията за добавяне на друго ниво в йерархията е проста, тя усложнява анализа на
ефективността. Дефиниции за второ ниво на кеша
не винаги са ясни. Нека започнем с определението за средна памет

време за достъп за кеш на две нива. Използвайки индексите L1 и L2 за препращане,

съответно, към кеш от първо ниво и кеш от второ ниво, оригиналната формула е
Средно време за достъп до паметта = време за попадение L1 + степен на пропуски L1 × наказание за пропуски L1
и
Пропуснато наказание L1 = Пропуснато наказание L2 + Пропуснато наказание L2 × Пропуснато наказание L2
така
Средно време за достъп до паметта = Hit timeL1 + Miss rateL1
× (Време за попадение L2 + процент на пропуски L2 × наказание за пропуски L2)
В тази формула процентът на пропуски от второ ниво се измерва върху остатъците от

кеша от първо ниво. За да се избегне двусмислие, тези термини са приети тук за
двустепенна кеш система:
Локален процент на пропуски— Този процент е просто броят пропуски в кеша,

разделен на общия брой достъпи до паметта към този кеш. Както бихте очаквали,
за кеша от първо ниво той е равен на Miss rateL1, а за кеша от второ ниво е Miss
rateL2. Глобален
процент пропуски— Броят пропуски в кеша, разделен на общия брой достъпи до паметта,
генерирани от процесора. Използвайки термините по-горе, глобалната честота
на пропуски за кеша от първо ниво все още е само Miss rateL1, но за кеша от второ
ниво е Miss rateL1 × Miss rateL2.
Този локален процент на пропуски е голям за кеш паметта от второ ниво, тъй като
кешът от първо ниво обира каймака на достъпите до паметта. Ето защо глобалният
процент на пропуски е по-полезната мярка: той показва каква част от достъпите до
паметта, които напускат процесора, отиват чак до паметта.
Ето място, където показателят за пропуски на инструкция блести. Вместо объркване относно
местни или глобални проценти на пропуски, ние просто разширяваме паметта на паметта на
инструкция, за да добавим въздействието на кеш от второ ниво.
Средно забавяне на паметта на инструкция = пропуски на инструкцияL1 × време на попадение L2
+ Пропуски на инструкция L2 × Пропуснато наказание L2
Пример Да предположим, че в 1000 препратки към паметта има 40 пропуска в кеша от първо ниво
и 20 пропуска в кеша от второ ниво. Какви са различните нива на пропуски?
Да приемем, че наказанието за пропуск от L2 кеша към паметта е 200 тактови цикъла,
времето за попадение на L2 кеша е 10 тактови цикъла, времето за попадение на L1 е 1
тактов цикъл и има 1,5 препратки към памет на инструкция. Какво е средното време за
достъп до паметта и средните цикли на спиране на инструкция? Игнорирайте въздействието на писан
Отговор Процентът на пропуски (локален или глобален) за кеша от първо ниво е 40/1000 или 4%.
Локалният процент на пропуски за кеша от второ ниво е 20/40 или 50%. Глобалният процент
на пропуски на кеша от второ ниво е 20/1000 или 2%. Тогава
Средно време за достъп до паметта = време за попадение L1 + степен на пропуск L1 × (време за попадение L2 + процент на пропуск L2 × наказание за пропуск L2)
= 1 + 4% × (10 + 50% × 200) = 1 + 4% × 110 = 5,4 тактови цикъла

За да видим колко пропуска получаваме на инструкция, разделяме 1000 препратки към паметта на 1,5
препратки към паметта на инструкция, което дава 667 инструкции.
По този начин трябва да умножим пропуските по 1,5, за да получим броя пропуски на 1000 инструкции.
Имаме 40 × 1,5 или 60 пропуска на L1 и 20 × 1,5 или 30 пропуска на L2 за 1000 инструкции. За средно
забавяне на паметта на инструкция, ако приемем, че пропуските са разпределени равномерно между
инструкциите и данните:
Средно забавяне на паметта на инструкция = пропуски на инструкцияL1 × време на попадение L2 + пропуски на инструкцияL2
× Пропусната дузпа L2
= (60/1000) × 10 + (30/1000) × 200 = 0,060 × 10 +
0,030 × 200 = 6,6 тактови цикъла
Ако извадим времето за попадение на L1 от средното време за достъп до паметта (AMAT) и след това
умножим по средния брой препратки към памет за инструкция, получаваме същото средно забавяне на
паметта за инструкция:
(5,4 – 1,0) × 1,5 = 4,4 × 1,5 = 6,6 тактови цикъла
Както показва този пример, може да има по-малко объркване с кешовете на много нива, когато се
изчислява, използвайки пропуски на инструкция спрямо проценти на пропуски.
Обърнете внимание, че тези формули са за комбинирано четене и запис, като се приема кеш от
първо ниво за обратно записване. Очевидно кешът от първо ниво за запис ще изпрати всички записи
на второ ниво, а не само пропуските, и може да се използва буфер за запис.
Фигури B.14 и B.15 показват как честотата на пропуски и относителното време за изпълнение се
променят с размера на кеша от второ ниво за един дизайн. От тези цифри можем да придобием две
прозрения. Първият е, че процентът на пропуски в глобалния кеш е много подобен на процентът на
пропуски в единичния кеш на кеша от второ ниво, при условие че кешът от второ ниво е много по-голям
от кеша от първо ниво. Следователно нашата интуиция и знания за кешовете от първо ниво се
прилагат. Второто прозрение е, че честотата на пропуски в локалния кеш не е добра мярка за
вторичните кеши; това е функция на честотата на пропуски на кеша от първо ниво и следователно
може да варира чрез промяна на кеша от първо ниво. По този начин глобалната честота на пропуски в
кеша трябва да се използва, когато се оценяват кешовете от второ ниво.
С тези определения можем да разгледаме параметрите на кешовете от второ ниво. Основната
разлика между двете нива е, че скоростта на кеша от първо ниво влияе върху тактовата честота на
процесора, докато скоростта на кеша от второ ниво влияе само на наказанието за пропуск на кеша от
първо ниво. По този начин можем да разгледаме много алтернативи в кеша от второ ниво, които не
биха били избрани за кеша от първо ниво. Има два основни въпроса за дизайна на кеша от второ
ниво: ще намали ли средното време за достъп до паметта част от CPI и колко струва?
Първоначалното решение е размерът на кеш от второ ниво. Тъй като всичко в кеша от първо ниво
е вероятно да бъде в кеша от второ ниво, кешът от второ ниво трябва да е много по-голям от първия. Ако
кешовете от второ ниво са малко по-големи, местният процент на пропуски ще бъде висок. Това
наблюдение вдъхновява дизайна на огромни кеш памети от второ ниво - размера на основната памет в
по-старите компютри!
100%
99% 99% 98%
90% 96% Местен процент пропуски
88%
80%
Глобален процент на пропуски
Процент на пропуски в единичен кеш
70%
67%
60%
50% 55%
sestiaMr
51%
40% 46%
39%
30% 34%
20%
10% 6% 5% 4% 4% 4% 3% 2% 2% 2% 1% 1%
0% 4% 4% 3% 3% 16
4 8 32 64 128 256 512 1024 2048 4096
Фигура B.14 Скорости на пропуски спрямо размера на кеша за кешове на много нива. Кешовете от второ ниво, по-
малки от сбора на двата 64 KB кеша от първо ниво, нямат смисъл, както се отразява във високите нива на
пропуски. След 256 KB единичният кеш е в рамките на 10% от глобалните нива на пропуски.
Процентът на пропуски на кеш от едно ниво спрямо размера се изобразява спрямо локалния процент на пропуски и
глобалния процент на пропуски на кеш от второ ниво, използвайки 32 KB кеш от първо ниво. L2 кешовете
(унифицирани) бяха двупосочни, асоциативни с подмяна. Всеки имаше разделени L1 инструкции и кешове за
данни, които бяха 64 KB двупосочен набор, асоциативен с LRU заместване. Размерът на блока за L1 и L2 кеша
беше 64 байта. Данните бяха събрани както е показано на Фигура B.4.
Един въпрос е дали асоциативността на набора има повече смисъл за кешове от второ ниво.
Пример Като се имат предвид данните по-долу, какво е влиянието на асоциативността на кеша от второ ниво върху неговото
наказание за пропуск?
Време на попадение L2 за директно картографиране = 10 тактови цикъла.
Асоциативността на двупосочния набор увеличава времето за попадение с 0,1 тактов цикъл до 10,1 часовникови цикъла
цикли.
Локален пропуск L2 за директно картографиране = 25%.
Локален процент на пропуски L2 за двупосочен набор асоциативно = 20%.
Наказание за пропуск L2 = 200 тактови цикъла.
Отговор За директно картографиран кеш от второ ниво, наказанието за пропуск на кеш от първо ниво е
Пропуснете наказание 1-посочен L2 = 10 + 25% × 200 = 60,0 тактови цикъла

L2 попадение = 8 тактови цикъла

1.02
8192 L2 попадение = 16 тактови цикъла
1.06
1.10
4096
1.14
1.60
2048 г
1,65
мош
реоар в т
те
з)оBа Р
в
аK
и кно(
1.76
1024
1.82
1,94
512
1,99
2.34
256
2.39
1,00 1.25 1.50 1,75 2.00 2.25 2.50

Относително време за изпълнение
Фигура B.15 Относително време за изпълнение според размера на кеша от второ ниво. Двете ленти са за
различни часовникови цикли за попадение в L2 кеш. Референтното време за изпълнение от 1.00 е за ан
8192 KB кеш от второ ниво с латентност от 1 тактов цикъл при попадение от второ ниво. Тези
данните бяха събрани по същия начин, както на Фигура B.14, с помощта на симулатор за имитиране на
Алфа 21264.
Добавянето на цената на асоциативността увеличава цената на попадението само с 0,1 тактов цикъл, което
прави новото наказание за пропуск на кеш от първо ниво:
Miss penalty2-way L2 = 10,1 + 20% × 200 = 50,1 тактови цикъла
В действителност кеш паметта от второ ниво почти винаги се синхронизира с кеша от първо ниво и
процесора. Съответно, времето за попадение на второ ниво трябва да бъде цялостен брой тактови цикли.
Ако имаме късмет, ще намалим времето за попадение от второ ниво
до 10 цикъла; ако не, закръгляме до 11 цикъла. И двата избора са подобрение
върху директно картографирания кеш от второ ниво:
Miss penalty2-way L2 = 10 + 20% × 200 = 50,0 тактови цикъла
Miss penalty2-way L2 = 11 + 20% × 200 = 51,0 тактови цикъла
Сега можем да намалим наказанието за пропуски, като намалим процента на пропуски на кешовете от второ
ниво.
Друго съображение се отнася до това дали данните в кеша от първо ниво са вътре
кеша от второ ниво. Многостепенното включване е естествената политика за паметта
йерархии: L1 данните винаги присъстват в L2. Включването е желателно, тъй като съгласуваността между
I/O и кешовете (или между кешовете в мултипроцесор) може да бъде
определя се само чрез проверка на кеша от второ ниво.

Един недостатък на включването е, че измерванията могат да предложат по-малки блокове

за по-малкия кеш от първо ниво и по-големи блокове за по-големия кеш от второ ниво
кеш памет. Например, Pentium 4 има 64-байтови блокове в своите L1 кешове и 128-
байтови блокове в неговия L2 кеш. Включването все още може да се поддържа с повече работа върху a
мис от второ ниво. Кешът от второ ниво трябва да обезсили всички блокове от първо ниво
тази карта върху блока от второ ниво, който трябва да бъде заменен, причинявайки малко по-висок процент
на пропуски от първо ниво. За да избегнат подобни проблеми, много дизайнери на кеша запазват размера на блока
същото във всички нива на кеш паметта.
Но какво ще стане, ако дизайнерът може да си позволи само L2 кеш, който е малко по-голям от L1
кеша? Ако значителна част от пространството му се използва като a
излишно копие на L1 кеша? В такива случаи разумна противоположна политика е изключването на
много нива: L1 данни никога не се намират в L2 кеш. Обикновено при изключване пропускът на кеша в
L1 води до размяна на блокове между L1 и L2 вместо
замяна на блок L1 с блок L2. Тази политика предотвратява загубата
място в L2 кеша. Например, чипът AMD Opteron се подчинява на изключението
свойство, използвайки два 64 KB L1 кеша и 1 MB L2 кеш.
Както илюстрират тези въпроси, въпреки че начинаещият може да проектира първия и
кешове от второ ниво независимо, дизайнерът на кеша от първо ниво има a
по-проста работа при наличие на съвместим кеш от второ ниво. По-малко хазартно е да използвате a
чрез записване, например, ако има кеш за обратно записване на следващото ниво, за да действа
като бекстоп за повтарящи се записи и използва многостепенно включване.
Същността на всички дизайни на кеша е балансирането на бързи удари и малко пропуски. За
кешове от второ ниво, има много по-малко попадения, отколкото в кеша от първо ниво, така че
акцентът се измества към по-малко пропуски. Това прозрение води до много по-големи кешове и
техники за намаляване на процента на пропуски, като по-висока асоциативност и по-големи блокове.
Пета оптимизация: Даване на приоритет на пропуските при четене пред записите, за да
се намали наказанието за пропуски
Тази оптимизация обслужва четения, преди записите да са завършени. Започваме с

разглеждане на сложността на буфер за запис.
При записващия кеш най-важното подобрение е буферът за запис
с подходящ размер. Буферите за запис обаче усложняват достъпа до паметта
тъй като те може да съдържат актуализираната стойност на местоположение, необходимо при пропуск на четене.
Пример Вижте тази кодова последователност:
SW R3, 512(R0) ;M[512] R3 (кеш индекс 0)

LW R1, 1024(R0) ;R1 M[1024] (кеш индекс 0)
LW R2, 512(R0) ;R2 M[512] (кеш индекс 0)
Да приемем, че директно картографиран, записващ кеш, който картографира 512 и 1024 към
същия блок и буфер за запис от четири думи, който не се проверява при пропуск на четене. Ще
стойността в R2 винаги да е равна на стойността в R3?

Отговор Използвайки терминологията от Глава 2, това е опасност от четене след запис на данни в паметта. Нека
проследим достъп до кеша, за да видим опасността. Данните в R3 се поставят в буфера за запис
след съхраняването. Следното зареждане използва същия индекс на кеша и следователно е пропуск.
Втората инструкция за зареждане се опитва да постави стойността в местоположение 512 в
регистър R2; това също води до пропуск. Ако буферът за запис не е завършил записа в
местоположение 512 в паметта, четенето на местоположение 512 ще постави старата грешна стойност
в блока на кеша и след това в R2. Без подходящи предпазни мерки R3 не би бил равен на R2!
Най-простият изход от тази дилема е пропускът при четене да изчака, докато буферът за
запис се изпразни. Алтернативата е да проверите съдържанието на буфера за запис при
пропуснато четене и ако няма конфликти и системата с памет е налична, оставете пропуснатото
четене да продължи. На практика всички настолни и сървърни процесори използват последния
подход, давайки приоритет на четенето пред записа.
Цената на записите от процесора в кеша за обратно записване също може да бъде намалена.
Да предположим, че пропускът при четене ще замени мръсния блок на паметта. Вместо да записваме
мръсния блок в паметта и след това да четем паметта, можем да копираме мръсния блок в буфер,
след това да четем памет и след това да записваме памет. По този начин четенето на процесора,
което процесорът вероятно чака, ще приключи по-рано. Подобно на предишната ситуация, ако възникне
пропуск при четене, процесорът може или да спре, докато буферът се изпразни, или да провери
адресите на думите в буфера за конфликти.
След като имаме пет оптимизации, които намаляват санкциите за пропуски в кеша или
процентите на пропуски, е време да разгледаме намаляването на крайния компонент на средното
време за достъп до паметта. Времето за попадение е критично, защото може да повлияе на тактовата
честота на процесора; в много процесори днес времето за достъп до кеша ограничава скоростта на
тактовия цикъл, дори за процесори, които отнемат няколко тактови цикъла за достъп до кеша.
Следователно бързото време за попадение е многократно по-важно отвъд формулата за средно време
за достъп до паметта, защото помага на всичко.
Шеста оптимизация: Избягване на превод на адреси по време на
Индексиране на кеша за намаляване на времето за попадение
Дори малък и прост кеш трябва да се справи с преобразуването на виртуален адрес от процесора
към физически адрес за достъп до паметта. Както е описано в Раздел B.4, процесорите третират
основната памет като просто друго ниво на йерархията на паметта и по този начин адресът на
виртуалната памет, която съществува на диска, трябва да бъде картографиран върху основната
памет.
Насоките да направим общия случай бърз предполага да използваме виртуални адреси за
кеша, тъй като попаденията са много по-чести от пропуските. Такива кешове се наричат виртуални
кешове, като физическият кеш се използва за идентифициране на традиционния кеш, който

използва физически адреси. Както скоро ще видим, важно е да се разграничат две задачи:
индексиране на кеша и сравняване на адреси. По този начин проблемите са дали виртуален или
физически адрес се използва за индексиране на кеша и дали виртуален или физически адрес
се използва при сравнението на тагове. Пълна виртуална
адресирането както за индекси, така и за тагове елиминира времето за транслация на адрес

от попадение в кеша. Тогава защо не всеки изгражда виртуално адресирани кешове?
Една от причините е защитата. Защитата на ниво страница се проверява като част от
преобразуването на виртуален към физически адрес и трябва да бъде наложена независимо от
всичко. Едно решение е да копирате защитната информация от TLB при пропуск, да добавите
поле, което да я задържи, и да я проверявате при всеки достъп до виртуално адресирания кеш.
Друга причина е, че всеки път, когато се превключи процес, виртуалните адреси се отнасят
до различни физически адреси, което изисква изчистване на кеша. Фигура B.16 показва
въздействието върху процентите на пропуски на това промиване. Едно решение е да се
увеличи ширината на тага за адрес на кеша с таг за идентификатор на процеса (PID). Ако
операционната система присвои тези етикети на процеси, тя трябва да изчисти кеша само
когато PID се рециклира; тоест, PID разграничава дали данните в кеша са за
20% 0,6%
0,4%
18%
16%
Прочистване
1,1%
14% PIDs
0,5% Uniprocess
12%
1,8%
10%
sestiaMr
18,8%
0,6%
8%
13,0%
6% 2,7%
3,4%
8,7% 0,6%
4%
3,9%
0,4% 4,1% 4,3% 4,3% 4,3%
2% 3,9%
2,7% 0,4%
0,9% 0,3% 0,3% 0,3% 0,3%
0,4% 0,3% 0,3% 0,3%
0%
2K 4K 8K 16K 32K 64K 128K 256K 512K 1024K
Фигура B.16 Честота на пропуски спрямо размера на виртуално адресирания кеш на програма, измерен по
три начина: без превключвания на процеси (uniprocess), с превключвания на процеси, използващи таг за
идентификатор на процеса (PID), и с превключвания на процеси, но без PID (прочистване).
PID увеличават абсолютния процент на пропуски при еднопроцесорни процеси с 0,3% до 0,6% и спестяват от
0,6% до 4,3% при прочистване. Agarwal [1987] събра тези статистики за операционната система Ultrix, работеща
на VAX, като се приемат директно картографирани кешове с размер на блока от 16 байта. Обърнете внимание,
че процентът на пропуски се повишава от 128K на 256K. Такова неинтуитивно поведение може да възникне в
кешовете, тъй като промяната на размера променя картографирането на блокове памет върху блокове на
кеша, което може да промени честотата на пропускане на конфликт.
тази програма. Фигура B.16 показва подобрението в процентите на пропуски чрез използване на PID за
избягване на промиване на кеша.
Трета причина, поради която виртуалните кешове не са по-популярни, е, че операционните системи и
потребителските програми могат да използват два различни виртуални адреса за един и същ физически
адрес. Тези дублирани адреси, наречени синоними или псевдоними, могат да доведат до две копия на едни и
същи данни във виртуален кеш; ако едното е модифицирано, другото ще има грешна стойност. С физически
кеш това няма да се случи, тъй като достъпите първо ще бъдат преведени към същия физически кеш блок.
Хардуерните решения на проблема със синонимите, наречени антиалиасинг, гарантират на всеки кеш
блок уникален физически адрес. Например, AMD Opteron използва 64 KB кеш за инструкции с 4 KB страница
и двупосочна асоциативност на набора; следователно хардуерът трябва да обработва псевдоними, свързани

с трите виртуални адресни бита в зададения индекс. Той избягва псевдонимите, като просто проверява
всичките осем възможни местоположения при пропуск - два блока във всеки от четирите комплекта - за да се
увери, че никой не съответства на физическия адрес на данните, които се извличат. Ако бъде намерен такъв,
той се анулира, така че когато новите данни се заредят в кеша, техният физически адрес е гарантирано
уникален.
Софтуерът може да направи този проблем много по-лесен, като принуди псевдонимите да споделят някои
адресни битове. По-стара версия на UNIX от Sun Microsystems, например, изискваше всички псевдоними да
бъдат идентични в последните 18 бита от техните адреси; това ограничение се нарича оцветяване на
страницата. Обърнете внимание, че оцветяването на страницата е просто зададен асоциативен картографски
пинг, приложен към виртуална памет: 4 KB (212 ) страници се картографират с помощта на 64 (26 ) набора, за да
се гарантира, че физическият и виртуалният адрес съвпадат в последните 18 бита. Това ограничение
означава, че директно картографиран кеш, който е 218 (256K) байта или по-малък, никога не може да има
дублирани физически адреси за блокове. От гледна точка на кеша, оцветяването на страницата ефективно
увеличава отместването на страницата, тъй като софтуерът гарантира, че последните няколко бита от
адреса на виртуалната и физическата страница са идентични.
Последната област на безпокойство при виртуалните адреси е I/O. I/O обикновено използва физически
адреси и следователно ще изисква картографиране към виртуални адреси за взаимодействие с виртуален
кеш. (Въздействието на I/O върху кешовете се обсъжда допълнително в Приложение D.)
Една алтернатива за извличане на най-доброто от виртуалния и физическия кеш е да се използва част
от отместването на страницата – частта, която е идентична във виртуалния и физическия адрес – за
индексиране на кеша. В същото време, когато кешът се чете с помощта на този индекс, виртуалната част от
адреса се превежда и съвпадението на етикета използва физически адреси.
Тази алтернатива позволява четенето на кеша да започне незабавно, но въпреки това сравнението на
таговете все още е с физически адреси. Ограничението на тази виртуално индексирана, физически
маркирана алтернатива е, че директно картографираният кеш не може да бъде по-голям от размера на
страницата. Например в кеша за данни на Фигура B.5 на страница B-13 индексът е 9 бита, а изместването на
блока на кеша е 6 бита. За да използвате този трик, размерът на виртуалната страница трябва да бъде поне
2(9+6) байта или 32 KB. Ако не, част от индекса трябва да бъде преведена от виртуален във физически адрес.
Фигура B.17 показва организацията на кеш паметта, буферите за наблюдение на транслацията (TLB) и
виртуалната памет, когато се използва тази техника.

Виртуален адрес <64>
Адрес за сравнение на TLB етикет <43> TLB индекс <7> L1 кеш индекс <8> Блоково отместване <6>

Адрес за сравнение на етикет L1 <26>

=? =?
=?
Фигура B.17 Цялостната картина на хипотетична йерархия на паметта, преминаваща от виртуален адрес към L2 достъп до кеша. Размерът на страницата е 16 KB. TLB
е двупосочен асоциативен набор с 256 записа. Кешът L1 е директно картографиран 16 KB, а кешът L2 е четирипосочен асоциативен набор с общо 4 MB. И двете
използват 64-байтови блокове. Виртуалният адрес е 64 бита, а физическият адрес е 40 бита.
Асоциативността може да запази индекса във физическата част на адреса и въпреки

това да поддържа голям кеш. Спомнете си, че размерът на индекса се контролира от тази
формула:
Индекс Размер на кеша
2 = -------------------------------------------------- ---------------------
Размер на блока× Задайте асоциативност
Например удвояването на асоциативността и удвояването на размера на кеша не променя

размера на индекса. Кешът на IBM 3033, като краен пример, е 16-посочен асоциативен
набор, въпреки че проучванията показват, че има малка полза за пропускане
Хит Мис Мис Хардуерна

Техника време дузпа процент
сложност Коментар
– + 0
По-голям размер на блока Тривиално; Pentium 4 L2 използва 128 байта
– + 1
По-голям размер на кеша Широко използван, особено за L2
кешове
– + 1
По-висока асоциативност Широко използван
Многостепенни кешове + 2 Скъп хардуер; по-трудно, ако L1 размер на

блок L2 размер на блок; широко използван
Приоритет на четене пред писане + 1 Широко използван
Избягване на превод на адрес по време на + 1 Широко използван
индексиране на кеша
Фигура B.18 Обобщение на основните оптимизации на кеша, показващи въздействието върху производителността и сложността на кеша за
техниките в това приложение. Обикновено една техника помага само на един фактор. + означава, че техниката се подобрява
факторът, – означава, че вреди на този фактор, а празното означава, че няма влияние. Мярката за сложност е субективна, с
0 е най-лесният, а 3 е предизвикателство.
нива над асоциативността на 8-посочен набор. Тази висока асоциативност позволява 64 KB

кеша, който да бъде адресиран с физически индекс, въпреки недостатъка от 4 KB
страници в архитектурата на IBM.
Резюме на основната оптимизация на кеша
Техниките в този раздел за подобряване на броя на пропуските, наказанието за пропуски и времето за попадение
като цяло влияят върху другите компоненти на уравнението за средния достъп до паметта
както и сложността на йерархията на паметта. Фигура B.18 обобщава
тези техники и оценява въздействието върху сложността, като + означава това
техниката подобрява фактора, което означава, че вреди на този фактор и празно
което означава, че няма влияние. Нито една оптимизация в тази фигура не помага повече от една
категория.
Б.4 Виртуална памет
. . . е създадена система, която да направи комбинацията от основни барабани да изглежда на

програмист като магазин на едно ниво, като се извършват необходимите прехвърляния
автоматично.
Kilburn et al. [1962]
Във всеки един момент компютрите изпълняват множество процеси, всеки със своя
собствено адресно пространство. (Процесите са описани в следващия раздел.) Би било също
скъпо да се отдели памет на стойност пълно адресно пространство за всеки процес,
B.4 Виртуална памет B-41
особено след като много процеси използват само малка част от адресното си пространство.
Следователно трябва да има средство за споделяне на по-малко количество физическа памет
сред много процеси.
Един от начините да направите това, виртуалната памет, разделя физическата памет на
блокове и ги разпределя към различни процеси. Присъщо на такъв подход трябва да бъде схема
за защита , която ограничава процеса до блоковете, принадлежащи само на този процес. Повечето
форми на виртуална памет също намаляват времето за стартиране на програма, тъй като не всички
кодове и данни трябва да бъдат във физическата памет, преди програмата да може да започне.
Въпреки че защитата, осигурена от виртуалната памет, е от съществено значение за
настоящите компютри, споделянето не е причината за изобретяването на виртуалната памет. Ако
една програма стане твърде голяма за физическа памет, работата на програмиста е да я направи подходяща.
Програмистите разделят програмите на части, след което идентифицират частите, които са
взаимно изключващи се, и зареждат или разтоварват тези наслагвания под контрола на
потребителската програма по време на изпълнение. Програмистът гарантира, че програмата
никога не се опитва да получи достъп до повече физическа основна памет, отколкото е в компютъра,
и че правилното наслагване се зарежда в точното време. Както можете да си представите, тази
отговорност ерозира продуктивността на програмиста.
Виртуалната памет е изобретена, за да облекчи програмистите от това бреме; той
автоматично управлява двете нива на йерархията на паметта, представена от основна памет и
вторично съхранение. Фигура B.19 показва картографирането на виртуална памет към
физическа памет за програма с четири страници.
Виртуален адрес Физически адрес

0 А 0
4K б 4K °С
8K °С 8K
12K д 12K
16K А Физическа основна памет

Виртуална памет 20K
24K б
28K
диск
д
Фигура B.19 Логическата програма в нейното непрекъснато виртуално адресно пространство е

показана отляво. Състои се от четири страници A, B, C и D. Действителното местоположение на
три от блоковете е във физическата основна памет, а другият се намира на диска.
В допълнение към споделянето на защитено пространство в паметта и автоматичното управление

йерархията на паметта, виртуалната памет също опростява зареждането на програмата за
екзекуция. Наречен преместване, този механизъм позволява една и съща програма да работи
всяко място във физическата памет. Програмата на Фигура B.19 може да бъде поставена навсякъде
във физическата памет или диска само чрез промяна на картографирането между тях.
(Преди популярността на виртуалната памет, процесорите включват преместване
регистрирайте се само за тази цел.) Алтернатива на хардуерно решение би било
софтуер, който променя всички адреси в програмата при всяко стартиране.
Няколко общи идеи за йерархия на паметта от Глава 1 относно кешовете са
аналогично на виртуалната памет, въпреки че много от термините са различни. Страница или
segment се използва за блок, а грешка на страницата или грешка на адреса се използва за пропуск. с
виртуална памет, процесорът произвежда виртуални адреси , които се транслират от a
комбинация от хардуер и софтуер към физически адреси, които имат достъп до главния
памет. Този процес се нарича картографиране на паметта или преобразуване на адреси. днес,
двете йерархични нива на паметта, контролирани от виртуалната памет, са DRAM и
магнитни дискове. Фигура B.20 показва типичен диапазон от параметри на йерархията на паметта
за виртуална памет.
Има допълнителни разлики между кеш паметта и виртуалната памет
тези количествени, посочени на фигура B.20:
Подмяната при пропуски в кеша се контролира основно от хардуера, докато

подмяната на виртуалната памет се контролира основно от операционната система.
Колкото по-дълго наказание за пропуск означава, че е по-важно да вземете добро решение,
така че операционната система може да се включи и да отнеме време да реши какво да прави
замени.
Размерът на адреса на процесора определя размера на виртуалната памет, но

размерът на кеша не зависи от размера на адреса на процесора.
Параметър Кеш памет от първо ниво Виртуална памет
Размер на блок (страница) 16–128 байта 1– 4096–65 536 байта
Хит време 3 тактови цикъла 100–200 тактови цикъла
Пропусната дузпа 8–200 тактови цикъла 1 000 000–10 000 000 тактови цикъла
(време за достъп) (6–160 тактови цикъла) (800 000–8 000 000 тактови цикъла)
(време за прехвърляне) (2–40 тактови цикъла) (200 000–2 000 000 тактови цикъла)
Miss rate 0,1–10% 0,00001–0,001%
Адресно съпоставяне на 25–45-битов физически адрес към 32–64-битов виртуален адрес

14–20-битов кеш адрес към 25–45-битов физически адрес
Фигура B.20 Типични диапазони от параметри за кешове и виртуална памет. Виртуален

параметрите на паметта представляват увеличения от 10 до 1 000 000 пъти спрямо параметрите на кеша.
Обикновено кешовете от първо ниво съдържат най-много 1 MB данни, докато физическите
паметта съдържа 256 MB до 1 TB.
Освен че действа като резервно хранилище на по-ниско ниво за основната памет в
йерархия, вторичното хранилище също се използва за файловата система. Всъщност файловата
система заема по-голямата част от вторичното хранилище. Обикновено не е в адресното пространство.
Виртуалната памет също така включва няколко свързани техники. Системите с виртуална памет
могат да бъдат категоризирани в два класа: тези с блокове с фиксиран размер,
наречени страници, и тези с блокове с променлив размер, наречени сегменти. Страниците обикновено
са фиксирани на 4096 до 8192 байта, докато размерът на сегмента варира. Най-големият сегмент
поддържани на всеки процесор варира от 216 байта до 232 байта; най-малкият
сегментът е 1 байт. Фигура B.21 показва как двата подхода могат да разделят кода
и данни.
Решението да се използва странирана виртуална памет срещу сегментирана виртуална памет
засяга процесора. Странираното адресиране има единичен адрес с фиксиран размер, разделен на
номер на страница и отместване в рамките на страница, аналогично на адресирането на кеша. Сингъл
Код Данни
Пейджинг
Сегментиране
Фигура B.21 Пример за това как странирането и сегментирането разделят програма.
Страница сегмент
Думи на адрес Видим един Две (сегмент и отместване)
ли програмист? Невидим за приложния Може да се вижда от приложния

програмист програмист
Смяна на блок Тривиално (всички блокове са с Трудно (трябва да се намери непрекъсната,

еднакъв размер) с променлив размер, неизползвана част
от основната памет)
Неефективно използване на паметта Вътрешна фрагментация Външна фрагментация (неизползвани

(неизползвана част от страницата) части от основната памет)
Ефективен дисков трафик Да (коригирайте размера на страницата, Не винаги (малките сегменти могат да
за да балансирате времето за достъп и прехвърлят само няколко байта)
времето за прехвърляне)
Фигура B.22 Пейджинг срещу сегментиране. И двете могат да губят памет, в зависимост от
размера на блока и колко добре сегментите се вписват в основната памет. Програмните езици с неограничени
указатели изискват наличието както на сегмента, така и на адреса
премина. Хибриден подход, наречен сегментирани сегменти, дава най-доброто от двата свята:
Сегментите са съставени от страници, така че замяната на блок е лесна, но сегмент може да бъде
се третира като логическа единица.

адрес не работи за сегментирани адреси; променливият размер на сегментите изисква 1 дума за номер
на сегмент и 1 дума за отместване в рамките на сегмент, за общо 2 думи. Несегментираното адресно
пространство е по-лесно за компилатора.
Плюсовете и минусите на тези два подхода са добре документирани в учебниците по операционни
системи; Фигура B.22 обобщава аргументите. Поради проблема със замяната (третият ред на фигурата),
малко компютри днес използват чисто сегментиране. Някои компютри използват хибриден подход,
наречен странирани сегменти, в който сегментът е цял брой страници. Това опростява подмяната, тъй
като не е необходимо паметта да е непрекъсната и не е необходимо пълните сегменти да са в основната
памет. По-скорошен хибрид е компютърът да предлага множество размери на страници, като по-големите
размери са мощности на 2 пъти най-малкия размер на страницата.
Вграденият процесор IBM 405CR, например, позволява 1 KB, 4 KB (22 × 1 KB), 16 KB (24 × 1 KB), 64 KB (26 × 1
KB), 256 KB (28 × 1 KB), 1024 KB (210 × 1 KB) и 4096 KB (212 × 1 KB), за да действа като една страница.
Преглед на четири въпроса за йерархията на паметта
Вече сме готови да отговорим на четирите въпроса за йерархията на паметта за виртуална памет.
Q1: Къде може да бъде поставен блок в основната памет?
Наказанието за пропуск за виртуална памет включва достъп до въртящо се магнитно устройство за

съхранение и следователно е доста високо. Предвид избора между по-ниски проценти на пропуски или
по-прост алгоритъм за поставяне, дизайнерите на операционни системи обикновено избират по-ниски
проценти на пропуски поради прекомерното наказание за пропуски. По този начин операционните
системи позволяват блоковете да бъдат поставени навсякъде в основната памет. Съгласно терминологията
във Фигура B.2 на страница B-8, тази стратегия ще бъде обозначена като напълно асоциативна.
Q2: Как се намира блок, ако е в основната памет?
Както странирането, така и сегментирането разчитат на структура от данни, която е индексирана от

номера на страницата или сегмента. Тази структура от данни съдържа физическия адрес на блока. За
сегментиране отместването се добавя към физическия адрес на сегмента, за да се получи крайният
физически адрес. За страниране отместването просто се свързва с този физически адрес на страница
(вижте Фигура B.23).
Тази структура от данни, съдържаща физическите адреси на страници, обикновено приема
формата на таблица на страниците. Индексиран по номера на виртуалната страница, размерът на
таблицата е броят на страниците във виртуалното адресно пространство. Като се има предвид 32-
битов виртуален адрес, 4 KB страници и 4 байта на запис в таблицата на страниците (PTE), размерът
на таблицата на страниците ще бъде (232/212) × 22 = 222 или 4 MB.
За да намалят размера на тази структура от данни, някои компютри прилагат хешираща функция
към виртуалния адрес. Хешът позволява структурата на данните да бъде дължината на броя на
физическите страници в основната памет. Този брой може да бъде много по-малък от броя на виртуалните
страници. Такава структура се нарича таблица с обърната страница. Използвайки предишния пример,
физическа памет от 512 MB ще се нуждае само от 1 MB (8 × 512 MB/4 KB) за таблица с обърнати страници;
допълнителните 4 байта на
Виртуален адрес
Номер на виртуална страница Отместване на страницата
Основен
памет
Страница
маса Физически адрес
Фигура B.23 Преобразуване на виртуален адрес към физически адрес чрез таблица на страници.
записът в таблицата на страниците е за виртуалния адрес. HP/Intel IA-64 покрива и двете бази
като предлага както таблици с традиционни страници, така и таблици с обърнати страници, оставяйки
избор на механизъм на програмиста на операционната система.
За да намалят времето за превод на адреси, компютрите използват кеш, предназначен за тях
преводи на адреси, наречени буфер за преглед на превода или просто превод
буфер, описан по-подробно накратко.
Q3: Кой блок трябва да бъде заменен при пропуск на виртуална памет?
Както споменахме по-рано, основната насока за операционната система е минимизиране
грешки на страницата. В съответствие с тази насока почти всички операционни системи се опитват
заменете най-малко използвания напоследък (LRU) блок, защото ако миналото предсказва
бъдеще, това е по-малко вероятно да е необходимо.
За да помогнат на операционната система да оцени LRU, много процесори предоставят използване
бит или референтен бит, който се задава логически при всеки достъп до страница. (Да се
намаляване на работата, всъщност е зададено само при пропуск на буфер за превод, което е
описано накратко.) Операционната система периодично изчиства използваните битове и по-късно
ги записва, за да може да определи кои страници са били докоснати по време на определено
времеви период. Като следи по този начин, операционната система може да избере страница
това е сред най-малко цитираните наскоро.
Q4: Какво се случва при запис?
Нивото под основната памет съдържа въртящи се магнитни дискове, които отнемат милиони
от тактови цикли за достъп. Поради голямото разминаване във времето за достъп, никой
все още е изградил операционна система за виртуална памет, която записва през основната памет на
диска във всеки магазин от процесора. (Тази забележка не трябва да се тълкува като възможност да
станете известни, като сте първият, който построи такъв!) По този начин,
стратегията за запис винаги е обратно запис.

Тъй като цената на ненужен достъп до следващото по-ниско ниво е толкова висока, системите с
виртуална памет обикновено включват мръсен бит. Той позволява блокове да бъдат записвани на диск
само ако са били променени, след като са били прочетени от диска.
Техники за бърз превод на адреси
Таблиците на страниците обикновено са толкова големи, че се съхраняват в основната памет и понякога

се странират сами. Пейджинг означава, че всеки достъп до паметта логично отнема поне два пъти повече
време, с един достъп до паметта за получаване на физическия адрес и втори достъп за получаване на
данните. Както бе споменато в глава 2, ние използваме локалност, за да избегнем допълнителния достъп
до паметта. Чрез запазване на преводите на адреси в специален кеш, достъпът до паметта рядко
изисква втори достъп за преобразуване на данните. Този специален кеш за транслация на адреси се
нарича транслационен буфер за преглед (TLB), наричан още транслационен буфер (TB).
Записът в TLB е като запис в кеша, където тагът съдържа части от виртуалния адрес, а частта с
данни съдържа номер на рамка на физическа страница, защитно поле, валиден бит и обикновено бит за
използване и бит за мръсен бит. За да промени номера на рамката на физическата страница или
защитата на запис в таблицата на страниците, операционната система трябва да се увери, че старият
запис не е в TLB; в противен случай системата няма да работи правилно. Обърнете внимание, че този
мръсен бит означава, че съответната страница е мръсна, а не че преводът на адресите в TLB е мръсен,
нито че определен блок в кеша за данни е мръсен. Операционната система нулира тези битове, като
промени стойността в таблицата на страниците и след това прави невалиден съответния TLB запис.
Когато записът се презареди от таблицата на страниците, TLB получава точно копие на битовете.
Фигура B.24 показва TLB организацията на данните на Opteron, като всяка стъпка от транслацията е
обозначена. Този TLB използва напълно асоциативно разположение; по този начин преводът започва
(стъпки 1 и 2) чрез изпращане на виртуалния адрес до всички тагове. Разбира се, етикетът трябва да
бъде маркиран като валиден, за да позволи съвпадение. В същото време типът достъп до паметта се
проверява за нарушение (също в стъпка 2) спрямо информацията за защита в TLB.
По причини, подобни на тези в случая с кеша, не е необходимо да се включват 12-те бита от
отместването на страницата в TLB. Съвпадащият етикет изпраща съответния физически адрес чрез
ефективно мултиплексор 40:1 (стъпка 3). След това отместването на страницата се комбинира с рамката
на физическата страница, за да се образува пълен физически адрес (стъпка 4). Размерът на адреса е
40 бита.
Преобразуването на адрес може лесно да бъде на критичния път, определящ тактовия цикъл на
процесора, така че Opteron използва виртуално адресирани, физически маркирани L1 кешове.
Избор на размер на страницата
Най-очевидният архитектурен параметър е размерът на страницата. Изборът на страницата е въпрос

на балансиране на силите, които предпочитат по-голям размер на страницата спрямо тези, които
предпочитат по-малък размер. Следното предпочита по-голям размер:
Номер на Отместване
виртуална на страницата
страница <36> <12>
<1> <1> <1> <36> <28>

1 2
V R/WU/S д А Етикет Физически адрес
(12 бита адрес от

нисък ред)
<12>
40-
3 40:1 мултиплексор
<28> 4 битов
физически адрес
(28 бита адрес от висок порядък)
Фигура B.24 Работа на TLB за данни на Opteron по време на транслация на адреси. Четирите
стъпки на попадение в TLB са показани като оградени числа. Този TLB има 40 записа. Раздел B.5
описва различните полета за защита и достъп на запис в таблица на страници на Opteron.
Размерът на таблицата със страници е обратно пропорционален на размера на страницата; следователно
паметта (или други ресурси, използвани за картата на паметта) могат да бъдат спестени чрез
увеличаване на страниците.
Както бе споменато в Раздел B.3, по-големият размер на страницата може да позволи по-големи кешове
бързи пъти за попадение в кеша.
Прехвърляне на по-големи страници към или от вторично хранилище, евентуално по мрежа-
работа, е по-ефективно от прехвърлянето на по-малки страници.
Броят на TLB записите е ограничен, така че по-големият размер на страницата означава, че повече памет
може да бъде картографирана ефективно, като по този начин се намалява броят на пропуските на TLB.
Поради тази последна причина последните микропроцесори решиха да поддържат множество размери на
страници; за някои програми пропуските на TLB могат да бъдат толкова значими за CPI, колкото и
пропуските в кеша.
Основната мотивация за по-малък размер на страницата е спестяването на място за съхранение.
Малкият размер на страницата ще доведе до по-малко загуба на място за съхранение, когато съседен регион
на виртуална памет не е равен по размер на кратно на размера на страницата. Терминът за тази
неизползвана памет в една страница е вътрешна фрагментация. Ако приемем, че всеки процес има три
основни сегмента (текст, купчина и стек), средната загуба на място за съхранение на процес ще бъде 1,5
пъти размера на страницата. Това количество е пренебрежимо малко за компютри със стотици мегабайти
памет и размер на страницата от 4 KB до 8 KB. Разбира се, когато размерите на страниците станат много
големи (повече от 32 KB), паметта (както основната, така и вторичната) може да бъде загубена, както и I/O
честотната лента. Последната грижа е времето за стартиране на процеса; много процеси са малки, така че
големият размер на страницата би удължил времето за извикване на процес.

Резюме на виртуалната памет и кешовете
С виртуална памет, TLB, кешове от първо ниво и кешове от второ ниво, всички картографиращи пинг
части от виртуалното и физическото адресно пространство, може да стане объркващо какво
бита отиват къде. Фигура B.25 дава хипотетичен пример за преминаване от 64-битов виртуален адрес
към 41-битов физически адрес с две нива на кеш. Този L1 кеш
е виртуално индексиран, физически маркиран както от размера на кеша, така и от размера на страницата
са 8 KB. L2 кеш паметта е 4 MB. Размерът на блока и за двете е 64 байта.
Виртуален адрес <64>
Адрес за сравнение на TLB етикет <43> TLB индекс <8> L1 кеш индекс <7> Блоково отместване <6>

Адрес за сравнение на L1 етикет <28>

=? =?
=?
Фигура B.25 Цялостната картина на хипотетична йерархия на паметта, преминаваща от виртуален адрес към L2 кеш
достъп. Размерът на страницата е 8 KB. TLB е директно картографиран с 256 записа. Кешът L1 е директно картографиран 8 KB и
L2 кешът е директно картографиран 4 MB. И двете използват 64-байтови блокове. Виртуалният адрес е 64 бита, а физическият адрес
е 41 бита. Основната разлика между тази проста фигура и истински кеш е репликацията на части от тази фигура.
B.5 Защита и примери за виртуална памет B-49
Първо, 64-битовият виртуален адрес е логически разделен на номер на виртуална страница и
отместване на страницата. Първият се изпраща до TLB, за да бъде преведен във физически адрес, а
старшият бит на втория се изпраща до L1 кеша, за да действа като индекс. Ако съвпадението на TLB е
попадение, тогава физическият номер на страницата се изпраща до L1 кеша за проверка за съвпадение.

Ако съвпада, това е попадение в кеш L1. След това отместването на блока избира думата за процесора.
Ако проверката на L1 кеша доведе до пропуск, физическият адрес се използва за опит с L2 кеша.
Средната част от физическия адрес се използва като индекс към 4 MB L2 кеш памет. Полученият L2 кеш
маркер се сравнява с горната част на физическия адрес, за да се провери за съвпадение. Ако съвпада,
имаме L2 кеш хит и данните се изпращат до процесора, който използва отместването на блока, за да
избере желаната дума. При пропуск L2 физическият адрес се използва за извличане на блока от паметта.
Въпреки че това е прост пример, основната разлика между този чертеж и истинския кеш е
репликацията. Първо, има само един L1 кеш. Когато има два L1 кеша, горната половина на диаграмата се
дублира. Обърнете внимание, че това ще доведе до два TLB, което е типично. Следователно един кеш и TLB
са за инструкции, управлявани от компютъра, а един кеш и TLB са за данни, управлявани от ефективния

адрес.
Второто опростяване е, че всички кешове и TLB са директно картографирани.
Ако някои бяха n-way set асоциативни, тогава бихме репликирали всеки набор от памет за тагове,
компаратори и памет за данни n пъти и бихме свързали памети за данни с n:1 мултиплексор, за да изберем
попадение. Разбира се, ако общият размер на кеша остане същият, индексът на кеша също ще се свие с log2n
бита съгласно формулата на фигура B.7 на страница B-22.
Б.5 Защита и примери за виртуална памет

Изобретяването на мултипрограмирането, при което един компютър ще бъде споделен от няколко програми,
работещи едновременно, доведе до нови изисквания за защита и споделяне между програмите. Тези
изисквания са тясно свързани с виртуалната памет в днешните компютри и затова разглеждаме темата
тук заедно с два примера за виртуална памет.
Мултипрограмирането води до концепцията за процес. Метафорично, процесът е въздухът за дишане
и жизненото пространство на програмата - тоест работеща програма плюс всяко състояние, необходимо за
продължаване на нейното изпълнение. Споделянето на време е вариант на мултипрограмиране, което споделя
процесора и паметта с няколко интерактивни потребители едновременно, създавайки илюзията, че всички
потребители имат свои собствени компютри.
Следователно във всеки един момент трябва да е възможно превключването от един процес към друг.
Този обмен се нарича превключване на процес или превключване на контекст.
Един процес трябва да работи правилно, независимо дали се изпълнява непрекъснато от началото до
края, или се прекъсва многократно и се превключва с други процеси.
Отговорността за поддържане на правилно поведение на процеса се споделя от дизайнерите на компютъра и
операционната система. Компютърният дизайнер трябва да гарантира, че процесорната част от състоянието
на процеса може да бъде запазена и

възстановен. Дизайнерът на операционната система трябва да гарантира, че процесите не го правят

се намесват взаимно в изчисленията си.
Най-сигурният начин да защитите състоянието на един процес от друг е да
копирайте текущата информация на диск. След това обаче ще се наложи превключване на процеса
секунди - твърде дълго за среда за споделяне на време.
Този проблем се решава, като операционните системи разделят основната памет така
че няколко различни процеса имат своето състояние в паметта едновременно. Това
разделение означава, че дизайнерът на операционната система се нуждае от помощ от компютъра
дизайнер, за да осигури защита, така че един процес да не може да променя друг.
Освен защита, компютрите осигуряват и споделяне на код и данни
между процесите, за да позволи комуникация между процесите или за запазване на паметта чрез
намаляване на броя на копията на идентична информация.
Защита на процесите
Процесите могат да бъдат защитени един от друг, като имат свои собствени таблици на страници,
всяка сочи към отделни страници от паметта. Очевидно потребителските програми трябва да бъдат
им е попречено да променят своите таблици на страници или защитата ще бъде заобиколена.
Защитата може да ескалира в зависимост от опасенията на компютърния дизайнер или купувача.
Пръстените , добавени към защитната структура на процесора, разширяват защитата на достъпа до
паметта от две нива (потребител и ядро) до
много повече. Подобно на военна класификационна система от строго секретни, секретни,
поверителни и некласифицирани, концентричните пръстени от нива на сигурност позволяват най-много
доверен за достъп до всичко, вторият най-доверен за достъп до всичко, освен
най-вътрешното ниво и т.н. „Гражданските“ програми се ползват с най-малко доверие
и следователно имат най-ограничен обхват на достъп. Възможно е също така да има ограничения за
това кои части от паметта могат да съдържат код— защита за изпълнение— и
дори на входа между нивата. Защитата на Intel 80x86
структура, която използва пръстени, е описана по-късно в този раздел. Не е ясно
дали пръстените са подобрение на практика в сравнение с простата система на потребителя
и режими на ядрото.
Тъй като опасенията на дизайнера ескалират до трепет, тези прости пръстени

може да не е достатъчно. Ограничаване на свободата, дадена програма във вътрешното светилище
изисква нова класификационна система. Вместо военен модел, аналогията на
тази система е за ключове и ключалки: Програмата не може да отключи достъпа до данните, освен ако
има ключа. За да бъдат полезни тези ключове или възможности , хардуерът и операционната система
трябва да могат изрично да ги предават от една програма на друга
без да позволява на самата програма да ги фалшифицира. Такава проверка изисква голяма
сделка за хардуерна поддръжка, ако времето за проверка на ключовете трябва да бъде ниско.
Архитектурата 80x86 е изпробвала няколко от тези алтернативи през годините.

Тъй като обратната съвместимост е една от насоките на тази архитектура, the
най-новите версии на архитектурата включват всички нейни експерименти във виртуална среда
памет. Тук ще разгледаме две от опциите: първо по-стария сегментиран адрес
пространство и след това по-новото плоско, 64-битово адресно пространство.
Пример за сегментирана виртуална памет:

Защита в Intel Pentium
Втората система е най-опасната система, която човек някога е проектирал. . . .
Общата тенденция е към прекомерно проектиране на втората система, като се използват всички
идеи и украшения, които бяха предпазливо отклонени от първата.
FP Брукс, младши
Митичният човек-месец (1975)
Оригиналът 8086 използва сегменти за адресиране, но не предоставя нищо за виртуална памет или
за защита. Сегментите имаха базови регистри, но без обвързани регистри и без проверки за
достъп и преди сегментен регистър да може да бъде зареден, съответният сегмент трябваше да бъде
във физическата памет. Отдадеността на Intel на виртуалната памет и защитата е очевидна в
наследниците на 8086, с няколко полета, разширени за поддръжка на по-големи адреси. Тази защитна
схема е сложна, с много детайли, внимателно проектирани, за да се опитат да избегнат пропуски в
сигурността. Ще го наричаме IA-32. Следващите няколко страници подчертават някои от предпазните
мерки на Intel; ако намирате четенето за трудно, представете си колко е трудно да ги приложите!
Първото подобрение е да се удвои традиционният двустепенен модел на защита: IA-32 има

четири нива на защита. Най-вътрешното ниво (0) съответства на традиционния режим на ядрото, а
най-външното ниво (3) е най-малко привилегированият режим. IA-32 има отделни стекове за всяко
ниво, за да се избегнат пробиви в сигурността между нивата. Има и структури от данни, аналогични
на традиционните таблици на страници, които съдържат физическите адреси за сегменти, както
и списък с проверки, които трябва да се направят на преведените адреси.
Дизайнерите на Intel не спират дотук. IA-32 разделя адресното пространство, позволявайки

както на операционната система, така и на потребителя да има достъп до пълното пространство.
Потребителят на IA-32 може да извика рутина на операционната система в това пространство и
дори да й предаде параметри, като запази пълната защита. Това безопасно повикване не е
тривиално действие, тъй като стекът за операционната система е различен от стека на
потребителя. Освен това IA-32 позволява на операционната система да поддържа нивото на защита на
извиканата рутина за параметрите, които са й предадени. Тази потенциална вратичка в
защитата е предотвратена, като не се позволява на потребителския процес да поиска от
операционната система индиректен достъп до нещо, до което тя самата не би могла да получи достъп.
(Такива вратички в сигурността се наричат троянски коне.)
Дизайнерите на Intel се ръководят от принципа да се доверяват възможно най-малко на
операционната система, като същевременно поддържат споделяне и защита. Като пример за
използване на такова защитено споделяне, да предположим, че програма за заплати изписва чекове
и също така актуализира информацията от година до дата за общи плащания на заплати и обезщетения.
По този начин искаме да дадем на програмата възможността да чете заплатата и информацията от
началото на годината и да променя информацията от началото на годината, но не и заплатата. Скоро ще
видим механизма за поддръжка на такива функции. В останалата част от този подраздел ще
разгледаме общата картина на защитата IA-32 и ще разгледаме нейната мотивация.
Добавяне на проверка на граници и картографиране на паметта
Първата стъпка в подобряването на процесора на Intel беше получаването на сегментирано

адресиране за проверка на границите, както и предоставяне на база. Вместо базов адрес,
сегментните регистри в IA-32 съдържат индекс към структура от данни на виртуалната памет,
наречена дескрипторна таблица. Дескрипторните таблици играят ролята на традиционни таблици на страници.
В IA-32 еквивалентът на запис в таблица на страници е сегментен дескриптор. Съдържа полета,
намерени в PTE:
Настоящ бит— Еквивалентен на валидния PTE бит, използван за указване, че това е валидно
превод
Основно поле— Еквивалентно на адрес на рамка на страница, съдържащ физическия

адрес на първия байт на сегмента
Бит за достъп — като референтния бит или бит за използване в някои архитектури
полезен за заместващи алгоритми
Поле за атрибути — Определя валидните операции и нива на защита за операции, които

използват този сегмент
Има и поле за ограничение, което не се среща в странираните системи, което установява горната
граница на валидните отмествания за този сегмент. Фигура B.26 показва примери за дескриптори
на сегменти IA-32.
IA-32 предоставя опционална система за пейджинг в допълнение към това сегментирано
адресиране. Горната част на 32-битовия адрес избира дескриптора на сегмента, а средната част
е индекс в таблицата на страниците, избрана от дескриптора.
По-долу описваме системата за защита, която не разчита на страниране.
Добавяне на споделяне и защита
За да се осигури защитено споделяне, половината от адресното пространство се споделя от всички

процеси, а половината е уникално за всеки процес, наречено съответно глобално адресно
пространство и локално адресно пространство . На всяка половина се дава дескрипторна таблица
с подходящото име. Дескриптор, сочещ към споделен сегмент, се поставя в глобалната дескрипторна
таблица, докато дескриптор за частен сегмент се поставя в локалната дескрипторна таблица.
Програмата зарежда сегментен регистър IA-32 с индекс към таблицата и малко, казвайки коя
таблица желае. Операцията се проверява според атрибутите в дескриптора, като физическият
адрес се формира чрез добавяне на отместването в процесора към основата в дескриптора, при
условие че отместването е по-малко от полето за ограничение. Всеки сегментен дескриптор има
отделно 2-битово поле, за да даде легалното ниво на достъп на този сегмент. Нарушение възниква
само ако програмата се опита да използва сегмент с по-ниско ниво на защита в дескриптора на
сегмента.
Вече можем да покажем как да извикаме споменатата по-горе програма за заплати, за да
актуализираме информацията от година до дата, без да й позволяваме да актуализира заплатите.
На програмата може да бъде даден дескриптор на информацията, който има изчистено поле за
запис, което означава, че може да чете, но не и да записва данните. След това може да бъде
предоставена доверена програма, която ще записва само информацията от годината до датата. Дава се дескриптор
8 бита 4 бита 32 бита 24 бита
Атрибути GD База Лимит
Кодов сегмент
Настояще DPL 11 Съответствие Четиво Достъп
Сегмент от данни
Настояще DPL 10 Разширете надолу Възможност за запис Достъп
8 бита 8 бита 16 бита 16 бита
Слово
Атрибути Селектор на дестинация Отместване на дестинацията
броя
Порта за обаждане
Настояще DPL 0 00100
Фигура B.26 Дескрипторите на сегменти IA-32 се отличават с битове в полето за атрибути. Base, limit,
present, readable и writable са ясни. Д дава
размерът на адресиране по подразбиране на инструкциите: 16 бита или 32 бита. G дава детайлността
от ограничението на сегмента: 0 означава в байтове и 1 означава в 4 KB страници. G е зададено на 1, когато
странирането е включено, за да зададете размера на таблиците на страниците. DPL означава привилегия на дескриптор
ниво— това се проверява спрямо нивото на привилегия на кода, за да се види дали достъпът ще бъде
позволен. Съответствието казва, че кодът приема нивото на привилегия на кода, който се извиква
а не нивото на привилегия на повикващия; използва се за библиотечни процедури. Полето за разширяване
надолу обръща чека, за да позволи на основното поле да бъде знакът за висока вода и полето за граница
бъде знакът за ниска вода. Както може да очаквате, това се използва за сегменти на стека, които нарастват
надолу. Броят на думите контролира броя на думите, копирани от текущия стек в
нов стек на врата за повикване. Другите две полета на дескриптора на вратата за повикване, дестинация
селектор и отместване на местоназначението, изберете дескриптора на местоназначението на повикването и
изместен в него, съответно. Има много повече от тези три сегментни дескриптора
в модела на защита IA-32.
с набора полета за запис (Фигура B.26). Програмата за заплати извиква доверените
код, използвайки дескриптор на кодов сегмент със съответния набор от полета. Тази настройка
означава, че извиканата програма приема нивото на привилегия на извикания код
а не нивото на привилегия на повикващия. Следователно програмата за заплати може да чете
заплатите и се обадете на доверена програма, за да актуализирате общите суми от годината до момента, но
програмата за заплати не може да променя заплатите. Ако троянски кон съществува в тази система, за да
бъде ефективен, той трябва да се намира в надеждния код, чиято единствена задача е да
актуализиране на информацията от година до дата. Аргументът за този стил на защита е
че ограничаването на обхвата на уязвимостта повишава сигурността.

Добавяне на безопасни обаждания от потребител към OS Gates и защита от наследяване

Ниво за параметри
Разрешаването на потребителя да влезе в операционната система е смела стъпка. Как тогава

един хардуерен дизайнер може да увеличи шансовете за безопасна система, без да се доверява
на операционната система или на друга част от кода? Подходът IA-32 е да се ограничи къде
потребителят може да въведе част от код, безопасно да се поставят параметри в правилния стек
и да се гарантира, че потребителските параметри не получават нивото на защита на извиквания
код.
За да ограничи влизането в чуждия код, IA-32 предоставя специален сегментен дескриптор

или порта за повикване, идентифициран с бит в полето за атрибути. За разлика от други
дескриптори, портите за повикване са пълни физически адреси на обект в паметта;
отместването, предоставено от процесора, се игнорира. Както беше посочено по-горе, тяхната
цел е да предотвратят произволното прескачане на потребителя навсякъде в защитен или по-
привилегирован кодов сегмент. В нашия пример за програмиране това означава, че единственото
място, където програмата за заплати може да извика надеждния код, е на правилната граница.
Това ограничение е необходимо, за да могат съответстващите сегменти да работят по предназначение.
Какво се случва, ако обаждащият се и обажданият са „взаимно подозрителни“, така че никой
да не вярва на другия? Решението се намира в полето за брой думи в долния дескриптор на
Фигура B.26. Когато инструкция за повикване извиква дескриптор на врата за повикване,

дескрипторът копира броя на думите, посочени в дескриптора, от локалния стек върху стека,
съответстващ на нивото на този сегмент. Това копиране позволява на потребителя да предава
параметри, като първо ги постави в локалния стек.
След това хардуерът безопасно ги прехвърля в правилния стек. Връщане от портал за повикване
ще извади параметрите от двата стека и ще копира всички върнати стойности в правилния
стек. Обърнете внимание, че този модел е несъвместим с настоящата практика за предаване на
параметри в регистрите.
Тази схема все още оставя отворена потенциалната вратичка операционната система да
използва адреса на потребителя, предаден като параметри, с нивото на защита на операционната
система, вместо с нивото на потребителя. IA-32 решава този проблем, като отделя 2 бита във
всеки регистър на сегмента на процесора за исканото ниво на защита. Когато се извика рутина
на операционна система, тя може да изпълни инструкция, която задава това 2-битово поле във
всички параметри на адреса с нивото на защита на потребителя, който е извикал рутината. По
този начин, когато тези адресни параметри се заредят в сегментните регистри, те ще настроят
исканото ниво на защита на правилната стойност. След това хардуерът IA-32 използва исканото
ниво на защита, за да предотврати всякакви глупости: нито един сегмент не може да бъде
достъпен от системната рутина, използвайки тези параметри, ако има по-привилегировано
ниво на защита от изискваното.
Пример за странирана виртуална памет:

64-битовото Opteron управление на паметта
Инженерите на AMD откриха малко приложения на сложния защитен модел, описан по-горе.
Популярният модел е плоско, 32-битово адресно пространство, въведено от 80386, което задава
всички базови стойности на сегментните регистри на нула. следователно
AMD се отказа от множеството сегменти в 64-битовия режим. Предполага се, че основата на сегмента
е нула и игнорира полето за граница. Размерите на страницата са 4 KB, 2 MB и 4 MB.
64-битовият виртуален адрес на архитектурата AMD64 е картографиран върху 52-битови

физически адреси, въпреки че реализациите могат да внедряват по-малко битове за опростяване
на хардуера. Opteron, например, използва 48-битови виртуални адреси и 40-битови физически
адреси. AMD64 изисква горните 16 бита на виртуалния адрес да бъдат само знаковото разширение
на долните 48 бита, което нарича канонична форма.
Размерът на таблиците на страниците за 64-битовото адресно пространство е тревожен.
Следователно AMD64 използва многостепенна йерархична таблица на страниците, за да
картографира адресното пространство, за да поддържа размера разумен. Броят на нивата зависи
от размера на виртуалното адресно пространство. Фигура B.27 показва транслацията на четири
нива на 48-битовите виртуални адреси на Opteron.
Отместванията за всяка от тези таблици на страници идват от четири 9-битови полета. Преобразуването
на адреси започва с добавяне на първото отместване към основния регистър на ниво 4 на картата на страницата
и след това четене на паметта от това местоположение, за да се получи основата на страницата от следващо ниво
63 48 47 39 38 30 29 21 20 12 11 0
000 . . . 0 или
Page-map L4 Page-dir-ptr Страница-директория Страница-таблица
111. . . 1
Отместване на страницата
Page-map L4
+
базов адрес (CR3)
Page-map L4 таблица
Таблица с указатели на
директории на страници
Page-mp запис + Таблица страница-

директория
Page-dir-ptr запис +
Таблица на страницата
Вписване в Page-dir +
Вписване в таблица на страници
Физически адрес
Номер на рамката на физическа страница Отместване на страницата
Главна памет
Фигура B.27 Нанасяне на виртуален адрес на Opteron. Реализацията на виртуалната памет на Opteron с четири нива на таблица на
страници поддържа ефективен размер на физически адрес от 40 бита. Всяка таблица на страници има 512 записа, така че всяко
поле на ниво е широко 9 бита. Документът за архитектурата AMD64 позволява размерът на виртуалния адрес да нарасне от
настоящите 48 бита на 64 бита, а размерът на физическия адрес да нарасне от настоящите 40 бита на 52 бита.
маса. Следващото изместване на адреса на свой ред се добавя към този новоизвлечен адрес и паметта се
осъществява отново, за да се определи основата на таблицата на третата страница. Това се случва отново по
същия начин. Последното адресно поле се добавя към този краен основен адрес и паметта се чете с помощта на тази
сума, за да (накрая) получи физическия адрес на страницата, към която се препраща. Този адрес се свързва с 12-
битовото отместване на страницата, за да се получи пълният физически адрес. Имайте предвид, че таблицата
на страниците в архитектурата на Opteron се побира в една страница от 4 KB.
Opteron използва 64-битов запис във всяка от тези таблици на страници. Първите 12 бита са запазени за
бъдеща употреба, следващите 52 бита съдържат номера на рамката на физическата страница, а последните 12
бита дават информация за защита и използване. Въпреки че полетата варират до известна степен между нивата
на таблицата на страниците, ето основните:
Присъствие— казва, че тази страница присъства в паметта.
Четене/запис— казва дали страницата е само за четене или за четене-запис.
Потребител/надзорник— казва дали даден потребител има достъп до страницата или е ограничен до горните три
нива на привилегии.
Dirty— казва дали страницата е била променена. Достъп
– казва дали страницата е била прочетена или записана от последния бит

изчистено.
Размер на страницата – казва дали последното ниво е за 4 KB страници или 4 MB страници; ако е последното,
тогава Opteron използва само три вместо четири нива на страници. Без изпълнение— Не е намерено в
схемата за защита 80386, към която е добавен този бит
предотвратяване на изпълнението на код в някои страници.
Деактивиране на кеша на ниво страница— казва дали страницата може да бъде кеширана или не.
Записване на ниво страница— Показва дали страницата позволява обратно записване или записване за кешове
на данни.
Тъй като Opteron обикновено преминава през четири нива на таблици при пропуск на TLB, има три
потенциални места за проверка на ограниченията за защита. Opteron се подчинява само на PTE от най-ниско ниво,
като проверява останалите само за да се увери, че валидният бит е зададен.
Тъй като записът е дълъг 8 байта, всяка таблица на страници има 512 записа, а Opteron има 4 KB страници,
таблиците на страниците са дълги точно една страница. Всяко от четирите полета на ниво е с дължина 9 бита, а
отместването на страницата е 12 бита. Това извличане оставя 64 – (4 × 9 + 12) или 16 бита за разширяване на
знака, за да се осигурят канонични адреси.
Въпреки че обяснихме превода на юридически адреси, какво пречи на потребителя да създаде незаконни
преводи на адреси и да попадне в пакост? Самите таблици на страниците са защитени от писане от потребителски
програми. По този начин потребителят може да опита всеки виртуален адрес, но чрез контролиране на записите
в таблицата на страниците операционната система контролира каква физическа памет е достъпна. Споделянето
на паметта между процесите се осъществява чрез запис в таблица на страници във всяко адресно пространство,
сочещ към една и съща страница с физическа памет.
Opteron използва четири TLB, за да намали времето за транслация на адреси, два за достъп до инструкции
и два за достъп до данни. Подобно на многостепенните кешове,

B.6 Заблуди и капани B-57
Параметър Описание
Размер на блока 1 PTE (8 байта)
L1 време за попадение
1 тактов цикъл
L2 време за попадение
7 тактови цикъла
L1 TLB размер Същото за TLB с инструкции и данни: 40 PTE на TLB, с

32 страници от 4 KB и 8 за страници от 2 MB или 4 MB
L2 TLB размер Същото за TLB с инструкции и данни: 512 PTE от 4 KB страници
Блокиране на избор LRU
Напишете стратегия (Не е приложимо)
Поставяне на блок L1 Напълно асоциативен
Поставяне на блок L2 4-посочен набор асоциативен
Фигура B.28 Параметри на йерархията на паметта на инструкцията Opteron L1 и L2 и

данни TLB.
Opteron намалява пропуските на TLB, като има два по-големи L2 TLB: един за инструкции
и един за данни. Фигура B.28 описва данните TLB.
Резюме: Защита на 32-битовия Intel Pentium срещу 64-

битовия AMD Opteron
Управлението на паметта в Opteron е типично за повечето настолни или сървърни компютри днес,
разчитайки на преобразуване на адрес на ниво страница и правилна работа на
операционната система, за да осигури безопасност на множество процеси, споделящи компютъра. Макар
и представени като алтернативи, Intel последва примера на AMD и
възприема архитектурата AMD64. Следователно и AMD, и Intel поддържат 64-
битово разширение 80х86; все пак, от съображения за съвместимост, и двете поддържат разработката
схема за сегментирана защита.
Ако моделът на сегментирана защита изглежда по-труден за изграждане от AMD64
модел, това е така, защото е така. Това усилие трябва да е особено разочароващо за инженерите, тъй
като малко клиенти използват сложния защитен механизъм. В допълнение,
фактът, че моделът на защита не съответства на простата защита на пейджинг
на UNIX-подобни системи означава, че ще се използва само от някой, който пише операционна система
специално за този компютър, което все още не се е случило.
B.6 Заблуди и клопки
Дори прегледът на йерархията на паметта има грешки и клопки!
Клопка Твърде малко адресно пространство.
Само пет години след като DEC и университетът Карнеги Мелън си сътрудничат за проектиране
новото семейство компютри PDP-11, беше очевидно, че тяхното създаване е имало фатален край
недостатък. Архитектура, обявена от IBM шест години преди PDP-11, все още процъфтява, с малки
модификации, 25 години по-късно. А DEC VAX, критикуван за включването на ненужни функции, продаде
милиони бройки, след като PDP-11 излезе от производство. Защо?
Фаталният недостатък на PDP-11 беше размерът на неговите адреси (16 бита) в сравнение с размерите
на адресите на IBM 360 (24 до 31 бита) и VAX (32 бита).
Размерът на адреса ограничава дължината на програмата, тъй като размерът на програмата и количеството
данни, необходими на програмата, трябва да са по-малки от 2Address size. Причината, поради която размерът
на адреса е толкова труден за промяна, е, че той определя минималната ширина на всичко, което може да
съдържа адрес: компютър, регистър, дума от паметта и аритметика на ефективния адрес. Ако няма план за
разширяване на адреса от самото начало, тогава шансовете за успешна промяна на размера на адреса са
толкова малки, че това обикновено означава края на това компютърно семейство. Bell and Strecker [1976] го
формулират така:
Има само една грешка, която може да бъде допусната в компютърния дизайн, която е
трудна за възстановяване - липсата на достатъчно адресни битове за адресиране на
паметта и управление на паметта. PDP-11 следва непрекъснатата традиция на почти
всеки известен компютър. [стр. 2]
Частичен списък на успешни компютри, които в крайна сметка умряха от глад поради липса на адресни битове,
включва PDP-8, PDP-10, PDP-11, Intel 8080, Intel 8086, Intel 80186, Intel 80286, Motorola 6800, AMI 6502, Zilog Z80 ,
CRAY-1 и CRAY X-MP.
Почитаемата линия 80x86 се отличава с това, че е била разширена два пъти, първо до 32 бита с Intel
80386 през 1985 г. и наскоро до 64 бита с AMD Opteron.
Клопка Пренебрегване на влиянието на операционната система върху производителността на паметта
йерархия.
Фигура B.29 показва времето за задържане на паметта поради прекараната от операционната система три
големи натоварвания. Около 25% от времето на спиране се изразходва или в пропуски в операционната
система, или е резултат от пропуски в приложните програми поради смущения в операционната система.
Клопка Разчитане на операционните системи за промяна на размера на страницата с течение на времето.
Архитектите на Alpha имаха сложен план за разрастване на архитектурата с течение на времето чрез
увеличаване на размера на страницата й, дори вграждането й в размера на нейния виртуален адрес. Когато
дойде време да се увеличат размерите на страниците с по-късните Alpha, дизайнерите на операционната
система се отказаха и системата за виртуална памет беше преработена, за да увеличи адресното
пространство, като същевременно запази страницата от 8 KB.
Архитектите на други компютри забелязаха много високи нива на пропуски на TLB и затова добавиха
множество по-големи размери на страници към TLB. Надеждата беше, че програмистите на операционни
системи ще разпределят обект към най-голямата страница, която има смисъл, като по този начин ще запазят TLB
записите. След десетилетие опити повечето операционни системи използват тези „суперстраници“ само
за ръчно подбрани функции: картографиране на паметта на дисплея или други I/O устройства или използване
на много големи страници за кода на базата данни.

B.8 Историческа перспектива и препратки B-59
време
% дължимо време
Госпожици приложението пропуска % Време, дължимо директно на пропуски на ОС
% време
ОС пропуска
операционна система Данни
присъщо конфликти операционна система Данни пропуски Почивка
и
%в %в приложение с инструкция пропуски за в блок на ОС приложение
Натовареност приложенията операционна система пропуски приложения пропуски миграция операции пропуски конфликти
Pmake 47% 53% 14,1% 4,8% 10,9% 1,0% 6,2% 2,9% 25,8%
Multipgm 53% 47% 21,6% 3,4% 9,2% 4,2% 4,7% 3,4% 24,9%
Оракул 73% 27% 25,7% 10,2% 10,6% 2,6% 0,6% 2,8% 26,8%
Фигура B.29 Пропуски и време, прекарано в пропуски за приложения и операционна система. Операционната система
добавя около 25% към времето за изпълнение на приложението. Всеки процесор има 64 KB кеш за инструкции и двустепенен кеш за данни
с 64 KB на първо ниво и 256 KB на второ ниво; всички кешове са директно картографирани с 16-
байтови блокове. Събрани на Silicon Graphics POWER station 4D/340, мултипроцесор с четири процесора 33 MHz R3000, изпълняващи три
натоварвания на приложения под UNIX System V— Pmake, паралелна компилация от 56 файла; Multi-pgm, паралелната цифрова програма MP3D,
работеща едновременно с Pmake и сесия за редактиране на пет екрана; и
Oracle, изпълнява ограничена версия на бенчмарка TP-1, използвайки базата данни на Oracle. (Данни от Torrellas, Gupta,
и Хенеси [1992].)
B.7 Заключителни бележки

Трудността при изграждането на система с памет, която да върви в крак с по-бързите процесори, е
подчертано от факта, че суровината за основната памет е същата като тази
намерени в най-евтиния компютър. Тук ни помага принципът на местността -
неговата здравина се демонстрира на всички нива на йерархията на паметта в момента
компютри, от дискове до TLB.
Въпреки това нарастващата относителна латентност на паметта отнема стотици
тактови цикли през 2011 г., означава, че програмистите и авторите на компилатори трябва да бъдат
са наясно с параметрите на кешовете и TLB, ако искат техните програми да го направят
представят се добре.
Б.8 Историческа перспектива и препратки
В раздел L.3 (достъпен онлайн) разглеждаме историята на кеш паметта, виртуалната памет и
виртуалните машини. (Историческият раздел обхваща както това приложение, така и
Глава 3.) IBM играе важна роля в историята и на трите. Референции за
са включени допълнителни четения.
Упражнения от Амр Заки
B.1 [10/10/10/15] <B.1> Опитвате се да оцените колко важен е принципът на локалност в оправдаването на използването на
кеш памет, така че експериментирате с компютър, който има L1 кеш данни и основна памет (вие се фокусирате
изключително върху достъпа до данни). Закъсненията (в цикли на процесора) на различните видове достъпи са
както следва: попадение в кеша, 1 цикъл; кеш пропуск, 105 цикъла; достъп до основната памет с деактивиран кеш,
100 цикъла. а. [10] <B.1> Когато стартирате програма с общ процент пропуски от 5%, какво ще бъде средното време
за достъп до паметта (в цикли на процесора)?
b. [10] <B.1> След това стартирате програма, специално проектирана да произвежда напълно произволни адреси
на данни без локалност. За тази цел използвате масив с размер 256 MB (всички се побират в основната
памет). Достъпите до произволни елементи от този масив се правят непрекъснато (използвайки унифициран
генератор на произволни числа за генериране на индексите на елементите). Ако размерът на кеша ви за
данни е 64 KB, какво ще бъде средното време за достъп до паметта?
° С. [10] <B.1> Ако сравните резултата, получен в част (b) с времето за достъп до основната памет, когато кешът е
деактивиран, какво можете да заключите относно ролята на принципа на локалност в оправдаването на
използването на кеш-памет?
д. [15] <B.1> Забелязахте, че попадение в кеша води до печалба от 99 цикъла (1 цикъл срещу 100), но води до загуба
от 5 цикъла в случай на пропуск (105 цикъла срещу.
100). В общия случай можем да изразим тези две величини като G (печалба) и L (загуба). Използвайки тези
две величини (G и L), идентифицирайте най-високия процент на пропуски, след който използването на кеша
би било неблагоприятно.
B.2 [15/15] <B.1> За целите на това упражнение приемаме, че имаме 512-байтов кеш с 64-байтови блокове. Ще приемем също,
че основната памет е с размер 2 KB. Можем да разглеждаме паметта като масив от 64-байтови блокове: M0, M1, …,
M31.
Фигура B.30 скицира блоковете памет, които могат да се намират в различни кеш блокове, ако кешът е напълно
асоциативен. а. [15 ] <B.1> Показване на
съдържанието на таблицата, ако кешът е организиран като директен
картографиран кеш.
b. [15] <B.1> Повторете част (a) с кеша, организиран като асоциативен набор от четири посоки
кеш памет.
B.3 [10/10/10/10/15/10/15/20] <B.1> Организацията на кеша често се влияе от желанието да се намали консумацията на енергия
от кеша. За тази цел приемаме, че кешът е физически разпределен в масив от данни (съдържащ данните), масив
с етикети (съдържащ етикетите) и заместващ масив (съдържащ информация, необходима за политиката за замяна).
Освен това, всеки един от тези масиви е физически разпределен в множество под-масиви (по един на начин),
които могат да бъдат индивидуално достъпни; например четирипосочен набор асоциативен най-скоро използван
(LRU) кеш би имал

Упражнения от Амр Заки B-61
Блокове памет, които могат да се

Кеш блок Комплект
начин намират в кеш блок
0 0 0 M0, M1, M2, …, M31
1 0 1 M0, M1, M2, …, M31
2 0 2 M0, M1, M2, …, M31
3 0 3 M0, M1, M2, …, M31
4 0 4 M0, M1, M2, …, M31
5 0 5 M0, M1, M2, …, M31
6 0 6 M0, M1, M2, …, M31
7 0 7 M0, M1, M2, …, M31
Фигура B.30 Блокове памет, които могат да се намират в кеш блок.
четири под-масива с данни, четири под-масива с етикети и четири заместващи под-масива. Ние
приемем, че заместващите подмасиви са достъпени веднъж на достъп, когато
Използва се политика за замяна на LRU и веднъж на пропуск, ако първи влезе, първи излезе (FIFO)
използва се политика за замяна. Не е необходимо, когато има политика за произволна замяна
използвани. За конкретен кеш беше установено, че достъпът до различни
масивите имат следните тегла на консумация на енергия:
Тегло на консумация на енергия

Масив (на начин на достъп)
Масив от данни 20 единици
Етикет Масив 5 единици
Разни масиви 1 единица
Оценете потреблението на мощност на кеша (в захранващи блокове) за следните конфигурации.

Предполагаме, че кешът е четирипосочен асоциативен. Мощност за достъп до основната памет—
макар и важен - не се разглежда тук. Дайте отговори за LRU, FIFO и
политики за произволна замяна.
а. [10]<B.1> Попадение при четене от кеша. Всички масиви се четат едновременно.
b. [10] <B.1> Повторете част (a) за пропуск при четене на кеша.
° С. [10] <B.1> Повторете част (a), като приемете, че достъпът до кеша е разделен на две
цикли. В първия цикъл се осъществява достъп до всички под-масиви на тагове. Във втория
цикъл, ще бъде достъпен само подмасивът, чийто етикет съответства.
д. [10] <B.1> Повторете част (c) за пропуск при четене на кеша (няма достъп до масив от данни в
втори цикъл).
д. [15] <B.1> Повторете част (c), като приемете, че е добавена логика за предвиждане на кеша
начин за достъп. Има достъп само до подмасива на етикета за предвидения начин
в първи цикъл. Попадение в пътя (съвпадение на адреса по предвиден начин) предполага попадение в кеша.
Пропуснат начин диктува изследване на всички под-масиви на етикети във втория цикъл. в
в случай на попадение на път, само един подмасив от данни (този, чийто етикет съвпадна) се
осъществява достъп във втория цикъл. Да приемем, че има пътен удар.
f. [10] <B.1> Повторете част (e), като приемете, че предсказващият начин е пропуснал (избраният начин е
грешен). Когато не успее, предсказващият начин добавя допълнителен цикъл, в който осъществява достъп
до всички подмасиви на тагове. Да приемем, че има попадение при четене на кеша.
ж. [15] <B.1> Повторете част (f), като приемете пропуск при четене на
кеша. ч. [20] <B.1> Използвайте части (e), (f) и (g) за общия случай, когато работното натоварване
има следните статистически данни: процент на пропуски на предсказател на пътя = 5% и
процент на пропуски в кеша = 3 %. (Помислете за различни политики за замяна.)
B.4 [10/10/15/15/15/20] <B.1> Ние сравняваме изискванията за честотна лента за запис на кешове за запис
и обратно запис, като използваме конкретен пример. Да приемем, че имаме 64 KB кеш с размер на
реда 32 байта. Кешът ще разпредели ред при пропуск при запис. Ако е конфигуриран като кеш
за обратно записване, той ще запише обратно целия мръсен ред, ако трябва да бъде заменен. Ще
приемем също, че кешът е свързан с по-ниското ниво в йерархията чрез 64-битова (8-байтова)
шина. Броят на процесорните цикли за B-байтов достъп за запис по тази шина е
Б
10 5 + --- 1–
8
Б
Например, 8-байтов запис ще отнеме 10 5 + --- 1– цикли, докато използва
8
по същата формула 12-байтов запис ще отнеме 15 цикъла. Отговорете на следните въпроси, като се
позовавате на C кодовия фрагмент по-долу:
…
#define ЧАСТИЦА 1 … Основа = 8*i; for (unsigned int j=base; j < base+PORTION; j++) //
предполагаме, че j се съхранява в регистър
данни [j] = j;
а. [10] <B.1> За кеш за записване, колко цикъла на процесора се изразходват за прехвърляне на

запис към паметта за всички комбинирани итерации на j цикъла? b. [10] <B.1> Ако кешът е
конфигуриран като кеш за обратно записване, колко CPU

цикли се изразходват за обратно записване на кеш ред?
° С. [15] <B.1> Променете ПОРЦИЯ на 8 и повторете част (a). д. [15]
<B.1> Какъв е минималният брой актуализации на масива на същия кеш ред (преди замяната му),
които биха направили кеша за обратно запис превъзходен? д. [15] <B.1> Помислете за
сценарий, при който всички думи от реда на кеша ще бъдат записани (не непременно с помощта на
горния код) и кешът за запис ще изисква по-малко общи процесорни цикли от кеша за обратно
записване.
B.5 [10/10/10/10/] <B.2> Изграждате система около процесор с подредено изпълнение, който работи на 1,1
GHz и има CPI от 0,7 без достъп до паметта. Единствените инструкции, които четат или записват
данни от паметта, са зареждания
(20% от всички инструкции) и магазини (5% от всички инструкции). Системата с памет за този
компютър е съставена от разделен L1 кеш, който не налага наказание за попадения. Както I-cache,
така и D-cache са директно картографирани и съдържат 32 KB всеки.
I-кешът има 2% честота на пропуски и 32-байтови блокове, а D-кешът е чрез запис с 5% процент на
пропуски и 16-байтови блокове. Има буфер за запис в D-кеша, който елиминира спиранията за
95% от всички записи. Обединеният L2 кеш с обратно запис от 512 KB има 64-байтови блокове и
време за достъп от 15 ns. Той е свързан към L1 кеша чрез 128-битова шина за данни, която работи
на 266 MHz и може да прехвърля една 128-битова дума на цикъл на шина. От всички препратки към
паметта, изпратени до L2 кеша в тази система, 80% са удовлетворени, без да отиват в основната
памет. Освен това 50% от всички сменени блокове са мръсни. Основната памет с ширина 128 бита
има латентност на достъпа от 60 ns, след което произволен брой шинни думи могат да бъдат
прехвърлени със скорост една на цикъл по шината на основната памет с ширина 128 бита и 133 MHz.
а. [10] <B.2> Какво е средното време за достъп до паметта за достъп до
инструкции? b. [10] <B.2> Какво е средното време за достъп до паметта за четене на данни? ° С. [10]
<B.2> Какво е средното време за достъп до паметта за запис на данни? д. [10] <B.2> Какъв
е общият CPI, включително достъпите до паметта?
B.6 [10/15/15] <B.2> Преобразуването на честота на пропуски (пропуски на препратка) в пропуски на

инструкция разчита на два фактора: препратки на извлечена инструкция и частта от
извлечените инструкции, която действително се ангажира. а.
[10] <B.2> Формулата за пропуски на инструкция на страница B-5 е написана първо по отношение на
три фактора: честота на пропуски, достъпи до паметта и брой инструкции. Всеки от тези
фактори представлява действителни събития. Какво е различното при записването на
пропуски за инструкция като честота на пропуски, умножена по отношение на достъпа на факторната памет з
b. [15] <B.2> Спекулативните процесори ще извличат инструкции, които не се ангажират.

Формулата за пропуски на инструкция на страница B-5 се отнася до пропуски на инструкция по
пътя на изпълнение, тоест само инструкциите, които действително трябва да бъдат изпълнени,
за да се изпълни програмата. Преобразувайте формулата за пропуски на инструкция на
страница B-5 в такава, която използва само процент на пропуски, препратки за извлечена
инструкция и част от извлечените инструкции, които се ангажират. Защо да разчитате на
тези фактори, а не на тези във формулата на страница B-5?
° С. [15] <B.2> Преобразуването в част (b) може да доведе до неправилна стойност до степента, в
която стойността на факторните препратки за извлечена инструкция не е равна на броя
препратки за всяка конкретна инструкция. Препишете формулата на част (b), за да
коригирате този недостатък.
B.7 [20] <B.1, B.3> В системи с L1 кеш за запис, поддържан от L2 кеш за обратно записване вместо основна
памет, обединяващият буфер за запис може да бъде опростен.
Обяснете как може да стане това. Има ли ситуации, при които наличието на пълен буфер за запис
(вместо опростената версия, която току-що предложихте) може да бъде полезно?
B.8 [20/20/15/25] <B.3> Политиката за замяна на LRU се основава на предположението, че ако адрес A1 е бил
достъпен по-рядко от адрес A2 в миналото, тогава A2 ще бъде достъпен отново преди A1 в бъдещето.
Следователно на A2 се дава приоритет пред A1. Обсъдете как това предположение не успява да се
задържи, когато непрекъснато се изпълнява a цикъл, по-голям от кеша на инструкциите. Например,
помислете за напълно
асоциативен 128-байтов кеш за инструкции с 4-байтов блок (всеки блок може да съдържа точно една
инструкция). Кешът използва политика за замяна на LRU. а. [20] <B.3> Какъв е асимптотичният
процент пропуски на инструкции за 64-байтов цикъл с голям брой итерации?
b. [20] <B.3> Повторете част (a) за цикъл с размери 192 байта и 320 байта. ° С. [15]
<B.3> Ако политиката за замяна на кеша е променена на последно използван (MRU) (заменете най-скоро
достъпния кеш ред), кой от трите горни случая (64-, 192- или 320-байтови цикли ) биха се
възползвали от тази политика?
д. [25] <B.3> Предложете допълнителни политики за замяна, които може да надминат

LRU.
B.9 [20] < B.3> Увеличаването на асоциативността на кеша (с всички други параметри, поддържани
постоянни), статистически намалява процента на пропуски. Въпреки това, може да има патологични
случаи, при които увеличаването на асоциативността на кеша би увеличило процента на пропуски
за определено работно натоварване. Разгледайте случая на директно картографиране в сравнение
с двупосочен набор асоциативен кеш с еднакъв размер. Да приемем, че зададеният асоциативен
кеш използва политиката за заместване на LRU. За да опростим, приемете, че размерът на блока е една дума.
Сега изградете следа от достъпи на думи, които биха довели до повече пропуски в двупосочния
асоциативен кеш. (Подсказка: Съсредоточете се върху конструирането на следа от достъпи, които
са изключително насочени към единичен набор от асоциативния кеш на двупосочния набор, така че
една и съща трасировка да има изключителен достъп до два блока в директно картографирания
кеш.)
B.10 [10/10/15] <B.3> Да разгледаме двустепенна йерархия на паметта, съставена от L1 и L2 кешове за данни.
Да приемем, че и двата кеша използват политика за обратно записване при попадение на запис и
двата имат еднакъв размер на блока. Избройте действията, предприети в отговор на следните
събития:
а. [10] <B.3> Пропуск на L1 кеш, когато кешовете са организирани в включен

йерархия.
b. [10] <B.3> Пропуск на L1 кеш, когато кешовете са организирани в изключителен режим

йерархия.
° С. [15] <B.3> И в двете части (a) и (b) разгледайте възможността изгонените

линията може да е чиста или мръсна.
B.11 [15/20] <B.2, B.3> Изключването на някои инструкции от влизането в кеша може
намаляване на конфликтните пропуски.
а. [15] <B.3> Скицирайте програмна йерархия, където части от програмата биха били по-добре
изключени от влизане в кеша на инструкциите. (Съвет: Помислете за програма с кодови
блокове, които са поставени в по-дълбоки циклични гнезда от другите блокове.)
b. [20] <B.2, B.3> Предложете софтуерни или хардуерни техники за налагане на изключване на
определени блокове от кеша на инструкциите.
B.12 [15] <B.4> Програма се изпълнява на компютър с напълно асоциативен (микро) транслационен буфер (TLB)
с четири записа:
VP# PP# Входът е валиден
5 30 1
71 0
10 10 1
15 25 1
Следното е следа от номера на виртуални страници, достъпни от програма. За
всеки достъп показва дали произвежда TLB хит/пропускане и, ако има достъп до
таблица на страниците, независимо дали създава попадение на страница или грешка. Поставете X под таблицата на страниците
колона, ако не е достъпна.
Индекс на виртуални страници Номер на физическа страница

Настояще
0 3г
1 7N
2 6N
3 5Y
4 14 Y
5 30 Y
6 26 Y
7 11 Y
8 13 н
9 18 н
10 10 Y
11 56 Y
12 110 Y
13 33 Y
14 12 н
15 25 Y
TLB Таблица на страниците
Осъществен е достъп до виртуалната страница (удар или пропуск) (попадение или грешка)
1
5
9
14
10
6
15
12
7
2
B.13 [15/15/15/15/] <B.4> Някои системи с памет обработват TLB пропуски в софтуера (по изключение),
докато други използват хардуер за TLB пропуски. а. [15]
<B.4> Какви са компромисите между тези два метода за обработка

TLB пропуски?
b. [15] <B.4> Ще бъде ли TLB обработката на пропуски в софтуера винаги по-бавна от TLB
обработката на пропуски в хардуера?
Обяснете. ° С. [15] <B.4> Има ли структури на таблици на страници, които биха били трудни
за обработка в хардуер, но възможни в софтуер? Има ли такива структури, които биха
били трудни за обработка от софтуера, но лесни за управление от хардуера?
д. [15] <B.4> Защо TLB процентите на пропуски за програмите с плаваща запетая са като цяло
по-високи от тези за целочислени програми?
B.14 [25/25/25/25/20] <B.4> Колко голям трябва да бъде TLB? TLB пропуските обикновено са много бързи
(по-малко от 10 инструкции плюс цената на изключение), така че може да не си струва да имате
огромен TLB само за да намалите малко процента на TLB пропуски. Използване на симулатора
SimpleS-calar (www.cs.wisc.edu/~mscalar/simplescalar.html) и един или повече сравнителни
показатели SPEC95, изчислете степента на пропуски на TLB и режийните разходи на TLB (в
процент на загубеното време за обработка на пропуски на TLB) за следните TLB конфигурации.
Да приемем, че всеки TLB пропуск изисква 20 инструкции. а. [25]
<B.4> 128 записа, асоциативен двупосочен набор, страници от 4 KB до 64 KB (на степен 2). b.
[25] <B.4> 256
записа, асоциативен двупосочен набор, страници от 4 KB до 64 KB (на степен 2). ° С. [25] <B.4>
512 записа,
асоциативен двупосочен набор, страници от 4 KB до 64 KB (на степен 2). д. [25] <B.4> 1024
записа,
асоциативен двупосочен набор, страници от 4 KB до 64 KB (на степен 2).
д. [20] <B.4> Какъв би бил ефектът върху степента на пропуски и режийните разходи на TLB
за многозадачна среда? Как честотата на превключване на контекста ще повлияе на
режийните разходи?
B.15 [15/20/20] <B.5> Възможно е да се осигури по-гъвкава защита от тази в архитектурата на Intel
Pentium, като се използва схема за защита, подобна на използваната в Hewlett-Packard Precision
Architecture (HP/PA ). В такава схема всеки запис в таблицата на страницата съдържа „ID
за защита“ (ключ) заедно с правата за достъп до страницата. При всяка препратка процесорът
сравнява защитния идентификатор в записа на таблицата на страницата с тези, съхранени
във всеки от четирите регистъра на защитния идентификатор (достъпът до тези регистри
изисква процесорът да бъде в режим на надзорник). Ако няма съвпадение за идентификатора
на защита в записа в таблицата на страниците или ако достъпът не е разрешен достъп
(например писане на страница само за четене), се генерира изключение.
а. [15] <B.5> Как един процес би могъл да има повече от четири валидни идентификатора за
защита в даден момент? С други думи, да предположим, че един процес иска да има 10
идентификатора за защита едновременно. Предложете механизъм, чрез който това може
да стане (може би с помощта на софтуер).
b. [20] <B.5> Обяснете как този модел може да се използва за улесняване на конструкцията
на операционни системи от относително малки парчета код, които не могат да презаписват
взаимно (микроядра). Какви предимства може да има такава операционна система
имат над монолитна операционна система, в която всеки код в операционната система може
запис на произволно място в паметта?
° С. [20] <B.5> Проста промяна в дизайна на тази система би позволила два идентификатора за
защита за всеки запис в таблицата на страниците, единият за достъп за четене, а другият за
достъп за запис или изпълнение (полето не се използва, ако не е зададен нито битът за запис,
нито за изпълнение). Какви предимства може да има от наличието на различни
идентификатори за защита за възможности за четене и запис? (Съвет: Това може ли да улесни
споделяне на данни и код между процеси?)
C.1 Въведение С-2
В.2 Основното препятствие при тръбопровода — опасности от С-11
В.3 тръбопровода Как се прилага тръбопровода? С-30
C.4 Какво прави тръбопровода труден за внедряване? С-43
В.5 Разширяване на MIPS Pipeline за обработка на многоциклови С-51
C.6 операции Събиране на всичко заедно: MIPS R4000 С-61
C.7 Pipeline Crosscutting С-70
C.8 Issues Заблуди и капани С-80
В.9 Заключителни бележки С-81
В.10 Историческа перспектива и препратки С-81
Актуализирани упражнения от Даяна Франклин С-82

°С
Конвейерна обработка: Основни и
Междинни понятия 1
Това е доста проблем с трите тръби.
Сър Артър Конан Дойл

Приключенията на Шерлок Холмс
C-2 Приложение C Конвейер: Основни и междинни концепции
C.1 Въведение
Много читатели на този текст ще са покрили основите на конвейера в друг текст (като нашия по-
основен текст Компютърна организация и дизайн) или в друг курс. Тъй като глава 3 надгражда до
голяма степен този материал, читателите трябва да се уверят, че са запознати с концепциите,
обсъждани в това приложение, преди да продължат. Докато четете Глава 2, може да намерите за
полезно да се обърнете към този материал за бърз преглед.
Започваме приложението с основите на тръбопровода, включително обсъждане на последиците

от пътя на данните, въвеждане на опасности и изследване на производителността на тръбопроводите.
Този раздел описва основния петстепенен RISC тръбопровод, който е основата за останалата част от
приложението. Раздел C.2 описва проблема с опасностите, защо те причиняват проблеми с
производителността и как могат да се справят с тях. Раздел C.3 обсъжда как всъщност се прилага
простият петстепенен тръбопровод, като се фокусира върху контрола и как се справят с
опасностите.
Раздел C.4 обсъжда взаимодействието между конвейерната обработка и различните аспекти

на дизайна на набора от инструкции, включително обсъждане на важната тема за изключенията и
тяхното взаимодействие с конвейерната обработка. Читателите, които не са запознати с понятията
за точни и неточни прекъсвания и възобновяване след изключения, ще намерят този материал за
полезен, тъй като те са ключови за разбирането на по-напредналите подходи в глава 3.
Раздел C.5 обсъжда как петстепенният конвейер може да бъде разширен, за да обработва по-
дълго изпълняващи се инструкции с плаваща запетая. Раздел C.6 обединява тези концепции в
казус на дълбоко конвейеризиран процесор, MIPS R4000/4400, включващ както осемстепенния
конвейер с цели числа, така и конвейера с плаваща запетая.
Раздел C.7 въвежда концепцията за динамично планиране и използването на табла за прилагане
на динамично планиране. Той се въвежда като междусекторен въпрос, тъй като може да се използва
като въведение към основните концепции в Глава 3, която се фокусира върху динамично
планираните подходи. Раздел C.7 е също леко въведение към по-сложния алгоритъм на Tomasulo,
обхванат в Глава 3. Въпреки че алгоритъмът на Tomasulo може да бъде разгледан и разбран без
въвеждане на табло, подходът на таблото е по-прост и лесен за разбиране.
Какво е тръбопровод?
Конвейерната обработка е техника за изпълнение, при която множество инструкции се

припокриват при изпълнение; той се възползва от паралелизма, който съществува сред
действията, необходими за изпълнение на инструкция. Днес конвейерната обработка е ключовата
техника за внедряване, използвана за създаване на бързи процесори.
Тръбопроводът е като поточна линия. В автомобилната поточна линия има много стъпки, всяка от
които допринася с нещо за конструкцията на автомобила. Всяко стъпало работи паралелно с другите
стъпала, макар и на различна кола. В компютърен конвейер всяка стъпка в конвейера завършва
част от инструкция. Подобно на
C.1 Въведение C-3
монтажна линия, различни стъпки завършват паралелно различни части от различни инструкции.
Всяка от тези стъпки се нарича тръбен етап или тръбен сегмент. Етапите са свързани един към
друг, за да образуват тръба - инструкциите влизат в единия край, напредват през етапите и
излизат в другия край, точно както биха направили автомобилите на поточна линия.
В автомобилна поточна линия производителността се определя като броя автомобили на час и

се определя от това колко често завършен автомобил излиза от поточната линия.
По същия начин пропускателната способност на конвейера на инструкции се определя от това колко
често дадена инструкция излиза от конвейера. Тъй като етапите на тръбата са закачени заедно,
всички етапи трябва да са готови да продължат по едно и също време, точно както бихме
изисквали в поточна линия. Времето, необходимо между преместването на инструкция една стъпка
надолу по конвейера, е процесорен цикъл. Тъй като всички етапи протичат по едно и също време,
дължината на цикъла на процесора се определя от времето, необходимо за най-бавния етап на
тръбата, точно както в линия за автоматично сглобяване най-дългата стъпка ще определи времето
между напредването на линията. В компютър този процесорен цикъл обикновено е 1 тактов цикъл
(понякога е 2, рядко повече).
Целта на дизайнера на тръбопровода е да балансира дължината на всеки етап от тръбопровода,
точно както дизайнерът на поточната линия се опитва да балансира времето за всяка стъпка в
процеса. Ако етапите са идеално балансирани, тогава времето за една инструкция на конвейерния
процесор - при идеални условия - е равно на
Време за инструкция на неконвейерна машина

-------------------------------------------------- -------------------------------------------------- -------
Брой тръбни етапи
При тези условия ускоряването от тръбопровода е равно на броя на тръбопроводните етапи, точно
както поточна линия с n етапа може в идеалния случай да произвежда коли n пъти по-бързо.
Обикновено обаче етапите няма да бъдат идеално балансирани; освен това, тръбопроводът включва
някои режийни разходи. По този начин времето за инструкция на конвейерния процесор няма да
има минималната възможна стойност, но може да бъде близко.
Конвейерната обработка води до намаляване на средното време за изпълнение на инструкция.

В зависимост от това какво считате за базова линия, намалението може да се разглежда като
намаляване на броя на тактовите цикли на инструкция (CPI), като намаляване на времето на
тактовия цикъл или като комбинация. Ако началната точка е процесор, който отнема няколко
тактови цикъла на инструкция, тогава конвейеризацията обикновено се разглежда като
намаляване на CPI. Това е основният възглед, който ще приемем. Ако началната точка е процесор,
който отнема 1 (дълъг) тактов цикъл на инструкция, тогава конвейерната обработка намалява
времето на тактовия цикъл.
Конвейерната обработка е техника за внедряване, която използва паралелизма между
инструкциите в последователен поток от инструкции. Той има същественото предимство, че за
разлика от някои техники за ускоряване (вижте Глава 4), не е видим за програмиста. В това
приложение първо ще разгледаме концепцията за тръбопровод с помощта на класически петстепенен
тръбопровод; други глави изследват по-сложните техники за конвейер, използвани в
съвременните процесори. Преди да кажем повече за конвейера и използването му в процесор,
имаме нужда от прост набор от инструкции, който представяме по-нататък.
Основите на набора от RISC инструкции
В цялата тази книга ние използваме RISC (компютър с редуциран набор от инструкции)
архитектура или архитектура за зареждане, за да илюстрираме основните концепции, въпреки
че почти всички идеи, които въвеждаме в тази книга, са приложими за други процесори.
В този раздел представяме ядрото на типична RISC архитектура. В това приложение и в цялата
книга нашата RISC архитектура по подразбиране е MIPS. На много места концепциите са значително
сходни, че ще се прилагат към всеки RISC. RISC архитектурите се характеризират с няколко
ключови свойства, които драматично опростяват тяхното внедряване:
Всички операции с данни се отнасят за данните в регистрите и обикновено променят

цял регистър (32 или 64 бита на регистър).
Единствените операции, които засягат паметта, са операциите за зареждане и съхраняване,

които преместват данни от памет към регистър или съответно към памет от регистър.
Често са налични операции за зареждане и съхраняване, които зареждат или съхраняват
по-малко от пълен регистър (напр. байт, 16 бита или 32 бита).
Форматите на инструкции са малко на брой, с всички инструкции обикновено

като един размер.
Тези прости свойства водят до драматични опростявания при внедряването на конвейер, поради
което тези набори от инструкции са проектирани по този начин.
За съгласуваност с останалата част от текста използваме MIPS64, 64-битовата версия на
набора от инструкции MIPS. Разширените 64-битови инструкции обикновено се обозначават с D
в началото или в края на мнемониката. Например DADD е 64-битовата версия на инструкция за
добавяне, докато LD е 64-битовата версия на инструкция за зареждане.
Подобно на други RISC архитектури, MIPS наборът от инструкции предоставя 32 регистъра,

въпреки че регистър 0 винаги има стойност 0. Повечето RISC архитектури, като MIPS, имат три
класа инструкции (вижте Приложение A за повече подробности):
1. Инструкции ALU— Тези инструкции приемат или два регистъра, или регистър и незабавен
разширен знак (наречени незабавни инструкции ALU, те имат 16-битово отместване в MIPS),
работят с тях и съхраняват резултата в трети регистър. Типичните операции включват
събиране (DADD), изваждане (DSUB) и логически операции (като И или ИЛИ), които не правят
разлика между 32-битови и 64-битови версии. Непосредствените версии на тези
инструкции използват същата мнемоника със суфикс I. В MIPS има както подписани, така и
неподписани форми на аритметичните инструкции; неподписаните формуляри, които не

генерират изключения при препълване - и следователно са еднакви в 32-битов и 64-битов
режим - имат U в края (напр. DADDU, DSUBU, DADDIU).
2. Инструкции за зареждане и съхраняване – тези инструкции приемат регистър източник,

наречен основен регистър, и непосредствено поле (16-битово в MIPS), наречено отместване ,
като операнди. Сумата, наречена ефективен адрес, на съдържанието на основния регистър и
разширеното отместване се използва като адрес на паметта. В случай на инструкция за
зареждане, втори регистров операнд действа като дестинация за
данни, заредени от паметта. В случай на магазин, вторият регистърен операнд
е източникът на данните, които се съхраняват в паметта. Инструкциите се зареждат
дума (LD) и дума за съхранение (SD) зареждат или съхраняват цялото 64-битово съдържание на регистъра.
3. Разклонения и скокове – Разклоненията са условни трансфери на контрол. Там
обикновено са два начина за определяне на условието за разклоняване в RISC архитектурите: с
набор от битове за условие (понякога наричан код на условие) или чрез
ограничен набор от сравнения между двойка регистри или между регистър
и нула. MIPS използва последното. За това приложение ние разглеждаме само сравнения за
равенство между два регистъра. Във всички RISC архитектури клонът
местоназначението се получава чрез добавяне на отместване с разширен знак (16 бита в MIPS) към
текущия компютър. Безусловните скокове са предоставени в много RISC архитектури, но ние няма
да покриваме скокове в това приложение.
Проста реализация на набор от RISC инструкции
За да разберете как набор от RISC инструкции може да бъде имплементиран в конвейер
мода, трябва да разберем как се прилага без конвейер. Това
раздел показва проста реализация, при която всяка инструкция отнема най-много 5
тактови цикли. Ние ще разширим тази основна реализация до конвейерна версия,
което води до много по-нисък CPI. Нашата неконвейерна реализация не е най-голямата
икономично или изпълнение с най-висока производителност без конвейер.
Вместо това, той е проектиран да води естествено до конвейерно изпълнение. Прилагането на набора
от инструкции изисква въвеждането на няколко временни регистъра, които не са част от
архитектурата; те са представени в този раздел за
опростете тръбопровода. Нашата реализация ще се съсредоточи само върху тръбопровод за целочислено
подмножество на RISC архитектура, която се състои от дума за зареждане, клон и
целочислени ALU операции.
Всяка инструкция в това RISC подмножество може да бъде изпълнена за най-много 5 такта
цикли. 5-те тактови цикъла са както следва.
1. Цикъл на извличане на инструкции
(IF): Изпратете програмния брояч (PC) в паметта и извлечете текущата инструкция
от паметта. Актуализирайте компютъра до следващия последователен компютър, като добавите 4 (от
всяка инструкция е 4 байта) към компютъра.
2. Цикъл на декодиране/регистриране на извличане на инструкции (ID):
Декодирайте инструкцията и прочетете регистрите, съответстващи на регистъра
спецификатори на източника от регистърния файл. Направете теста за равенство на регистрите
както се четат, за евентуален клон. Знак-удължаване на отместеното поле на
инструкция в случай, че е необходимо. Изчислете възможния целеви адрес на клон
чрез добавяне на разширеното отместване към увеличения PC. В агресивен
изпълнение, което изследваме по-късно, клонът може да бъде завършен на
край на този етап чрез съхраняване на целевия адрес на клона в компютъра, ако тестът за условие
даде истина.
Декодирането се извършва паралелно с четене на регистри, което е възможно
тъй като спецификаторите на регистъра са на фиксирано място в RISC архитектура.

C-6 Приложение C Конвейерна обработка: Основни и междинни концепции
Тази техника е известна като декодиране с фиксирано поле. Имайте предвид, че може да
прочетем регистър, който не използваме, което не помага, но също така не вреди на производителността.
(Това наистина губи енергия за четене на ненужен регистър и чувствителните към захранване
дизайни могат да избегнат това.) Тъй като непосредствената част от инструкцията също е
разположена на идентично място, разширеният знак непосредствено също се изчислява по време на
този цикъл в случай, че е необходимо.
3. Цикъл на изпълнение/ефективен адрес (EX):
ALU оперира с операндите, подготвени в предишния цикъл, като изпълнява една от трите функции
в зависимост от типа инструкция. Справка към паметта – ALU добавя
основния регистър и отместването, за да формира ефективния адрес.
Инструкция Register-Register ALU— ALU изпълнява операцията, определена от кода на

операцията ALU върху стойностите, прочетени от регистърния файл.
Инструкция за незабавно регистриране на ALU — ALU изпълнява операцията,

определена от кода на операцията на ALU върху първата стойност, прочетена от
регистрационния файл и незабавно разширения знак.
В архитектура за съхранение на зареждане, ефективният адрес и циклите на изпълнение

могат да бъдат комбинирани в един тактов цикъл, тъй като няма нужда от инструкция за едновременно
изчисляване на адрес на данни и извършване на операция върху данните.
4. Достъп до паметта (MEM):
Ако инструкцията е зареждане, паметта извършва четене, използвайки ефективния адрес,

изчислен в предишния цикъл. Ако това е магазин, тогава паметта записва данните от втория
регистър, прочетени от регистърния файл, използвайки ефективния адрес.
5. Цикъл на обратно записване (WB):
Инструкция за регистър-регистр ALU или инструкция за
зареждане: Запишете резултата в регистрационния файл, независимо дали идва от

системата с памет (за зареждане) или от ALU (за инструкция ALU).
В тази реализация инструкциите за разклоняване изискват 2 цикъла, инструкциите за

съхраняване изискват 4 цикъла и всички останали инструкции изискват 5 цикъла. Приемайки
честота на разклонения от 12% и честота на магазина от 10%, типичното разпределение на инструкциите
води до общ CPI от 4,54. Тази реализация обаче не е оптимална нито за постигане на най-добра
производителност, нито за използване на минимално количество хардуер, предвид нивото на
производителност; оставяме подобряването на този дизайн като упражнение за вас и вместо това се
съсредоточаваме върху конвейера на тази версия.
Класическият петстепенен тръбопровод за RISC процесор
Можем да тръбопроводим изпълнението, описано по-горе, без почти никакви промени, като просто
стартираме нова инструкция на всеки такт. (Вижте защо избрахме този дизайн?)
Номер на часовника
Номер на инструкция 1 2 3 4 5 6 7 8 9
Инструкция i АКО документ за самоличност EX MEM WB
Инструкция i + 1 АКО документ за самоличност EX MEM WB
Фигура C.1 Прост RISC тръбопровод. При всеки тактов цикъл се извлича друга инструкция и започва своето изпълнение от пет
цикъла. Ако дадена инструкция се стартира на всеки такт, производителността ще бъде до пет пъти по-висока от тази на процесор, който е
не се конвейеризира. Имената на етапите в конвейера са същите като тези, използвани за циклите в неконвейерния
изпълнение: IF = извличане на инструкции, ID = декодиране на инструкции, EX = изпълнение, MEM = достъп до паметта и WB =
пиша в отговор на писмо.
Всеки от тактовите цикли от предишния раздел се превръща в етап на тръба - цикъл
в тръбопровода. Това води до модела на изпълнение, показан на фигура C.1, който
е типичният начин за изчертаване на тръбопроводна структура. Въпреки че всяка инструкция отнема 5
тактови цикли за завършване, по време на всеки тактов цикъл хардуерът ще инициира нов
инструкция и ще изпълни част от петте различни инструкции.
Може да ви е трудно да повярвате, че тръбопроводът е толкова прост; не е. в
този и следващите раздели, ние ще направим нашия RISC тръбопровод „реален“ чрез сделка
с проблеми, които въвежда тръбопровода.
Като начало трябва да определим какво се случва на всеки тактов цикъл на
процесор и се уверете, че не се опитваме да извършим две различни операции с
един и същ ресурс за път на данни на един и същ такт. Например единично ALU
не може да бъде поискано да изчисли ефективен адрес и да извърши операция за изваждане
по същото време. По този начин трябва да гарантираме, че припокриването на инструкциите в
тръбопроводът не може да предизвика такъв конфликт. За щастие, простотата на RISC
наборът от инструкции прави оценката на ресурсите относително лесна. Фигура C.2 показва a
опростена версия на RISC път за данни, начертан по тръбопроводен начин. Както виждаш,
основните функционални единици се използват в различни цикли и следователно се припокриват
изпълнението на множество инструкции въвежда сравнително малко конфликти. Има

три наблюдения, на които почива този факт.
Първо, ние използваме отделни памети за инструкции и данни, които обикновено бихме внедрили
с отделни кешове за инструкции и данни (обсъдени в Глава 2).
Използването на отделни кешове елиминира конфликт за една памет, която би
възникват между извличането на инструкции и достъпа до паметта на данните. Забележете, че ако
нашият конвейерно облицован процесор има тактов цикъл, който е равен на този на неконвейерната версия,
системата с памет трябва да доставя пет пъти по-голяма честотна лента. Това повишено търсене
е една цена за по-висока производителност.
Второ, регистрационният файл се използва на два етапа: един за четене в ID и
един за писане в WB. Тези употреби са различни, така че ние просто показваме регистъра
файл на две места. Следователно трябва да извършваме две четения и едно писане на всеки
тактов цикъл. За обработка на четения и запис в същия регистър (и за друг

причина, която ще стане очевидна скоро), ние извършваме запис на регистъра в
първата половина на тактовия цикъл и четенето през втората половина.
Трето, фигура C.2 не се занимава с компютъра. За да започнете нова инструкция всеки
часовник, трябва да увеличаваме и съхраняваме компютъра на всеки часовник и това трябва да бъде направено
по време на етапа IF в подготовка за следващата инструкция. Освен това трябва

също имат разширител за изчисляване на потенциалната цел на клона по време на ID. Още един
проблемът е, че клонът не променя компютъра до етапа на идентификация. Това причинява a
проблем, който засега игнорираме, но ще се справим скоро.
Въпреки че е изключително важно да се гарантира, че инструкциите в тръбопровода не се опитват

за да използваме хардуерните ресурси едновременно, трябва също така да гарантираме, че
инструкциите в различните етапи на тръбопровода не си пречат една на друга. Това

разделянето се извършва чрез въвеждане на конвейерни регистри между последователните етапи на
тръбопровода, така че в края на тактовия цикъл всички резултати от даден етап
се съхраняват в регистър, който се използва като вход за следващия етап на следващия
тактов цикъл. Фигура C.3 показва тръбопровода, начертан с тези регистри на тръбопровода.
Време (в часовникови цикли)
CC 1 CC 2 CC 3 CC 4 CC 5 CC 6 CC 7 CC 8 CC 9
ULA
АЗ СЪМ
Рег DM Рег
ULA
АЗ СЪМ
Рег DM Рег
ъгдпсое
рт Р
и
нав
зр з
пн(
ULA
л
нр
еуа
DM
ицанкм
Рег Рег
аит
)етие
АЗ СЪМ
ULA
АЗ СЪМ Рег DM Рег

ULA
АЗ СЪМ
Рег DM Рег
Фигура C.2 Тръбопроводът може да се разглежда като поредица от пътища на данни, изместени във времето. Това показва припокриването между
частите от пътя на данните, с тактов цикъл 5 (CC 5), показващ ситуацията в стационарно състояние. Тъй като регистрационният файл е
използван като източник в етапа ID и като дестинация в етапа WB, той се появява два пъти. Показваме, че се чете в едно
част от сцената и написана в друга чрез използване на плътна линия, съответно отдясно или отляво, и пунктирана линия на
другата страна. Съкращението IM се използва за памет за инструкции, DM за памет за данни и CC за тактов цикъл.
CC 1 CC 2 CC 3 CC 4 CC 5 CC 6
ULA
ULA
АЗ СЪМ Рег DM
ULA
АЗ СЪМ Рег
ULA
АЗ СЪМ Рег
Фигура C.3 Конвейер, показващ регистрите на конвейера между последователните етапи на конвейера. Забележете, че
регистрите предотвратяват смущения между две различни инструкции в съседни етапи в конвейера. Свирят и регистрите
критичната роля на пренасянето на данни за дадена инструкция от един етап на друг. Свойството, задействано от край, на
регистри - това е, че стойностите се променят мигновено на фронта на часовника - е критично. Иначе данните от един
инструкция може да попречи на изпълнението на друга!
Въпреки че много фигури ще пропуснат такива регистри за простота, те са

необходими за правилното функциониране на тръбопровода и трябва да присъстват. Разбира се,
подобни регистри биха били необходими дори в многоцикличен път на данни, който няма
конвейерна линия (тъй като само стойностите в регистрите се запазват през границите на часовника). в
в случай на конвейерен процесор, конвейерните регистри също играят ключова роля
пренасяне на междинни резултати от един етап на друг, където източникът и дестинацията може
да не са непосредствено съседни. Например стойността на регистъра, която трябва да бъде съхранена
по време на инструкция за съхраняване се чете по време на ID, но всъщност не се използва до MEM; то е
преминава през два конвейерни регистъра, за да достигне до паметта за данни по време на MEM
сцена. По същия начин резултатът от ALU инструкция се изчислява по време на EX, но не
действително съхранени до WB; пристига там, като преминава през два тръбопроводни регистъра. Понякога е
полезно да наименувате регистрите на тръбопровода и ние следваме
конвенция за назоваването им чрез етапите на тръбопровода, които свързват, така че регистрите да се наричат
IF/ID, ID/EX, EX/MEM и MEM/WB.
Основни проблеми с производителността при конвейерна обработка
Конвейерната обработка увеличава пропускателната способност на процесора - броят на инструкциите
завършено за единица време, но не намалява времето за изпълнение на индивидуална инструкция. Всъщност това
обикновено леко увеличава времето за изпълнение на всеки
инструкция поради режийни разходи при управлението на тръбопровода. Увеличаването на пропускателната
способност на инструкциите означава, че програмата работи по-бързо и има по-ниско общо изпълнение
време, въпреки че нито една инструкция не работи по-бързо!
Фактът, че времето за изпълнение на всяка инструкция не намалява, поставя ограничения върху практическата
дълбочина на конвейера, както ще видим в следващия раздел. В допълнение към ограниченията, произтичащи от
латентността на тръбопровода, ограниченията възникват от дисбаланс
между тръбните етапи и от тръбопровода над главата. Дисбаланс между тръбата
етапи намалява производителността, тъй като часовникът не може да работи по-бързо от необходимото време
за най-бавния етап на тръбопровода. Разходите на тръбопровода възникват от комбинацията от
забавяне на регистъра на тръбопровода и изкривяване на часовника. Регистрите на тръбопровода добавят време за настройка,
което е времето, през което регистровият вход трябва да бъде стабилен преди часовниковия сигнал, който
задейства възникване на запис, плюс забавяне на разпространението до тактовия цикъл. Изкривяване на часовника,
което също е максимално закъснение между момента, в който часовникът пристигне във всеки два регистъра
допринася за долната граница на тактовия цикъл. След като часовниковият цикъл е толкова малък
тъй като сумата от изкривяването на часовника и главната стойност на резето не е полезна допълнителна конвейерна обработка,
тъй като в цикъла не остава време за полезна работа. Заинтересованият читател
трябва да видите Кункел и Смит [1986]. Както видяхме в глава 3, тази реж
повлия на подобренията в производителността, постигнати от Pentium 4 спрямо Pentium III.
Пример Разгледайте неконвейерния процесор в предишния раздел. Да приемем, че има 1
ns тактов цикъл и че използва 4 цикъла за ALU операции и разклонения и 5
цикли за операции с памет. Да приемем, че относителните честоти на тези
операциите са съответно 40%, 20% и 40%. Да предположим, че поради изкривяване на часовника
и настройка, тръбопроводът на процесора добавя 0,2 ns режийни разходи към часовника. Игнориране
каквото и да е влияние върху латентността, колко ще ускорим скоростта на изпълнение на инструкциите
печалба от тръбопровод?
Отговор Средното време за изпълнение на инструкцията на неконвейерния процесор е
Средно време за изпълнение на инструкцията

= Тактов цикъл× Среден CPI
[ ( = 1 ns ×40% 20 % +) ×+ 4 40 % 5 ] ×
= 1 ns 4,4 ×
= 4,4 ns
C.2 Основното препятствие при изграждането на тръбопроводи – опасности от тръбопровода C-11
При конвейерната реализация часовникът трябва да работи със скоростта на най-бавния
етап плюс режийни стойности, които ще бъдат 1 + 0,2 или 1,2 ns; това е средното време за изпълнение на
инструкцията. По този начин ускоряването от тръбопровода е
Средно време за инструкции

= -------------------------------------------------- без конвейер
----------------------------------------------
Ускоряване от тръбопровод
Средно време за инструкции за конвейер
4.4 ns
= = -------------- 3,7 пъти
1.2 ns
0,2 ns режийни по същество установява ограничение на ефективността на конвейерното свързване. Ако
режийните разходи не се влияят от промени в тактовия цикъл, законът на Амдал
ни казва, че режийните ограничават ускоряването.
Този прост RISC конвейер би функционирал добре за целочислени инструкции, ако
всяка инструкция беше независима от всяка друга инструкция в конвейера. в
реалност, инструкциите в тръбопровода могат да зависят една от друга; това е темата за

следващия раздел.
C.2 Основното препятствие при изграждането на тръбопроводи — опасности от тръбопровода
Има ситуации, наречени опасности, които пречат на следващата инструкция в
поток от инструкции от изпълнение по време на определения му тактов цикъл. Опасности
намаляване на производителността от идеалното ускоряване, постигнато чрез конвейер. Има

три класа на опасност:
1. Структурните опасности възникват от конфликти на ресурси, когато хардуерът не може
поддържа всички възможни комбинации от инструкции едновременно при припокриващо се
изпълнение.
2. Опасности за данни възникват, когато дадена инструкция зависи от резултатите от предишна
инструкция по начин, който е изложен от припокриването на инструкции в
3. Опасностите за управление възникват от тръбопровода на разклоненията и други инструкции
които променят компютъра.
Опасностите в тръбопроводите могат да наложат спирането на тръбопровода. Избягване на a
опасността често изисква някои инструкции в тръбопровода да бъдат оставени да продължат, докато
други се забавят. За тръбопроводите, които обсъждаме в това приложение,

когато дадена инструкция е спряна, всички инструкции, издадени по-късно от спряната
инструкциите – и следователно не толкова напред в процеса – също са в застой.
Инструкции, издадени по-рано от закъсалата инструкция — и следователно по-далеч
в тръбопровода – трябва да продължи, тъй като в противен случай опасността никога няма да изчезне. Като
в резултат на това не се извличат нови инструкции по време на спиране. Ще видим няколко
примери за това как работят сергиите на тръбопровода в този раздел - не се притеснявайте, те
не са толкова сложни, колкото може да звучат!

C-12 Приложение C Конвейерна обработка: основни и междинни концепции
Изпълнение на тръбопроводи с щандове
Сривът води до влошаване на производителността на тръбопровода от идеалната производителност.
Нека да разгледаме просто уравнение за намиране на действителното ускоряване от конвейер,
започвайки с формулата от предишния раздел:
Средно време за инструкции

= -------------------------------------------------- без конвейер
----------------------------------------------
Средно време за инструкции за конвейер
CPI unpipelined Неконвейеризиран × тактов цикъл

= -------------------------------------------------- -------------------------------------------------- ----
× цикъл конвейеризиран
CPI конвейерно Clock
= CPI без конвейер

------------------------------------- Неконвейеризиран тактов цикъл
× -------------------------------------------------- --------
CPI конвейеризиран Цикълът на часовника е конвейеризиран
Конвейерът може да се разглежда като намаляване на CPI или времето на тактовия цикъл. От
традиционно е да се използва CPI за сравняване на тръбопроводи, нека започнем с това предположение.
Идеалният CPI на конвейерен процесор е почти винаги 1. Следователно можем
изчислете конвейерния CPI:
= +
CPI pipelined Идеален CPI Pipeline тактови цикли за спиране на инструкция
+
= 1 тактови цикли на спиране на тръбопровода на инструкция
Ако пренебрегнем режийните разходи за време на цикъла на конвейерната обработка и приемем, че етапите са
перфектно балансиран, тогава времето на цикъла на двата процесора може да бъде еднакво, което води до
CPI без конвейер

= -------------------------------------------------- ----------------------------------------------
Ускори
+
1 цикъла на спиране на тръбопровода на инструкция
Един важен прост случай е, когато всички инструкции вземат еднакъв брой
цикли, които също трябва да са равни на броя на етапите на тръбопровода (наричан още дълбочина
на тръбопровода). В този случай неконвейерният CPI е равен на дълбочината на тръбопровода, водещ до
Дълбочина на тръбопровода
= -------------------------------------------------- ----------------------------------------------
Ускори
+
Ако няма спирания на конвейера, това води до интуитивния резултат, който конвейерът може
подобряване на производителността чрез дълбочината на тръбопровода.
Като алтернатива, ако мислим за тръбопровода като подобряване на времето на тактовия цикъл,
тогава можем да приемем, че CPI на неконвейерния процесор, както и този на
конвейерният процесор е 1. Това води до
= CPI без конвейер

------------------------------------- Неконвейеризиран тактов цикъл
Ускоряване от тръбопровод × -------------------------------------------------- --------
CPI конвейеризиран Цикълът на часовника е конвейеризиран
1 Неконвейеризиран тактов цикъл

= -------------------------------------------------- -------------------------------------------
× -------------------------------------------------- --------
+
1 цикъла на спиране на тръбопровода на инструкция Цикълът на часовника е конвейеризиран
В случаите, когато тръбните стъпала са идеално балансирани и няма излишни разходи,
тактовият цикъл на конвейерния процесор е по-малък от тактовия цикъл на
неконвейеризиран процесор с коефициент, равен на конвейерната дълбочина:
Неконвейеризиран тактов цикъл

= -------------------------------------------------- --------
Цикълът на часовника е конвейеризиран
Неконвейеризиран тактов цикъл

= -------------------------------------------------- --------
Цикълът на часовника е конвейеризиран
Това води до следното:
1 Неконвейеризиран тактов цикъл

= -------------------------------------------------- -------------------------------------------
× -------------------------------------------------- --------
+
1 цикъла на спиране на тръбопровода на инструкция Цикълът на часовника е конвейеризиран
1
×
= -------------------------------------------------- -------------------------------------------- Дълбочина на тръбопровода
+
Така, ако няма застой, ускорението е равно на броя на етапите на тръбопровода,
съпоставяне на нашата интуиция за идеалния случай.
Структурни опасности
Когато процесорът е конвейерен, припокриващото се изпълнение на инструкции изисква
тръбопроводи на функционални единици и дублиране на ресурси, за да позволи всички възможни
комбинации от инструкции в тръбопровода. Ако някаква комбинация от инструкции
процесорът не може да бъде приспособен поради конфликти на ресурсите

имат структурна опасност.
Най-честите случаи на структурни опасности възникват, когато някои функционални
модулът не е напълно тръбопроводен. След това поредица от инструкции, използващи това неконвейерно
модулът не може да работи със скорост един на такт. Друг често срещан начин, който
структурните опасности се появяват, когато даден ресурс не е дублиран достатъчно
за да позволи изпълнението на всички комбинации от инструкции в конвейера. Например,
процесорът може да има само един порт за запис на регистрационен файл, но при определени
обстоятелства конвейерът може да поиска да извърши два записа в един тактов цикъл. Това ще
генерират структурна опасност.
Когато последователност от инструкции срещне тази опасност, тръбопроводът ще спре
една от инструкциите, докато необходимата единица е налична. Такива сергии ще

увеличете CPI от обичайната му идеална стойност от 1.
Някои конвейерни процесори споделят конвейер с една памет за данни
и инструкции. В резултат на това, когато дадена инструкция съдържа препратка към паметта на
данните, тя ще бъде в конфликт с препратката към инструкция за по-късна инструкция, като
показано на фигура C.4. За да разрешим тази опасност, спираме тръбопровода за 1 часовник
цикъл, когато възникне достъп до паметта за данни. Сривът обикновено се нарича тръбопроводен балон
или просто балон, тъй като плава през тръбопровода, заемайки място, но
извършване на полезна работа. Ще видим друг тип щанд, когато говорим за него
опасности за данните.
Дизайнерите често показват поведението на сергия, като използват проста диаграма само с
имената на етапите на тръбите, както е на Фигура C.5. Формата на фигура C.5 показва щанда от
показване на цикъла, когато не се извършва действие и просто преместване на инструкция 3 към

C-14 Приложение C Конвейер: основни и междинни концепции
CC 1 CC 2 CC 3 CC 4 CC 5 CC 6 CC 7 CC 8
Мем Рег Мем Рег
ULA
Заредете
Инструкция 1 Мем Рег Мем Рег
ULA
ULA
ULA
Инструкция 4 Мем Рег Мем
Фигура C.4 Процесор само с един порт за памет ще генерира конфликт при всяка препратка към памет ULA
възниква. В този пример инструкцията за зареждане използва паметта за достъп до данни по същото време, което инструкция 3 иска
за извличане на инструкция от паметта.
вдясно (което забавя началото и края на изпълнението му с 1 цикъл). Ефектът на

pipeline bubble всъщност е да заема ресурсите за този слот за инструкции, тъй като
пътува през тръбопровода.
Пример Нека да видим колко може да струва товарната структурна опасност. Да предположим, че препратките
към данни съставляват 40% от микса и че идеалният CPI на конвейерния процесор,
пренебрегвайки структурния риск, е 1. Да приемем, че процесорът с
структурна опасност има тактова честота, която е 1,05 пъти по-висока от тактовата честота на
процесора без опасност. Без да се вземат предвид всички други загуби на производителност, е
тръбопроводът със или без структурна опасност по-бързо и с колко?
Отговор Има няколко начина, по които можем да разрешим този проблем. Може би най-простият е да
изчислете средното време за инструкции на двата процесора:
Средно време за обучение = Време×на цикъл на CPI часовник

Номер на тактовия цикъл
Инструкция 1 2 3 4 5 6 7 8 9 10
Инструкция за зареждане АКО документ за самоличност EX MEM WB
Инструкция i + 3 Сергия АКО документ за самоличност EX MEM WB
Инструкция i + 5 АКО документ за самоличност EX MEM
Инструкция i + 6 АКО документ за самоличност EX
Фигура C.5 Тръбопровод, блокиран поради структурна опасност — товар с един порт за памет. Както е показано тук, натоварването
инструкция ефективно открадва цикъл за извличане на инструкции, което води до спиране на тръбопровода - не се инициира инструкция на
тактов цикъл 4 (който обикновено би инициирал инструкция i + 3). Тъй като инструкцията, която се извлича, е в застой, всички
други инструкции в конвейера, преди блокираната инструкция да може да продължи нормално. Цикълът на спиране ще продължи
преминават през тръбопровода, така че нито една инструкция да не завърши на тактовия цикъл 8. Понякога тези диаграми на тръбопровода са
начертана със сергия, заемаща цял хоризонтален ред и инструкция 3, преместена на следващия ред; в двете
случай, ефектът е същият, тъй като инструкция i + 3 не започва изпълнение до цикъл 5. Използваме формата по-горе,
тъй като заема по-малко място на фигурата. Имайте предвид, че тази фигура предполага, че инструкции i + 1 и i + 2 не са памет
препратки.
Тъй като няма задръствания, средното време за инструкции за идеалния процесор е просто идеалното време
на тактовия цикъл. Средното време за инструкции за процесора с

структурната опасност е
=
Средно време за инструкции CPI Време×на цикъл на часовника
Идеално време за цикъл на часовника

= ( 1 0,4 1 ) + × × -------------------------------------------------- -
1.05
= ×
1.3 Идеално време за часовников цикъл
Ясно е, че процесорът без структурната опасност е по-бърз; можем да използваме съотношението
от средното време за инструкции, за да заключим, че процесорът без опасност

е 1,3 пъти по-бързо.
Като алтернатива на тази структурна опасност, дизайнерът може да осигури отделен достъп до паметта
за инструкции, като раздели кеша на отделни
кеширане на инструкции и данни или чрез използване на набор от буфери, обикновено наричани инструкции
буфери, за съхранение на инструкции. Глава 5 обсъжда както идеите за разделен кеш, така и за буфер на
Ако всички други фактори са равни, процесор без структурни опасности ще го направи
винаги имат по-нисък CPI. Защо тогава проектантът би допуснал структурни опасности?
Основната причина е да се намалят разходите за единицата, тъй като тръбопроводът на всички функционални
единици или тяхното дублиране може да бъде твърде скъпо. Например процесори, които
поддържа както инструкция, така и достъп до кеша на данни всеки цикъл (за предотвратяване на
структурна опасност от горния пример) изискват два пъти повече обща памет
честотна лента и често имат по-висока честотна лента при щифтовете. По същия начин пълното
конвейерно изграждане на умножител с плаваща запетая (FP) изразходва много портове. Ако
структурната опасност е рядка, може да не си струва цената да се избегне.
Опасности за данни
Основен ефект от конвейера е да се промени относителното време на инструкциите чрез

припокриване на тяхното изпълнение. Това припокриване въвежда опасности за данните и контрола.
Опасности за данни възникват, когато тръбопроводът промени реда на достъпите за четене/запис
операнди, така че редът да се различава от реда, наблюдаван при последователно изпълнение
инструкции за неконвейерен процесор. Помислете за конвейерното изпълнение на
тези инструкции:
ТАТО R1, R2, R3

DSUB R4, R1, R5
И R6, R1, R7
ИЛИ R8, R1, R9
XOR R10, R1, R11
Всички инструкции след DADD използват резултата от инструкцията DADD. Като

показано на Фигура C.6, инструкцията DADD записва стойността на R1 в канала WB
етап, но инструкцията DSUB чете стойността по време на своя етап ID. Този проблем
се нарича опасност от данни. Освен ако не са взети предпазни мерки за предотвратяването му, DSUB
инструкцията ще прочете грешната стойност и ще се опита да я използва. Всъщност стойността, използвана от
инструкцията DSUB дори не е детерминистична: Въпреки че може да я мислим за логична

да приемем, че DSUB винаги ще използва стойността на R1, която е присвоена от an
инструкция преди DADD, това не винаги е така. Ако настъпи прекъсване
между инструкциите DADD и DSUB, WB етапът на DADD ще завърши,
и стойността на R1 в тази точка ще бъде резултатът от DADD. Това непредвидимо
поведението е очевидно неприемливо.
И инструкцията също е засегната от тази опасност. Както виждаме от
Фигура C.6, записът на R1 не завършва до края на тактовия цикъл 5.
По този начин инструкцията И, която чете регистрите по време на тактовия цикъл 4, ще получи
грешните резултати.
Инструкцията XOR работи правилно, защото нейното четене на регистъра се извършва в
тактов цикъл 6, след запис в регистъра. Инструкцията OR също работи без
излагане на опасност, тъй като извършваме четене на регистърния файл през втората половина на
цикъла и записите през първата половина.
Следващият подраздел обсъжда техника за елиминиране на спиранията за опасността,
включваща инструкциите DSUB и AND.
Минимизиране на опасността от спиране на данни чрез препращане
Проблемът, поставен на фигура C.6, може да бъде решен с проста хардуерна техника
наречено пренасочване (наричано също заобикаляне и понякога късо съединение). The
ключово прозрение при препращането е, че резултатът не е наистина необходим на DSUB, докато
ULA
DADD R1, R2, R3 АЗ СЪМ
Рег DM Рег
ULA
DSUB R4, R1, R5
АЗ СЪМ
Рег DM Рег
ULA
Р
и
нав
зр
ъгдпсое з
пн(
DM
рт
И R6, R1, R7 Рег

л
АЗ СЪМ
ицанкм
аит
)етие нр
еуа
ULA
ИЛИ R8, R1, R9
АЗ СЪМ
Рег
XOR R10, R1, R11
АЗ СЪМ
Рег
Фигура C.6 Използването на резултата от инструкцията DADD в следващите три инструкции причинява опасност, тъй като
регистърът не се записва, докато не го прочетете след тези инструкции.
след като DADD действително го произвежда. Ако резултатът може да бъде преместен от тръбопровода
регистрирайте, където DADD го съхранява до мястото, където DSUB се нуждае от него, тогава необходимостта от a
сривът може да бъде избегнат. Използвайки това наблюдение, препращането работи по следния начин:
1. Резултатът от ALU от конвейерните регистри EX/MEM и MEM/WB е
винаги се връща обратно към ALU входовете.
2. Ако хардуерът за пренасочване открие, че предишната операция на ALU е записала регистъра,
съответстващ на източник за текущата операция на ALU, контролната логика избира препратения
резултат като вход на ALU, а не стойността
прочетете от регистърния файл.
Забележете, че при пренасочване, ако DSUB е в застой, DADD ще бъде завършен
и байпасът няма да бъде активиран. Тази връзка е вярна и за случая на
прекъсване между двете инструкции.
Както показва примерът на фигура C.6 , трябва не само да препращаме резултатите
от непосредствено предишната инструкция, но също така евентуално от инструкция

който е започнал 2 цикъла по-рано. Фигура C.7 показва нашия пример с обходните пътища
на място и подчертаване на времето на четене и запис на регистъра. Този код
последователността може да се изпълни без застой.
Препращането може да се обобщи, за да включва предаване на резултат директно към
функционалната единица, която го изисква: Резултатът се препраща от регистъра на тръбопровода,
съответстващ на изхода на една единица към входа на друга, а не само от
резултатът от единица към входа на същата единица. Вземете например следното
ТАТО R1, R2, R3

LD R4,0(R1)
SD R4,12(R1)
ULA

Рег DM Рег
ULA
DSUB R4, R1, R5

АЗ СЪМ
Рег DM Рег
ULA
Р
и
нав
зр
ъгдпсое з
пн(
DM
рт
И R6, R1, R7 Рег

АЗ СЪМ
ицанкм
аит
)етие л
нр
еуа
ULA
ИЛИ R8, R1, R9

АЗ СЪМ
Рег
XOR R10, R1, R11
АЗ СЪМ
Рег
Фигура C.7 Набор от инструкции, който зависи от резултата от DADD, използва пътища за препращане, за да избегне опасността от данни.
Входовете за инструкциите DSUB и AND препращат от конвейерните регистри към първия ALU вход. ИЛИ
получава своя резултат чрез препращане през регистърния файл, което се постига лесно чрез четене на регистрите в
втората половина на цикъла и писане в първата половина, както показват прекъснатите линии на регистрите. Забележете, че
препратеният резултат може да отиде към всеки ALU вход; всъщност и двата ALU входа могат да използват препратени входове от всеки от
същия тръбопроводен регистър или от различни тръбопроводни регистри. Това би се случило, например, ако инструкцията AND беше
И R6, R1, R4.
ULA
Рег DM Рег
ULA
LD R4, 0(R1) АЗ СЪМ
Рег DM Рег
аит
)етие еуа
ицанкм л
нррт Р
и
нав
зр
ъгдпсое з
пн(
ULA
SD R4,12(R1) АЗ СЪМ
Рег DM
Фигура C.8 Препращане на операнд, изискван от магазините по време на MEM. Резултатът от натоварването се изпраща от
изход от паметта към входа на паметта, който да бъде съхранен. В допълнение, ALU изходът се препраща към ALU входа за
изчисляване на адреса както на натоварването, така и на магазина (това не е по-различно от препращането към друга ALU операция). Ако
магазинът зависи от непосредствено предшестваща ALU операция (не е показана по-горе), резултатът трябва да бъде пренасочен, за да
се предотврати спиране.
За да предотвратим спиране в тази последователност, ще трябва да препратим стойностите на

Изход на ALU и изход на единица памет от конвейерните регистри към ALU и
входове за памет за данни. Фигура C.8 показва всички препращащи пътища за този пример.
Опасности за данни, изискващи застой
За съжаление, не всички потенциални опасности за данните могат да бъдат обработени чрез заобикаляне.
Обмислете следната последователност от инструкции:
LD R1,0(R2)
DSUB R4, R1, R5
И R6, R1, R7
ИЛИ R8, R1, R9
Конвейерният път на данни с байпасните пътища за този пример е показан в

Фигура C.9. Този случай е различен от ситуацията с гръб-към-гръб ALU
операции. Инструкцията LD няма данни до края на часовника
цикъл 4 (неговият MEM цикъл), докато DSUB инструкцията трябва да има данните от
началото на този часовников цикъл. Следователно опасността от данните от използването на резултата
на инструкция за зареждане не може да бъде напълно елиминирана с прост хардуер.
Както показва Фигура C.9 , такъв препращащ път трябва да работи в обратна посока
CC 1 CC 2 CC 3 CC 4 CC 5
UL A
LD R1, 0(R2) АЗ СЪМ
Рег DM Рег
ULA
DSUB R4, R1, R5 АЗ СЪМ
Рег DM
ULA
рт
л
нр
еуа
ицанкм ъгдпсое Р
и
нав
зр з
пн(
И R6, R1, R7
аит
Рег
)етие
АЗ СЪМ
ИЛИ R8, R1, R9 АЗ СЪМ

Рег
Фигура C.9 Инструкцията за зареждане може да заобиколи своите резултати към инструкциите И и ИЛИ, но не и към DSUB, тъй като
това би означавало препращане на резултата за „отрицателно време“.
навреме – възможност, която все още не е достъпна за компютърните дизайнери! Можем да препратим
резултатът незабавно към ALU от регистрите на конвейера за използване в
И операция, която започва 2 тактови цикъла след натоварването. По същия начин ИЛИ
инструкцията няма проблем, тъй като получава стойността чрез регистърния файл.
За инструкцията DSUB препратеният резултат пристига твърде късно — в края на a
тактов цикъл, когато е необходимо в началото.
Инструкцията за зареждане има забавяне или латентност, които не могат да бъдат елиминирани
само чрез пренасочване. Вместо това трябва да добавим хардуер, наречен блокировка на тръбопровода, към
запазване на правилния модел на изпълнение. По принцип блокировката на тръбопровода открива a
опасност и спира тръбопровода, докато опасността бъде отстранена. В този случай блокировката
спира тръбопровода, започвайки с инструкцията, която иска да използва данните до
изходната инструкция го произвежда. Тази блокировка на тръбопровода въвежда срив или
балон, точно както беше за структурната опасност. CPI за блокираната инструкция
се увеличава с дължината на срива (1 тактов цикъл в този случай).
Фигура C.10 показва тръбопровода преди и след срива, използвайки имената на
тръбопроводни етапи. Тъй като сривът води до инструкциите, започващи с DSUB
преместете 1 цикъл по-късно във времето, препращането към инструкцията AND сега върви
чрез регистрационния файл и изобщо не е необходимо препращане за инструкцията ИЛИ.
Вмъкването на балончето води до броя на циклите за завършване на това
последователност да расте с едно. Никаква инструкция не се стартира по време на часовников цикъл 4 (и нито една
завършва по време на цикъл 6).

LD R1,0(R2) АКО документ за самоличност EX MEM WB
DSUB R4,R1,R5 АКО документ за самоличност EX MEM WB
И R6, R1, R7 АКО документ за самоличност EX MEM WB
ИЛИ R8,R1,R9 АКО документ за самоличност EX MEM WB
LD R1,0(R2) АКО документ за самоличност EX MEM WB
DSUB R4,R1,R5 АКО документ за самоличност сергия EX MEM WB
И R6, R1, R7 АКО сергия документ за самоличност EX MEM WB
ИЛИ R8,R1,R9 сергия АКО документ за самоличност EX MEM WB
Фигура C.10 В горната половина можем да видим защо е необходимо спиране: MEM цикълът на товара произвежда стойност, която е
необходими в EX цикъла на DSUB, който се случва по същото време. Този проблем се решава чрез поставяне на щанд, като
показано в долната половина.
Опасности от разклонения
Контролните опасности могат да причинят по-голяма загуба на производителност за нашия MIPS тръбопровод от
правете опасности за данните. Когато се изпълни клон, той може или не може да промени компютъра на
нещо различно от текущата му стойност плюс 4. Спомнете си, че ако клон промени
PC към целевия си адрес, това е взет клон; ако падне, не се взема, или
невзет. Ако инструкция i е взет клон, тогава компютърът обикновено не се променя
до края на ID, след завършване на изчисляването и сравнението на адреса.
Фигура C.11 показва, че най-простият метод за работа с клонове е да

повторете извличането на инструкцията, следваща клон, след като открием клона
по време на ID (когато инструкциите се декодират). Първият IF цикъл е по същество застой,
защото никога не извършва полезна работа. Може би сте забелязали, че ако клонът е
не е взето, тогава повторението на етапа IF е ненужно, тъй като правилната инструкция наистина
е извлечена. Ще разработим няколко схеми, от които да се възползваме
този факт скоро.
Един цикъл на спиране за всеки клон ще доведе до загуба на производителност от 10% до 30%
в зависимост от честотата на клона, така че ще разгледаме някои техники за справяне
с тази загуба.
Отраслова инструкция АКО документ за самоличност EX MEM WB
Клон наследник АКО АКО документ за самоличност EX MEM WB
Клон наследник + 1 АКО документ за самоличност EX MEM
Клон наследник + 2 АКО ID EX
Фигура C.11 Разклонението причинява спиране с един цикъл в петстепенния тръбопровод.

Инструкцията след разклонението се извлича, но инструкцията се игнорира и извличането се рестартира
след като целта на клона е известна. Вероятно е очевидно, че ако клонът не бъде взет,
вторият IF за наследник на клон е излишен. Това ще бъде разгледано скоро.
Намаляване на санкциите за клонове на тръбопроводи
Има много методи за справяне със спиранията на тръбопровода, причинени от разклонение

забавяне; обсъждаме четири прости схеми за време за компилиране в този подраздел. В тези
четири схеми действията за клон са статични - те са фиксирани за всеки клон
по време на цялото изпълнение. Софтуерът може да се опита да минимизира наказанието за клона
използване на знания за хардуерната схема и поведението на разклоненията. Глава 3
разглежда по-мощни хардуерни и софтуерни техники за статични и
динамично прогнозиране на разклонения.
Най-простата схема за справяне с клоните е да замразите или промиете тръбопровода,

задържане или изтриване на всички инструкции след разклонението до местоназначението на разклонението
е известно. Привлекателността на това решение се крие преди всичко в неговата простота и двете
за хардуер и софтуер. Това е решението, използвано по-рано в тръбопровода, показан в
Фигура C.11. В този случай наказанието за бранша е фиксирано и не може да бъде намалено с
софтуер.
По-ефективна и само малко по-сложна схема е лечението

всеки клон като незает, просто позволявайки на хардуера да продължи, сякаш
клонове не бяха изпълнени. Тук трябва да се внимава да не се смени процесора
състояние, докато резултатът от разклонението стане определено известен. Сложността на това
схема възниква от необходимостта да се знае кога състоянието може да бъде променено от
инструкции и как да „отмените“ такава промяна.
В простия петстепенен тръбопровод, тази предвидена-не-приета или предвидена-неприета
схема се прилага чрез продължаване на извличането на инструкции, сякаш
клонът беше нормална инструкция. Тръбопроводът изглежда така, сякаш не се случва нищо необичайно.
Ако клонът е взет обаче, трябва да обърнем извлечения
инструкция в no-op и рестартирайте извличането на целевия адрес. Фигура C.12
показва и двете ситуации.
Невзета инструкция за клон АКО документ за самоличност EX MEM WB
Взета клонова инструкция АКО документ за самоличност EX MEM WB
Инструкция i + 1 АКО празен празен празен празен
Разклонителна цел АКО документ за самоличност EX MEM WB
Разклонение цел + 1 АКО документ за самоличност EX MEM WB
Разклоняване цел + 2 АКО документ за самоличност EX MEM WB
Фигура C.12 Схемата за предвидено-не-взето и последователността на тръбопровода, когато клонът не е поет (отгоре) и
взето (отдолу). Когато клонът е незает, определен по време на ID, ние извличаме падането и просто продължаваме. Ако
клонът е взет по време на ID, ние рестартираме извличането в целта на клона. Това води до всички инструкции, следващи
разклоняване до спиране 1 тактов цикъл.
Алтернативна схема е всеки клон да се третира като взет. Веднага щом клонът
се декодира и целевият адрес се изчислява, приемаме клона, който ще бъде взет
и започнете да извличате и изпълнявате в целта. Защото в нашия петстепенен тръбопровод
ние не знаем целевия адрес по-рано, отколкото знаем резултата от разклонението,
няма предимство в този подход за този тръбопровод. В някои процесори -
особено тези с имплицитно зададени кодове на условия или по-мощни (и следователно
по-бавни) условия на разклоняване – целта на разклонението е известна преди изхода на
разклонението и схемата с предвидено взето може да има смисъл. В схема с предвидено-взето или
предвидено-не-взето, компилаторът може да подобри производителността чрез
организиране на кода, така че най-честият път да съвпада с този на хардуера
избор. Нашата четвърта схема предоставя повече възможности за компилатора
подобряване на производителността.
Четвъртата схема, използвана в някои процесори, се нарича забавено разклоняване. Това

Техниката е широко използвана в ранните RISC процесори и работи сравнително добре
в петстепенния тръбопровод. При забавено разклонение, цикълът на изпълнение с разклонение
забавяне на един е
клонова инструкция
последователен наследник1
целта на клона, ако е взета
Последователният наследник е в слота за забавяне на разклонението. Тази инструкция се изпълнява

дали клонът е взет или не. Поведението на тръбопровода на петстепенния тръбопровод със закъснение
на разклонението е показано на фигура C.13. Въпреки че е възможно да има
клон забавяне по-дълго от едно, на практика почти всички процесори със закъснение
клонът има забавяне на една инструкция; други техники се използват, ако тръбопроводът
има по-дълго потенциално наказание за клон.
Невзета инструкция за клон АКО документ за самоличност EX MEM WB
Инструкция за забавяне на клона (i + 1) АКО документ за самоличност EX MEM WB
Взета клонова инструкция АКО документ за самоличност EX MEM WB
Инструкция за забавяне на клона (i + 1) АКО документ за самоличност EX MEM WB
Разклонителна цел АКО документ за самоличност EX MEM WB
Разклонение цел + 1 АКО документ за самоличност EX MEM WB
Разклоняване цел + 2 АКО документ за самоличност EX MEM WB
Фигура C.13 Поведението на забавено разклоняване е същото независимо дали разклонението е взето или не. Инструкциите в
слота за забавяне (има само един слот за забавяне за MIPS) се изпълняват. Ако клонът не е взет, изпълнението продължава с
инструкцията след инструкцията за забавяне на клона; ако клонът е взет, изпълнението продължава в целта на клона.
Когато инструкцията в слота за забавяне на разклонението също е разклонение, значението е неясно: Ако разклонението не е взето, какво
трябва да се случи с клона в слота за забавяне на клона? Поради това объркване, архитектурите със закъснение се разклоняват
често забраняват поставянето на клон в слота за забавяне.
DADD R1, R2, R3 DADD R1, R2, R3

DSUB R4, R5, R6
ако R2 = 0 тогава ако R1 = 0 тогава
Слот за забавяне DADD R1, R2, R3 Слот за забавяне
ако R1 = 0 тогава ИЛИ R7, R8, R9
DSUB R4, R5, R6

Слот за забавяне
става става става
DSUB R4, R5, R6 DADD R1, R2, R3
ако R2 = 0 тогава ако R1 = 0 тогава
DADD R1, R2, R3 DADD R1, R2, R3 ИЛИ R7, R8, R9
ако R1 = 0 тогава
DSUB R4, R5, R6 DSUB R4, R5, R6
(а) От преди (b) От целта (c) От падане
Фигура C.14 Планиране на слота за забавяне на разклонението. Горното поле във всяка двойка показва кода преди планиране;
долното поле показва планирания код. В (a) слотът за забавяне е планиран с независима инструкция от преди разклонението.
Това е най-добрият избор. Стратегии (b) и (c) се използват, когато (a) не е възможно. В кодовите последователности за (b) и (c)
използването на R1 в условието за разклоняване предотвратява преместването на инструкцията DADD (чиято дестинация е
R1) след разклонението. В (b) слотът за забавяне на разклонението се планира от целта на разклонението; обикновено
целевата инструкция ще трябва да бъде копирана, защото може да бъде достигната по друг път. Стратегия (b) се предпочита,
когато разклонението е взето с голяма вероятност, като например разклонение на цикъл. И накрая, разклонението може да бъде
насрочено от невзетото падане, както в (c). За да бъде тази оптимизация легална за (b) или (c), трябва да е ОК да се изпълни
преместената инструкция, когато разклонението тръгне в неочаквана посока. Под OK имаме предвид, че работата е загубена,
но програмата ще продължи да се изпълнява правилно. Такъв е случаят например в (c), ако R7 беше неизползван временен
регистър, когато разклонението тръгне в неочаквана посока.
Работата на компилатора е да направи последващите инструкции валидни и полезни.

Използват се редица оптимизации. Фигура C.14 показва трите начина, по които може да се планира
забавянето на разклонението.
Ограниченията на планирането на отложено разклоняване произтичат от: (1) ограниченията
върху инструкциите, които са планирани в слотовете за закъснение, и (2) способността ни да
прогнозираме по време на компилиране дали е вероятно дадено разклонение да бъде взето или не.
За да се подобри способността на компилатора да запълва слотовете за забавяне на разклоненията,
повечето процесори с условни разклонения са въвели анулиращ или анулиращ разклонение. При
анулиращо разклонение инструкцията включва посоката, в която разклонението е предвидено.
Когато клонът се държи според предвиденото, инструкцията в слота за забавяне на клона просто се изпълнява, както би
обикновено е със забавен клон. Когато разклонението е неправилно предвидено,

инструкцията в слота за забавяне на разклонението просто се превръща в безоперационна.
Изпълнение на клонови схеми
Какво е ефективното представяне на всяка от тези схеми? Ефективното ускоряване на

тръбопровода с санкции за разклонения, като се приеме, че идеалният CPI е 1, е
= -------------------------------------------------- -------------------------------------------
Ускоряване на тръбопровода
+
1 Цикли на спиране на тръбопровода от разклонения
Поради следното:
Цикли на спиране на тръбопровода от разклонения = Честота на разклонение × наказание за разклонение
ние добиваме:
= -------------------------------------------------- --------------------------------------------
Ускоряване на тръбопровода
+
1 Честота ×
на клон Наказание за клон
Честотата на разклоняване и наказанието за разклоняване могат да имат компонент и от двете

безусловни и условни клонове. Последните обаче доминират, тъй като те
са по-чести.
Пример За по-дълбок конвейер, като този в MIPS R4000, са необходими поне три етапа на тръбопровода, преди
да стане известен адресът на клона на целта и допълнителен цикъл
преди да бъде оценено състоянието на клона, като се приеме, че няма застой в регистрите в
условно сравнение. Тристепенно забавяне води до санкции на бранша за
три най-прости схеми за прогнозиране, изброени на фигура C.15.
Намерете ефективната добавка към CPI, произтичаща от разклонения за този конвейер,
като се приемат следните честоти:
Безусловен клон 4%
Условен клон, незает 6%
Условен клон, взет 10%
Разклонителна схема Дузпа безусловна Неизпълнена дузпа Изпълнена дузпа
Промийте тръбопровода 2 3 3
Предвидено взето 2 3 2
Предвидено невзето 2 0 3
Фигура C.15 Наказания за разклонения за трите най-прости схеми за прогнозиране за по-дълбок конвейер.
Добавки към CPI от разходите на клона
Безусловни Невзети условни Взети условни

Разклонителна схема клонове клонове клонове Всички клонове
Честота на събитието 4% 6% 10% 20%
Задържащ тръбопровод 0,08 0,18 0,30 0,56
Предвидено взето 0,08 0,18 0,20 0,46
Предвидено невзето 0,08 0,00 0,30 0,38
Фигура C.16 Наказания за CPI за три схеми за прогнозиране на разклонения и по-дълбок конвейер.
Отговор Намираме CPI чрез умножаване на относителната честота на безусловните, условно невзетите и условно взетите
разклонения по съответните санкции. The
резултатите са показани на фигура C.16.
Разликите между схемите се увеличават значително с това по-дълго забавяне. Ако базовият CPI
беше 1 и клоновете бяха единственият източник на сергии,
идеалният тръбопровод би бил 1,56 пъти по-бърз от тръбопровод, който използва схемата за застой-
тръбопровод. Прогнозираната невзета схема би била 1,13 пъти по-добра от тази
схема на застой-тръбопровод при същите предположения.
Намаляване на разходите за клонове чрез прогнозиране
Тъй като тръбопроводите стават по-дълбоки и потенциалното наказание за разклонения се увеличава, използвайки
забавени клонове и подобни схеми стават недостатъчни. Вместо това имаме нужда
обърнете се към по-агресивни средства за прогнозиране на клонове. Такива схеми попадат в
два класа: евтини статични схеми, които разчитат на информацията, налична при компилирането
време и стратегии, които предвиждат разклонения динамично въз основа на поведението на програмата.
Тук обсъждаме и двата подхода.
Статично прогнозиране на разклонения
Ключов начин за подобряване на прогнозирането на клонове по време на компилиране е използването на
информация за профила, събрана от по-ранни изпълнения. Основното наблюдение, което прави това полезно
е, че поведението на клоновете често е бимодално разпределено; това означава, че отделен клон често е
силно предубеден към взето или невзето. Фигура C.17 показва
успех на прогнозирането на разклонения, използвайки тази стратегия. Използвани са същите входни данни
за писти и за събиране на профила; други проучвания показват, че промяната на
въвеждане, така че профилът да е за различен цикъл води само до малка промяна в
точност на прогнозиране, базирано на профила.
Ефективността на всяка схема за прогнозиране на разклонения зависи както от точността на схемата,
така и от честотата на условните разклонения, които варират в
SPEC от 3% до 24%. Фактът, че степента на погрешно предвиждане за целочислените програми е по-висока
и такива програми обикновено имат по-висока честота на разклоняване, е
основно ограничение за статично предвиждане на разклонения. В следващия раздел разглеждаме
динамични предсказатели на разклонения, които най-новите процесори са използвали.

25%
22%
20% 18%
15%
15%
12% 12%
11%
нш
енавзот
ак сед
не а
р
огр
цре оП
пн
10%
10% 9%
5% 6%
5%
0%
ли
gcc ухо
чydro2dmdljdpsu2cor
додук
eqntott
еспресо компрес
Цяло число Плаваща запетая
Бенчмарк
Фигура C.17 Степента на погрешно прогнозиране на SPEC92 за базиран на профил предиктор

варира в широки граници, но като цяло е по-добра за програмите с плаваща запетая, които имат
среден процент на погрешно прогнозиране от 9% със стандартно отклонение от 4%, отколкото за
цяло число програми, които имат среден процент на грешни прогнози от 15% със стандартно
отклонение от 5%. Реалната производителност зависи както от точността на прогнозиране, така
и от честотата на разклоненията, които варират от 3% до 24%.
Динамично предсказване на разклонения и буфери за предсказване на разклонения
Най-простата динамична схема за предсказване на разклонения е буфер за предсказване на

разклонения или таблица с история на разклоненията. Буферът за предсказване на разклонения
е малка памет, индексирана от долната част на адреса на инструкцията за разклоняване.
Паметта съдържа бит, който казва дали клонът е бил взет наскоро или не. Тази схема е най-
простият вид буфер; той няма етикети и е полезен само за намаляване на забавянето на
разклонението, когато е по-дълго от времето за изчисляване на възможните целеви компютри.
С такъв буфер всъщност не знаем дали прогнозата е вярна - може да е поставена там от друг
клон, който има същите адресни битове от нисък ред.
Но това няма значение. Прогнозата е намек, който се приема за правилен и извличането започва
в предвидената посока. Ако подсказката се окаже грешна, прогнозният бит се обръща и се
съхранява обратно.
Този буфер е ефективно кеш, където всеки достъп е хит, и, както ще видим,
производителността на буфера зависи както от това колко често е прогнозата за
интересуващия ни клон, така и колко точна е прогнозата, когато съвпада. Преди да анализираме
производителността, е полезно да направим малко, но важно подобрение в точността на схемата
за предсказване на разклонения.
Тази проста 1-битова схема за предсказване има недостатък в производителността: Дори ако
едно разклонение е почти винаги взето, ние вероятно ще прогнозираме неправилно два пъти, вместо
веднъж, когато не е взето, тъй като погрешното предсказване причинява преобръщане на бита за
прогнозиране.
За да се коригира тази слабост, често се използват 2-битови схеми за предсказване. В 2-
битова схема една прогноза трябва да пропусне два пъти, преди да бъде променена. Фигура C.18
показва процесора с крайно състояние за 2-битова схема за прогнозиране.
Буферът за предсказване на разклонения може да бъде реализиран като малък, специален
„кеш“, достъпен с адреса на инструкцията по време на етапа на IF тръбата, или като двойка битове,
прикрепени към всеки блок в кеша на инструкциите и извлечени с инструкцията. Ако инструкцията
е декодирана като разклонение и ако разклонението е предвидено като взето, извличането започва
от целта веднага след като компютърът е известен. В противен случай последователното извличане
и изпълнение продължават. Както показва фигура C.18 , ако прогнозата се окаже грешна, битовете за
прогноза се променят.
Какъв вид точност може да се очаква от буфер за предсказване на разклонения, използващ 2
бита на запис в реални приложения? Фигура C.19 показва това за SPEC89
Взета
Не е взето
Прогнозирайте взето Прогнозирайте
11 взето 10
Взета
Взета Не е взето
Не е взето
Прогнозата не е взета Прогнозата не е взета

01 00
Взета
Не е взето
Фигура C.18 Състоянията в 2-битова схема за прогнозиране. Чрез използването на 2 бита, а не на

1, клон, който силно предпочита взето или не взето - както правят много клонове - ще бъде погрешно
прогнозиран по-рядко, отколкото с 1-битов предиктор. Двата бита се използват за кодиране на
четирите състояния в системата. 2-битовата схема всъщност е специализация на по-обща схема,
която има n-битов насищащ брояч за всеки запис в буфера за прогнозиране. С n-битов брояч броячът
може да приема стойности между 0 и 2n – 1: Когато броячът е по-голям или равен на половината от
максималната си стойност (2n – 1), разклонението е предварително предвидено както е взето; в
противен случай се прогнозира като невзет. Проучванията на n-битови предиктори показват, че
2-битовите предиктори се справят почти толкова добре, поради което повечето системи разчитат
на 2-битови предиктори на разклонения, а не на по-общите n-битови предиктори.
nasa7 1%
матрица300 0%
tomcatv 1%
додук 5%
подправка 9%
а8
евокр9 чE
мC Pб
не S
fpppp 9%
gcc 12%
еспресо 5%
eqntott 18%
ли 10%
0% 2% 4% 6% 8% 10% 12% 14% 16% 18%
Фигура C.19 Точност на прогнозиране на 4096-въведен 2-битов буфер за прогнозиране за

тестовете SPEC89. Процентът на погрешни прогнози за показателите за цели числа (gcc,
espresso, eqntott и li) е значително по-висок (средно 11%) от този за програмите с плаваща
запетая (средно 4%). Пропускането на ядрата с плаваща запетая (nasa7, matrix300 и tomcatv)
все още дава по-висока точност за FP бенчмарковете, отколкото за целочислените
бенчмаркове. Тези данни, както и останалите данни в този раздел, са взети от проучване
за прогнозиране на разклонения, направено с помощта на архитектурата IBM Power и
оптимизиран код за тази система. Вижте Pan, So и Rameh [1992]. Въпреки че тези данни са
за по-стара версия на подмножество от бенчмарковете SPEC, по-новите бенчмаркове са по-
големи и биха показали малко по-лошо поведение, особено за целочислените бенчмаркове.
сравнителен анализ на буфер за прогнозиране на клонове с 4096 записа води до точност на прогнозиране, варираща
от над 99% до 82%, или процент на грешни прогнози от 1% до 18%.
4K входен буфер, като този, използван за тези резултати, се счита за малък според стандартите от 2005 г. и по-
голям буфер може да доведе до малко по-добри резултати.
Докато се опитваме да използваме повече ILP, точността на нашето предвиждане на разклонения става
критична. Както можем да видим на Фигура C.19, точността на предикторите за целочислени програми, които
обикновено имат и по-високи честоти на разклоненията, е по-ниска, отколкото за научните програми с интензивни
цикли. Можем да атакуваме този проблем по два начина: чрез увеличаване на размера на буфера и чрез
увеличаване на точността на схемата, която използваме за всяка прогноза. Буфер с 4K записи обаче, както показва
Фигура C.20 , работи доста сравнимо с безкраен буфер, поне за бенчмаркове като тези в SPEC. Данните на фигура
C.20 показват ясно, че честотата на попадения на буфера не е основният ограничаващ фактор. Както споменахме по-
горе, просто се увеличава

1%
nasa7
0%
0% 4096 записа: 2
матрица300
0% бита на запис
Неограничени
записи: 2 бита на запис
1%
tomcatv
0%
5%
додук
5%
9%
подправка
9%
а8
евокр9 чE
мC Pб
не S
9%
fpppp
9%
12%
gcc
11%
5%
еспресо
5%
18%
eqntott
18%
10%
ли
10%
0% 2% 4% 6% 8% 10% 12% 14% 16% 18%
Фигура C.20 Точност на прогнозиране на 2-битов буфер за прогнозиране с 4096 записа спрямо
безкраен буфер за сравнителните тестове SPEC89. Въпреки че тези данни са за по-стара
версия на подмножество от тестовете на SPEC, резултатите биха били сравними за по-нови
версии с може би до 8K записи, необходими за съпоставяне на безкраен 2-битов предиктор.
броят битове на предиктор без промяна на структурата на предиктора също има малко
влияние. Вместо това трябва да разгледаме как можем да увеличим точността на всеки
предиктор.
C.3 Как се изпълнява тръбопроводът?
Преди да пристъпим към основно конвейерно изграждане, трябва да прегледаме проста

реализация на неконвейерна версия на MIPS.
C.3 Как се изпълнява тръбопроводът? C-31
Проста реализация на MIPS

В този раздел ние следваме стила на раздел C.1, като първо показваме проста неконвейерна
реализация и след това конвейерната реализация. Този път обаче
нашият пример е специфичен за MIPS архитектурата.
В този подраздел се фокусираме върху тръбопровод за цяло число на MIPS, което
се състои от дума за зареждане-съхраняване, клон, равен на нула, и целочислени ALU операции.
По-късно в това приложение ще включим основните операции с плаваща запетая.
Въпреки че обсъждаме само част от MIPS, основните принципи могат да бъдат разширени
да се справи с всички инструкции. Първоначално използвахме по-малко агресивно изпълнение
на разклонителна инструкция. Показваме как да приложим по-агресивната версия
в края на този раздел.
Всяка MIPS инструкция може да бъде изпълнена за най-много 5 тактови цикъла. 5

тактовите цикли са както следва:
1. Цикъл на извличане на инструкции
(IF): IR Mem[PC]; NPC

PC + 4;
Операция — Изпратете компютъра и изтеглете инструкцията от паметта в

регистър на инструкции (IR); увеличете компютъра с 4, за да адресирате следващата последователност
инструкция. IR се използва за задържане на инструкцията, която ще е необходима при следващите
тактови цикли; по същия начин регистърът NPC се използва за задържане на следващия

последователен компютър.
2. Цикъл на декодиране/регистриране на извличане на инструкции (ID):
A Regs[rs];
B Regs[rt];
Imm разширено със знак непосредствено поле на IR;
Операция — Декодиране на инструкцията и достъп до регистрационния файл, за да го прочетете

регистри (rs и rt са спецификаторите на регистъра). Резултатите от регистрите с общо
предназначение се четат в два временни регистъра (A и B) за използване в
по-късни часовникови цикли. По-малките 16 бита на IR също са разширени със знак и
се съхраняват във временния регистър Imm, за използване в следващия цикъл.
Декодирането се извършва паралелно с четене на регистри, което е възможно
защото тези полета са на фиксирано място във формата на MIPS инструкция.
Тъй като непосредствената част от инструкцията се намира в идентичен

място във всеки MIPS формат, разширеното със знак незабавно също се изчислява
по време на този цикъл, в случай че е необходимо в следващия цикъл.
3. Цикъл на изпълнение/ефективен адрес (EX):
ALU оперира върху операндите, подготвени в предишния цикъл, като изпълнява

една от четирите функции в зависимост от типа MIPS инструкция:
Препратка към паметта:
ALUOutput A + Imm;
Операция – ALU добавя операндите, за да формира ефективния адрес и

поставя резултата в регистъра ALUOutput.
Инструкция за регистриране-регистриране на ALU:
ALUOutput A func B;
Операция — АЛУ изпълнява операцията, определена от функционалния код

върху стойността в регистър A и върху стойността в регистър B. Резултатът се поставя
във временния регистър ALUOutput.
Инструкция за незабавно регистриране на ALU:
ALUOutput A op Imm;
Операция – ALU изпълнява операцията, определена от кода на операцията на

стойността в регистър A и стойността в регистър Imm. Резултатът е поставен
във временния регистър ALUOutput.
Клон:
ALUOutput NPC + (Imm << 2);
Cond (A == 0)
Операция – ALU добавя NPC към разширената със знак непосредствена стойност
в Imm, което се измества наляво с 2 бита, за да се създаде отместване на думата, за да се изчисли
адрес на целевия клон. Регистър А, който е прочетен в предишния
цикъл, се проверява, за да се определи дали разклонението е взето. Тъй като ние сме
като се има предвид само една форма на клон (BEQZ), сравнението е срещу 0.
Имайте предвид, че BEQZ всъщност е псевдоинструкция, която се превежда като BEQ с
R0 като операнд. За простота, това е единствената форма на клон, която разглеждаме.
Архитектурата за зареждане на MIPS означава, че ефективният адрес и
циклите на изпълнение могат да бъдат комбинирани в един такт, тъй като не

инструкцията трябва едновременно да изчисли адрес на данни, да изчисли an
целеви адрес на инструкция и извършете операция върху данните. Другият
целочислените инструкции, които не са включени по-горе, са скокове от различни форми, които
са подобни на клони.
4. Достъп до паметта/цикъл на завършване на разклоняване (MEM):
Компютърът е актуализиран за всички инструкции: PC NPC;
Препратка към паметта:

LMD Mem[ALUOutput] или
Mem[ALUOutput] B;
Операция — достъп до паметта, ако е необходимо. Ако инструкцията е зареждане, данните се връщат
от паметта и се поставят в регистъра LMD (load memory data); ако то
е магазин, тогава данните от регистър B се записват в паметта. в
и в двата случая използваният адрес е този, изчислен по време на предишния цикъл и
съхранявани в регистъра ALUOutput.
Клон:
if (cond) PC ALUOutput
Операция — Ако инструкцията се разклонява, компютърът се заменя с разклонението

целеви адрес в регистъра ALUOutput.
5. Цикъл на обратно записване (WB):
Инструкция за регистриране-регистриране на ALU:
Regs[rd] ALUOutput;
Инструкция за незабавно регистриране на ALU:
Regs[rt] ALUOutput;
Инструкция за зареждане:
Regs[rt] LMD;
Операция — Запишете резултата в регистрационния файл, независимо дали идва от

система с памет (която е в LMD) или от ALU (която е в ALUOut-put); полето за местоназначение на
регистъра също е в една от двете позиции (rd или rt)
в зависимост от ефективния опкод.
Фигура C.21 показва как дадена инструкция преминава през пътя на данните. Накрая
на всеки тактов цикъл, всяка стойност, изчислена по време на този тактов цикъл и необходима
на по-късен тактов цикъл (независимо дали за тази инструкция или за следващата) се записва в a
устройство за съхранение, което може да бъде памет, регистър с общо предназначение, компютър или a
временен регистър (т.е. LMD, Imm, A, B, IR, NPC, ALUOutput или Cond). The
временните регистри съхраняват стойности между тактовите цикли за една инструкция, докато
другите елементи за съхранение са видими части от състоянието и съхраняват стойности между тях
последователни инструкции.
Въпреки че всички процесори днес са конвейерни, това многоциклово изпълнение

е разумно приближение на начина, по който повечето процесори биха били внедрени в по-ранни
времена. Прост краен автомат може да се използва за прилагане на контрола, следвайки 5-цикълната
структура, показана по-горе. За много повече
сложен процесор, може да се използва контрол на микрокод. И в двата случая последователност от
инструкции като тази по-горе ще определи структурата на контрола.
Има някои хардуерни излишъци, които могат да бъдат елиминирани в тази многоциклова
реализация. Например, има две ALU: едно за увеличаване на

PC и един, използван за изчисление на ефективен адрес и ALU. Тъй като те не са
необходими за един и същ тактов цикъл, бихме могли да ги обединим чрез добавяне на допълнителни
мултиплексори и споделяне на едно и също ALU. По същия начин инструкциите и данните могат да бъдат
съхранявани в една и съща памет, тъй като достъпите до данни и инструкции се случват на различни
часовникови цикли.
Вместо да оптимизираме тази проста реализация, ще оставим дизайна като
това е на фигура C.21, тъй като това ни предоставя по-добра основа за конвейерната обработка
изпълнение.
Като алтернатива на многоцикловия дизайн, обсъден в този раздел, бихме могли
също са внедрили процесора, така че всяка инструкция отнема 1 дълъг тактов цикъл.
В такива случаи временните регистри ще бъдат заличени, тъй като няма да има
всяка комуникация през тактови цикли в рамките на инструкция. Всяка инструкция
ще се изпълни в 1 дълъг тактов цикъл, записвайки резултата в паметта за данни, регистрите или
компютъра в края на часовниковия цикъл. CPI би бил един за такъв процесор.
Изпълнение/
Декодиране на инструкции/ Достъп до
Извличане на инструкции
адресно Пиша в
извличане на регистър изчисление паметта отговор на писмо
М
u
х
Добавете NPC
Клон
4 Нула? Cond
взета
М
u
Инструкция А х
IR
памет Регистри ALU
ALU
М изход
б u Данни
LMD М
х памет u
х
16 32
Знак- лмм
удължаване
Фигура C.21 Реализирането на MIPS пътя за данни позволява всяка инструкция да бъде изпълнена за 4 или 5 тактови цикъла. Въпреки
че компютърът е показан в частта от пътя на данните, която се използва при извличане на инструкции, и регистрите са показани в
частта от пътя на данните, която се използва при декодиране/регистриране на инструкции, и двете функционални единици се
четат, както и се записват по инструкция. Въпреки че показваме тези функционални единици в цикъла, съответстващ на мястото,
където се четат, компютърът се записва по време на тактовия цикъл за достъп до паметта, а регистрите се записват по време на
тактовия цикъл за обратно записване. И в двата случая записите в по-късните етапи на канала се показват от изхода на
мултиплексора (при достъп до паметта или обратно записване), който пренася стойност обратно към компютъра или регистрите. Тези
обратни сигнали въвеждат голяма част от сложността на тръбопровода, тъй като показват възможността за опасности.
Тактовият цикъл обаче ще бъде приблизително равен на пет пъти тактовия цикъл на
многоцикловия процесор, тъй като всяка инструкция ще трябва да премине през всички
функционални единици. Дизайнерите никога не биха използвали това изпълнение с един
цикъл по две причини. Първо, внедряването на един цикъл би било много неефективно за
повечето процесори, които имат разумна вариация в количеството работа и следователно във
времето на тактовия цикъл, необходимо за различни инструкции. Второ, изпълнението с един
цикъл изисква дублирането на функционални единици, които биха могли да бъдат споделени
в изпълнение с много цикъл. Независимо от това, този път на данни с един цикъл ни позволява
да илюстрираме как конвейерната обработка може да подобри времето на тактовия цикъл, за разлика от CPI, на проце
Основен тръбопровод за MIPS
Както и преди, можем да конвейеризираме пътя на данните от Фигура C.21 без почти никакви
промени, като стартираме нова инструкция на всеки такт. Тъй като всеки тръбен етап е такъв
активен на всеки такт, всички операции в етап на тръба трябва да завършат за 1 такт и всяка
комбинация от операции трябва да може да се осъществи наведнъж.
Освен това конвейерната обработка на пътя на данните изисква стойностите, предавани от един
етап на тръба към следващия, да бъдат поставени в регистри. Фигура C.22 показва MIPS
тръбопровода със съответните регистри, наречени тръбопроводни регистри или конвейери на
тръбопровода, между всеки етап на тръбопровода. Регистрите са обозначени с имената на етапите,
които свързват. Фигура C.22 е начертана така, че връзките през регистрите на тръбопровода
от един етап към друг да са ясни.
Всички регистри, необходими за временно задържане на стойности между тактовите цикли
в рамките на една инструкция, се включват в тези конвейерни регистри. Полетата на регистъра
с инструкции (IR), който е част от регистъра IF/ID, са етикетирани, когато се използват за
предоставяне на имена на регистри. Регистрите на тръбопровода пренасят както данни, така и
управление от един етап на тръбопровода към следващия. Всяка стойност, необходима на по-късен
етап на конвейер, трябва да бъде поставена в такъв регистър и копирана от един регистър на
конвейер в следващия, докато вече не е необходима. Ако се опитахме просто да използваме
временните регистри, които имахме в нашия по-ранен неконвейерен път на данни, стойностите
можеха да бъдат презаписани, преди всички употреби да са завършени. Например полето на използван регис
IF/ID ID/EX EX/MEM MEM/WB
4
М Клонът
ДОБАВЯНЕ u взет
х
Нула?
IR6..10
М
IR11..15
u
Памет за IR
х
инструкции MEM/WB.IR Регистри ALU
М
u Памет М
х за данни u
х
16 32
Знак-
Фигура C.22 Пътят на данните е конвейерен чрез добавяне на набор от регистри, по един между всяка двойка етапи на конвейер.
Регистрите служат за предаване на стойности и контролна информация от един етап на следващ. Можем също така да мислим за компютъра
като за тръбопроводен регистър, който се намира преди IF етапа на тръбопровода, което води до един тръбопроводен регистър за всеки тръбен етап.
Спомнете си, че компютърът е регистър, задействан от край, записан в края на тактовия цикъл; следователно, няма условие за състезание
при писането на PC. Мултиплексорът за избор за PC е преместен, така че PC се записва точно на един етап (IF). Ако не го преместим, ще има
конфликт, когато възникне разклонение, тъй като две инструкции ще се опитат да запишат различни стойности в компютъра. Повечето от
пътищата на данните протичат отляво надясно, което е от по-рано във времето към по-късно. Пътищата, протичащи отдясно наляво (които
пренасят информацията за обратно записване на регистъра и информацията за компютъра на клон) въвеждат усложнения в нашия тръбопровод.
за операция за запис при натоварване или ALU се предоставя от регистъра на тръбопровода MEM/WB,
а не от регистъра IF/ID. Това е така, защото искаме операция за зареждане или ALU да запише
регистъра, определен от тази операция, а не регистърното поле на инструкцията, която в момента
преминава от IF към ID! Това поле на регистъра на дестинацията просто се копира от един
тръбопроводен регистър в следващия, докато стане необходимо по време на етапа на WB.
Всяка инструкция е активна в точно един етап от конвейера в даден момент; следователно
всички действия, предприети от името на инструкция, се случват между двойка конвейерни
регистри. По този начин можем също така да разгледаме дейностите на конвейера, като изследваме
какво трябва да се случи на всеки етап от конвейера в зависимост от типа инструкция. Фигура C.23
показва този изглед. Полетата на конвейерните регистри са именувани така, че да показват потока
от данни от един етап към следващия. Забележете, че действията в първите два етапа са независими
от текущия тип инструкция; те трябва да са независими, тъй като инструкцията не се декодира до
края на ID етапа. IF дейността зависи от това дали инструкцията в EX/MEM е взет клон. Ако е така,
тогава целевият адрес на разклонението на инструкцията за разклоняване в EX/MEM се записва в
компютъра в края на IF; в противен случай увеличеният компютър ще бъде записан обратно. (Както
казахме по-рано, този ефект на разклоненията води до усложнения в тръбопровода, с които ще се
занимаваме в следващите няколко раздела.) Кодирането с фиксирана позиция на операндите на

източника на регистъра е от решаващо значение за позволяване на регистрите да бъдат извлечени
по време на ID.
За да контролираме този прост тръбопровод, ние трябва само да определим как да зададем
контрола за четирите мултиплексора в пътя на данните от Фигура C.22. Двата мултиплексора в ALU
стъпалото се настройват в зависимост от вида на инструкцията, който се диктува от IR полето на ID/
EX регистъра. Горният входен мултиплексор на ALU се задава от това дали инструкцията е
разклонение или не, а долният мултиплексор се задава от това дали инструкцията е ALU операция
регистър-регистър или друг тип операция.
Мултиплексорът в етапа IF избира дали да използва стойността на инкрементирания компютър или
стойността на EX/MEM.ALUOutput (целевия клон), за да записва в компютъра. Този мултиплексор се
управлява от полето EX/MEM.cond. Четвъртият мултиплексор се контролира от това дали
инструкцията в WB етапа е зареждане или ALU операция. В допълнение към тези четири
мултиплексора, има нужда от един допълнителен мултиплексор, който не е начертан на Фигура C.22,
но чието съществуване е ясно от разглеждане на WB етапа на ALU операция. Полето на регистъра на
местоназначението е на едно от две различни места в зависимост от типа на инструкцията (регистър-
регистр ALU срещу ALU непосредствено или зареждане). По този начин ще се нуждаем от мултиплексор,
за да изберем правилната част от IR в регистъра MEM/WB, за да посочим полето за местоназначение
на регистъра, ако приемем, че инструкцията записва регистър.
Внедряване на контрола за MIPS тръбопровода
Процесът на оставяне на дадена инструкция да се премести от етапа на декодиране на инструкции

(ID) в етапа на изпълнение (EX) на този конвейер обикновено се нарича издаване на инструкции; се
казва, че е издадена инструкция, която е направила тази стъпка . За целочисления конвейер на MIPS
всички опасности от данни могат да бъдат проверени по време на фазата на идентификация на конвейера.
Ако съществува опасност от данни, инструкцията се спира, преди да бъде издадена. По същия начин
можем да определим какво препращане ще е необходимо по време на ID и да зададем подходящото

сцена Всякакви инструкции
АКО
IF/ID.IR Mem[PC];
IF/ID.NPC,PC (if ((EX/MEM.opcode == клон) & EX/MEM.cond){EX/MEM.
ALUOutput} else {PC+4});
ID/EX.A Regs[IF/ID.IR[rs]]; ID/EX.B Regs[IF/ID.IR[rt]];

ID/EX.NPC IF/ID.NPC; ID/EX.IR IF/ID.IR;
ID/EX.Imm sign-extend(IF/ID.IR[непосредствено поле]);
ALU инструкция Заредете или съхранете инструкция Отраслова инструкция
EX EX/MEM.IR ID/EX.IR; EX/MEM.IR към ID/EX.IR

EX/MEM.ALUOutput EX/MEM.ALUOutput EX/MEM.ALUOutput ID/
ID/EX.A func ID/EX.B; ID/EX.A + ID/EX.Imm; EX.NPC + (ID/
или
EX.Imm << 2);
EX/MEM.ALUOutput ID/
EX.A op ID/EX.Imm;
EX/MEM.B ID/EX.B; EX/MEM.cond (ID/
EX.A == 0);
MEM MEM/WB.IR EX/MEM.IR; MEM/WB.IR EX/MEM.IR;

MEM/WB.ALUOutput MEM/WB.LMD
EX/MEM.ALUизход; Mem[EX/MEM.ALUOutput];
или
Mem[EX/MEM.ALUOutput] EX/
MEM.B;
WB Regs[MEM/WB.IR[rd]] Само за натоварване:
MEM/WB.ALUOutput; Regs[MEM/WB.IR[rt]]
или
MEM/WB.LMD;
Regs[MEM/WB.IR[rt]]
MEM/WB.ALUOutput;
Фигура C.23 Събития на всеки тръбен етап от MIPS конвейера. Нека прегледаме действията в етапите, които са специфични
към тръбопроводната организация. В IF, в допълнение към извличането на инструкцията и изчисляването на новия компютър, ние съхраняваме
увеличен компютър както в компютъра, така и в тръбопроводен регистър (NPC) за по-късна употреба при изчисляване на целта на клона
адрес. Тази структура е същата като организацията на фигура C.22, където компютърът се актуализира в IF от един от двата
източници. В ID извличаме регистрите, разширяваме знака на долните 16 бита на IR (непосредственото поле) и предаваме
по IR и NPC. По време на EX извършваме ALU операция или изчисляване на адрес; минаваме по IR и
регистър B (ако инструкцията е съхраняване). Също така задаваме стойността на cond на 1, ако инструкцията е взето разклонение. По време на
фазата на MEM, ние циклично променяме паметта, записваме компютъра, ако е необходимо, и предаваме необходимите стойности в крайната тръба
сцена. И накрая, по време на WB актуализираме полето на регистъра или от ALU изхода, или от заредената стойност. За простота
ние винаги предаваме целия IR от един етап на следващия, въпреки че докато инструкцията продължава по тръбопровода, по-малко
и е необходимо по-малко от IR.
контроли тогава. Откриването на блокировки в началото на тръбопровода намалява хардуера

сложност, защото хардуерът никога не трябва да спира инструкция, която има
актуализира състоянието на процесора, освен ако целият процесор не е спрял. Като алтернатива
можем да открием опасността или пренасочването в началото на часовниковия цикъл
който използва операнд (EX и MEM за този конвейер). За да покаже разликите в
тези два подхода ще покажем как блокировката за четене след запис (RAW)
опасност с източник, идващ от инструкция за зареждане (наречена блокировка за зареждане) може
да се реализира чрез проверка в ID, докато изпълнението на препращащи пътища
Примерна кодова
Ситуация последователност Действие
Без зависимост LD R1,45(R2) Не е възможна опасност, тъй като не съществува

DADD R5,R6,R7 зависимост от R1 в следващите три инструкции
DSUB R8,R6,R7 непосредствено.
ИЛИ R9, R6, R7
Зависимост LD R1,45(R2) Сравнителните програми откриват използването на R1 в DADD
изискваща сергия DADD R5,R1,R7 и спре DADD (и DSUB и OR) преди DADD да започне
DSUB R8,R6,R7 EX.
ИЛИ R9, R6, R7
Зависимостта LD R1,45(R2) Компараторите откриват използването на R1 в DSUB и

се преодолява DADD R5,R6,R7 препращат резултата от натоварването към ALU навреме за DSUB
чрез препращане DSUB R8,R1,R7 за начало EX.

ИЛИ R9, R6, R7
Зависимост с LD R1,45(R2) Не е необходимо действие, тъй като четенето на R1 чрез ИЛИ

достъпи в ред DADD R5,R6,R7 се извършва през втората половина на фазата на
DSUB R8,R6,R7 идентификация, докато записът на заредените данни се
ИЛИ R9,R1,R7 извършва през първата половина.
Фигура C.24 Ситуации, които хардуерът за откриване на опасност в тръбопровода може да види чрез
сравняване на дестинацията и източниците на съседни инструкции. Тази таблица показва това
единственото необходимо сравнение е между дестинацията и източниците на двете
инструкции, следващи инструкцията, която е написала дестинацията. В случай на щанд,
зависимостите на тръбопровода ще изглеждат като третия случай, след като изпълнението продължи. На
Разбира се, опасностите, които включват R0, могат да бъдат игнорирани, тъй като регистърът винаги съдържа 0 и
тестът по-горе може да бъде разширен, за да направи това.
към ALU входовете може да се направи по време на EX. Фигура C.24 изброява разнообразието от обстоятелства,
с които трябва да се справим.
Нека започнем с прилагането на блокировката на товара. Ако има опасност от RAW
като инструкцията източник е зареждане, инструкцията за зареждане ще бъде в EX
етап, когато инструкция, която се нуждае от данните за зареждане, ще бъде в етап ID. По този начин,
можем да опишем всички възможни рискови ситуации с малка таблица, която може да бъде
директно преведено в изпълнение. Фигура C.25 показва таблица, която открива
всички блокировки за зареждане, когато инструкцията, използваща резултата за зареждане, е в етап ID.
След като бъде открита опасност, управляващият блок трябва да постави спирачката на тръбопровода
и предотвратяване на напредването на инструкциите в етапите IF и ID. Както казахме
по-рано цялата контролна информация се носи в регистрите на тръбопровода. (Носене
инструкцията е достатъчна, тъй като целият контрол се извлича от нея.) По този начин, когато
откриваме опасност, трябва само да променим контролната част на тръбопровода ID/EX
регистрирайте всички 0, което се оказва не-операция (инструкция, която не прави нищо,
като DADD R0,R0,R0). В допълнение, ние просто рециркулираме съдържанието на
IF/ID се регистрира за задържане на блокираната инструкция. В тръбопровод с по-сложни
опасности, ще се прилагат същите идеи: можем да открием опасността чрез сравняване
някакъв набор от конвейерни регистри и изместване на no-ops за предотвратяване на погрешно изпълнение.
Прилагането на логиката за пренасочване е подобно, въпреки че има повече случаи
да обмисли. Ключовото наблюдение, необходимо за прилагане на логиката за препращане, е

Полето на кода на операцията на Полето за код на операцията на
ID/EX (ID/EX.IR0..5) IF/ID (IF/ID.IR0..5) Съответстващи полета на операнд
Заредете
Регистър-регистр ALU ID/EX.IR[rt] == IF/
ID.IR[rs]
Заредете
Регистър-регистр ALU ID/EX.IR[rt] == IF/
ID.IR[rt]
Заредете Заредете, съхранявайте, незабавно ALU ID/EX.IR[rt] == IF/

или разклонете ID.IR[rs]
Фигура C.25 Логиката за откриване на необходимостта от блокировки на товара по време на етапа на идентификация на
една инструкция изисква три сравнения. Редове 1 и 2 на таблицата проверяват дали
load дестинационен регистър е един от регистрите източник за операция регистър-регистър
в ID. Ред 3 на таблицата определя дали регистърът на местоназначението на зареждането е източник за зареждане
или съхранете ефективен адрес, незабавен ALU или тест за клон. Не забравяйте, че IF/ID
регистърът съдържа състоянието на инструкцията в ID, което потенциално използва резултата от зареждането,
докато ID/EX държи състоянието на инструкцията в EX, която е инструкцията за зареждане.
че регистрите на тръбопровода съдържат както данните за препращане, така и

полета за регистър на източника и местоназначението. Всички препращания логично се случват от
ALU или изхода на паметта за данни към входа ALU, входа на паметта за данни или
единица за откриване на нула. По този начин можем да реализираме препращането чрез сравнение на
регистрите на местоназначението на IR, съдържащи се в EX/MEM и MEM/WB
етапи срещу регистрите на източника на IR, съдържащи се в ID/EX и EX/
MEM регистри. Фигура C.26 показва сравненията и възможното препращане
операции, при които дестинацията на препратения резултат е ALU вход за
инструкция в момента в EX.
В допълнение към компараторите и комбинираната логика, които трябва да определим кога
трябва да се активира препращащ път, ние също трябва да разширим мултиплексорите на ALU
входовете и да добавим връзките от регистрите на конвейера
които се използват за изпращане на резултатите. Фигура C.27 показва съответните сегменти на
конвейерният път на данни с допълнителните мултиплексори и връзки на място.
За MIPS хардуерът за откриване на опасност и препращане е сравнително прост; ще видим,
че нещата стават малко по-сложни, когато ние
разширете този тръбопровод, за да се справите с плаваща запетая. Преди да направим това, трябва
дръжка клонове.
Работа с клонове в тръбопровода

В MIPS клоновете (BEQ и BNE) изискват тестване на регистър за равенство на
друг регистър, който може да е R0. Ако разгледаме само случаите на BEQZ и
BNEZ, които изискват нулев тест, е възможно да завършите това решение до края
на ID цикъла чрез преместване на нулевия тест в този цикъл. За да се възползвате от
ранно решение за това дали клонът е взет, и двата компютъра (взети и невзети) трябва
да се изчисли рано. Изчисляването на целевия клон адрес по време на ID изисква an
допълнителен суматор, тъй като основният ALU, който е бил използван за тази функция т.н
Регистър
на Дестинация
Регистър на Операционен код тръбопровода, на Сравнение
тръбопровода, съдържащ на източника съдържащ Операционен код на инструкцията препратения (ако е равно,
инструкция за източник инструкция инструкция за местоназначение
за местоназначение резултат тогава напред)
EX/MEM Регистър- ID/EX Регистър-регистр ALU, Горен ALU EX/MEM.IR[rd] == ID/

регистр ALU ALU незабавно, товар, вход EX.IR[rs]
магазин, клон
EX/MEM Регистър- ID/EX Регистър-регистр ALU Долен ALU вход EX/MEM.IR[rd] == ID/
регистр ALU EX.IR[rt]
MEM/WB Регистър- ID/EX Регистър-регистр ALU, Горен ALU MEM/WB.IR[rd] == ID/
регистр ALU ALU незабавно, товар, вход EX.IR[rs]
MEM/WB Регистър- ID/EX Регистър-регистр ALU Долен ALU вход MEM/WB.IR[rd] ==

регистр ALU ID/EX.IR[rt]
EX/MEM ALU ID/EX Регистър-регистр ALU, Горен ALU EX/MEM.IR[rt] == ID/
веднага ALU незабавно, товар, вход EX.IR[rs]
EX/MEM ALU ID/EX Регистър-регистр ALU Долен ALU вход EX/MEM.IR[rt] == ID/
веднага EX.IR[rt]
MEM/WB ALU ID/EX Регистър-регистр ALU, Горен ALU MEM/WB.IR[rt] ==
веднага ALU незабавно, товар, вход ID/EX.IR[rs]
MEM/WB ALU ID/EX Регистър-регистр ALU Долен ALU вход MEM/WB.IR[rt] ==

веднага ID/EX.IR[rt]
MEM/WB Заредете ID/EX Регистър-регистр ALU, Горен ALU MEM/WB.IR[rt] == ID/
ALU незабавно, товар, вход EX.IR[rs]
MEM/WB Заредете ID/EX Регистър-регистр ALU Долен ALU вход MEM/WB.IR[rt] == ID/
EX.IR[rt]
Фигура C.26 Препращането на данни към двата входа на ALU (за инструкцията в EX) може да възникне от резултата на ALU
(в EX/MEM или в MEM/WB) или от резултата от натоварването в MEM/WB. Необходими са 10 отделни сравнения, за да се каже
дали трябва да се извърши операция по препращане. Горният и долният ALU входове се отнасят за входовете, съответстващи на
първият и вторият ALU изходен операнд, съответно, и са показани изрично на Фигура C.21 на страница C-34 и в
Фигура C.27 на страница C-41. Не забравяйте, че ключът на тръбопровода за инструкция за местоназначение в EX е ID/EX, докато
стойностите на източника идват от частта ALUOutput на EX/MEM или MEM/WB или частта LMD на MEM/WB. Има
едно усложнение, което не се разглежда от тази логика: работа с множество инструкции, които записват един и същ регистър. За
например по време на кодовата последователност DADD R1, R2, R3; DADDI R1, R1, #2; DSUB R4, R3, R1, логиката трябва да гарантира това
инструкцията DSUB използва резултата от инструкцията DADDI, а не резултата от инструкцията DADD. Логиката
показано по-горе може да се разшири, за да се справи с този случай, като просто се тества дали препращането от MEM/WB е разрешено само
когато препращането от EX/MEM не е активирано за същия вход. Тъй като резултатът от DADDI ще бъде в EX/MEM, така ще бъде
бъде препратен, а не резултатът DADD в MEM/WB.
далеч, не е използваем до EX. Фигура C.28 показва ревизирания канал на конвейерни данни.
С отделния суматор и решение за разклоняване, взето по време на ID, има само a
1-часов цикъл сергия на клонове. Въпреки че това намалява забавянето на разклонението до 1 цикъл,
ID/EX EX/MEM MEM/WB
Нула?
М
u
х
ALU
Данни
М памет
u
х
Фигура C.27 Препращането на резултати към ALU изисква добавянето на три

допълнителни входа на всеки ALU мултиплексор и добавянето на три пътя към новите входове.
Пътищата съответстват на байпас на: (1) ALU изхода в края на EX, (2) ALU изхода в края
на MEM етапа и (3) изхода на паметта в края на MEM етапа.
това означава, че ALU инструкция, последвана от разклоняване на резултата от инструкцията,

ще доведе до застой на данни. Фигура C.29 показва разклонителната част на ревизираната
таблица на тръбопровода от Фигура C.23.
В някои процесори опасностите от разклоняване са дори по-скъпи в тактови цикли,
отколкото в нашия пример, тъй като времето за оценка на състоянието на разклоняване и
изчисляване на дестинацията може да бъде дори по-дълго. Например, процесор с отделни етапи
на декодиране и извличане на регистри вероятно ще има забавяне на разклонението -
продължителността на контролната опасност - което е поне 1 тактов цикъл по-дълго. Забавянето
на клона, освен ако не бъде разгледано, се превръща в наказание за клон. Много по-стари
процесори, които прилагат по-сложни набори от инструкции, имат забавяне на разклоняването
от 4 тактови цикъла или повече, а големите, дълбоко конвейерни процесори често имат
наказание за разклоняване от 6 или 7. Като цяло, колкото по-дълбок е конвейерът, толкова по-
лошо е наказанието за разклоняване в тактови цикли. Разбира се, относителният ефект от
производителността на по-дългото наказание на разклонението зависи от общия CPI на процесора.
Процесор с нисък CPI може да си позволи да има по-скъпи разклонения, тъй като процентът от
производителността на процесора, който ще бъде загубен от разклоненията, е по-малък.
ID/EX
ДОБАВЯНЕ
IF/ID EX/MEM MEM/WB
4 Нула?
М
ДОБАВЯНЕ u
х
IR6..10
настолен компютър IR11..15
Инструкция IR
памет Регистрира ALU
MEM/WB.IR
М
u Памет М
х за данни u
х
16 32
Знак-
Фигура C.28 Блокирането от опасностите от разклонения може да бъде намалено чрез преместване на нулевия тест и изчислението на целта
на разклонението във фазата на ID на тръбопровода. Забележете, че сме направили две важни промени, всяка от които премахва 1 цикъл от
3-цикълния застой за клонове. Първата промяна е да преместите както изчислението на адреса на разклонението, така и решението за
условието на разклонението към цикъла на идентификация. Втората промяна е да се напише PC на инструкцията във фазата IF, като се
използва или целевият адрес на клона, изчислен по време на ID, или увеличеният PC, изчислен по време на IF. За сравнение, Фигура C.22
получи адреса на разклонението от регистъра EX/MEM и записа резултата по време на тактовия цикъл на MEM. Както е споменато на фигура
C.22, компютърът може да се разглежда като тръбопроводен регистър (напр. като част от ID/IF), който се записва с адреса на следващата
инструкция в края на всеки IF цикъл.
Етап на тръбата Отраслова инструкция
АКО
IF/ID.IR Mem[PC]; IF/
ID.NPC,PC (ако ((IF/ID.opcode == клон) & (Regs[IF/ID.IR6..10] op 0)) {IF/ID.NPC + разширен знак (IF /
ID.IR[непосредствено поле] << 2) else {PC + 4}); ID/EX.A Regs[IF/ID.IR6..10]; ID/EX.B Regs[IF/ID.IR11..15]; ID/EX.IR IF/
ID.IR; ID/EX.Imm (IF/ID.IR16)16##IF/ID.IR16..31
EX
MEM
WB
Фигура C.29 Тази преработена структура на тръбопровода се основава на оригинала от Фигура C.23. Той използва отделен суматор, както
е на Фигура C.28, за да изчисли адреса на целта на клона по време на ID. Операциите, които са нови или променени, са с удебелен шрифт.
Тъй като добавянето на клон-целеви адрес се случва по време на ID, това ще се случи за всички инструкции; условието за разклоняване
(Regs[IF/ID.IR6..10] op 0) също ще бъде направено за всички инструкции. Изборът на последователния компютър или целевия клон все още се
извършва по време на IF, но сега използва стойности от етапа на ИД, които съответстват на стойностите, зададени от предишната
инструкция. Тази промяна намалява наказанието за разклоняване с 2 цикъла: един от оценяване на целта и състоянието на разклонението по-
рано и един от контролиране на избора на компютър на същия часовник, а не на следващия часовник.
Тъй като стойността на cond е зададена на 0, освен ако инструкцията в ID не е взето разклонение, процесорът трябва да декодира
инструкцията преди края на ID. Тъй като разклонението се извършва до края на ID, етапите EX, MEM и WB не се използват за разклонения.
Допълнително усложнение възниква при скокове, които имат по-дълго отместване от разклоненията. Можем да разрешим това, като използваме
допълнителен суматор, който сумира PC и по-ниски 26 бита от IR след изместване наляво с 2 бита.
C.4 Какво прави тръбопровода труден за внедряване? C-43
C.4 Какво прави тръбопровода труден за внедряване?
Сега, след като разбираме как да откриваме и разрешаваме опасности, можем да се справим с тях
някои усложнения, които сме избягвали досега. Първата част на този раздел
разглежда предизвикателствата на изключителни ситуации, при които изпълнението на инструкцията
редът се променя по неочаквани начини. Във втората част на този раздел обсъждаме някои от
предизвикателствата, повдигнати от различни набори инструкции.
Справяне с изключения
Изключителните ситуации са по-трудни за справяне в конвейерен процесор, тъй като припокриването на
инструкции прави по-трудно да се разбере дали дадена инструкция може
безопасна промяна на състоянието на процесора. В конвейерния CPU се изпълнява инструкция
част по част и не е завършен за няколко тактови цикъла. За съжаление др
инструкциите в конвейера могат да предизвикат изключения, които могат да принудят процесора да прекъсне
инструкциите в тръбопровода, преди да са завършени. Преди да обсъдим тези
проблемите и техните решения в детайли, трябва да разберем какви типове ситуации могат да възникнат
и какви архитектурни изисквания съществуват за поддържането им.
Видове изключения и изисквания
Терминологията, използвана за описание на изключителни ситуации, при които нормалният ред на изпълнение
на инструкцията се променя, варира в зависимост от процесора. Условията прекъсват,
грешка и изключение се използват, макар и не по последователен начин. Ние използваме
термин изключение , за да обхване всички тези механизми, включително следното:
Заявка за I/O устройство
Извикване на услуга на операционната система от потребителска програма
Проследяване на изпълнението на инструкциите
Точка на прекъсване (прекъсване, поискано от програмиста)
Препълване на целочислена аритметика
Аномалия на FP аритметика
Грешка в страницата (не в основната памет)
Неправилно подравнени достъпи до паметта (ако се изисква подравняване)
Нарушаване на защитата на паметта
Използване на недефинирана или неизпълнена инструкция
Хардуерни неизправности
Прекъсване на захранването
Когато искаме да се позовем на определен клас такива изключения, ще използваме
по-дълго име, като I/O прекъсване, изключение с плаваща запетая или грешка на страницата.
Фигура C.30 показва разнообразието от различни имена за често срещаното изключение

събития по-горе.
Изключително събитие IBM 360 VAX Motorola 680x0 Intel 80x86
Заявка за I/O устройство Прекъсване на Прекъсване на устройството Изключение (Автовектор от L0 Векторизирано прекъсване
вход/изход до L7)
Извикване на услугата на Прекъсване на разговора Изключение (прихващане на Изключение Прекъсване
операционната система от на супервайзъра супервайзора за промяна на режима) (неприложена инструкция) (INT инструкция)
потребителска програма —
на Macintosh
Изпълнение на инструкции Не е приложимо Изключение (проследяване на грешки) Изключение (проследяване) Прекъсване (прихващане
за проследяване в една стъпка)
Точка на пречупване Не е приложимо Изключение Изключение (незаконна Прекъсване
(грешка в точката на прекъсване) инструкция или (прихващане на точка на прекъсване)
точка на прекъсване)
Целочислено аритметично Прекъсване на програмата Изключение (прихващане на Изключение Прекъсване (преливане
препълване или препълване; (изключение при целочислено препълване (грешки на копроцесора капан или математическа единица
FP капан препълване или препълване) или грешка при плаващ с плаваща запетая) изключение)
недостатъчен поток)
Грешка в Не е приложимо (само Изключение (превод Изключение (грешка с Прекъсване
страницата (не в основната памет) в 370) невалидна памет) грешки на управляващия (грешка на страницата)
блок)
Неправилно подравнена памет Прекъсване на програмата Не е приложимо Изключение Не е приложимо

достъпи (изключение от (грешка в адреса)
спецификацията)
Нарушения на защитата на Прекъсване на програмата Изключение (достъп Изключение Прекъсване

паметта (изключение за защита) повреда при нарушаване на (шинова грешка) (изключение на
управлението) защитата)
Използване на Прекъсване на програмата Изключение (неизправност при Изключение (незаконна Прекъсване (невалиден код
недефинирани инструкции (изключение от операция) привилегирован/запазен код на инструкция или точка на на операция)
операция) прекъсване/неприложена
инструкция)
Хардуерни Прекъсване на Изключение (прекъсване на Изключение Не е приложимо

неизправности машинната проверка машинна проверка) (шинова грешка)
Спиране на тока Прекъсване на Спешно прекъсване Не е приложимо Не се маскира

машинната проверка прекъсвам
Фигура C.30 Имената на обичайните изключения варират в четири различни архитектури. Всяко събитие на IBM
360 и 80x86 се нарича прекъсване, докато всяко събитие на 680x0 се нарича изключение. VAX разделя събитията на
прекъсвания или изключения. Прилагателните устройство, софтуер и спешно се използват с VAX прекъсвания, докато VAX
изключенията се подразделят на грешки, капани и прекъсвания.
Въпреки че използваме термина изключение , за да обхванем всички тези събития, индивидуални
събитията имат важни характеристики, които определят какво действие е необходимо в
хардуер. Изискванията за изключения могат да бъдат характеризирани по пет полунезависими оси:
1. Синхронно срещу асинхронно – ако събитието се случи на едно и също място
всеки път, когато програмата се изпълнява със същите данни и разпределение на паметта,
събитието е синхронно. С изключение на хардуерни неизправности, асинхронните събития се причиняват
от устройства, външни за процесора и паметта.
Асинхронните събития обикновено могат да се обработват след завършване на
текуща инструкция, което ги прави по-лесни за работа.
2. Поискано от потребителя срещу принудително – Ако задачата на потребителя го изисква директно, това е a
събитие , поискано от потребителя . В известен смисъл изключенията, поискани от потребителя, всъщност не са
изключения, тъй като те са предвидими. Те обаче се третират като изключения, тъй като същите механизми
се използват за запазване и възстановяване на състоянието
се използват за тези събития, поискани от потребителя. Тъй като единствената функция на an
инструкцията, която задейства това изключение, е да предизвика изключението, поисканите от
потребителя изключения винаги могат да бъдат обработени, след като инструкцията е завършена.
Принудените изключения са причинени от някакво хардуерно събитие, което не е така
под контрола на потребителската програма. Принудителните изключения са по-трудни
прилагат, защото не са предвидими.
3. Потребителят може да се маскира спрямо потребителя, който не може да се маскира – Ако дадено събитие може да бъде маскирано или дис-
активиран от потребителска задача, той може да се маскира от потребителя. Тази маска просто контролира дали
хардуерът отговаря на изключението или не.
4. Вътрешни срещу между инструкции – Тази класификация зависи от това дали
събитието предотвратява завършването на инструкцията, като се случва по средата на изпълнението –
без значение колко е кратко – или дали се разпознава между инструкциите. Изключенията, които възникват
в инструкциите, обикновено са синхронни,
тъй като инструкцията задейства изключението. По-трудно е да се приложат изключения, които възникват
в инструкциите, отколкото тези между инструкциите, тъй като
инструкцията трябва да бъде спряна и рестартирана. Асинхронни изключения, които
възникват в рамките на инструкции, произтичат от катастрофални ситуации (напр. хардуер
неизправност) и винаги причинява прекратяване на програмата.
5. Възобновяване срещу прекратяване— Ако изпълнението на програмата винаги спира след
прекъсване, това е завършващо събитие. Ако изпълнението на програмата продължи след това
прекъсването, то е възобновяващо се събитие. По-лесно е да се прилагат изключения, които
прекратяване на изпълнението, тъй като не е необходимо процесорът да може да рестартира изпълнението на
същата програма след обработка на изключението.
Фигура C.31 класифицира примерите от фигура C.30 според тези пет
категории. Трудната задача е прилагането на прекъсвания, възникващи в рамките на инструкции, при които
инструкцията трябва да бъде възобновена. Прилагане на такива изключения
изисква да се извика друга програма, за да се запази състоянието на изпълнението
програма, коригирайте причината за изключението и след това възстановете състоянието на програмата, преди
инструкцията, причинила изключението, да може да бъде изпробвана отново. Този процес трябва да бъде
ефективно невидим за изпълняващата програма. Ако тръбопровод осигурява
способността на процесора да се справи с изключението, да запази състоянието и да рестартира
без да се засяга изпълнението на програмата, конвейера или процесора се казва
да може да се рестартира. Докато ранните суперкомпютри и микропроцесори често липсваха
това свойство, почти всички процесори днес го поддържат, поне за целочислен конвейер, защото е необходимо
за реализиране на виртуална памет (вижте Глава 2).

Вътре срещу
Синхронен срещу Потребителска заявка Маскируем между Резюме vs.
Тип изключение асинхронен срещу принудителна потребител срещу немаскиран

инструкции прекратявам
Заявка за I/O устройство Асинхронен Принуден Не се маскира Между Продължи
Извикване на операционната система Синхронен Потребителска заявка Nonmaskable Между Продължи
Изпълнение на инструкции за проследяване Синхронно Потребителска заявка Между Продължи
Точка на пречупване Синхронен Потребителска заявка Между Продължи
Целочислено аритметично препълване Синхронен Принуден Потребител може да се маскира в рамките Продължи
Аритметика с плаваща запетая Синхронно Принуден Потребител може да се маскира в рамките Продължи
преливане или недопускане
Грешка в страницата Синхронен Принуден Не се маскира В рамките на Продължи
Неправилно подравнената памет осъществява синхронен достъп Принуден Потребител може да се маскира в рамките Продължи
Нарушения на защитата на паметта Синхронно Принуден Не се маскира В рамките на Продължи
Използване на недефинирани инструкции Синхронно Принуден Не се маскира В рамките на Прекратете
Хардуерни неизправности Асинхронен Принуден Не се маскира В рамките на Прекратете
Спиране на тока Асинхронен Принуден Не се маскира В рамките на Прекратете
Фигура C.31 Използват се пет категории, за да се определи какви действия са необходими за различните показани типове изключения
на фигура C.30. Изключенията, които трябва да позволяват възобновяване, са маркирани като възобновяване, въпреки че софтуерът може често
изберете да прекратите програмата. Синхронни, принудителни изключения, възникващи в рамките на инструкции, които могат да бъдат
възобновени са най-трудни за изпълнение. Можем да очакваме, че нарушенията на достъпа за защита на паметта ще
винаги води до прекратяване; модерните операционни системи обаче използват защита на паметта за откриване на събития като
първият опит за използване на страница или първото писане на страница. По този начин процесорите трябва да могат да се възобновят след такива изключения.
Спиране и рестартиране на изпълнението
Както при неконвейерните реализации, най-трудните изключения имат две свойства: (1) те се появяват
в рамките на инструкциите (т.е. в средата на инструкцията
изпълнение, съответстващо на EX или MEM тръбни етапи), и (2) те трябва да бъдат
рестартируем. В нашия MIPS тръбопровод, например, повреда на страница с виртуална памет,
произтичаща от извличане на данни, не може да възникне до някъде в етапа на MEM на инструкцията.
Докато тази грешка се види, няколко други инструкции ще бъдат в изпълнение. А
Page fault трябва да може да се рестартира и изисква намесата на друг процес, напр
като операционна система. По този начин тръбопроводът трябва да бъде безопасно затворен и държавата
запазени, така че инструкцията да може да се рестартира в правилното състояние. Рестартирането
обикновено се осъществява чрез запазване на компютъра на инструкцията, от която да се рестартира. Ако
рестартираната инструкция не е клон, тогава ще продължим да извличаме последователността
наследници и да започне тяхното изпълнение по обичайния начин. Ако рестартираната инструкция е клон,
тогава ще преоценим състоянието на клона и ще започнем да извличаме
или от целта, или от падането. Когато възникне изключение, тръбопроводът
контролът може да предприеме следните стъпки, за да запази безопасно състоянието на конвейера:
1. Принудително прихващане на инструкция в тръбопровода на следващия IF.
2. Докато прихващането не бъде взето, изключете всички записи за грешката инструкция и за всички
инструкции, които следват в тръбопровода; това може да стане чрез поставяне на нули в
фиксаторите на тръбопровода на всички инструкции в тръбопровода, започвайки с

инструкцията, която генерира изключението, но не и тези, които предхождат тази
инструкция. Това предотвратява всякакви промени в състоянието за инструкции, които
няма да бъдат завършени, преди да бъде обработено изключението.
3. След като процедурата за обработка на изключения в операционната система получи контрол,

тя незабавно записва на компютъра грешката инструкция. Тази стойност ще се използва за
връщане от изключението по-късно.
Когато използваме забавени разклонения, както беше споменато в последния раздел, вече
не е възможно да пресъздадем състоянието на процесора с един компютър, тъй като инструкциите
в конвейера може да не са свързани последователно. Така че трябва да запазим и възстановим
толкова компютри, колкото е дължината на забавянето на разклонението плюс едно. Това се прави
в третата стъпка по-горе.
След като изключението бъде обработено, специални инструкции връщат процесора от
изключението чрез презареждане на компютрите и рестартиране на потока от инструкции
(използвайки инструкцията RFE в MIPS). Ако тръбопроводът може да бъде спрян, така че
инструкциите точно преди грешката да бъдат изпълнени, а тези след него да могат да бъдат
рестартирани от нулата, се казва, че тръбопроводът има точни изключения. В идеалния случай
грешката инструкция не би променила състоянието, а правилното обработване на някои
изключения изисква грешката инструкция да няма ефект. За други изключения, като изключения
с плаваща запетая, грешката инструкция на някои процесори записва своя резултат, преди
изключението да може да бъде обработено. В такива случаи хардуерът трябва да бъде подготвен
да извлече операндите източник, дори ако дестинацията е идентична с един от операндите
източник.
Тъй като операциите с плаваща запетая могат да се изпълняват в продължение на много цикли,
много вероятно е някаква друга инструкция да е написала изходните операнди (както ще видим
в следващия раздел, операциите с плаваща запетая често завършват неправилно).
За да преодолеят това, много скорошни високопроизводителни процесори въведоха два режима
на работа. Единият режим има точни изключения, а другият (бърз или производителен режим)
не. Разбира се, прецизният режим на изключение е по-бавен, тъй като позволява по-малко
припокриване между инструкциите с плаваща запетая. В някои процесори с висока
производителност, включително Alpha 21064, Power2 и MIPS R8000, прецизният режим често е
много по-бавен (>10 пъти) и следователно полезен само за отстраняване на грешки в кодове.
Поддържането на точни изключения е изискване в много системи, докато в други е „просто“

ценно, защото опростява интерфейса на операционната система. Като минимум, всеки процесор
с пейджинг при поискване или манипулатори на IEEE аритметични прихващания трябва да
направи своите изключения прецизни, или в хардуера, или с някаква софтуерна поддръжка.
За целочислените конвейери задачата за създаване на точни изключения е по-лесна и
разполагането на виртуална памет силно мотивира поддръжката на точни изключения за
препратки към памет. На практика тези причини са накарали дизайнерите и архитектите
винаги да предоставят точни изключения за конвейера с цели числа. В този раздел ние
описваме как да внедрим точни изключения за целочисления конвейер на MIPS. Ще опишем
техники за справяне с по-сложните предизвикателства, възникващи в тръбопровода с плаваща
запетая в раздел C.5.
Изключения в MIPS
Фигура C.32 показва етапите на MIPS тръбопровода и кои проблеми са изключения
може да се появи на всеки етап. При конвейерната обработка могат да възникнат множество изключения в
същия тактов цикъл, защото има множество инструкции в изпълнение. Например, разгледайте тази
последователност от инструкции:
LD АКО документ за самоличност EX MEM WB
ТАТО АКО документ за самоличност EX MEM WB
Тази двойка инструкции може да причини грешка на страницата с данни и аритметично изключение
в същото време, тъй като LD е в етап MEM, докато DADD е в EX
сцена. Този случай може да бъде решен, като се работи само с грешката на страницата с данни и след това
рестартиране на изпълнението. Второто изключение ще се появи отново (но не и първото, ако
софтуерът е правилен) и когато се появи второто изключение, то може да бъде обработено
независимо.
В действителност ситуацията не е толкова ясна, колкото този прост пример.
Изключения могат да възникнат неправилно; това означава, че дадена инструкция може да предизвика изключение
преди по-ранна инструкция да го причини. Разгледайте отново горната последователност от
инструкции, LD последвано от DADD. LD може да получи грешка в страницата с данни, видяна кога
инструкцията е в MEM и DADD може да получи грешка на страницата с инструкции, видяно
когато инструкцията DADD е в IF. Грешката на страницата с инструкции действително ще възникне
първо, въпреки че е причинено от по-късна инструкция!
Тъй като ние прилагаме точни изключения, тръбопроводът трябва да
първо обработете изключението, причинено от инструкцията LD. За да обясня как това
работи, нека извикаме инструкцията в позицията на LD инструкция i, и
инструкция в позицията на инструкцията DADD i + 1. Конвейерът не може просто да обработи изключение,
когато то се появи навреме, тъй като това ще доведе до изключения
възникващи извън неконвейерния ред. Вместо това хардуерът публикува всички изключения
причинени от дадена инструкция във вектор на състоянието, свързан с тази инструкция.
Векторът на състоянието на изключение се пренася, докато инструкцията върви надолу
тръбопровод. След като индикацията за изключение е зададена във вектора на състоянието на изключение, всеки
контролният сигнал, който може да причини запис на стойност на данните, е изключен (това включва
Етап на тръбопровод Възникват изключения на проблема
АКО
Грешка на страницата при извличане на инструкции; неправилен достъп до паметта; памет
нарушение на защитата
Недефиниран или незаконен код на операцията
EX Аритметично изключение
MEM Грешка на страницата при извличане на данни; неправилен достъп до паметта;
нарушение на защитата на паметта
WB Нито един
Фигура C.32 Изключения, които могат да възникнат в MIPS тръбопровода. Изключения, повдигнати от
инструкции или данни за достъп до паметта за шест от осем случая.

както записи в регистъра, така и записи в паметта). Защото един магазин може да предизвика изключение
по време на MEM хардуерът трябва да бъде подготвен да предотврати завършването на магазина, ако
предизвика изключение.
Когато дадена инструкция влезе в WB (или е на път да напусне MEM), векторът на състоянието на
изключението се проверява. Ако има публикувани изключения, те се обработват в реда
които биха възникнали във времето на неконвейерен процесор - изключението, съответстващо на най-
ранната инструкция (и обикновено най-ранния етап на тръбата за това
инструкция) се обработва първо. Това гарантира, че всички изключения ще се видят на
инструкция i преди всички се виждат на i + 1. Разбира се, всяко действие, предприето в по-ранна тръба
етапи от името на инструкция i може да са невалидни, но тъй като записва в регистрационния файл
и паметта са деактивирани, нито едно състояние не може да бъде променено. Както ще видим в
Раздел C.5, поддържането на този точен модел за FP операции е много по-трудно.
В следващия подраздел ние описваме проблемите, които възникват при внедряването на изключения
в конвейерите на процесори с по-мощни, по-дълго изпълняващи се инструкции.
Усложнения на набора от инструкции
Никоя MIPS инструкция няма повече от един резултат и нашият MIPS конвейер записва това
резултат само в края на изпълнението на инструкцията. Когато дадена инструкция е гарантирана за
изпълнение, тя се нарича ангажирана. В целочисления тръбопровод на MIPS всички
инструкциите се предават, когато достигнат края на етапа MEM (или началото на WB) и нито една
инструкция не актуализира състоянието преди този етап. Така, прецизно
изключенията са ясни. Някои процесори имат инструкции, които се променят

състоянието в средата на изпълнението на инструкцията, преди инструкцията и нейното
предшествениците са гарантирани за завършване. Например адресиране с автоматично нарастване
режимите в архитектурата IA-32 причиняват актуализирането на регистрите в средата на an

изпълнение на инструкцията. В такъв случай, ако инструкцията бъде прекъсната поради an
по изключение ще остави състоянието на процесора променено. Въпреки че знаем кое
инструкция е причинила изключението, без допълнителна хардуерна поддръжка изключението ще бъде
неточно, защото инструкцията ще бъде наполовина завършена. Рестартиране на
потокът от инструкции след такова неточно изключение е труден. Като алтернатива, ние
може да избегне актуализирането на състоянието, преди инструкцията да се ангажира, но това може да бъде
трудно или скъпо, тъй като може да има зависимости от актуализираното състояние: Помислете
VAX инструкция, която автоматично увеличава един и същ регистър няколко пъти. По този начин, към
поддържат точен модел на изключение, повечето процесори с такива инструкции имат
способността да се отменят всички промени в състоянието, направени преди инструкцията да бъде
ангажирана. Ако възникне изключение, процесорът използва тази възможност, за да нулира състоянието на
процесор до неговата стойност преди началото на прекъснатата инструкция. В следващия раздел ще
видим, че може да се въведе по-мощен MIPS конвейер с плаваща запетая
подобни проблеми и Раздел C.7 въвежда техники, които значително усложняват обработката на изключения.
Свързан източник на трудности възниква от инструкции, които актуализират паметта
състояние по време на изпълнение, като например операциите за копиране на низове на VAX или IBM
360 (вижте Приложение К). За да бъде възможно прекъсването и рестартирането на тези инструкции,
инструкциите са дефинирани да използват регистрите с общо предназначение като работещи

регистри. По този начин състоянието на частично завършената инструкция винаги е в

регистри, които се записват при изключение и се възстановяват след изключение,
което позволява на инструкцията да продължи. Във VAX допълнителен бит държавни записи
когато дадена инструкция е започнала да актуализира състоянието на паметта, така че когато
тръбопроводът се рестартира, процесорът знае дали да рестартира инструкцията от началото или
от средата на инструкцията. Инструкциите за низове IA-32 също използват
регистрите като работно хранилище, така че запазването и възстановяването на регистрите спестява
и възстановява състоянието на такива инструкции.
Различен набор от трудности възниква от странни битове на състояние, които могат да създадат
допълнителни опасности от тръбопровода или може да изисква допълнителен хардуер за запазване и възстановяване.
Кодовете на условия са добър пример за това. Много процесори поставят условието

кодове имплицитно като част от инструкцията. Този подход има предимства, тъй като
кодовете на условие отделят оценката на условието от действителния клон.
Неявно зададените кодове на условия обаче могат да причинят трудности при планирането на всеки
закъснения на тръбопровода между задаване на кода на условието и разклонението, тъй като повечето
инструкции задават кода на условието и не могат да се използват в слотовете за забавяне между
оценката на състоянието и клона.
Освен това при процесори с кодове на условия процесорът трябва да реши

когато състоянието на клона е фиксирано. Това включва установяване кога състоянието
кодът е зададен за последен път преди клона. В повечето процесори с
имплицитно задаване на кодове на условие, това се прави чрез забавяне на оценката на условието за
разклоняване, докато всички предишни инструкции не са имали възможност да зададат кода на условието.
Разбира се, архитектурите с изрично зададени кодове на условия позволяват забавянето

между теста на състоянието и клона, който трябва да бъде планиран; обаче контрол на тръбопровода
все още трябва да проследява последната инструкция, която задава кода на условието, за да знае кога
решава се състоянието на клона. Всъщност кодът на условието трябва да се третира като
операнд, който изисква откриване на опасност за RAW опасности с разклонения, точно както
MIPS трябва да направи в регистрите.
Последната трънлива област в тръбопровода са многоцикловите операции. Представете си, че се опитвате
тръбопровод последователност от VAX инструкции като тази:
MOVL R1,R2 ;движи се между регистрите

ADDL3 42(R1),56(R1)+,@(R1) ;добавя места в паметта
SUBL2 R2,R3 ;изважда регистри
MOVC3 @(R1)[R2],74(R2),R3 ;премества символен низ
Тези инструкции се различават радикално по броя на тактовите цикли, които ще изискват,

от само един до стотици тактови цикли. Те също изискват различни
брой достъпи до паметта за данни, от нула до евентуално стотици. Опасностите при данните са много
сложни и възникват както между, така и в рамките на инструкциите. Простото решение за изпълнение
на всички инструкции за един и същ брой часовници
цикли е неприемливо, защото въвежда огромен брой опасности и
байпасни условия и прави изключително дълъг тръбопровод. Конвейер на VAX в
нивото на обучение е трудно, но VAX 8800 намери умно решение
дизайнери. Те тръбопроводят изпълнението на микроинструкцията ; микроинструкция е a
проста инструкция, използвана в последователности за изпълнение на по-сложна инструкция
комплект. Тъй като микроинструкциите са прости (приличат много на MIPS), на
C.5 Разширяване на MIPS конвейера за обработка на многоциклови операции C-51
управлението на тръбопровода е много по-лесно. От 1995 г. всички микропроцесори Intel IA-32

използват тази стратегия за преобразуване на инструкциите IA-32 в микрооперации и след
това конвейерна обработка на микрооперациите.
За сравнение, процесорите за съхранение на натоварване имат прости операции със сходни
количества работа и по-лесен конвейер. Ако архитектите осъзнаят връзката между дизайна на
набора от инструкции и конвейера, те могат да проектират архитектури за по-ефективен
конвейер. В следващия раздел ще видим как MIPS тръбопроводът се справя с дългосрочни
инструкции, по-специално с операции с плаваща запетая.
В продължение на много години се смяташе, че взаимодействието между набори от инструкции
и имплементации е малко и проблемите с изпълнението не бяха основен фокус при проектирането
на набори от инструкции. През 80-те години на миналия век стана ясно, че трудността и
неефективността на конвейера могат да бъдат увеличени чрез усложнения в набора от
инструкции. През 90-те години всички компании преминаха към по-прости набори от инструкции
с цел намаляване на сложността на агресивните реализации.
C.5 Разширяване на MIPS конвейера за обработка на

многоциклови операции
Сега искаме да проучим как нашият MIPS конвейер може да бъде разширен, за да обработва
операции с плаваща запетая. Този раздел се концентрира върху основния подход и
алтернативите на дизайна, като завършва с някои измервания на производителността на MIPS
тръбопровод с плаваща запетая.
Непрактично е да се изисква всички MIPS FP операции да завършват за 1 тактов цикъл
или дори за 2. Това би означавало приемане на бавен такт или използване на огромни количества
логика в FP единиците, или и двете. Вместо това FP тръбопроводът ще позволи по-дълго забавяне
на операциите. Това е по-лесно за разбиране, ако си представим, че FP инструкциите имат същия
конвейер като целочислените инструкции, с две важни промени. Първо, цикълът EX може да се
повтори толкова пъти, колкото е необходимо за завършване на операцията - броят на повторенията
може да варира за различните операции. Второ, може да има множество FP функционални
единици. Застой ще възникне, ако инструкцията, която ще бъде издадена, ще причини или
структурна опасност за функционалната единица, която използва, или опасност за данните.
За този раздел нека приемем, че има четири отделни функционални единици

нашата реализация на MIPS:
1. Основната целочислена единица, която обработва зареждания и съхранява, цели ALU операции,
и клонове
2. FP и целочислен умножител 3. FP
суматор, който обработва FP събиране, изваждане и преобразуване 4.
FP и целочислен делител
Ако приемем също така, че етапите на изпълнение на тези функционални единици не са

конвейерни, тогава Фигура C.33 показва получената конвейерна структура. Тъй като EX не е
конвейерен, никоя друга инструкция, използваща тази функционална единица, не може да бъде издадена до
EX
Цяло числова единица
EX
FP/цяло число
умножават се
АКО документ за самоличност MEM WB
EX
FP суматор
EX
FP/цяло число
разделител
Фигура C.33 Конвейерът MIPS с три допълнителни неконвейерни, с плаваща запетая,

функционални единици. Тъй като само една инструкция се издава на всеки такт, всички
инструкции преминават през стандартния конвейер за целочислени операции. FP операциите просто
цикъл, когато достигнат етап EX. След като завършат етапа EX, те продължават
до MEM и WB за завършване на изпълнението.
предишната инструкция оставя EX. Освен това, ако дадена инструкция не може да продължи
към етапа EX, целият тръбопровод зад тази инструкция ще бъде спрян.
В действителност междинните резултати вероятно не се въртят около единицата EX
както показва фигура C.33 ; вместо това етапът на тръбопровода EX има определен брой часовници
закъснения, по-големи от 1. Можем да обобщим структурата на конвейера FP, показан в
Фигура C.33 , за да се позволи тръбопровод на някои етапи и множество текущи операции.
За да опишем такъв тръбопровод, трябва да дефинираме както латентността на функционала
единици, както и интервала на започване или интервала на повторение. Ние определяме латентността
по същия начин, по който го дефинирахме по-рано: броят на междинните цикли между an
инструкция, която произвежда резултат и инструкция, която използва резултата. Интервалът на
започване или повторение е броят на циклите, които трябва да изминат между издаването
две операции от даден тип. Например ще използваме закъсненията и интервалите на иницииране,
показани на фигура C.34.
С тази дефиниция на латентност целочислените ALU операции имат латентност 0,
тъй като резултатите могат да се използват в следващия тактов цикъл, а зарежданията имат латентност от
1, тъй като техните резултати могат да се използват след един междинен цикъл. Тъй като повечето
операции консумират операндите си в началото на EX, забавянето обикновено е
брой етапи след EX, на които дадена инструкция дава резултат – например,
Функционална единица Латентност Интервал на започване
Цяло число ALU 0 1
Памет за данни (цяло число и FP зареждания) 1 1
FP доп 3 1
FP умножение (също и цяло число) 6 1
FP деление (също цяло число деление) 24 25
Фигура C.34 Закъснения и интервали на започване за функционални единици.
нулеви етапи за ALU операции и един етап за товари. Основното изключение е
магазини, които консумират стойността, която се съхранява 1 цикъл по-късно. Следователно, латентността към
ще има хранилище за стойността, която се съхранява, но не и за основния адресен регистър
1 цикъл по-малко. Латентността на тръбопровода е по същество равна на 1 цикъл по-малко от дълбочината на
конвейерът за изпълнение, който е броят на етапите от EX етапа до
етап, който произвежда резултата. По този начин, за примерния тръбопровод точно по-горе,
броят на етапите в FP add е четири, докато броят на етапите в FP multi-ply е седем. За да постигнат по-висока
тактова честота, дизайнерите трябва да поставят по-малко логически нива във всеки тръбен етап, което
прави броя на тръбните етапи, необходими за повече
сложни операции по-големи. Следователно наказанието за по-високата тактова честота е по-дълго
латентност за операции.
Примерната структура на тръбопровода на фигура C.34 позволява до четири неизпълнени
FP събира, седем изключителни FP/целочислени умножения и едно FP деление. Фигура C.35
показва как този тръбопровод може да бъде начертан чрез разширяване на Фигура C.33. Повторението
интервалът е реализиран на фигура C.35 чрез добавяне на допълнителни етапи на тръбопровода,
които ще бъдат разделени от допълнителни конвейерни регистри. Тъй като единиците са
независими, ние наричаме етапите по различен начин. Етапите на тръбопровода, които отнемат множество
тактови цикъла, като разделящата единица, са допълнително подразделени, за да покажат
латентност на тези етапи. Защото не са пълни етапи, а само една операция
може да е активен. Структурата на тръбопровода може също да бъде показана с помощта на познатите диаграми
от по-рано в приложението, както е показано на фигура C.36 за набор от независими
FP операции и FP зарежда и съхранява. Естествено, по-дългата латентност на FP
операции увеличава честотата на опасностите от RAW и произтичащите от това спирания, както ще направим
вижте по-късно в този раздел.
Структурата на тръбопровода на фигура C.35 изисква въвеждането на
допълнителни конвейерни регистри (напр. A1/A2, A2/A3, A3/A4) и модификацията
на връзките към тези регистри. Регистърът ID/EX трябва да бъде разширен до
свържете ID към EX, DIV, M1 и A1; можем да се позовем на частта от регистъра
свързан с един от следващите етапи с нотацията ID/EX, ID/DIV, ID/M1,
или ID/A1. Регистърът на тръбопровода между ID и всички други етапи може да бъде
мислени като логически отделни регистри и всъщност могат да бъдат реализирани като отделни регистри.
Тъй като само една операция може да бъде в етап на тръба в даден момент, the
контролната информация може да бъде свързана с регистъра в началото на етапа.

EX
FP/умножение на цяло число
M1 M2 M3 M4 M5 M6 M7
АКО документ за самоличност MEM WB

FP суматор
A1 A2 A3 A4
FP/целочислен делител
DIV
Фигура C.35 Конвейер, който поддържа множество незавършени FP операции. FP умножителят и суматорът са пълни
тръбопроводни и имат дълбочина съответно седем и четири степени. FP делителят не е конвейерен, но изисква 24
часовникови цикли за завършване. Закъснението в инструкциите между издаването на FP операция и използването на резултата от
тази операция без предизвикване на спиране на RAW се определя от броя на циклите, прекарани в етапите на изпълнение.
Например, четвъртата инструкция след FP добавяне може да използва резултата от FP добавянето. За целочислени ALU операции,
дълбочината на конвейера за изпълнение е винаги една и следващата инструкция може да използва резултатите.
МУЛ.Д АКО документ за самоличност M1 M2 M3 M4 M5 M6 M7 MEM WB
ДОБ.Д АКО документ за самоличност A1 A2 A3 A4 MEM WB
LD АКО документ за самоличност EX MEM WB
SD АКО документ за самоличност EX MEM WB
Фигура C.36 Времето на конвейера на набор от независими FP операции. Етапите в курсив показват къде са данните
необходими, докато етапите с удебелен шрифт показват къде има наличен резултат. Разширението „.D” на мнемониката с инструкции
показва операции с плаваща запетая с двойна точност (64 бита). FP зарежда и съхранява използва 64-битов път към паметта, така че
че времето за конвейер е точно като цяло число зареждане или съхраняване.
Опасности и пренасочване в тръбопроводи с по-дълга латентност
Има редица различни аспекти на откриването и препращането на опасност

за тръбопровод като този, показан на фигура C.35.
1. Тъй като разделителната единица не е напълно тръбопроводна, могат да възникнат структурни опасности.
Те ще трябва да бъдат открити и издаването на инструкции ще трябва да бъде спряно.

2. Тъй като инструкциите имат различно време на изпълнение, броят на регистъра
записи, необходими в цикъл, могат да бъдат по-големи от 1.
3. Възможни са опасности от запис след запис (WAW), тъй като инструкциите вече не са
достигнете WB в ред. Обърнете внимание, че опасностите от запис след четене (WAR) не са възможни,
тъй като четенията на регистъра винаги се случват в ID.
4. Инструкциите могат да се изпълнят в различен ред, отколкото са били издадени, причинявайки
проблеми с изключения; разглеждаме това в следващия подраздел.
5. Поради по-дългата латентност на операциите, опасностите от спиране на RAW ще бъдат повече
често срещан.
Увеличаването на сергиите, произтичащо от по-дълги латентности на операции, е фундаментално
същото като това за конвейера с цели числа. Преди да опишем новите проблеми, които
възникват в този FP тръбопровод и разглеждайки решенията, нека разгледаме потенциала
въздействието на опасности от РАО. Фигура C.37 показва типична FP кодова последователност и
получени сергии. В края на този раздел ще разгледаме ефективността на това
FP тръбопровод за нашето SPEC подмножество.
Сега вижте проблемите, произтичащи от записи, описани като (2) и (3) в
по-ранен списък. Ако приемем, че FP регистрационният файл има един порт за запис, последователности от FP
операции, както и FP натоварване заедно с FP операции, могат да причинят конфликти
за порта за запис в регистъра. Разгледайте последователността на тръбопровода, показана на фигура C.38. в
часовников цикъл 11, и трите инструкции ще достигнат WB и ще искат да запишат регистъра
файл. Само с един порт за запис на регистрационен файл, процесорът трябва да сериализира
завършване на инструкцията. Този единствен регистрационен порт представлява структурна опасност. Ние
може да увеличи броя на портовете за запис, за да разреши това, но това решение може да бъде
непривлекателно, тъй като допълнителните портове за запис ще се използват само рядко. Това е
защото максималният стабилен брой необходими портове за запис е 1. Вместо това ние
изберете да откриете и наложите достъп до порта за запис като структурна опасност.
Има два различни начина за прилагане на това блокиране. Първият е да се проследи
използването на порта за запис в етапа на идентификация и спиране на инструкция, преди да бъде издадена,
Инструкция 1234 5 6 7 8 9 10 11 12 13 14 15 16 17
LD F4,0(R2) IF ID EX MEM WB
MUL.D F0,F4,F6 IF ID Stall M1 M2 M3 M4 M5 M6 M7 MEM WB
ADD.D F2,F0,F8 IF Stall ID Stall Stall Stall Stall Stall Stall Stall A1 A2 A3 A4 MEM WB
SD F2,0(R2) IF Stall Stall Stall Stall Stall Stall ID EX EX Stall Stall Stall MEM
Фигура C.37 Типична поредица от FP кодове, показваща спиранията, произтичащи от опасности от RAW. По-дългият тръбопровод значително
повишава честотата на спиранията в сравнение с по-плитката целочислена тръбопровода. Всяка инструкция в тази последователност е
зависи от предишния и продължава веднага щом данните са налични, което предполага, че тръбопроводът има пълно
заобикаляне и пренасочване. SD трябва да бъде спрян за допълнителен цикъл, така че неговият MEM да не е в конфликт с ADD.D. Екстра
хардуерът може лесно да се справи с този случай.
Инструкция 1 2 3 4 5 6 7 8 9 10 11
MUL.D F0,F4,F6 АКО ID M1 M2 M3 M4 M5 M6 M7 MEM WB

... АКО ID EX MEM WB
ДОБАВЯНЕ F2,F4,F6 АКО документ за самоличност A1 A2 A3 A4 MEM WB
... АКО документ за самоличност EX MEM WB
LD F2,0(R2) АКО документ за самоличност EX MEM WB
Фигура C.38 Три инструкции искат да извършат обратно записване към FP регистрационния файл едновременно, както е показано в
тактов цикъл 11. Това не е най-лошият случай, тъй като по-ранно разделение в FP единицата също може да завърши на същия часовник.
Имайте предвид, че въпреки че всички MUL.D, ADD.D и LD са в етап MEM в тактов цикъл 10, само LD всъщност използва
памет, така че не съществува структурна опасност за MEM.
точно както бихме направили за всяка друга структурна опасност. Проследяване на използването на записа
порт може да се направи с регистър за смяна, който показва кога вече издадени инструкции ще
използват регистърния файл. Ако инструкцията в ID трябва да използва регистърния файл
в същото време като вече издадена инструкция, инструкцията в ID е спряна
за цикъл. На всеки часовник резервационният регистър се измества с 1 бит. Това внедряване има
предимство: поддържа свойството, че всички блокиращи откриване и
вмъкването на срив се извършва в етапа на идентификация. Цената е добавянето на регистъра за смяна
и напишете конфликтна логика. Ще приемем тази схема в този раздел.
Алтернативна схема е да спрете конфликтна инструкция, когато се опита да влезе
или етап MEM или WB. Ако изчакаме да спрем противоречивите инструкции до
искат да влязат в етап MEM или WB, ние можем да изберем да спрем някоя от инструкциите. Една
проста, макар и понякога неоптимална евристика е да се даде приоритет на
единица с най-голяма латентност, тъй като това е най-вероятно да е причинило
друга инструкция, която трябва да бъде спряна за опасност от RAW. Предимството на тази схема
е, че не изисква от нас да открием конфликта до влизането на MEM
или WB етап, където е лесно да се види. Недостатъкът е, че усложнява контрола на тръбопровода, тъй
като сега могат да възникнат задръствания от две места. Забележете, че забавянето преди
влизането в MEM ще доведе до заемане на етапа EX, A4 или M7, което вероятно ще принуди спирането
да се върне обратно в тръбопровода. По същия начин забавянето преди WB би го направило
кара MEM да архивира.
Другият ни проблем е възможността за опасност от WAW. За да видите, че те съществуват,
разгледайте примера на фигура C.38. Ако инструкцията LD беше издадена един цикъл
по-рано и имаше дестинация F2, тогава това би създало опасност от WAW, защото
той ще напише F2 един цикъл по-рано от ADD.D. Обърнете внимание, че само тази опасност
възниква, когато резултатът от ADD.D се презапише без никаква инструкция
използвайки го! Ако имаше използване на F2 между ADD.D и LD, тръбопроводът

ще трябва да бъде спрян за опасност от RAW и LD няма да се издаде до
ADD.D беше завършен. Можем да твърдим, че за нашия тръбопровод WAW представлява опасност само
възникват, когато се изпълни безполезна инструкция, но все пак трябва да ги открием и
уверете се, че резултатът от LD се появява във F2, когато сме готови. (Както ще направим
вижте в раздел C.8, такива последователности понякога се срещат в разумен код.)
Има два възможни начина за справяне с тази опасност от WAW. Първият подход
е да отложи издаването на инструкцията за зареждане, докато ADD.D влезе в MEM. Вторият подход е да се
премахне резултатът от ADD.D чрез откриване на опасността и
промяна на контролата, така че ADD.D да не записва своя резултат. Тогава ЛД може
издайте веднага. Тъй като тази опасност е рядка, и двете схеми ще работят добре - вие
може да избере всичко, което е по-лесно за изпълнение. И в двата случая опасността може да бъде
открит по време на ID, когато LD се издава, и забавяне на LD или извършване на
ADD.D a no-op е лесно. Трудната ситуация е да се открие, че LD може да завърши
преди ADD.D, защото това изисква да се знае дължината на тръбопровода и
текущата позиция на ДОП.Д. За щастие тази кодова последователност (две записи с no
intervening read) ще бъде много рядко, така че можем да използваме просто решение: Ако инструкция в ID иска
да запише същия регистър като вече издадена инструкция, не

издайте инструкцията на EX. В раздел C.7 ще видим как допълнителен хардуер
може да елиминира сергии за такива опасности. Първо, нека съберем елементите за внедряване на
логиката на опасностите и проблемите в нашия FP конвейер.
При откриването на възможните опасности трябва да вземем предвид опасностите сред FP
инструкции, както и опасности между FP инструкция и целочислена инструкция. С изключение на FP
зарежда-запаметява и премества FP-цялочислен регистър, FP и целочислените регистри са различни.
Всички инструкции за цели числа работят върху регистрите за цели числа,
докато операциите на FP работят само в собствените си регистри. По този начин имаме нужда само от
вземете под внимание FP зарежда-съхранява и премества FP регистър при откриване на опасности между FP
и целочислени инструкции. Това опростяване на контрола на тръбопровода е допълнително
предимство на наличието на отделни регистрационни файлове за цели числа и данни с плаваща запетая.
(Основните предимства са удвояване на броя на регистрите, без да се правят
или задайте по-голямо и увеличаване на честотната лента, без да добавяте повече портове към нито едно от двете
комплект. Основният недостатък, освен необходимостта от допълнителен регистрационен файл, е малкият
разходите за случайни премествания, необходими между двата регистрови комплекта.) Ако приемем, че
тръбопроводът прави всички откривания на опасности в ID, трябва да има три проверки
изпълнява се преди инструкцията да може да издаде:
1. Проверете за структурни опасности— Изчакайте, докато необходимата функционална единица не стане
заето (това е необходимо само за разделяния в този конвейер) и се уверете, че портът за запис на
регистър е наличен, когато е необходим.
2. Проверете за опасност от RAW данни— Изчакайте, докато регистрите на източника не бъдат посочени като
чакащи дестинации в регистър на тръбопровода, които няма да бъдат налични, когато това
инструкцията се нуждае от резултата. Тук трябва да се направят редица проверки в зависимост

както върху инструкцията източник, която определя кога резултатът ще бъде наличен, така и
инструкцията местоназначение, която определя кога стойността е
необходими. Например, ако инструкцията в ID е FP операция с регистър източник F2, тогава F2 не може
да бъде посочен като дестинация в ID/A1, A1/A2 или A2/A3,
които съответстват на FP добавят инструкции, които няма да бъдат завършени, когато
инструкцията в ID се нуждае от резултат. (ID/A1 е частта от изходния регистър на

ID, който се изпраща до A1.) Разделянето е малко по-сложно, ако искаме да позволим на
последните няколко цикъла на разделяне да бъдат припокрити, тъй като трябва да се справим със случая
когато разделение е близо до завършване като специално. На практика дизайнерите могат

игнорирайте тази оптимизация в полза на по-прост тест за проблем.
3. Проверете за опасност от WAW данни — Определете дали някоя инструкция в A1, . . . , А4,
D, M1, . .. , M7 има същата дестинация на регистъра като тази инструкция. Ако е така,
забавяне на издаването на инструкцията в ID.
Въпреки че откриването на опасност е по-сложно с многоцикличните FP операции, концепциите са

същите като за MIPS целочислен конвейер. Същото е вярно
за логиката на препращане. Препращането може да се осъществи чрез проверка дали
регистър на местоназначението във всеки от EX/MEM, A4/MEM, M7/MEM, D/MEM или
Регистрите MEM/WB са един от регистрите източник на инструкция с плаваща запетая. Ако
така че подходящият входен мултиплексор ще трябва да бъде активиран, за да изберете
препратени данни. В упражненията ще имате възможност да уточните логиката
за откриване на опасност от RAW и WAW, както и за препращане.
Многоцикличните FP операции също въвеждат проблеми за нашите механизми за изключение, с
които се занимаваме по-нататък.
Поддържане на точни изключения
Друг проблем, причинен от тези дългосрочни инструкции, може да бъде илюстриран

със следната последователност от кодове:
DIV.D F0, F2, F4

ADD.D F10, F10, F8
SUB.D F12, F12, F14
Тази кодова последователност изглежда ясна; няма никакви зависимости. Проблем

възниква обаче, защото инструкция, издадена по-рано, може да завърши след an
инструкция, издадена по-късно. В този пример можем да очакваме ADD.D и SUB.D да завършат преди
DIV.D да завърши. Това се нарича завършване извън поръчка и е
често срещани в тръбопроводи с продължителни операции (вижте раздел C.7). защото
откриването на опасност ще предотврати всякаква зависимост между инструкциите
нарушено, защо завършването извън ред е проблем? Да предположим, че SUB.D
предизвиква аритметично изключение с плаваща запетая в момент, в който ADD.D е завършил, но
DIV.D не е. Резултатът ще бъде неточно изключение, нещо, което се опитваме да избегнем. Може да
изглежда, че това може да се реши чрез отдаване под наем
източването на тръбопровода с плаваща запетая, както правим за тръбопровода с цели числа. Но
изключението може да е в положение, в което това не е възможно. Например, ако DIV.D
решихме да направим изключение за аритметика с плаваща запетая след приключване на добавянето, ние
не може да има точно изключение на хардуерно ниво. Всъщност, тъй като

ADD.D унищожава един от своите операнди, не можахме да възстановим състоянието до каквото беше
преди DIV.D, дори със софтуерна помощ.
Този проблем възниква, защото инструкциите се изпълняват в различен ред
отколкото са били издадени. Има четири възможни подхода за справяне с неправилно завършване.
Първият е да игнорирате проблема и да се примирите с неточността
изключения. Този подход е използван през 60-те и началото на 70-те години. Все още се използва
в някои суперкомпютри, където определени класове изключения не са разрешени или
се обработват от хардуера без спиране на конвейера. Трудно е да се използва
този подход в повечето процесори, създадени днес, поради функции като виртуални
памет и стандарта IEEE с плаваща запетая, които по същество изискват прецизни
изключения чрез комбинация от хардуер и софтуер. Както споменахме по-рано, някои скорошни процесори
са решили този проблем чрез въвеждане на два режима
на изпълнение: бърз, но вероятно неточен режим и по-бавен, прецизен режим. The
по-бавният прецизен режим се реализира или с превключвател на режима, или чрез вмъкване на
изрични инструкции, които тестват за FP изключения. И в двата случая количеството на
припокриването и пренареждането, разрешено в тръбопровода на FP, е значително ограничено, така че
че ефективно само една FP инструкция е активна в даден момент. Този разтвор се използва в
DEC Alpha 21064 и 21164, в IBM Power1 и Power2, и в

MIPS R8000.
Вторият подход е да се буферират резултатите от дадена операция, докато не завършат всички
операции, които са били издадени по-рано. Някои процесори всъщност използват това решение,
но става скъпо, когато има разлика във времената на работа между операциите
е голям, тъй като броят на резултатите за буфериране може да стане голям. Освен това,
резултатите от опашката трябва да бъдат заобиколени, за да продължат да издават инструкции, докато
в очакване на по-дългата инструкция. Това изисква голям брой компаратори
и много голям мултиплексор.
Има две жизнеспособни вариации на този основен подход. Първият е история
файл, използван в CYBER 180/990. Файлът с хронологията следи оригиналните стойности на регистрите.
Когато възникне изключение и състоянието трябва да бъде върнато по-рано от някоя инструкция, която е
завършена не по ред, първоначалната стойност на
регистърът може да бъде възстановен от файла с историята. Подобна техника се използва за адресиране
с автоматично нарастване и автоматично намаляване на процесори като VAX. Друг
подход, бъдещият файл, предложен от Smith и Pleszkun [1988], запазва
по-нова стойност на регистър; когато всички предишни инструкции са изпълнени, основният
регистрационният файл се актуализира от бъдещия файл. По изключение главният регистрационен файл
има точните стойности за прекъснато състояние. В Глава 3 видяхме разширения
на тази идея, които се използват в процесори като PowerPC 620 и MIPS
R10000, за да позволи припокриване и пренареждане, като същевременно запазва точни изключения.
Трета използвана техника е да се позволи на изключенията да станат донякъде
неточно, но да запази достатъчно информация, така че рутинните процедури за обработка на прихващания да могат
създайте точна последователност за изключението. Това означава да знаете какви операции
бяха в процес на подготовка и техните компютри. След това, след обработка на изключението, софтуерът
завършва всички инструкции, които предхождат последната завършена инструкция, и
последователността може да се рестартира. Помислете за следната кодова последователност в най-лошия случай:
Инструкция1— Дълго изпълняваща се инструкция, която в крайна сметка прекъсва изпълнението.
Инструкция 2 ,. . . , Инструкцияn–1— Поредица от инструкции, които не са
завършен.
Инструкцияn— Инструкция, която е завършена.

Като се имат предвид компютрите на всички инструкции в конвейера и компютърът за връщане на изключение,
софтуерът може да намери състоянието на инструкция1 и инструкцияn. Тъй като instructionn е

завършена, ще искаме да рестартираме изпълнението при instructionn+1. След
обработвайки изключението, софтуерът трябва да симулира изпълнението на инструкция1,
. . . , инструкцияn–1. След това можем да се върнем от изключението и да рестартираме при
инструкция n +1. Сложността на правилното изпълнение на тези инструкции от манипулатора е
основната трудност на тази схема.
Има важно опростяване за прости MIPS-подобни тръбопроводи: Ако
инструкция 2 ,. . . , инструкцияn са всички инструкции с цяло число, ние знаем, че ако
instructionn е завършил цялата инструкция2, . . , инструкцияn–1 имат .
също завършен. Следователно трябва да се обработват само FP операции. За да направите това
схема проследима, броят на инструкциите с плаваща запетая, които могат да бъдат припокрити
при изпълнение, може да бъде ограничен. Например, ако припокриваме само две
инструкции, тогава само прекъсващата инструкция трябва да бъде завършена от софтуера. Това
ограничение може да намали потенциалната производителност, ако FP тръбопроводите
са дълбоки или ако има значителен брой функционални единици на FP. Това
подходът се използва в архитектурата на SPARC, за да позволи припокриване на плаваща запетая
и целочислени операции.
Последната техника е хибридна схема, която позволява издаването на инструкции
продължете само ако е сигурно, че всички инструкции преди инструкцията за издаване
ще завърши, без да причини изключение. Това гарантира, че когато възникне изключение,
никакви инструкции след прекъсващата няма да бъдат изпълнени и всички
инструкциите преди прекъсващата може да бъде завършена. Това понякога
означава спиране на процесора за поддържане на точни изключения. За да направите тази схема
работят, функционалните единици с плаваща запетая трябва да определят дали е възможно
изключение рано в етапа на EX (в първите 3 тактови цикъла в MIPS конвейера), така че
предотвратяване на изпълнението на допълнителни инструкции. Тази схема се използва в MIPS
R2000/3000, R4000 и Intel Pentium. Обсъжда се по-нататък в
Приложение Й.
Производителност на MIPS FP конвейер
Тръбопроводът MIPS FP на Фигура C.35 на страница C-54 може да генерира и двете структурни
спира за разделящия модул и спира за опасности от RAW (може да има и опасности от WAW, но това
рядко се случва на практика). Фигура C.39 показва броя на кабините
цикли за всеки тип операция с плаваща запетая на базата на всеки екземпляр (т.е
първата лента за всеки FP бенчмарк показва броя на спиранията на резултатите от FP за всеки FP
добавяне, изваждане или преобразуване). Както можем да очакваме, циклите на спиране за всяка работна писта
латентността на FP операциите, варираща от 46% до 59% от латентността на

функционална единица.
Фигура C.40 дава пълната разбивка на целите числа и FP сергиите за пет

SPECfp бенчмаркове. Показани са четири класа щандове: FP резултати, FP
сравнете сергии, закъснения при натоварване и разклоняване и структурни закъснения на FP. Компилаторът се опитва
да планира закъсненията както при натоварване, така и при FP, преди да планира забавяния на разклонения. Общата сума
броят на спиранията на инструкция варира от 0,65 до 1,21.

C.6 Събираме всичко заедно: Конвейерът MIPS R4000 C-61
Добавяне/изваждане/конвертиране
1.7
1.7 Сравнява
додук 3.7
Умножете
15.4
Разделям
2.0
Разделете структурно
1.6
2.0
ухо 2.5
12.4
0,0
2.3
2.5
хидро2д 3.2
чE
евокрамC Pб
не S
F
0,4
0,0
2.1
mdljdp 1.2
2.9
24.5
0,0
0,7
1,5
su2cor 1,6
18.6
0,6
0,0 5.0 10.0 15.0 20.0 25,0
Брой щандове
Фигура C.39 Застой на FP операция за всеки основен тип FP операция за SPEC89 FP

бенчмаркове. С изключение на разделителните структурни опасности, тези данни не
зависят от честотата на дадена операция, а само от нейната латентност и броя на циклите
преди използването на резултата. Броят спирания от RAW опасности грубо проследява
латентността на FP модула. Например средният брой спирания на добавяне, изваждане или
преобразуване на FP е 1,7 цикъла или 56% от латентността (3 цикъла). По същия начин
средният брой спирания за умножения и разделяния е съответно 2,8 и 14,2, или 46% и 59%
от съответната латентност. Структурните опасности за разделянето са редки, тъй като
честотата на разделяне е ниска.
C.6 Събираме всичко заедно: Конвейерът MIPS R4000
В този раздел разглеждаме структурата на конвейера и производителността на

фамилията процесори MIPS R4000, която включва 4400. R4000 прилага MIPS64, но използва
по-дълбок конвейер от този на нашия петстепенен дизайн както за целочислени, така и за
FP програми. Този по-дълбок тръбопровод му позволява да постигне по-високи тактови
честоти чрез разлагане на петстепенния конвейер с цели числа на осем етапа. Тъй като
достъпът до кеша е особено критичен във времето, допълнителните етапи на тръбопровода
идват от разлагането на достъпа до паметта. Този тип по-дълбока конвейеризация понякога
се нарича суперконвейеризация.
0,98
0,07
додук
0,08
0,08 FP резултатът спира
FP сравнете сергии
0,52
Клон/товарни щандове
0,09
ухо FP структурен
0,07
0,00
0,54
0,22
хидро2д 0,04
0,00
чE
евокрамC Pб
не S
F
0,88
mdljdp 0,10
0,03
0,00
0,61
0,02
su2cor
0,01
0,01
0,00 0,10 0,20 0,30 0,50 0,40 0,60 0,70 0,80 0,90 1,00
Брой щандове
Фигура C.40 Сривове, възникващи за MIPS FP тръбопровода за пет от SPEC89 FP бенчмаркове.

Общият брой спирания на инструкция варира от 0,65 за su2cor до 1,21 за doduc, със средно 0,87.
Сривовете в резултат на FP доминират във всички случаи, със средно 0,71 спирания на
инструкция, или 82% от циклите с блокиране. Сравненията генерират средно 0,1 спирания на
инструкция и са вторият по големина източник. Разделителната структурна опасност е значима
само за doduc.
АКО Е RF EX DF ДС TC WB
ULA
Памет за инструкции Рег Памет за данни Рег
Фигура C.41 Осемстепенната конвейерна структура на R4000 използва конвейерни инструкции и кешове за данни. Тръбните
стъпала са обозначени и тяхната подробна функция е описана в текста. Вертикалните пунктирани линии представляват
границите на етапа, както и местоположението на ключалките на тръбопровода. Инструкцията всъщност е налична в края на IS, но
проверката на етикета се извършва в RF, докато регистрите се извличат. По този начин показваме паметта на инструкциите
като работеща чрез RF. Етапът TC е необходим за достъп до паметта на данните, тъй като не можем да запишем данните в регистъра,
докато не разберем дали достъпът до кеша е бил хит или не.
Фигура C.41 показва осемстепенната конвейерна структура, използваща

абстрахирана версия на пътя на данните. Фигура C.42 показва припокриването на
последователни инструкции в конвейера. Забележете, че въпреки паметта за инструкции и данни
CC 1 CC 2 CC 3 CC 4 CC 5 CC 6 CC 7 CC 8 CC 9 CC 10 CC 11
LD R1 Памет за инструкции Рег Памет за данни Рег
ULA
Инструкция 1 Памет за инструкции Рег Памет за данни Рег
ULA
ULA
ДОБАВИ R2, R1 Памет за инструкции Рег Памет за данни Рег
ULA
Фигура C.42 Структурата на целочисления тръбопровод R4000 води до забавяне на натоварването от 2 цикъла. Възможно е забавяне от 2 цикъла
тъй като стойността на данните е налична в края на DS и може да бъде заобиколена. Ако проверката на етикета в TC показва пропуск,
тръбопроводът се архивира за цикъл, когато са налични правилните данни.
заемат множество цикъла, те са напълно конвейерни, така че нова инструкция може
стартирайте на всеки часовник. Всъщност тръбопроводът използва данните преди удара на кеша
откриването е завършено; Глава 2 обсъжда как това може да се направи по-подробно.
Функцията на всеки етап е следната:
IF— Първата половина на извличане на инструкции; Изборът на компютър всъщност се случва тук,
заедно с иницииране на достъп до кеша на инструкциите.
IS— Втората половина на извличане на инструкции, пълен достъп до кеша на инструкциите.
RF— декодиране на инструкции и извличане на регистри, проверка на опасност и инструкции

откриване на удари в кеша.
EX— Изпълнение, което включва изчисление на ефективен адрес, операция на ALU и изчисление на целта на
клона и оценка на състоянието.
DF— Извличане на данни, първата половина на достъпа до кеша на данни.
DS— Втората половина на извличането на данни, завършване на достъпа до кеша на данни.
TC— Проверка на етикета, за да се определи дали достъпът до кеша на данни е достигнат.
WB— Обратно записване за зареждания и операции регистър-регистр.
В допълнение към значителното увеличаване на необходимото количество препращане, това
тръбопроводът с по-голяма латентност увеличава както натоварването, така и забавянето на разклонението. Фигура C.42
показва, че закъсненията при зареждане са 2 цикъла, тъй като стойността на данните е налична в края на
LD R1,... АКО Е RF EX DF ДС TC WB
DADD R2,R1,... АКО Е RF Сергия Stall EX DF ДС
DSUB R3,R1,... АКО Е Сергия Сергия RF EX DF
ИЛИ R4,R1,... АКО Сергия Сергия Е RF EX
Фигура C.43 Инструкция за зареждане, последвана от незабавно използване, води до спиране на 2 цикъла. Нормални препращащи пътища
може да се използва след 2 цикъла, така че DADD и DSUB получават стойността чрез препращане след спирането. Инструкцията OR получава
стойността от регистърния файл. Тъй като двете инструкции след натоварването могат да бъдат независими и следователно да не блокират,
байпасът може да бъде към инструкции, които са 3 или 4 цикъла след натоварването.
CC 1 CC 2 CC 3 CC 4 CC 5 CC 6 CC 7 CC 8 CC 9 CC 10 CC 11
BEQZ Памет за инструкции Рег Памет за данни Рег

ULA

ULA

ULA

ULA
Мишена Памет за инструкции Рег Памет за данни

ULA
Фигура C.44 Основното забавяне на разклонението е 3 цикъла, тъй като оценката на състоянието се извършва по време на EX.
ДС. Фигура C.43 показва съкратения график на тръбопровода при незабавно използване
следва натоварване. Показва, че се изисква препращане за резултата от натоварването
инструкция до дестинация, която е 3 или 4 цикъла по-късно.
Фигура C.44 показва, че основното забавяне на разклонението е 3 цикъла, тъй като разклонението
условие се изчислява по време на EX. Архитектурата на MIPS има един цикъл
забавен клон. R4000 използва прогнозирана-неприета стратегия за оставащите 2 цикъла от забавянето
на разклонението. Както показва фигура C.45 , невзетите клонове са
просто клонове със закъснение от 1 цикъл, докато взетите клонове имат забавяне от 1 цикъл
слот, последван от 2 цикъла на празен ход. Наборът от инструкции осигурява разклоняване
инструкция, която описахме по-рано и която помага при попълването на клона
Отраслова инструкция АКО Е RF EX DF ДС TC WB
Слот за забавяне АКО Е RF EX DF ДС TC WB
Сергия Сергия Сергия Сергия Сергия Сергия Сергия Стал

л
Сергия Сергия Сергия Сергия Сергия Сергия Стал

л
Разклонителна цел АКО Е RF EX DF
Отраслова инструкция АКО Е RF EX DF ДС TC WB
Слот за забавяне АКО Е RF EX DF ДС TC WB
Инструкция за клон + 2 АКО Е RF EX DF ДС TC
Инструкция за клон + 3 АКО Е RF EX DF ДС
Фигура C.45 Взет клон, показан в горната част на фигурата, има слот за забавяне от 1 цикъл, последван от 2 цикъла
спиране, докато невзето разклонение, показано в долната част, има просто слот за забавяне от 1 цикъл. Инструкцията за разклоняване
може да бъде обикновено забавено разклоняване или вероятно разклоняване, което отменя ефекта на инструкцията в слота за забавяне
ако клонът не е взет.
слот за забавяне. Блокировките на тръбопроводите налагат както наказанието за спиране на 2-цикълния клон на a
взето разклонение и всякаква опасност от застой на данни, която възниква от използването на резултат от зареждане.
В допълнение към увеличаването на сергиите за товари и разклонения, по-дълбокият тръбопровод

увеличава броя на нивата на препращане за ALU операции. В нашия MIPS
петстепенен тръбопровод, препращане между две инструкции регистър-регистър ALU
може да се случи от регистрите ALU/MEM или MEM/WB. В R4000
тръбопровод, има четири възможни източника за ALU байпас: EX/DF, DF/DS, DS/
TC и TC/WB.
Тръбопроводът с плаваща запетая
Модулът R4000 с плаваща запетая се състои от три функционални блока: плаваща запетая
делител, умножител с плаваща запетая и суматор с плаваща запетая. Логиката на суматора е
използва се на последната стъпка на умножение или деление. FP операциите с двойна точност могат
вземете от 2 цикъла (за отрицание) до 112 цикъла (за квадратен корен). В допълнение,
различните единици имат различни скорости на започване. Функционалната единица FP може да бъде
смята се, че има осем различни етапа, изброени на фигура C.46; тези етапи са
комбинирани в различни поръчки за изпълнение на различни FP операции.
Има едно копие на всеки от тези етапи, както и различни инструкции
използвайте етап нула или повече пъти и в различен ред. Фигура C.47 показва
сцена Функционална единица Описание
А FP суматор Mantissa ADD етап

д FP делител Разделете етапа на тръбопровода
д FP множител Изключителен тестов етап
М FP множител Първи етап на мултипликатора
н FP множител Втори етап на мултипликатора
Р FP суматор Етап на закръгляване
С FP суматор Етап на изместване на операнд
U Разопаковайте номерата на FP
Фигура C.46 Осемте етапа, използвани в тръбопроводите с плаваща запетая R4000.
FP инструкция Латентност Интервал на започване Тръбни етапи
Добавяне, изваждане 4 3 U, S + A, A + R, R + S
Умножете 8 4 U, E + M, M, M, M, N, N + A, R
Разделям 36 35 U, A, R, D28, D + A, D + R, D + A, D + R, A, R
Корен квадратен 112 111 U, E, (A+R)108, A, R
Отхвърляне 2 1 НАС
Абсолютна стойност 2 1 НАС
FP сравнение 3 2 U, A, R
Фигура C.47 Закъсненията и интервалите на започване за FP операциите зависят от етапите на FP единицата, които
дадената операция трябва да използва. Стойностите на латентността предполагат, че инструкцията местоназначение е FP операция;
закъсненията са с 1 цикъл по-малко, когато дестинацията е магазин. Етапите на тръбата са показани в реда, в който са използвани
всяка операция. Нотацията S + A показва тактов цикъл, в който се използват както етапите S, така и A. Нотацията D28
показва, че етапът D е използван 28 пъти подред.
латентност, скорост на иницииране и етапи на конвейер, използвани от най-често срещаните FP операции
с двойна точност.
От информацията на фигура C.47 можем да определим дали последователност
различни, независими FP операции могат да излязат без забавяне. Ако времето на
последователността е такава, че възниква конфликт за споделен етап на тръбопровода, след това спиране
ще са необходими. Фигури C.48, C.49, C.50 и C.51 показват четири общи възможни
поредици от две инструкции: умножение, последвано от добавяне, добавяне, последвано от a
умножение, деление, последвано от събиране, и събиране, последвано от деление. Фигурите показват
всички интересни начални позиции за втората инструкция и
дали тази втора инструкция ще бъде издадена или ще спре за всяка позиция. Разбира се,
може да има три активни инструкции, в който случай възможностите за сергии
са много по-високи и фигурите са по-сложни.

C.6 Обединяване на всичко: Конвейерът MIPS R4000 C-67
Операция Проблем/застой 0 1 2 3 4 5 6 7 8 9 10 11 12
Умножете проблем UE + MMMMN N + AR

Добавете Проблем US + AA + RR + S
Проблем US + AA + RR + S
Сергия US + A A + RR + S
Сергия U S + AA + R R + S
Проблем U S + AA + RR + S
Проблем U S + AA + RR + S
Фигура C.48 FP умножение, издадено на часовник 0, е последвано от единично FP добавяне, издадено между часовници 1 и 7 .
втората колона показва дали инструкция от посочения тип спира, когато е издадена n цикъла по-късно, където n е
номерът на тактовия цикъл, в който се появява етапът U на втората инструкция. Етапът или етапите, които причиняват спиране
са в удебелен шрифт. Имайте предвид, че тази таблица се занимава само с взаимодействието между умножението и едно добавяне, издадено между
часовници 1 и 7. В този случай добавянето ще спре, ако бъде издадено 4 или 5 цикъла след умножението; в противен случай издава без
забавяне. Забележете, че добавянето ще бъде спряно за 2 цикъла, ако издаде в цикъл 4, тъй като при следващия тактов цикъл все още ще
бъде в конфликт с умножението; ако обаче добавите проблеми в цикъл 5, той ще спре само за 1 тактов цикъл, тъй като това ще елиминира
конфликтите.
Операция Издаване/застой 01 2 3 4 5 6 7 8 9 10 11 12
Умножете Проблем UE + MMMMNN + AR

Проблем ЪММММН N + AR
Фигура C.49 Издаване на умножение след добавяне винаги може да продължи без спиране, тъй като по-кратката инструкция
изчиства споделените етапи на конвейера, преди по-дългата инструкция да ги достигне.
Производителност на тръбопровода R4000
В този раздел ние разглеждаме сергиите, които се случват за тестовете SPEC92
когато работи върху структурата на тръбопровода R4000. Има четири основни причини за
спирания или загуби на тръбопровода:
1. Зареждането спира – Закъснения, произтичащи от използването на резултат от натоварване 1 или 2 цикъла след
натоварването
2. Закъснения на клонове — Закъснения с два цикъла на всяко взето клонене плюс незапълнени или отменени слотове
за забавяне на клонове
3. FP резултат спира – спира поради опасност от RAW за FP операнд

Операция Проблем/срив 25 26 27 28 29 30 31 32 33 34 35 36
Разделям Издадена през DDD DD D + AD + RD + AD + RAR

цикъл 0. . .
Сергия US + A A + RR + S
Сергия U S + A A + RR + S
Сергия U S + A A + RR + S
Проблем US + AA + R
Проблем САЩ + А
Проблем U
Фигура C.50 Разделяне на FP може да доведе до забавяне на добавяне, което започва близо до края на разделянето. Разделението започва от
цикъл 0 и завършва в цикъл 35; показани са последните 10 цикъла на разделението. Тъй като разделението силно използва
хардуер за закръгляване, необходим за добавянето, той спира добавяне, което започва в някой от циклите 28 до 33. Забележете, че
стартирането на добавяне в цикъл 28 ще бъде спряно до цикъл 36. Ако добавянето започне веднага след разделянето, няма конфликт, тъй като доп
може да завърши преди разделянето да се нуждае от споделените етапи, точно както видяхме на фигура C.49 за умножение и събиране. Като
в по-ранната фигура този пример предполага точно едно добавяне, което достига U етап между тактовите цикли 26 и 35.
Операция Издаване/застой 0 1 2 3 4 5 6 7 8 9 10 11 12
Добавете Проблем US + A A + RR + S
Разделям Сергия U AR DDDDDDD D д
Проблем UA RDDDDDD D д
Проблем U ARDDDDD D д
Фигура C.51 Добавяне с двойна точност е последвано от разделяне с двойна точност. Ако разделянето започне 1 цикъл след
add, разделянето спира, но след това няма конфликт.
4. FP структурни сергии - Закъснения поради ограничения на проблема, произтичащи от кон-

фликти за функционални единици в конвейера на FP
Фигура C.52 показва разбивката на CPI на тръбопровода за тръбопровода R4000 за 10

SPEC92 бенчмаркове. Фигура C.53 показва същите данни, но в таблична форма.
От данните на фигури C.52 и C.53 можем да видим наказанието на по-дълбокото
тръбопроводи. Тръбопроводът на R4000 има много по-дълги закъснения на разклоненията от класическия
3.00
2.50
2.00
1.50
Pат
доворпобъIр Cн
1,00 База
Заредете сергии
Клонови сергии
0,50
FP резултатът спира
FP структурни сергии
0,00 ли
gcc ухо
додук mdljdp su2cor
хидро2д
компресирамeqntott еспресо
SPEC92 бенчмарк
Фигура C.52 CPI на тръбопровода за 10 от референтните показатели SPEC92, като се приема перфектен
кеш памет. CPI на тръбопровода варира от 1,2 до 2,8. Най-левите пет програми са цели числа
програми и забавянията на клоновете са основният фактор за CPI за тях. Най-десните пет
програмите са FP, а сергиите с FP резултати са основният фактор за тях. Фигура C.53
показва числата, използвани за построяване на този график.
Бенчмарк CPI на тръбопровод Заредете сергии Клонови сергии FP резултатни сергии FP структурни сергии
Компресирайте 1.20 0,14 0,06 0,00 0,00
Eqntott 1,88 0,27 0,61 0,00 0,00
Еспресо 1.42 0,07 0,35 0,00 0,00
Gcc 1.56 0,13 0,43 0,00 0,00
Ли 1.64 0,18 0,46 0,00 0,00
Средно цяло число 1.54 0,16 0,38 0,00 0,00
Doduc 2.84 0,01 0,22 1.39 0,22
Mdljdp2 2.66 0,01 0,31 1.20 0,15
Ухо 2.17 0,00 0,46 0,59 0,12
Hydro2d 2.53 0,00 0,62 0,75 0,17
Su2cor 2.18 0,02 0,07 0,84 0,26
FP средно 2.48 0,01 0,33 0,95 0,18
Общо средно 2.00 0,10 0,36 0,46 0,09
Фигура C.53 Показани са общият CPI на тръбопровода и приносът на четирите основни източника на забавяне. Основният
сътрудниците са FP резултатни сергии (както за клонове, така и за FP входове) и клонови сергии, с натоварвания и FP структурни
сергии добавяне на по-малко.
петстепенен тръбопровод. По-дългото забавяне на разклонението значително увеличава циклите

изразходвани за разклонения, особено за целочислени програми с по-висока честота на разклонения.
Интересен ефект за FP програмите е, че латентността на FP
функционални единици води до повече забавяния на резултатите, отколкото структурните опасности, които възникват
както от ограниченията на началния интервал, така и от конфликти за функционални единици
от различни FP инструкции. По този начин се намалява латентността на FP операциите

трябва да бъде първата цел, а не повече тръбопроводи или репликация на функционалните единици.
Разбира се, намаляването на латентността вероятно ще увеличи структурните спирания, тъй като
много потенциални структурни спирания са скрити зад опасности за данни.
C.7 Междусекторни въпроси
Набори от RISC инструкции и ефективност на конвейерната обработка
Вече обсъдихме предимствата на простотата на набора от инструкции при изграждането

тръбопроводи. Простите комплекти инструкции предлагат друго предимство: Те улесняват
код на график за постигане на ефективност на изпълнение в конвейер. За да видите това, помислете
прост пример: Да предположим, че трябва да добавим две стойности в паметта и да съхраним
резултат обратно в паметта. В някои сложни набори от инструкции това ще отнеме само a
единична инструкция; в други ще отнеме две или три. Типична RISC архитектура
ще изисква четири инструкции (две зареждания, добавяне и съхраняване). Тези инструкции
не могат да бъдат планирани последователно в повечето тръбопроводи без намеса в застой.
С набор от RISC инструкции отделните операции са отделни инструкции и могат да бъдат
индивидуално планирани или от компилатора (като се използват техниките, които обсъдихме по-
рано, и по-мощни техники, обсъдени в гл.
3) или използване на техники за динамично хардуерно планиране (които обсъждаме по-нататък и
по-подробно в глава 3). Тези предимства на ефективността, съчетани с
по-голяма лекота на изпълнение, изглеждат толкова значими, че почти всички скорошни
конвейерните реализации на сложни набори от инструкции всъщност превеждат техните
сложни инструкции в прости операции, подобни на RISC, и след това планирайте и
тръбопроводи на тези операции. Глава 3 показва, че както Pentium III, така и Pentium
4 използвайте този подход.
Динамично планирани тръбопроводи
Простите конвейери извличат инструкция и я издават, освен ако няма зависимост от данни между
инструкция, която вече е в конвейера, и извлечената инструкция
които не могат да бъдат скрити чрез заобикаляне или препращане. Логиката на препращане намалява
ефективната латентност на тръбопровода, така че определени зависимости да не водят до опасности.
Ако има неизбежна опасност, тогава хардуерът за откриване на опасност спира
тръбопровода (започвайки с инструкцията, която използва резултата). Не се извличат или издават

нови инструкции, докато зависимостта не бъде изчистена. За да се преодолеят тези
C.7 Междусекторни въпроси C-71
загуба на производителност, компилаторът може да се опита да планира инструкции, които да избегне
опасността; този подход се нарича компилатор или статично планиране.
Няколко ранни процесора използваха друг подход, наречен динамично планиране,
при което хардуерът пренарежда изпълнението на инструкциите, за да намали спиранията.
Този раздел предлага по-просто въведение в динамичното планиране чрез обяснение
техниката на таблото на CDC 6600. Някои читатели ще открият, че е по-лесно
прочетете този материал, преди да се потопите в по-сложната схема на Tomasulo,
който е разгледан в глава 3.
Всички техники, обсъдени в това приложение досега, използват инструкции в ред
проблем, което означава, че ако дадена инструкция е спряна в конвейера, по-късните инструкции не могат
да продължат. С проблем в реда, ако има опасност между две инструкции
тях, конвейерът ще спре, дори ако има по-късни инструкции, които са независими и няма да блокират.
В MIPS тръбопровода, разработен по-рано, имаше както структурни опасности, така и опасности за данни
проверено по време на декодиране на инструкция (ID): Когато дадена инструкция може да се изпълни
правилно, тя е издадена от ID. За да позволите на дадена инструкция да започне изпълнение веднага щом
неговите операнди са налични, дори ако предшественикът е в застой, трябва да отделим
процесът на издаване на две части: проверка на структурните опасности и изчакване на

липса на опасност от данни. Декодираме и издаваме инструкции по ред; обаче ние
искат инструкциите да започнат да се изпълняват веднага щом техните операнди с данни станат налични.
По този начин тръбопроводът ще извърши извънредно изпълнение, което предполага извънредно завършване.
За да реализираме изпълнение извън реда, трябва да разделим ID
тръбен етап на два етапа:
1. Проблем— Декодирайте инструкциите, проверете за структурни опасности.
2. Четене на операнди— Изчакайте , докато няма опасност от данни, след което прочетете операндите.
Етапът IF продължава етапа на издаване, а етапът EX следва етапа на четене на опери и етапа, точно
както в конвейера на MIPS. Както в MIPS тръбопровода с плаваща запетая,
изпълнението може да отнеме няколко цикъла в зависимост от операцията. Така можем
трябва да се прави разлика кога дадена инструкция започва да се изпълнява и кога завършва
екзекуция; между двете времена инструкцията е в изпълнение. Това позволява
множество инструкции, които да се изпълняват едновременно. В допълнение към тези
промени в структурата на тръбопровода, ние също ще променим дизайна на функционалната единица
чрез промяна на броя на единиците, латентността на операциите и функционалната единица
тръбопроводи, така че да изследваме по-добре тези по-напреднали тръбопроводни техники.
Динамично планиране с табло

В динамично планиран конвейер всички инструкции преминават през етапа на издаване
в ред (в ред издание); те обаче могат да бъдат блокирани или да се заобикалят взаимно в
втори етап (четене на операнди) и по този начин влиза в изпълнение извън ред. Scoreboard-ing е техника
за позволяване на инструкциите да се изпълняват без ред, когато има такива
достатъчно ресурси и липса на зависимости от данни; той е кръстен на CDC 6600
табло с показатели, което разработи тази възможност.

Преди да видим как таблото може да се използва в MIPS тръбопровода, това е така
важно е да се отбележи, че опасностите от ВОЙНА, които не съществуват в конвейерите с плаваща
запетая или цели числа на MIPS, могат да възникнат, когато инструкциите се изпълняват неправилно. За
например, разгледайте следната кодова последователност:
DIV.D F0, F2, F4

ADD.D F10, F0, F8
SUB.D F8, F8, F14
Има антизависимост между ADD.D и SUB.D: Ако тръбопроводът изпълни SUB.D преди ADD.D, той ще
наруши антизависимостта, давайки
неправилно изпълнение. По същия начин, за да се избегне нарушаване на изходните зависимости,
опасностите от WAW (напр., както би се случило, ако дестинацията на SUB.D беше F10) също трябва да бъдат
открити. Както ще видим, и двете тези опасности се избягват в таблото чрез забавяне на по-късната
инструкция, включена в антизависимостта.
Целта на таблото е да поддържа скорост на изпълнение на една инструкция
на тактов цикъл (когато няма структурни опасности) чрез изпълнение на инструкция
възможно най-рано. По този начин, когато следващата инструкция за изпълнение е спряна, др
инструкциите могат да бъдат издадени и изпълнени, ако не зависят от никакви активни или
блокирана инструкция. Таблото с резултати поема пълна отговорност за издаване на инструкции
и изпълнение, включително всички откривания на опасности. Възползвайки се от извън ред
изпълнението изисква множество инструкции да бъдат в техния EX етап едновременно.
Това може да се постигне с множество функционални единици, с конвейерна функционалност
единици, или и с двете. Тъй като тези две възможности— тръбопроводни функционални единици и
множество функционални единици - по същество са еквивалентни за целите на тръбопровода
контрол, ще приемем, че процесорът има множество функционални единици.
CDC 6600 имаше 16 отделни функционални единици, включително 4 с плаваща запетая
единици, 5 единици за препратки към паметта и 7 единици за операции с цели числа. На
процесор за MIPS архитектурата, таблата имат смисъл предимно на
единица с плаваща запетая, тъй като латентността на другите функционални единици е много малка.
Да приемем, че има два умножителя, един суматор, една единица за деление и една единица за цяло
число за всички препратки към паметта, разклонения и операции с цели числа.
Въпреки че този пример е по-прост от CDC 6600, той е достатъчно мощен
да демонстрирате принципите, без да имате много подробности или да се нуждаете от много
дълги примери. Тъй като и MIPS, и CDC 6600 са архитектури за съхранение на натоварване,
техниките са почти идентични за двата процесора. Фигура C.54
показва как изглежда процесора.
Всяка инструкция преминава през таблото, където се записват данните
изграждат се зависимости; тази стъпка съответства на проблем с инструкция и замества
част от стъпката на ID в MIPS тръбопровода. След това таблото определя кога
инструкцията може да прочете своите операнди и да започне изпълнението. Ако таблото с резултати
реши, че инструкцията не може да се изпълни веднага, той следи всяка промяна в
хардуера и решава кога инструкцията може да се изпълни. Таблото с резултати
също контролира кога една инструкция може да запише своя резултат в регистъра на местоназначението.
По този начин цялото откриване и разрешаване на опасности е централизирано в таблото с резултати.
Ще видим снимка на таблото по-късно (Фигура C.55 на страница C-76), но

Регистри Шини за данни
FP мулти
FP мулти
FP разделение
FP доп
Табло с резултати
Контрол/ Контрол/
състояние състояние
Фигура C.54 Основната структура на MIPS процесор с табло. Функцията на таблото е да

контролира изпълнението на инструкции (вертикални контролни линии). Целият поток
от данни между регистрационния файл и функционалните единици през шините
(хоризонталните линии, наречени стволове в CDC 6600). Има два FP умножителя, FP
делител, FP суматор и цяло число. Един набор от шини (два входа и един изход)
обслужва група функционални единици. Подробностите за таблото са показани на фигури C.55 до C
първо трябва да разберем стъпките в сегмента за издаване и изпълнение на тръбопровода.
Всяка инструкция преминава през четири стъпки в изпълнение. (Тъй като се

концентрираме върху FP операциите, няма да разглеждаме стъпка за достъп до паметта.)
Нека първо разгледаме неофициално стъпките и след това да разгледаме подробно как
таблото с резултати съхранява необходимата информация, която определя кога да
преминете от една стъпка към друга. Четирите стъпки, които заместват стъпките ID, EX
и WB в стандартния MIPS тръбопровод, са както следва:
1. Проблем— Ако функционална единица за инструкцията е свободна и никоя друга
активна инструкция няма същия регистър на местоназначението, таблото издава

инструкцията към функционалната единица и актуализира нейната вътрешна
структура от данни. Тази стъпка замества част от стъпката ID в MIPS конвейера. Като гарантир
никоя друга активна функционална единица не иска да запише резултата си в дестинацията
регистрирайте, ние гарантираме, че не могат да съществуват опасности от WAW. Ако структурна или
Съществува опасност от WAW, след което издаването на инструкции спира и няма да се издават
допълнителни инструкции, докато тези опасности не бъдат изчистени. Когато етапът на проблема спре, то
предизвиква запълване на буфера между извличане на инструкции и издаване; ако буферът е a
едно влизане, извличането на инструкции спира незабавно. Ако буферът е опашка с
множество инструкции, спира, когато опашката се запълни.
2. Четене на операнди— Таблото с резултати следи наличността на изходните операнди. Операнд
източник е наличен, ако не е издадена по-рано активна инструкция
ще го напиша. Когато операндите източник са налични, таблото показва
функционалната единица да продължи да чете операндите от регистрите и
започнете изпълнението. Таблото с резултати разрешава динамично RAW опасностите в това
стъпка и инструкциите могат да бъдат изпратени за изпълнение неправилно. Тази стъпка,
заедно с издаване, завършва функцията на стъпката за идентификация в простия MIPS
3. Изпълнение— Функционалната единица започва изпълнение при получаване на операнди.
Когато резултатът е готов, той уведомява таблото, че е завършен
екзекуция. Тази стъпка замества EX стъпката в MIPS конвейера и отнема няколко цикъла в MIPS FP
конвейера.
4. Запишете резултата— След като таблото с резултати разбере, че функционалната единица е
завършило изпълнението, таблото с резултати проверява за опасности от WAR и спира инструкцията
за завършване, ако е необходимо.
Опасност от ВОЙНА съществува, ако има кодова последователност като нашия по-ранен пример
с ADD.D и SUB.D, които и двете използват F8. В този пример имахме кода
DIV.D F0, F2, F4

ADD.D F10, F0, F8
SUB.D F8, F8, F14
ADD.D има операнд източник F8, който е същия регистър като дестинацията
на ПОДС.Д. Но ADD.D всъщност зависи от по-ранна инструкция. Таблото с резултати все още ще спира
SUB.D в неговия етап на запис на резултата, докато ADD.D не го прочете
операнди. По принцип не може да се допусне завършваща инструкция

напишете резултатите си, когато:
Има инструкция, която не е прочела своите операнди, които предхождат (т.е. в

ред на издаване) инструкцията за завършване и Един от
операндите е същия регистър като резултата от завършването

Ако тази опасност от ВОЙНА не съществува или когато тя изчезне, таблото с резултати показва
функционална единица за съхраняване на резултата в регистъра на местоназначението. Тази стъпка
замества стъпката WB в простия конвейер MIPS.
На пръв поглед може да изглежда, че таблото ще има трудности при разделянето на опасностите RAW
и WAR.
Тъй като операндите за дадена инструкция се четат само когато и двата операнда са
налични в регистрационния файл, това табло не се възползва от препращането. Вместо това
регистрите се четат само когато и двата са налични. Това не е така
голяма глоба, както може би си мислите първоначално. За разлика от нашия прост тръбопровод от по-рано,
инструкциите ще запишат резултата си в регистрационния файл веднага щом завършат
изпълнение (приемайки, че няма WAR опасности), вместо да чака статично присвоен
слот за запис, който може да е на няколко цикъла разстояние. Ефектът е намалена латентност на конвейера
и ползите от препращането. Все още има един допълнителен цикъл на латентност, който
възниква, тъй като етапите на резултат от запис и операнд за четене не могат да се припокриват. Бихме
се нуждаят от допълнително буфериране, за да елиминират това натоварване.
Въз основа на собствената си структура от данни, таблото с резултати контролира напредъка

на инструкциите от една стъпка към следващата чрез комуникация с функционалните звена.
Има обаче малко усложнение. Има само ограничен брой
изходни операндни шини и резултатни шини към регистърния файл, който представлява a
структурна опасност. Таблото трябва да гарантира, че броят на функционалните
единици, на които е разрешено да преминат към стъпки 2 и 4, не надвишава броя на автобусите
на разположение. Няма да навлизаме в повече подробности за това, освен да споменем, че
CDC 6600 реши този проблем, като групира 16-те функционални единици заедно в
четири групи и доставя набор от шини, наречени канали за данни, за всяка група. само
едно устройство в група може да прочете своите операнди или да запише резултата си по време на часовник.
Сега нека да разгледаме подробната структура на данните, поддържана от MIPS таблица с

резултати с пет функционални единици. Фигура C.55 показва как изглежда информацията на
таблото наполовина през изпълнението на тази проста последователност от
инструкции:
LD F6,34(R2)
LD F2,45(R3)
ПОДП.Д F8, F6, F2
DIV.D F10, F0, F6
ДОБ.Д F6, F8, F2
Таблото има три части:
1. Състояние на инструкцията — показва в коя от четирите стъпки се намира инструкцията.
2. Състояние на функционалната единица — Показва състоянието на функционалната единица (FU). Там

има девет полета за всяка функционална единица:
Busy— Показва дали устройството е заето или не.
Op— Операция за изпълнение в единицата (напр. добавяне или изваждане).
Fi— Регистър на дестинацията.
Fj, Fk— номера на регистъра на източника.
Qj, Qk— Функционални единици, произвеждащи регистри източник Fj, Fk.
Rj, Rk— Флагове, показващи кога Fj, Fk са готови и все още не са прочетени. Задайте Не
след прочитане на операндите.
Инструкция Проблем Четене на операнди Изпълнение завършено Запис на резултат
LD F6,34(R2)
LD F2,45(R3)
MUL.D F0,F2,F4
SUB.D F8,F6,F2
DIV.D F10,F0,F6
Състояние на функционалната единица
Име Зает оп Fi Fj Fk Qj Qk Rj Rk
Цяло число да Заредете F2 R3 Не
Множество1 да Мулт F0 F2 F4 Цяло число Не да
Мулт2 Не
Добавете да Под F8 F6 F2 Цяло число да Не
Разделям да див F10 F0 F6 Множество1 Не да
Регистрирайте състояние на резултата
F0 F2 F4 F6 F8 F10 F12 ... F30
ФУ Множество1 Цяло число Добавете Разделям
Фигура C.55 Компоненти на таблото с резултати. Всяка инструкция, която е издадена или предстои да бъде издадена, има запис в
таблицата за състоянието на инструкциите. Има един запис в таблицата за състоянието на функционалната единица за всяка функционална единица. След като един
проблеми с инструкции, записът на неговите операнди се съхранява в таблицата със състоянието на функционалните единици. И накрая, регистрирайте таблицата с резултати
показва коя единица ще произведе всеки чакащ резултат; броят на записите е равен на броя на регистрите. The
таблицата със състоянието на инструкциите казва, че: (1) първият LD е завършил и е написал резултата си и (2) вторият LD е
завърши изпълнението, но все още не е написал резултата си. Всички MUL.D, SUB.D и DIV.D са издадени, но са в застой,
чакат своите операнди. Състоянието на функционалната единица казва, че първата единица за умножение чака целочислената единица,
единицата за добавяне чака целочислената единица, а единицата за деление чака първата единица за умножение.
Инструкцията ADD.D е спряна поради структурна опасност; ще се изчисти, когато SUB.D завърши. Ако запис в една от тези
таблици на таблото с резултати не се използва, той остава празен. Например полето Rk не се използва при натоварване, а единицата Mult2 е
неизползвани, следователно техните полета нямат значение. Освен това, след като операндът бъде прочетен, полетата Rj и Rk се настройват на No.
Фигура C.58 показва защо тази последна стъпка е решаваща.
3. Статус на резултата от регистъра — Показва коя функционална единица ще записва всеки регистър,
ако активна инструкция има регистъра като местоназначение. Това поле е зададено на
празно, когато няма чакащи инструкции, които ще запишат този регистър.
Сега нека да разгледаме как кодовата последователност, започнала на фигура C.55, продължава
да се изпълнява. След това ще можем да разгледаме подробно условията, които
табло, използвано за контрол на изпълнението.
Пример Да приемем следните закъснения на EX цикъл (избрани, за да илюстрират поведението и
не е представителен) за функционалните единици с плаваща запетая: Добавянето е 2 тактови цикъла,
умножението е 10 тактови цикъла, а делението е 40 тактови цикъла. Използвайки кодовия сегмент на
Фигура C.55 и започвайки с точката, посочена от статуса на инструкцията на Фигура C.55, покажете как
изглеждат таблиците за състояние, когато MUL.D и DIV.D
са готови да преминат към състояние на резултат от запис.
Отговор Съществуват опасности от RAW данни от втория LD до MUL.D, ADD.D и SUB.D,
от MUL.D към DIV.D и от SUB.D към ADD.D. Има опасност от WAR данни
между DIV.D и ADD.D и SUB.D. И накрая, има структурна опасност за

добавете функционална единица за ADD.D и SUB.D. Как изглеждат масите, когато MUL.D
и DIV.D са готови да напишат своите резултати е показано на фигури C.56 и C.57,
съответно.
Сега можем да видим как таблото работи в детайли, като разгледаме какво трябва
се случи таблото да позволи на всяка инструкция да продължи. Фигура C.58
показва какво изисква таблото с резултати за всяка инструкция за напредване и счетоводните
действия, необходими, когато инструкцията напредне. Таблото с резултати
записва информация за спецификатора на операнд, като например номера на регистрите. Например ние
трябва да записва изходните регистри, когато се издаде инструкция. Защото ние се отнасяме
към съдържанието на регистър като Regs[D], където D е име на регистър, няма
неяснота. Например, Fj[FU] S1 предизвиква поставянето на името на регистъра S1
Fj[FU], а не съдържанието на регистър S1.
Разходите и ползите от таблото са интересни съображения. The
Дизайнерите на CDC 6600 измериха подобрение на производителността от 1,7 за FOR-TRAN програми и
2,5 за ръчно кодиран асемблер. Това обаче беше
измерено в дните преди планирането на софтуерния конвейер, полупроводникова главна
памет и кешове (които намаляват времето за достъп до паметта). Таблото с резултати на
CDC 6600 имаше приблизително толкова логика, колкото една от функционалните единици, което е
изненадващо ниско. Основният разход беше в големия брой автобуси - около четири пъти
толкова, колкото биха били необходими, ако процесорът изпълнява само инструкции в ред (или
ако инициира само една инструкция на цикъл на изпълнение). Наскоро нарастващата
интересът към динамичното планиране е мотивиран от опити за издаване на повече инструкции на
часовник (така че цената на повече автобуси трябва да бъде платена така или иначе) и от идеи като
спекулации (разгледани в раздел 4.7), които естествено се основават на динамично планиране.
Таблото с резултати използва наличното ILP, за да минимизира броя на възникващите сергии
от истинските зависимости на данните на програмата. При елиминиране на сергии има табло с резултати
ограничен от няколко фактора:
1. Степента на наличен паралелизъм между инструкциите – това определя дали могат да бъдат намерени
независими инструкции за изпълнение. Ако всеки
инструкцията зависи от нейния предшественик, нито една динамична схема за планиране не може
намалете сергиите. Ако инструкциите в тръбопровода трябва едновременно да бъдат избрани от
един и същ основен блок (както беше вярно в 6600), това ограничение вероятно ще
бъде доста тежък.

Напишете
Инструкция Проблем Четене на операнди Изпълнението е завършено резултата
LD F6,34(R2)
LD F2,45(R3)
MUL.D F0,F2,F4
SUB.D F8,F6,F2
DIV.D F10,F0,F6
ADD.D F6,F8,F2
Цяло число Не
Множество1 да Мулт F0 F2 F4 Не не
Мулт2 Не
Добавете да Добавете F6 F8 F2 Не не
Разделям да див F10 F0 F6 Множество1 Не Да
F0 F2 F4 F6 F8 F10 F12 . . . F30
ФУ Мулт 1 Добавете Разделям
Фигура C.56 Таблици с табло точно преди MUL.D да започне да записва резултат. DIV.D все още не е прочел нито едно от тях
операнди, тъй като има зависимост от резултата от умножението. ADD.D е прочел операндите си и е в процес на изпълнение,
въпреки че е бил принуден да изчака, докато SUB.D завърши, за да получи функционалната единица. ADD.D не може да продължи да пише
резултат поради WAR опасността на F6, която се използва от DIV.D. Полетата Q са уместни само когато функционален
единица чака друга единица.
2. Броят на записите в таблото – Това определя колко далече напред може да търси
тръбопроводът за независими инструкции. Наборът от прегледани инструкции
като кандидати за потенциално изпълнение се нарича прозорец. Размерът на
таблото определя размера на прозореца. В този раздел приемаме a
прозорецът не се простира отвъд клон, така че прозорецът (и таблото с резултати)
винаги съдържа праволинеен код от един основен блок. Глава 3
показва как прозорецът може да бъде разширен отвъд клон.
3. Броят и видовете функционални единици - Това определя важността на

структурни опасности, които могат да се увеличат, когато се използва динамично планиране.
Напишете
Инструкция Проблем Четене на операнди Изпълнението е завършено резултата
LD F6,34(R2)d
LD F2,45(R3)
MUL.D F0,F2,F4
SUB.D F8,F6,F2
DIV.D F10,F0,F6
Цяло число Не
Множество1 да Мулт F0 F2 F4 Не Не
Мулт2 Не
Добавете да Добавете F6 F8 F2 Не Не
Разделям да див F10 F0 F6 Не да
F0 F2 F4 F6 F8 F10 F12 ... F30
ФУ Мулт 1 Добавете Разделям
Фигура C.57 Таблици с табло точно преди DIV.D да запише резултата. ADD.D успя да завърши веднага щом
DIV.D премина през операнди за четене и получи копие на F6. Остава да завърши само DIV.D.
4. Наличието на антизависимости и зависимости на продукцията – Те водят до

ВОЙНА и WAW сергии.
Глава 3 се фокусира върху техники, които атакуват проблема с излагането и по-добре

използване на наличния паралелизъм на ниво инструкция (ILP). Вторият и третият фактор
може да бъде атакуван чрез увеличаване на размера на таблото и броя на функционалните
единици; тези промени обаче имат отражение върху разходите и могат също да повлияят
време на цикъл. Опасностите от WAW и WAR стават все по-важни в динамиката
планирани процесори, тъй като тръбопроводът излага повече зависимости от имена.
Опасностите от WAW също стават по-важни, ако използваме динамично планиране с a
схема за предсказване на разклонения, която позволява припокриване на множество итерации на цикъл.
Състояние на инструкцията Изчакай докато Счетоводство
Проблем Не съм зает [FU] и няма резултат [D] Зает [FU] да; Op[FU] op; Fi[FU] D;
Fj[FU] S1; Fk[FU] S2;
Qj Резултат [S1]; Qk Резултат [S2];
Rj не Qj; Rk не Qk; Резултат[D] FU;
Четене на операнди Rj и Rk Rj Не; Rk No; Qj 0; Qk 0
Изпълнението е завършено Изпълнен функционален блок
Напишете резултата f((Fj[f ] ¦ Fi[FU] или Rj[f ] = No) & f(ако Qj[f ]=FU тогава Rj[f ] Да);
(Fk[f ] ¦ Fi[FU] или Rk[f ] = Не)) f(ако Qk[f ]=FU тогава Rk[f ] Да);
Резултат[Fi[FU]] 0; Зает [FU] Не
Фигура C.58 Необходими проверки и счетоводни действия за всяка стъпка от изпълнението на инструкцията. FU означава
функционална единица, използвана от инструкцията, D е името на регистъра местоназначение, S1 и S2 са имената на регистрите източник,
и op е операцията, която трябва да се извърши. За достъп до записа в таблото с име Fj за функционална единица FU използваме нотацията
Fj[FU]. Резултат [D] е името на функционалната единица, която ще записва регистър D. Тестът на случай на резултат от запис предотвратява
записа, когато има опасност от WAR, която съществува, ако друга инструкция има дестинацията на тази инструкция
(Fi[FU]) като източник (Fj[f ] или Fk[f ]) и ако някаква друга инструкция е записала регистъра (Rj = Да или Rk = Да). Променливата f се
използва за всяка функционална единица.
C.8 Заблуди и клопки
Клопка Неочакваните последователности на изпълнение могат да причинят неочаквани опасности.
На пръв поглед опасностите от WAW изглеждат така, сякаш никога не трябва да се появяват в код
последователност, тъй като нито един компилатор никога не би генерирал два записа в
един и същ регистър без намесено четене, но те могат да възникнат, когато последователността
е неочаквана. Например, първият запис може да бъде в слота за забавяне на взето разклонение
когато планировчикът смяташе, че клонът няма да бъде взет. Ето кода
последователност, която може да причини това:
BNEZ R1,foo
DIV.D F0,F2,F4; преместен в слота за забавяне
;от пропадане
.....
.....
Фу: LD F0,qrs
Ако клонът бъде взет, тогава преди DIV.D да може да завърши, LD ще достигне
WB, причинявайки опасност от WAW. Хардуерът трябва да открие това и може да спре
издаване на LD Друг начин това може да се случи е, ако второто записване е в капан
рутина. Това се случва, когато инструкция, която прихваща и записва резултати,
продължава и завършва след инструкция, която записва същия регистър в прихващането
манипулатор. Хардуерът трябва да открие и предотврати и това.
Клопка Обширната конвейерна обработка може да повлияе на други аспекти на дизайна, което води до общо по-лошо състояние
цена-производителност.
C.10 Историческа перспектива и препратки C-81
Най-добрият пример за това явление идва от две реализации на VAX, 8600 и 8700. Когато
8600 беше доставен първоначално, той имаше време на цикъл от 80 ns. Впоследствие беше
представена преработена версия, наречена 8650, с часовник от 55 ns. 8700 има много по-
опростен тръбопровод, който работи на ниво микроинструкция, което води до по-малък CPU с
по-бърз тактов цикъл от 45 ns. Общият резултат е, че 8650 има предимство на CPI от около 20%,
но 8700 има тактова честота, която е с около 20% по-бърза. Така 8700 постига същата
производителност с много по-малко хардуер.
Клопка Оценяване на динамично или статично планиране на базата на неоптимизиран код.
Неоптимизираният код – съдържащ излишни зареждания, съхранявания и други операции,

които могат да бъдат елиминирани от оптимизатор – е много по-лесен за планиране от
„стегнатия“ оптимизиран код. Това важи за планирането както на закъснения на управлението
(със забавени разклонения), така и на закъснения, произтичащи от опасности от RAW. В gcc,
работещ на R3000, който има тръбопровод, почти идентичен с този в Раздел C.1, честотата на
неактивните тактови цикли се увеличава с 18% от неоптимизирания и планиран код към
оптимизирания и планиран код. Разбира се, оптимизираната програма е много по-бърза, тъй
като има по-малко инструкции. За да оцените справедливо планировчик по време на
компилиране или динамично планиране по време на изпълнение, трябва да използвате
оптимизиран код, тъй като в реалната система ще получите добра производителност от
други оптимизации в допълнение към планирането.
C.9 Заключителни бележки
В началото на 80-те години конвейерът беше техника, запазена предимно за суперкомпютри и

големи мейнфрейми за милиони долари. До средата на 80-те години на миналия век се
появиха първите конвейерни микропроцесори и помогнаха за трансформирането на света
на компютрите, позволявайки на микропроцесорите да заобиколят миникомпютрите по
производителност и в крайна сметка да поемат и надминат мейнфреймите. До началото на 90-
те години на миналия век вградените микропроцесори от висок клас прегърнаха
конвейерната обработка, а настолните компютри се насочиха към използването на
усъвършенстваните динамично планирани подходи с множество проблеми, обсъдени в Глава
3. Материалът в това приложение, който се смяташе за разумно напреднал за завършилите
студенти, когато този текст се появява за първи път през 1990 г., сега се счита за основен
материал за студенти и може да се намери в процесори, струващи по-малко от $2!
C.10 Историческа перспектива и препратки
Раздел L.5 (достъпен онлайн) включва дискусия относно разработването на паралелизъм на

ниво конвейер и инструкции, обхващащ както това приложение, така и материала в Глава
3. Предоставяме множество препратки за по-нататъшно четене и изследване на тези теми.
Актуализирани упражнения от Даяна Франклин
C.1 [15/15/15/15/25/10/15] <A.2> Използвайте следния кодов фрагмент:
цикъл: LD R1,0(R2) ;зареди R1 от адрес 0+R2

ТАТЕ R1, R1, #1 ;R1=R1+1
SD R1,0,(R2) ;съхранява R1 на адрес 0+R2
ТАТЕ R2, R2, #4 ;R2=R2+4
DSUB R4, R3, R2 R4=R3-R2
БНЕЗ R4, Цикъл ;разклоняване към цикъл, ако R4!=0
Да приемем, че първоначалната стойност на R3 е R2 + 396.
а. [15] <C.2> Опасностите за данни са причинени от зависимости на данните в кода.

Дали дадена зависимост причинява опасност зависи от внедряването на машината (т.е. броя
на етапите на тръбопровода). Избройте всички зависимости на данните в
код по-горе. Запишете регистъра, инструкцията източник и инструкцията местоназначение;
например, има зависимост на данните за регистър R1 от LD до
ТАТОТО.
b. [15] <C.2> Покажете времето на тази последователност от инструкции за 5-степенния RISC

тръбопровод без хардуер за пренасочване или заобикаляне, но като се приеме, че a
четене на регистър и запис в същия тактов цикъл „напред“ през регистрационния файл,
както е показано на фигура C.6. Използвайте времева диаграма на тръбопровода като тази
на Фигура C.5. Да приемем, че разклонението се обработва чрез промиване на тръбопровода. Падам
препратките към памет отнемат 1 цикъл, колко цикъла отнема изпълнението на този цикъл?
° С. [15] <C.2> Покажете времето на тази последователност от инструкции за 5-степенния RISC

тръбопровод с пълно препращане и байпасиращ хардуер. Използвайте синхронизация на тръбопровода
диаграма като тази, показана на фигура C.5. Да приемем, че клонът се управлява от

предвиждайки го като невзето. Ако всички препратки към паметта отнемат 1 цикъл, колко
необходими ли са циклите за изпълнение на този цикъл?
д. [15] <C.2> Покажете времето на тази последователност от инструкции за 5-степенния RISC

тръбопровод с пълно препращане и байпасиращ хардуер. Използвайте синхронизация на тръбопровода
диаграма като тази, показана на фигура C.5. Да приемем, че клонът се управлява от

предвиждайки го така, както е взето. Ако всички препратки към паметта отнемат 1 цикъл, колко цикъла
този цикъл отнема ли да се изпълни?
д. [25] <C.2> Високопроизводителните процесори имат много дълбоки конвейери — повече

повече от 15 етапа. Представете си, че имате 10-стъпален конвейер, в който всеки етап
от 5-стъпалния тръбопровод е разделен на две. Единствената уловка е, че за данни
препращане, данните се препращат от края на двойка етапи до началото на двата етапа, където
са необходими. Например данните се препращат
от изхода на втория етап на изпълнение до входа на първия етап на изпълнение
етап, все още причинявайки забавяне от 1 цикъл. Покажете времето на тази инструкция
последователност за 10-степенния RISC тръбопровод с пълно препращане и байпас
хардуер. Използвайте времева диаграма на тръбопровода като тази, показана на фигура C.5. Предположете
Актуализирани упражнения от Даяна Франклин C-83
че клонът се обработва, като се предскаже, че е взет. Ако всички препратки към паметта
отнемат 1 цикъл, колко цикъла са необходими за изпълнение на този цикъл?
f. [10] <C.2> Да приемем, че в 5-степенния конвейер най-дългият етап изисква 0,8 ns, а забавянето
на регистъра на конвейера е 0,1 ns. Какво е времето на тактовия цикъл на 5-степенния
тръбопровод? Ако 10-степенният тръбопровод разделя всички етапи наполовина, какво е
времето на цикъла на 10-степенната машина?
ж. [15] <C.2> Като използвате вашите отговори от части (d) и (e), определете циклите на
инструкция (CPI) за цикъла на 5-степенна конвейерна линия и 10-степенна конвейерна линия.
Уверете се, че броите само от момента, в който първата инструкция достигне етапа на
обратно записване до края. Не отчитайте стартирането на първата инструкция.
Като използвате времето на тактовия цикъл, изчислено в част (f), изчислете средното
време за изпълнение на инструкции за всяка машина.
C.2 [15/15] <C.2> Да предположим, че честотите на разклоненията (като проценти от всички инструкции)
са както следва:
Условни разклонения 15%
Скокове и плащания 1%
Взети условни клонове 60% са взети
а. [15] <C.2> Изследваме тръбопровод с четири дълбочини, където разклонението се разрешава

в края на втория цикъл за безусловни разклонения и в края на третия цикъл за условни
разклонения. Ако приемем, че винаги може да се направи само първият тръбен етап,
независимо от това дали разклонението върви и игнорирайки други спирания на
тръбопровода, колко по-бърза ще бъде машината без опасност от разклоняване?
b. [15] <C.2> Сега приемете процесор с висока производителност, в който имаме конвейер с
дълбочина 15, където разклонението се разрешава в края на петия цикъл за безусловни
разклонения и в края на десетия цикъл за условни разклонения . Ако приемем, че винаги
може да се направи само първият етап на тръбопровода, независимо от това дали
разклонението върви и игнорирайки други спирания на тръбопровода, колко по-бърза ще
бъде машината без опасност от разклоняване?
C.3 [5/15/10/10] <C.2> Започваме с компютър, реализиран в изпълнение с един цикъл. Когато етапите са
разделени по функционалност, етапите не изискват абсолютно същото време. Оригиналната
машина имаше часовников цикъл от 7 ns. След като етапите бяха разделени, измерените
времена бяха IF, 1 ns; ID, 1,5 ns; EX, 1 ns; MEM, 2 ns; и WB, 1,5 ns. Закъснението на регистъра на
конвейера е 0,1 ns. а. [5] <C.2> Какъв е часовниковият цикъл на 5-степенната конвейерна
машина? b. [15] <C.2> Ако има забавяне на всеки 4 инструкции, какъв е CPI на новата
машина?
° С. [10] <C.2> Какво е ускоряването на конвейерната машина спрямо едноцикловата машина?
д. [10] <C.2> Ако конвейерната машина имаше безкраен брой етапи, какво
дали неговото ускоряване ще бъде над едноцикловата машина?
C.4 [15] <C.1, C.2> Намалена хардуерна реализация на класическата петстепенна

RISC тръбопроводът може да използва хардуера на етапа EX за изпълнение на инструкция за разклоняване
сравнение и след това действително не доставя целевия компютър на клона на етапа IF, докато
тактовият цикъл, в който инструкцията за разклоняване достига етапа MEM. контрол
опасните застоявания могат да бъдат намалени чрез разрешаване на инструкции за разклоняване в ID, но
подобряването на производителността в едно отношение може да намали производителността при други обстоятелства.
Напишете малък фрагмент от код, в който изчислявате разклонението в етапа на ID

причинява опасност от данни, дори при препращане на данни.
C.5 [12/13/20/20/15/15] <C.2, C.3> За тези проблеми ще проучим конвейер

за архитектура регистър-памет. Архитектурата има два формата на инструкции:
формат регистър-регистър и формат регистър-памет. Има режим на адресиране с една памет
(отместване + основен регистър). Има набор от ALU операции
с формат:
ALUop Rdest, Rsrc1, Rsrc2
или
ALUop Rdest, Rsrc1, MEM
където ALUop е едно от следните: събиране, изваждане, И, ИЛИ, зареждане (Rsrc1

игнориран), или съхранявайте. Rsrc или Rdest са регистри. MEM е основен регистър и отместване
двойка. Клоните използват пълно сравнение на два регистъра и са свързани с PC. Предположете
че тази машина е конвейерна, така че на всеки такт да се стартира нова инструкция
цикъл. Структурата на тръбопровода е подобна на тази, използвана в микротръбопровода VAX 8700
[Clark 1987], е
АКО RF ALU1 MEM WB
АКО RF ALU1 MEM ALU2 WB

Първият етап на ALU се използва за изчисляване на ефективен адрес за препратки към паметта и
разклонения. Вторият ALU цикъл се използва за операции и клонове
сравнение. RF е както цикъл на декодиране, така и цикъл на регистриране. Да приемем, че когато a
четене на регистър и запис на регистър на същия регистър се случват в същия часовник
данните за запис се препращат.
а. [12] <C.2> Намерете броя на необходимите суматори, като броите всеки суматор или
инкрементатор; покажете комбинация от инструкции и етапи на тръбата, които оправдават това
отговор. Трябва да дадете само една комбинация, която максимизира броя на суматора.
b. [13] <C.2> Намерете броя на портовете за четене и запис на регистър и четене на паметта
и необходими портове за запис. Покажете, че отговорът ви е правилен, като покажете
комбинация от инструкции и етап на тръбопровод, посочващ инструкцията и
брой портове за четене и портове за запис, необходими за тази инструкция.
° С. [20] <C.3> Определете всички препращания на данни за всички ALU, които ще са необходими.
Да приемем, че има отделни ALU за тръбните стъпала ALU1 и ALU2.
Въведете цялото пренасочване между ALU, необходимо за избягване или намаляване на застоя.
Покажете връзката между двете инструкции, включени в препращането, като използвате
формата на таблицата на Фигура C.26 , но пренебрегвайки последните две колони.
Внимавайте да обмислите препращане през междинна инструкция - например,
ADD R1, ... произволна
инструкция ADD ...,

R1, ...
д. [20] <C.3> Показване на всички изисквания за препращане на данни, необходими за избягване

или намаляване на спиранията, когато източникът или дестинацията не са ALU. Използвайте
същия формат като на фигура C.26, като отново игнорирате последните две колони.
Не забравяйте да препращате към и от препратките към паметта.
д. [15] <C.3> Покажете всички оставащи опасности, които включват поне една единица, различна от
ALU, като единица източник или дестинация. Използвайте таблица като тази, показана на
фигура C.25, но заменете последната колона с дължините на опасностите.
f. [15] <C.2> Покажете всички контролни опасности чрез пример и посочете дължината на срива.
Използвайте формат като този, показан на Фигура C.11, като етикетирате всеки пример.
C.6 [12/13/13/15/15] <C.1, C.2, C.3> Сега ще добавим поддръжка за ALU операции с регистър-памет към
класическия петстепенен RISC конвейер. За да се компенсира това нарастване на сложността,
цялото адресиране на паметта ще бъде ограничено до индиректен регистър (т.е. всички адреси
са просто стойност, съхранявана в регистър; към стойността на регистъра не може да се добавя
отместване или изместване). Например, инструкцията регистър-памет ADD R4, R5, (R1) означава
добавяне на съдържанието на регистър R5 към съдържанието на местоположението на паметта с
адрес, равен на стойността в регистър R1, и поставяне на сумата в регистър R4 . Операциите
регистър-регистр ALU са непроменени. Следните елементи се отнасят за целочисления RISC
конвейер: a. [12] <C.1> Избройте
пренареден ред на петте традиционни етапа на RISC тръбопровода, които ще поддържат операции
регистър-памет, реализирани изключително чрез непряко адресиране на регистъра.
b. [13] <C.2, C.3> Опишете какви нови пътеки за пренасочване са необходими за тръбопровода със
задна позиция, като посочите източника, дестинацията и информацията, прехвърлена по
всеки необходим нов път.
° С. [13] <C.2, C.3> За пренаредените етапи на RISC тръбопровода какви нови опасности за данните
се създават от този режим на адресиране? Дайте последователност от инструкции,
илюстрираща всяка нова опасност.
д. [15] <C.3> Избройте всички начини, по които RISC конвейерът с ALU операции с регистър-памет
може да има различен брой инструкции за дадена програма от оригиналния RISC конвейер.
Дайте двойка специфични последователности от инструкции, една за оригиналния конвейер
и една за пренаредения конвейер, за да илюстрирате всеки начин.
д. [15] <C.3> Да приемем, че всички инструкции отнемат 1 тактов цикъл на етап. Избройте всички
от начините, по които RISC регистър-памет може да има различен CPI за a
дадена програма в сравнение с оригиналния RISC конвейер.
C.7 [10/10] <C.3> В този проблем ще проучим как задълбочаването на тръбопровода

влияе върху производителността по два начина: по-бърз тактов цикъл и увеличени застой поради
опасности за данни и управление. Да приемем, че оригиналната машина е 5-стъпален тръбопровод
с тактов цикъл от 1 ns. Втората машина е 12-стъпален конвейер с 0,6 ns
тактов цикъл. 5-степенният тръбопровод претърпява срив поради опасност от данни на всеки 5
инструкции, докато 12-степенният тръбопровод има 3 прекъсвания на всеки 8 инструкции. Освен
това разклоненията съставляват 20% от инструкциите, а степента на грешно прогнозиране и за
двете машини е 5%.
а. [10] <C.3> Какво е ускоряването на 12-степенния тръбопровод спрямо 5-степенния

тръбопровод, като се вземат предвид само опасностите от данните?
b. [10] <C.3> Ако наказанието за неправилно предвиждане на клона за първата машина е 2 цикъла
но втората машина е 5 цикъла, какви са CPI на всяка, като се вземе предвид
отчетете сергиите поради грешни прогнози на клона?
C.8 [15] <C.5> Създайте таблица, показваща логиката на пренасочване за цяло число R4000
тръбопровод, използвайки същия формат като този, показан на фигура C.26. Включете само
MIPS инструкции, които разгледахме на Фигура C.26.
C.9 [15] <C.5> Създайте таблица, показваща целочисленото откриване на опасност R4000, използвайки
същият формат като показания на фигура C.25. Включете само инструкциите на MIPS
разгледани на фигура C.26.
C.10 [25] <C.5> Да предположим, че MIPS има само един набор от регистри. Конструирайте препращането
таблица за FP и целочислени инструкции, използвайки формата от Фигура C.26. Игнорирайте
FP и цели числа.
C.11 [15] <C.5> Изградете таблица като тази, показана на фигура C.25 , за да проверите за WAW
спира в MIPS FP тръбопровода от Фигура C.35. Не вземайте под внимание FP разделения.
C.12 [20/22/22] <C.4, C.6> В това упражнение ще разгледаме как общ вектор
цикъл работи на статично и динамично планирани версии на MIPS тръбопровода.
Цикълът е така нареченият DAXPY цикъл (разгледан подробно в Приложение G)
и централната операция при елиминиране на Гаус. Цикълът изпълнява векторната операция Y =
a * X + Y за вектор с дължина 100. Ето MIPS кода за
цикълът:
Фу: LD F2, 0(R1) ; натоварване X(i)

MUL.D F4, F2, F0 ; умножете a*X(i)
LD F6, 0 ($2) ; натоварване Y(i)
ADD.D F6, F4, F6 ; добавете a*X(i) + Y(i)
SD 0(R2), F6 ; съхранява Y(i)
DADDIU R1, R1, #8 ; увеличаване на индекса X
DADDIU R2, R2, #8 ; увеличаване на индекса Y
SGTIU R3, R1, готово ; тествайте дали е направено
BEQZ R3, фу ; цикъл, ако не е направено

За части (a) до (c) приемете, че целочислените операции се издават и завършват за 1 часовник
цикъл (включително натоварвания) и че техните резултати са напълно заобиколени. Игнорирайте клона
забавяне. Ще използвате (само) латентностите на FP, показани на Фигура C.34, но приемете това
FP единицата е напълно конвейерна. За таблата по-долу приемете, че това е инструкция
изчакване на резултат от друга функционална единица може да премине през операнди за четене на
в същото време се изписва резултатът. Да предположим също, че една инструкция при завършване на WR
ще позволи на текущо активна инструкция, която чака на същата функционална единица да бъде издадена
в същия тактов цикъл, в който първата инструкция
завършва WR.
а. [20] <C.5> За този проблем използвайте MIPS тръбопровода от раздел C.5 с
закъснения на тръбопровода от Фигура C.34, но напълно конвейерна FP единица, така че интервалът
на иницииране е 1. Начертайте времева диаграма, подобна на Фигура C.37, показваща
времето за изпълнение на всяка инструкция. Колко тактови цикъла прави всеки
итерация на цикъл, като се брои от момента, в който първата инструкция влезе в WB
етап до кога последната инструкция влиза в етапа WB?
b. [22] <C.6> Използвайки MIPS кода за DAXPY по-горе, покажете състоянието на
таблици с резултати (както на фигура C.56), когато инструкцията SGTIU достигне
напиши резултата. Приемете този проблем и всеки операнд за четене отнема цикъл. Предположете
че има една целочислена функционална единица, която отнема само едно изпълнение
цикъл (закъснението за използване е 0 цикъла, включително зареждания и съхранявания). Да приемем
Конфигурация на FP единица от Фигура C.54 с FP латентности от Фигура C.34.

Клонът не трябва да се включва в таблото с резултати.
° С. [22] <C.6> Използвайки MIPS кода за DAXPY по-горе, приемете табло с резултати
с FP функционалните единици, описани на Фигура C.54, плюс една целочислена функционална
единица (използвана също и за товарене). Да приемем закъсненията, показани на фигура
C.59. Покажете състоянието на таблото (както на фигура C.56), когато клонът
проблеми за втори път. Да приемем, че разклонението е правилно предвидено
взето и взе 1 цикъл. Колко тактови цикъла отнема всяка итерация на цикъл?
Можете да пренебрегнете всички конфликти на регистрационен порт/шина.
C.13 [25] <C.8> Изключително важно е таблото с резултати да може да разграничава RAW и WAR
опасности, тъй като опасността от ВОЙНА изисква забавяне на инструкцията, изпълняваща писането
докато инструкцията, четеща операнд, започне изпълнение, но опасност от RAW
Закъснение в тактови
Инструкцията дава резултат Инструкция за използване на резултата цикли
FP умножение FP ALU оп 6
FP доп FP ALU оп 4
FP умножение FP магазин 5
FP доп FP магазин 3
Цялочислена операция (включително натоварване) Всякакви

0
Фигура C.59 Закъснения на тръбопровода, където закъснението е число.

изисква забавяне на инструкцията за четене, докато инструкцията за писане приключи - точно

обратното. Например, разгледайте последователността:
MUL.D F0, F6, F4

DSUB.D F8, F0, F2
ADD.D F2, F10, F2
DSUB.D зависи от MUL.D (опасност RAW), поради което MUL.D трябва да бъде позволено да завърши
преди DSUB.D. Ако MUL.D е бил спрян за DSUB.D поради невъзможност да се прави разлика между
RAW и WAR опасности, процесорът ще блокира. Тази последователност съдържа опасност от ВОЙНА
между ADD.D и DSUB.D и ADD.D не може да бъде разрешено да завърши, докато DSUB.D не започне
изпълнение. Трудността се състои в разграничаването на опасността от RAW между MUL.D и
DSUB.D и опасността от WAR между DSUB.D и ADD.D. За да разберете точно защо сценарият с три
инструкции е важен, проследете обработката на всяка инструкция етап по етап чрез проблем,
четене на операнди, изпълнение и запис на резултата. Да приемем, че всеки етап от таблото,
различен от изпълнение, отнема 1 тактов цикъл. Да приемем, че инструкцията MUL.D изисква 3
тактови цикъла за изпълнение и че инструкциите DSUB.D и ADD.D изискват по 1 цикъл за
изпълнение. И накрая, приемете, че процесорът има две функционални единици за умножение и
две функционални единици за добавяне. Представете следата по следния начин.
1. Направете таблица със заглавията на колоните Instruction, Issue, Read Operands, Execute, Write
Result и Comment. В първата колона избройте инструкциите в програмен ред (бъдете
щедри с интервал между инструкциите; по-големите клетки на таблицата ще съдържат по-
добре резултатите от вашия анализ). Започнете таблицата, като напишете 1 в колоната
Издаване на реда с инструкции на MUL.D, за да покажете, че MUL.D завършва етапа на
издаване в тактовия цикъл 1. Сега попълнете колоните на етапа на таблицата през цикъла,
в който таблото първо спира инструкция.
2. За блокирана инструкция напишете думите „изчакване на часовников цикъл X“, където X е

номерът на текущия часовников цикъл, в съответната колона на таблицата, за да покажете,
че таблото разрешава RAW или WAR опасност чрез забавяне на този етап. В колоната
Коментар посочете какъв тип опасност и коя зависима инструкция причинява изчакването.
3. Добавяйки думите „завършва с часовников цикъл Y“ към запис в таблица „изчакване“,

попълнете останалата част от таблицата през времето, когато всички инструкции са изпълнени.
За инструкция, която е спряла, добавете описание в колоната Коментари, обясняващо защо
чакането е приключило, когато е приключило, и как е избегната безизходицата. (Съвет:
Помислете как се предотвратяват опасностите от WAW и какво означава това за активните
последователности от инструкции.) Обърнете внимание на реда на завършване на трите
инструкции в сравнение с техния програмен ред.
C.14 [10/10/10] <C.5> За този проблем ще създадете поредица от малки фрагменти, които илюстрират
проблемите, които възникват при използване на функционални единици с различни закъснения.
За всеки от тях начертайте времева диаграма, подобна на фигура C.38 , която илюстрира всяка
концепция и ясно посочете проблема. а. [10] <C.5>
Демонстрирайте, използвайки код, различен от този, използван на фигура C.38, структурната

опасност от наличието на хардуер само за един MEM и WB етап.
b. [10] <C.5> Демонстрирайте опасност от WAW, изискваща срив.

D.1 Въведение D-2

D.2 Теми за напреднали в дисковото съхранение D-2
D.3 Дефиниция и примери за реални неизправности и повреди D-10
D.4 I/O производителност, мерки за надеждност и бенчмаркове D-15
D.5 Малка теория на опашките Д-23
D.6 Междусекторни въпроси Д-34
D.7 Проектиране и оценка на I/O система—
Интернет архивният клъстер Д-36
D.8 Събираме всичко заедно: NetApp FAS6000 Filer Д-41
D.9 Заблуди и клопки Д-43
D.10 Заключителни бележки Д-47
D.11 Историческа перспектива и препратки Д-48
Казуси с упражнения от Андреа С. Арпачи-Дюсо и Ремзи Х.

Арпачи-Дюсо Д-48
д
Системи за съхранение 1
Мисля, че Силиконовата долина беше погрешно наречена. Ако погледнете назад към доларите,
доставени в продукти през последното десетилетие, има повече приходи от магнитни дискове,
отколкото от силиций. Трябва да преименуват мястото на Долината на железния оксид.
Ал Хогланд
Пионер на магнитните дискове
(1982)
Комбиниране на честотна лента и съхранение. . . дава възможност за бърз и надежден достъп до
непрекъснато разширяващите се масиви от съдържание на разпространяващите се дискове и
. . . хранилища от типа на Интернет се ... капацитета на масивите за съхранение на всички
разраства стремглаво изпреварвайки напредъка на компютърната производителност.
Джордж Гилдър
„Краят наближава“,
Forbes ASAP (4 април 2000 г.)
D-2 Приложение D Системи за съхранение
D.1 Въведение
Популярността на интернет услуги като търсачки и търгове нараства
увеличи значението на I/O за компютрите, тъй като никой не би искал настолен компютър, който няма достъп до
Интернет. Това нарастване на важността на I/O е
отразени от имената на нашето време. 60-те до 80-те години на миналия век бяха наречени Компютърна
революция; периодът след 1990 г. е наречен Информационна ера, с
опасения, фокусирани върху напредъка в информационните технологии срещу суровата изчислителна
мощност. Интернет услугите зависят от масивно съхранение, което е фокусът
на тази глава и работата в мрежа, която е във фокуса на Приложение F.
Това изместване на фокуса от изчисленията към комуникацията и съхранението на информация набляга
на надеждността и скалируемостта, както и на ефективността на разходите.
Въпреки че е разочароващо, когато дадена програма се срине, хората изпадат в истерия, ако
губят данните си; следователно системите за съхранение обикновено се държат на по-висок стандарт
на надеждност от останалата част от компютъра. Надеждността е в основата на
съхранение, но също така има своя собствена богата теория за производителността - теория на опашките - това
балансира пропускателната способност спрямо времето за реакция. Софтуерът, който определя кои
характеристиките на процесора, които се използват, е компилаторът, но операционната система узурпира това
роля за съхранение.
По този начин съхранението има различна, многостранна култура от процесорите, но все пак е така
все още се намира в архитектурната палатка. Започваме нашето проучване с напредък в
магнитни дискове, тъй като те са доминиращото устройство за съхранение днес в настолните и
сървърни компютри. Предполагаме, че читателите вече са запознати с основите на
устройства за съхранение, някои от които бяха разгледани в глава 1.
D.2 Разширени теми в дисковото съхранение
В исторически план дисковата индустрия се е концентрирала върху подобряването на капацитета на
дискове. Подобряването на капацитета обикновено се изразява като подобрение на площта
плътност, измерена в битове на квадратен инч:
Писти битове
Плътност на площта
= --------------- на повърхността на диска × ---------- на писта
Инч Инч
До около 1988 г. степента на подобрение на площната плътност беше 29% на
година, като по този начин удвоява плътността на всеки 3 години. Между тогава и около 1996 г
скоростта се подобрява до 60% на година, учетворяване на плътността на всеки 3 години и съвпадение

традиционната скорост на DRAM. От 1997 г. до около 2003 г. процентът се увеличи до
100%, удвояване всяка година. След иновациите, които позволиха този ренесанс
до голяма степен се изиграха, процентът наскоро спадна до около 30% годишно. в
2011, най-високата плътност в търговските продукти е 400 милиарда бита на квадрат
инч. Цената на гигабайт е спаднала поне толкова бързо, колкото площната плътност
увеличени, като задвижванията с по-малък диаметър играят по-голяма роля в това подобрение. Разходите за
гигабайт се подобриха с почти фактор от 1 000 000 между тях

1983 и 2011 г.
Магнитните дискове са били оспорвани много пъти за надмощие на вторичното съхранение.

Фигура D.1 показва една причина: легендарната разлика във времето за достъп между дискове
и DRAM. Латентността на DRAM е около 100 000 пъти по-малка от тази на диска и това предимство
в производителността струва 30 до 150 пъти повече на гигабайт за DRAM.
Разликата в честотната лента е по-сложна. Например, бърз диск през 2011 г. прехвърля с
200 MB/sec от дисковата медия с 600 GB място за съхранение и струва около $400. 4 GB DRAM
модул, струващ около $200 през 2011 г., може да прехвърля при 16 000 MB/сек (вижте Глава 2),
давайки на DRAM модула около 80 пъти по-висока честотна лента от диска. Въпреки това,
честотната лента на GB е 6000 пъти по-висока за DRAM, а честотната лента на долар е 160 пъти
по-висока.
Мнозина са се опитвали да измислят технология, по-евтина от DRAM, но по-бърза от диска,
за да запълнят тази празнина, но досега всички са се провалили. Претендентите никога не са
имали продукт за пускане на пазара в точното време. По времето, когато се доставя нов продукт,
DRAM и дисковете са постигнали напредък, както беше предвидено по-рано, разходите са
спаднали съответно и предизвикателният продукт веднага е остарял.
Най-близкият конкурент е флаш паметта. Тази полупроводникова памет е енергонезависима
като дисковете и има приблизително същата честотна лента като дисковете, но латентността
е 100 до 1000 пъти по-бърза от дисковата. През 2011 г. цената на гигабайт Flash беше 15 до 20
пъти по-евтина от DRAM. Flash е популярен в мобилните телефони, защото се предлага с много по-
малък капацитет и е по-енергийно ефективен от дисковете, въпреки че цената на гигабайт е
15 до 25 пъти по-висока от дисковете. За разлика от дисковете
1 000 000
1980 г
DRAM
1985 г
100 000
1980 г
1990
10 000
1995 1985 г
диск
2000 г 1990 г
1000
Разлика във времето за достъп

/$G
е
ан)B Ц(
1995 г
2005 г
100
2000 г
10
2005 г
0,1
1 10 100 1000 10 000 100 000 1 000 000 10 000 000 100 000 000
Време за достъп (ns)
Фигура D.1 Разходи срещу време за достъп за DRAM и магнитен диск през 1980, 1985, 1990, 1995, 2000 и 2005 г. Разликата от два
порядъка на големина в цената и разликата от пет порядъка на големина във времето за достъп между полупроводниковата памет и
въртящите се магнитни дискове са вдъхновили множество конкурентни технологии да се опитат да ги запълнят. Досега подобни
опити са остарели преди производството чрез подобрения в магнитните дискове, DRAM или и двете.
Обърнете внимание, че между 1990 г. и 2005 г. цената на гигабайт DRAM чипове отбеляза по-малко подобрение, докато цената на
диска направи драматично подобрение.
и DRAM, битовете на флаш паметта се износват - обикновено ограничени до 1 милион

записвания - и затова не са популярни в настолни и сървърни компютри.
Докато дисковете ще останат жизнеспособни в обозримо бъдеще, конвенционалният модел
със секторни писти и цилиндър не е такъв. Предположенията на модела са, че близките
блокове са на една и съща писта, блоковете в един и същи цилиндър отнемат по-малко време за
достъп, тъй като няма време за търсене и някои писти са по-близо от други.
Първо, дисковете започнаха да предлагат интелигентни интерфейси от по-високо ниво,
като ATA и SCSI, когато включиха микропроцесор в диска. За да ускорят последователните
трансфери, тези интерфейси от по-високо ниво организират дисковете повече като ленти,
отколкото като устройства с произволен достъп. Логическите блокове са подредени по
змиевиден начин през една повърхност, опитвайки се да уловят всички сектори, които са
записани с една и съща битова плътност. (Дисковете променят плътността на записа, тъй като
е трудно за електрониката да се справи с блоковете, въртящи се много по-бързо по външните
писти, а намаляването на линейната плътност опростява задачата.) Следователно
последователните блокове може да са на различни писти. Ще видим по-късно във Фигура D.22
на страница D-45 илюстрация на погрешността на приемането на конвенционалния модел на
секторна писта при работа със съвременни дискове.
Второ, малко след като микропроцесорите се появиха в дисковете, дисковете включваха

буфери за задържане на данните, докато компютърът беше готов да ги приеме, и по-късно
кешове, за да се избегнат достъпи за четене. Те бяха обединени от опашка от команди, която
позволи на диска да реши в какъв ред да изпълни командите, за да увеличи максимално
производителността, като същевременно поддържа правилното поведение. Фигура D.2 показва
как дълбочина на опашка от 50 може да удвои броя I/Os за секунда на произволни I/Os поради по-
добро планиране на достъпите. Въпреки че е малко вероятно една система наистина да има 256
команди в опашка, това ще утрои броя I/Os за секунда. Като се имат предвид буфери, кешове
и достъпи извън реда, точният модел на производителност на реален диск е много по-сложен от
цилиндъра за секторна писта.
600
Произволни 512-байтови четения за секунда

500
400
300
аO
аднуке/з
сI
200
100
0
0 50 100 150 200 250 300
Дълбочина на опашката
Фигура D.2 Пропускателна способност спрямо дълбочина на опашката с команди при използване на
произволни 512-байтови четения. Дискът извършва 170 четения в секунда, започвайки без опашка с
команди и удвоява производителността при 50 и утроява при 256 [Anderson 2003].
Накрая броят на плочите се сви от 12 в миналото до 4 или дори 1 днес,
така че цилиндърът има по-малко значение от преди, защото процентът на данните в
цилиндър е много по-малко.
Мощност на диска
Мощността е все по-голяма грижа както за дисковете, така и за процесорите. Типичен ATA
диск през 2011 г. може да използва 9 вата при неактивност, 11 вата при четене или запис и
13 вата при търсене. Тъй като е по-ефективно да се върти по-малка маса,
дисковете с по-малък диаметър могат да пестят енергия. Една формула, която показва значението на
скоростта на въртене и размера на плочите за мощността, консумирана от
дисковият двигател е следният [Gurumurthi et al. 2005]:
Мощност Диаметър4,6×RPM2,8 × Брой плочи
По този начин по-малките плочи, по-бавното въртене и по-малкото плочи помагат за намаляване на диска
мощност на двигателя и по-голямата част от мощността е в двигателя.
Фигура D.3 показва спецификациите на два 3,5-инчови диска през 2011 г. Серийният
ATA (SATA) дисковете имат висок капацитет и най-добрата цена на гигабайт, така че
2000 GB устройства струват по-малко от $0,05 на гигабайт. Те използват най-широките плочи
които отговарят на форм фактора и използват четири или пет от тях, но се въртят с 5900 RPM
и се стремят сравнително бавно, за да позволят по-висока площна плътност и да намалят мощността. The
съответното Serial Attach SCSI (SAS) устройство се стреми към производителност, така че се върти при
15 000 RPM и търси много по-бързо. Той използва по-ниска повърхностна плътност, за да се върти при това
висока оценка. За да се намали мощността, плочата е много по-тясна от форм-фактора.
Тази комбинация намалява капацитета на SAS устройството до 600 GB.
Цената на гигабайт е около пет пъти по-добра за SATA устройствата и,
обратно, цената на I/O за секунда или прехвърлен MB за секунда е около a
фактор пет по-добър за SAS дисковете. Въпреки използването на по-малки чинии и много
по-малко от тях, SAS дисковете използват два пъти повече мощност от SATA дисковете, поради
много по-бързи RPM и търсене.
анеЦ
аталП
MPR
анииД(
аовМ(
/O
/сI
еД
B
с(
уB
Бс(
уаР
бн(
TM
ч(
тетица)пBаGК(
иM
зBаM
ът
С(
е
m
кW
кW
ке
sр
са
)етвсоотнщ
ре/)ф
м)ф
к/)сB
B
р
оч
)евFоT
еоннедс)е
ее
тевм
рр
ръ)е
SATA 2000 $85 4 5900 3.7 16 12 47 45–95 300 32 0.6M

SAS 600 $400 4 15 000 2.6 3–4 16 285 122–204 750 16 1.6M
Фигура D.3 Serial ATA (SATA) срещу Serial Attach SCSI (SAS) устройства в 3,5-инчов форм фактор през 2011 г. I/Os на
вторите бяха изчислени с помощта на средното търсене плюс времето за половин ротация плюс времето за прехвърляне на едно
сектор от 512 KB.
Теми за напреднали в дисковите масиви
Иновация, която подобрява както надеждността, така и производителността на системите за съхранение,
са дисковите масиви. Един аргумент за масивите е, че потенциалната производителност може да бъде
увеличен чрез наличие на много дискови устройства и следователно много дискови рамена, а не по-малко
големи дискове. Простото разпространение на данни върху множество дискове, наречено ивици,
автоматично принуждава достъп до няколко диска, ако файловете с данни са големи. (Въпреки че масивите
подобряване на пропускателната способност, латентността не е непременно подобрена.) Както видяхме в глава 1,
недостатъкът е, че с повече устройства надеждността намалява: N устройства като цяло имат 1/N
надеждността на едно устройство.
Въпреки че един дисков масив би имал повече грешки, отколкото по-малък брой по-големи
дискове, когато всеки диск има еднаква надеждност, надеждността се подобрява чрез добавяне на
излишни дискове към масива, за да толерират грешки. Тоест, ако един диск се повреди,
изгубената информация се възстановява от излишна информация. Единствената опасност е
при повреда на друг диск по време на средното време за ремонт (MTTR). Тъй като
средното време до отказ (MTTF) на дисковете е десетки години и MTTR се измерва
в часове, резервирането може да увеличи измерената надеждност на много дискове
по-висока от тази на един диск.
Такива излишни дискови масиви са станали известни с акронима RAID,
което първоначално означаваше излишен масив от евтини дискове, въпреки че някои
предпочитам думата независим за I в акронима. Способността за възстановяване от повреди плюс по-
висока пропускателна способност, измерена като мегабайти в секунда или I/Os
в секунда, правят RAID привлекателен. Когато се комбинира с предимствата на
по-малък размер и по-ниска мощност на устройства с малък диаметър, RAID вече доминират
мащабни системи за съхранение.
Фигура D.4 обобщава петте стандартни RAID нива, показвайки как осем
дисковете с потребителски данни трябва да бъдат допълнени с излишни или контролни дискове на всеки
RAID ниво и изброява плюсовете и минусите на всяко ниво. Стандартните RAID нива
са добре документирани, така че просто ще направим бърз преглед тук и ще обсъдим
напреднали нива в по-голяма дълбочина.
RAID 0— Няма излишък и понякога се нарича JBOD, само за
куп дискове, въпреки че данните може да са разпръснати по дисковете в масива.
Това ниво обикновено се включва, за да действа като измервателна пръчка за другия RAID
нива по отношение на цена, производителност и надеждност.
RAID 1— Нарича се също отразяване или засенчване, има две копия на всяко
част от данните. Това е най-простата и най-старата схема за резервиране на дискове, но също така
има най-висока цена. Някои контролери на масиви ще оптимизират производителността на четене
като позволява на огледалните дискове да действат независимо за четене, но тази оптимизация
означава, че може да отнеме повече време за завършване на огледалните записи.
RAID 2— Тази организация е вдъхновена от прилагането на кодове за коригиране на грешки (ECC) в
стил памет към дискове. Беше включен, защото имаше такъв
продукт на дисков масив по времето на оригиналната хартия RAID, но оттогава няма
тъй като други RAID организации са по-привлекателни.

Позволява се
повреда на диска,
проверете за излишно пространство Фирмени

RAID ниво 8 диска с данни Професионалисти минуси продукти
0 Неизлишно райе 0 повреди, 0 Без място над главата Без защита Широко използван
дискове за проверка
1 Огледален 1 повреда, Без изчисляване на паритета; Най-големи разходи EMC, HP

8 контролни диска бързо възстановяване; малките за съхранение на чекове (Тандем), IBM
записи по-бързи от по-високите
RAID; бързо четене
2 ECC в стил памет 1 повреда, Не разчита на повреден диск за ~ Дневник 2 Не се използва
4 диска за проверка самодиагностика проверка на съхранение
3 Паритет с преплитане 1 грешка, 1 Ниски разходи за проверка; висока Няма поддръжка за Съхранение
на битове диск за проверка честотна лента за големи четения или малки произволни Концепции
записи четения или записи
4 Паритет с преплитане на 1 грешка, 1 Ниски разходи за проверка; повече Паритетният диск е мрежа
блокове диск за проверка честотна лента за малки четения малък проблем за запис Уред
5 Разпределен паритет 1 грешка, 1 Ниски разходи за проверка; Малки записи 4 Широко използван
с преплитане на блокове диск за проверка повече честотна лента за малки дискови достъпа
четения и записи
6 Паритет по ред- 2 повреди, 2 Предпазва от повреди на 2 Малки записи 6 мрежа
диагонал, ЧЕТНО-НЕЧЕТНО диска за проверка диска дискови достъпа; 2× Уред

проверете режийни
Фигура D.4 Нива на RAID, тяхната толерантност към грешки и тяхното натоварване в излишни дискове. Документът, който въведе
терминът RAID [Patterson, Gibson и Katz 1987] използва числена класификация, която стана популярна. Всъщност, на
нередундантният дисков масив често се нарича RAID 0, което показва, че данните са разделени на няколко диска, но без
съкращаване. Обърнете внимание, че дублирането (RAID 1) в този случай може да преживее до осем повреди на диска, при условие че има само един диск
на всяка огледална двойка е неуспешна; най-лошият случай е и двата диска в огледална двойка да се повредят. През 2011 г. може да няма комерсиални
реализации на RAID 2; останалите се намират в широка гама от продукти. RAID 0 + 1, 1 + 0, 01, 10 и 6 се обсъждат в
Текстът.
RAID 3— Тъй като дисковите интерфейси от по-високо ниво разбират изправността на a

диск, лесно е да разберете кой диск е неуспешен. Дизайнерите разбраха, че ако един
допълнителният диск съдържа паритета на информацията в дисковете с данни, единичен
диск позволява възстановяване от повреда на диска. Данните са организирани в ивици,
с N блока данни и един блок за паритет. Когато възникне повреда, ние просто „изваждаме“
добрите данни от добрите блокове и това, което остава, е липсващото
данни. (Това работи независимо дали повреденият диск е диск с данни или диск за паритет.)
RAID 3 предполага, че данните се разпространяват по всички дискове при четене и запис,
което е привлекателно при четене или писане на големи количества данни.
RAID 4— Много приложения са доминирани от малък достъп. Тъй като сектори

имат собствена проверка на грешки, можете безопасно да увеличите броя на четенията
в секунда, като позволява на всеки диск да извършва независими четения. Би било
изглежда, че записите ще бъдат бавни, ако трябва да четете всеки диск, за да изчислите
късния паритет. За да увеличите броя на записите в секунда, алтернатива
подходът включва само два диска. Първо, масивът чете старите данни, които са на път
да бъдат презаписани, и след това изчислява какви битове ще се променят, преди да
запише новите данни. След това чете старата стойност на паритета на дисковете за
проверка, актуализира паритета според списъка с промени и след това записва новата
стойност на паритета на диска за проверка. Следователно, тези така наречени „малки
записи“ все още са по-бавни от малките четения – те включват достъп до четири диска –
но са по-бързи, отколкото ако трябва да четете всички дискове при всяко записване.
RAID 4 има същото ниско ниво на проверка на диска като RAID 3 и все още може да извършва
големи четения и записи толкова бързо, колкото RAID 3 в допълнение към малки четения
и записи, но контролът е по-сложен.
RAID 5— Имайте предвид, че недостатък в производителността при малки записи в RAID

4 е, че всички те трябва да четат и записват един и същ диск за проверка, така че
това е затруднение в производителността. RAID 5 просто разпределя информацията за
паритет между всички дискове в масива, като по този начин премахва препятствията.
Блокът за паритет във всяка лента се завърта, така че паритетът да се разпредели
равномерно по всички дискове. Контролерът на дисковия масив сега трябва да изчисли
кой диск има паритет, когато иска да запише даден блок, но това може да бъде просто
изчисление. RAID 5 има същото ниско ниво на проверка на диска като RAID 3 и 4 и може да
извършва големи четения и записи на RAID 3 и малките четения на RAID 4, но има по-
висока честотна лента за малък запис от RAID 4. Въпреки това, RAID 5 изисква най-
усъвършенствания контролер от класическите RAID нива.
След като завършихме нашия бърз преглед на класическите RAID нива, вече можем
разгледайте две нива, които станаха популярни след въвеждането на RAID.
RAID 10 срещу 01 (или 1 + 0 срещу RAID 0 + 1)
Една тема, която не винаги е описана в литературата за RAID, включва как отразяването в
RAID 1 взаимодейства с стрипинга. Да предположим, че имате, да кажем, четири диска с
данни за съхранение и осем физически диска за използване. Бихте ли създали четири
чифта дискове – всеки организиран като RAID 1 – и след това да разделите данните в
четирите RAID 1 двойки? Като алтернатива, бихте ли създали два комплекта от четири
диска — всеки организиран като RAID 0 — и след това огледално записване в двата комплекта
RAID 0? Терминологията на RAID еволюира, за да нарече първия RAID 1 + 0 или RAID 10
(„огледални ивици“), а втория RAID 0 + 1 или RAID 01 („огледални ивици“).
RAID 6: Отвъд повреда на единичен диск
Схемите, базирани на паритет на RAID 1 до 5, защитават срещу единичен самоидентифициращ

се отказ; обаче, ако оператор случайно смени грешния диск по време на повреда, тогава
дисковият масив ще претърпи две повреди и данните ще бъдат загубени. Друго безпокойство
е, че тъй като честотната лента на диска нараства по-бавно от капацитета на диска, MTTR на
диск в RAID система се увеличава, което от своя страна увеличава шансовете за втори
отказ. Например, 500 GB SATA диск може да отнеме около 3 часа за последователно четене, ако
приемем, че няма смущения. Като се има предвид, че повреденият RAID вероятно ще продължи
да обслужва данни, реконструкцията би могла
да се разтегне значително, като по този начин се увеличи MTTR. Освен увеличаването на времето за
реконструкция, друго притеснение е, че четенето на много повече данни по време на реконструкция
означава увеличаване на шанса за некоригируема повреда на носителя, което би довело до загуба на
данни. Други аргументи за безпокойство относно едновременните множество повреди са нарастващият
брой дискове в масиви и използването на ATA дискове, които са по-бавни и по-големи от SCSI дисковете.
Следователно през годините има нарастващ интерес към защита срещу повече от един отказ.
Network Appliance (NetApp), например, стартира чрез изграждане на RAID 4 файлови сървъри. Тъй като
двойните повреди се превръщаха в опасност за клиентите, те създадоха по-стабилна схема за
защита на данните, наречена паритет по диагонал на ред или RAID-DP [Corbett et al. 2004]. Подобно на
стандартните RAID схеми, паритетът по диагонал на редове използва излишно пространство въз
основа на изчисление на паритет на базата на лента. Тъй като защитава срещу двоен отказ, той добавя
два блока за проверка на лента от данни. Да приемем, че има общо p + 1 диска, така че p – 1 диска имат
данни.
Фигура D.5 показва случая, когато p е 5.
Дискът за паритет на редове е точно като в RAID 4; той съдържа четния паритет в другите четири
блока данни в своята лента. Всеки блок от диска за диагонален паритет съдържа четния паритет на
блоковете в същия диагонал. Имайте предвид, че всеки диагонал не покрива един диск; например
диагонал 0 не покрива диск 1. Следователно имаме нужда само от p – 1 диагонали, за да защитим p
дисковете, така че дискът има само диагонали от 0 до 3 на Фигура D.5.
Нека да видим как работи паритетът по диагонал на редове, като приемем, че дискове с данни 1
и 3 се провалят на фигура D.5. Не можем да извършим стандартното възстановяване на RAID, като
използваме първия ред, използвайки паритет на редове, тъй като липсват два блока данни от дискове 1 и 3.
Въпреки това, можем да извършим възстановяване на диагонал 0, тъй като липсва само блокът данни,
свързан с диск 3. По този начин, паритетът по диагонал на ред започва с възстановяване на един от
четирите блока на неуспешния диск в този пример, използвайки диагонален паритет.
Тъй като всеки диагонал пропуска един диск и всички диагонали пропускат различен диск, на два
диагонала липсва само един блок. Те са диагонали 0 и 2 в този пример,
Диск с данни 0 Диск с данни 1 Диск с данни 2 Диск с данни 3 Паритет на редове Диагонален паритет
0 1 2 3 4 0
1 2 3 4 0 1
2 3 4 0 1 2
3 4 0 1 2 3
Фигура D.5 Диагонален паритет на ред за p = 5, който защитава четири диска с данни от двойни
повреди [Corbett et al. 2004]. Тази фигура показва диагоналните групи, за които паритетът се
изчислява и съхранява в диска за диагонален паритет. Въпреки че това показва всички данни за
проверка в отделни дискове за паритет на редове и диагонален паритет, както в RAID 4, има
завъртяна версия на паритет по диагонал на редове, която е аналогична на RAID 5. Параметър p
трябва да е първичен и по-голям от 2; въпреки това можете да направите p по-голямо от броя на
дисковете с данни, като приемете, че липсващите дискове имат всички нули и схемата все още
работи. Този трик улеснява добавянето на дискове към съществуваща система. NetApp избира p да
бъде 257, което позволява на системата да нарасне до 256 диска с данни.
така че следващото възстановяване на блока от диагонал 2 от повреден диск 1. Когато данните за

тези блокове са възстановени, тогава стандартната схема за възстановяване на RAID може да се
използва за възстановяване на още два блока в стандартните RAID 4 ленти 0 и 2, които в turn ни
позволява да възстановим повече диагонали. Този процес продължава, докато два повредени
диска бъдат напълно възстановени.
Схемата EVEN-ODD, разработена по-рано от изследователи в IBM, е подобна на паритета по
диагонал на ред, но има малко повече изчисления по време на работа и възстановяване [Blaum
1995]. Статии, които са по-нови, показват как да се разшири EVEN-ODD, за да се защити срещу три
грешки [Blaum, Bruck, and Vardy 1996; Blaum и др. 2001].
D.3 Дефиниция и примери за реални неизправности и повреди
Въпреки че хората може да са склонни да живеят с компютър, който от време на време се срива и
принуждава всички програми да бъдат рестартирани, те настояват информацията им никога да
не се губи. След това основната директива за съхранение е да се помни информацията, независимо
какво се случва.
Глава 1 обхваща основите на надеждността, а този раздел разширява това
информация за предоставяне на стандартни дефиниции и примери за откази.
Първата стъпка е да се изясни объркването по отношение на термините. Термините грешка,
грешка и повреда често се използват взаимозаменяемо, но имат различни значения в литературата
за надеждност. Например грешка в програмирането грешка, грешка или провал ли е? Има ли
значение дали говорим кога е проектирана или кога се изпълнява програмата? Ако изпълняваната
програма не упражнява грешката, все още ли е повреда/грешка/провал? Пробвай друг. Да
предположим, че алфа частица удари клетка от DRAM памет. Повреда/грешка/повреда ли е, ако
не променя стойността? Грешка/неизправност ли е, ако паметта няма достъп до променения бит?
Възникна ли все още повреда/грешка/повреда, ако паметта имаше корекция на грешки и достави
коригираната стойност на процесора? Получавате движението на трудностите. Ясно е, че се
нуждаем от точни определения, за да обсъждаме интелигентно подобни събития.
За да се избегне подобна неточност, този подраздел се основава на терминологията, използвана

от Laprie [1985] и Gray и Siewiorek [1991], одобрена от Работна група 10.4 на IFIP и Техническия
комитет на IEEE Computer Society относно устойчивостта на грешки. Ние говорим за система като
единичен модул, но терминологията се прилага за подмодули рекурсивно. Нека започнем с
определение за надеждност:
Надеждността на компютърната система е качеството на предоставената услуга, така че да

може оправдано да се разчита на тази услуга. Услугата , предоставена от дадена система, е
нейното наблюдавано действително поведение , както се възприема от други системи ,
взаимодействащи с потребителите на тази система. Всеки модул също има идеално определено
поведение, където спецификацията на услугата е съгласувано описание на очакваното
поведение. Системен срив възниква, когато действителното поведение се отклонява от определеното поведение.
Повредата е възникнала поради грешка, дефект в този модул. Причината за грешка е повреда.
Когато възникне грешка, тя създава латентна грешка, която става ефективна , когато се
активира; когато грешката действително засяга доставената услуга, възниква повреда.
D.3 Дефиниция и примери за реални грешки и повреди D-11
Времето между възникването на грешка и произтичащата от това повреда е

латентността на грешката. По този начин грешката е проявата на грешка в
системата , а повредата е проявата на грешка в услугата . [стр. 3]
Нека се върнем към нашите мотивиращи примери по-горе. Грешка в програмирането е грешка.
Последствието е грешка (или скрита грешка) в софтуера. При активиране грешката става ефективна.
Когато тази ефективна грешка генерира грешни данни, които засягат доставената услуга, възниква
повреда .
Алфа частица, удряща DRAM, може да се счита за повреда. Ако промени паметта, създава грешка.
Грешката ще остане латентна, докато не бъде прочетена засегнатата дума от паметта. Ако ефективната
грешка в думата засяга доставената услуга, възниква грешка. Ако ECC коригира грешката, няма да възникне
грешка.
Грешка на човешки оператор е грешка. Получените променени данни са an

грешка. Той е латентен, докато не се активира и така нататък както преди.
За да изясним, връзката между неизправностите, грешките и отказите е следната:
Грешка създава една или повече латентни грешки.
Свойствата на грешките са (1) латентната грешка става ефективна, след като бъде активирана; (2)
грешката може да се движи между нейното латентно и ефективно състояние; и (3) ефективна грешка
често се разпространява от един компонент към друг, като по този начин създава нови грешки. По този
начин или ефективната грешка е предишна латентна грешка в този компонент, или се е
разпространила от друга грешка в този компонент или от другаде.
Повреда на компонент възниква, когато грешката засяга доставената услуга. Тези свойства са
рекурсивни и се прилагат за всеки компонент в системата.
Грей и Сиевьорек класифицират грешките в четири категории според причината за тях:
1. Хардуерни грешки - устройства, които се провалят, като например поради алфа частица, удряща клетка
с памет
2. Грешки в дизайна - Грешки в софтуера (обикновено) и дизайна на хардуера (понякога)
3. Неизправности при работа — Грешки от персонала по експлоатацията и поддръжката 4.
Неизправности в околната среда — Пожар, наводнение, земетресение, прекъсване на захранването и саботаж
Неизправностите също се класифицират според тяхната продължителност на преходни, периодични и
постоянни [Nelson 1990]. Преходните повреди съществуват за ограничено време и не се повтарят.
Периодичните повреди карат системата да се колебае между неизправна и безотказна работа. Постоянните
грешки не се коригират сами с течение на времето.

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

Третичният диск на Бъркли
Проектът Tertiary Disk в Калифорнийския университет създаде художествен образ

сървър за Музеите на изящните изкуства в Сан Франциско през 2000 г. Тази база данни се състои
от висококачествени изображения на над 70 000 произведения на изкуството [Talagala et al., 2000]. The
базата данни се съхранява в клъстер, който се състои от 20 компютъра, свързани с a
комутируем Ethernet и съдържащ 368 диска. Заемаше седем стелажа с височина 7 фута.
Фигура D.6 показва процентите на отказ на различните компоненти на Tertiary Disk.
Преди да изградят системата, дизайнерите са приели, че SCSI дискове с данни
биха били най-малко надеждната част от системата, тъй като те са едновременно механични и
изобилни. Следващите щяха да бъдат IDE дисковете, тъй като имаше по-малко от тях, след това мощността
консумативи, последвани от интегрални схеми. Те предположиха, че пасивни устройства като напр
кабелите едва ли ще се повредят.
Фигура D.6 разбива някои от тези предположения. Тъй като дизайнерите последваха
Съветът на производителя да се увери, че кутиите за дискове са с намалени вибрации и добро
охлаждане, дисковете с данни бяха много надеждни. За разлика от това, шасито на компютъра,
съдържащо IDE/ATA дисковете, не позволяваше същия контрол на околната среда.
(IDE/ATA дисковете не съхраняваха данни, но помогнаха на приложението и работата
система за зареждане на компютрите.) Фигура D.6 показва, че SCSI задната платка, кабелите и
Ethernet кабелите не бяха по-надеждни от самите дискове с данни!
Тъй като Tertiary Disk беше голяма система с много излишни компоненти, тя
може да преживее този широк спектър от неуспехи. Компонентите бяха свързани и бяха поставени
огледални изображения, така че нито една повреда не можеше да направи някое изображение
недостъпно. Тази стратегия, която първоначално изглеждаше пресилена, се оказа жизненоважна.
Този опит също демонстрира разликата между преходните повреди и
тежки грешки. На практика всички откази на фигура D.6 се появяват първо като преходни
грешки. Операторът трябваше да реши дали поведението е толкова лошо, че те
трябва да бъдат заменени или ако могат да продължат. Всъщност думата „провал“ беше
не се използва; вместо това групата заимства термини, които обикновено се използват за справяне
с проблемни служители, като операторът решава дали даден проблемен компонент трябва
или не трябва да бъде „уволнен“.
Тандем
Следващият пример идва от индустрията. Грей [1990] събира данни за грешки за

Tandem Computers, която беше една от пионерските компании в устойчивостта на грешки
компютри и използвани предимно за бази данни. Фигура D.7 показва графики на грешките, които
причиниха системни повреди между 1985 и 1989 г. в абсолютни грешки на система и
в процент на откритите неизправности. Данните показват ясно подобрение в
надеждност на хардуера и поддръжка. Дисковете през 1985 г. изискваха годишно обслужване от
Тандем, но те бяха заменени с дискове, които не изискваха планирана поддръжка.
Намаляващ брой чипове и конектори на система плюс способността на софтуера да
толерира хардуерни грешки, намалява приноса на хардуера само до 7% от повреди
до 1989 г. Освен това, когато хардуерът беше повреден, софтуерът, вграден в хардуерното
устройство (фърмуер), често беше виновникът. Данните показват, че софтуерът в
D.3 Дефиниция и примери за реални грешки и повреди D-13
Процент
Компонент Общо в системата Тотално неуспешно се провали
SCSI контролер 44 1 2,3%
SCSI кабел 39 1 2,6%
SCSI диск 368 7 1,9%
IDE/ATA диск 24 6 25,0%
Корпус за диск— задна платка 46 13 28,3%
Дискова кутия — захранване 92 3 3,3%
Ethernet контролер 20 1 5,0%
Ethernet комутатор 2 1 50,0%
Ethernet кабел 42 1 2,3%
Процесор/дънна платка 20 0 0%
Фигура D.6 Откази на компоненти в третичен диск за 18 месеца работа.

За всеки тип компонент таблицата показва общия брой в системата, т
брой неуспешни и процент на неуспех. Дисковите кутии имат два входа
в таблицата, защото имаха два вида проблеми: повреди в целостта на задната платка и
повреди в захранването. Тъй като всеки корпус имаше две захранвания, захранване
повредата не повлия на наличността. Този клъстер от 20 компютъра, съдържащи се в седем стелажа с
височина 7 фута и ширина 19 инча, помещава 368 8,4 GB, 7200 RPM, 3,5-инчови IBM дискове. Компютрите
бяха P6-200 MHz с 96 MB DRAM всеки. Те пуснаха FreeBSD 3.0 и хостовете
бяха свързани чрез комутиран 100 Mbit/sec Ethernet. Всички SCSI дискове бяха свързани към
два компютъра чрез двустранни SCSI вериги за поддръжка на RAID 1. Основното приложение
се нарича Zoom Project, който през 1998 г. беше най-голямата в света база данни за художествени
изображения със 72 000 изображения. Вижте Talagala et al. [2000b].
1989 г. е основният източник на отчетени прекъсвания (62%), следван от системните операции (15%).
Проблемът с всяка такава статистика е, че данните се отнасят само за това, което е
докладвани; например неуспехите на околната среда поради прекъсване на захранването не бяха
докладваха на Тандем, защото се разглеждаха като местен проблем. Данни за операцията
грешките са много трудни за събиране, тъй като операторите трябва да докладват лични грешки, които могат
да повлияят на мнението на техните мениджъри, което от своя страна може да повлияе
сигурност на работното място и повишаване на заплатите. Грей предположи, че както екологичните грешки, така и
грешките на оператора се отчитат недостатъчно. Неговото проучване заключава, че постигането на по-високи
наличността изисква подобрение в качеството на софтуера и толерантността на софтуера към грешки, по-
прости операции и толерантност към оперативни грешки.
Други изследвания на ролята на операторите в надеждността
Докато Tertiary Disk и Tandem са проучвания за надеждност, ориентирани към съхранението, ние
трябва да погледнем извън хранилището, за да намерим по-добри измервания за ролята на хората
в провалите. Мърфи и Гент [1995] се опитаха да подобрят точността на данните
грешки на оператора, като системата автоматично подканва оператора за всяка от тях

120
неизвестен
100
Околна среда (захранване, мрежа)
Операции (по клиент)
Поддръжка (от тандем)
80 Хардуер
Софтуер (приложения + ОС)
0аГ
1
сн
60
и
иимкешт0ес0р
40
20
0
1985 г 1987 г 1989 г
100%
4% 5% 5%
6% 6%
9%
9%
80% 15%
12%
19% 5%
13%
7%
60%
29% 22%
ее
ц
инокегш
р
яит аП
р
отр к
зг
40%
62%
39%
20%
34%
0%
1985 г 1987 г 1989 г
Фигура D.7 Грешки в тандем между 1985 и 1989 г. Грей [1990] събра тези данни за
устойчиви на грешки тандемни компютри въз основа на доклади за откази на компоненти от
клиенти.
зареждане поради причината за това рестартиране. Те класифицираха последователни

сривове към една и съща грешка като грешка на оператора и включиха действия на оператора,
които директно водят до сривове, като например даване на лоши стойности на параметри,
лоши конфигурации и лоша инсталация на приложение. Въпреки че вярваха, че грешката на
оператора е недостатъчно докладвана, те получиха по-точна информация от Грей, който
разчиташе на формуляр, който операторът попълни и след това изпрати нагоре по веригата за управление. The
D.4 I/O производителност, мерки за надеждност и показатели D-15
хардуер/операционна система премина от причиняване на 70% от сривовете в VAX системите през 1985 г.
до 28% през 1993 г., а сривовете, дължащи се на операторите, се повишиха от 15% до
52% през същия период. Мърфи и Гент очакваха системите за управление да бъдат
основното предизвикателство за надеждност в бъдеще.
Окончателният набор от данни идва от правителството. Федералната комисия по комуникациите (FCC)
изисква всички телефонни компании да представят обяснения, когато претърпят прекъсване, което засяга
най-малко 30 000 души или продължава
30 минути. Тези подробни доклади за смущения не страдат от проблема със самоотчитането на по-ранни данни,
тъй като разследващите определят причината за
прекъсване, а не операторите на оборудването. Kuhn [1997] изследва причините за
прекъсвания между 1992 и 1994 г., а Enriquez [2001] направи последващо проучване за
първата половина на 2001 г. Въпреки че имаше значително подобрение на неуспехите
поради претоварване на мрежата през годините, повреди поради хора
се увеличи от около една трета на две трети от минутите за прекъсване на работата на клиента.
Тези четири примера и други предполагат, че основната причина за неуспехите в
големите системи днес са грешки от човешки оператори. Хардуерните грешки са намалели
поради намаляващия брой чипове в системите и по-малко конектори. Хардуер
надеждността се е подобрила чрез техники за устойчивост на грешки, като например памет
ECC и RAID. Поне някои операционни системи обмислят надеждността
последици преди добавянето на нови функции, така че през 2011 г. до голяма степен се случиха неуспехи
другаде.
Въпреки че повреди могат да бъдат инициирани поради грешки от страна на операторите, това е лошо
размисъл върху състоянието на техниката на системите, които процесите на поддръжка и
надграждането са толкова податливи на грешки. Повечето доставчици на хранилища твърдят днес, че клиентите
харчат много повече за управление на хранилището през целия му живот, отколкото за закупуване на
хранилището. По този начин, предизвикателството за надеждни системи за съхранение на бъдещето
е или да се толерират грешки от страна на операторите, или да се избегнат грешки чрез опростяване на задачите
на системната администрация. Имайте предвид, че RAID 6 позволява на системата за съхранение да оцелее
дори ако операторът погрешка смени добър диск.
Вече разгледахме основния въпрос за надеждността, давайки дефиниции,
казуси и техники за подобряването им. Следващата стъпка в обиколката на хранилището е представянето.
D.4 I/O производителност, мерки за надеждност и бенчмаркове
I/O производителността има мерки, които нямат аналог в дизайна. Едно от тези
е разнообразие: Кои I/O устройства могат да се свързват към компютърната система? Друг е
капацитет: Колко I/O устройства могат да се свържат към компютърна система?
В допълнение към тези уникални мерки, традиционните мерки за ефективност
(а именно време за реакция и пропускателна способност) също се прилагат за I/O. (I/O пропускателна способност е
понякога се нарича I/O честотна лента , а времето за реакция понякога се нарича латентност.)
Следващите две фигури предлагат представа за това как се търгуват времето за реакция и производителността
един срещу друг. Фигура D.8 показва простия модел производител-сървър. The
производителят създава задачи за изпълнение и ги поставя в буфер; сървърът
взема задачи от буфера "първи влязъл, първи излязъл" и ги изпълнява.

Опашка
Продуцент сървър
Фигура D.8 Традиционният модел производител-сървър на време за реакция и пропускателна

способност. Времето за реакция започва, когато дадена задача е поставена в буфера, и завършва,
когато тя бъде завършена от сървъра. Пропускателната способност е броят задачи, изпълнени от сървъра
за единица време.
Времето за реакция се дефинира като времето, необходимо на задачата от момента, в който е поставена
в буфера, докато сървърът завърши задачата. Пропускателната способност е просто средният брой задачи,
изпълнени от сървъра за период от време. За да получите възможно най-високата пропускателна способност,
сървърът никога не трябва да е неактивен, следователно буферът никога не трябва да е празен. Времето за
реакция, от друга страна, отчита времето, прекарано в буфера, така че празният буфер го свива.
Друга мярка за I/O производителност е намесата на I/O при изпълнението на процесора. Прехвърлянето на
данни може да попречи на изпълнението на друг процес.
Има и режийни разходи поради обработка на I/O прекъсвания. Нашата загриженост тук е колко време ще отнеме
един процес поради I/O за друг процес.
Пропускателна способност срещу време за реакция
Фигура D.9 показва пропускателна способност спрямо времето за отговор (или латентност) за типична I/O
система. Коляното на кривата е областта, където малко по-голяма производителност води до много по-дълго време
за реакция или, обратно, малко по-кратко време за реакция води до много по-ниска производителност.
Как архитектът балансира тези противоречиви изисквания? Ако компютърът взаимодейства с човешки
същества, Фигура D.10 предлага отговор. Едно взаимодействие или транзакция с компютър се разделя на три
части:
1. Време за въвеждане — Времето, за което потребителят трябва да въведе командата.
2. Време за реакция на системата — Времето между момента, в който потребителят въведе командата
и се показва пълният отговор.
3. Време за мислене — Времето от получаването на отговора до началото на потребителя

за да въведете следващата команда.
Сумата от тези три части се нарича време за транзакция. Няколко проучвания съобщават, че производителността
на потребителите е обратно пропорционална на времето за транзакция. Резултатите на фигура D.10 показват,
че намаляването на времето за реакция на системата с 0,7 секунди спестява 4,9 секунди (34%) от
конвенционалната транзакция и 2,0 секунди (70%) от графичната транзакция. Този неправдоподобен резултат
се обяснява с човешката природа: хората се нуждаят от по-малко време за мислене, когато им се даде по-бърз
отговор. Въпреки че това проучване е на 20 години, времето за реакция често е много по-бавно от 1 секунда,
дори ако процесорите са

300
200
)аsр
смъкек
)еиняеинец mВ
р
аз
ае з(
100
0 0% 20% 40% 60% 80% 100%
Процент от максималната пропускателна способност (честотна лента)
Фигура D.9 Пропускателна способност спрямо времето за отговор. Латентността обикновено се отчита като
време за реакция. Обърнете внимание, че минималното време за реакция достига само 11% от
пропускателната способност, докато времето за реакция за 100% пропускателна способност отнема седем
пъти повече от минималното време за реакция. Забележете също, че независимата променлива в тази
крива е имплицитна; за да проследите кривата, обикновено променяте натоварването (едновременност).
Чен и др. [1990] събира тези данни за масив от магнитни дискове.
Натовареност
Конвенционално интерактивно натоварване
(1,0 сек време за реакция на системата)
Конвенционално интерактивно натоварване –34% общо (–

(0,3 секунди време за реакция на системата) 70% мисля)
Високофункционално графично натоварване

(1,0 сек време за реакция на системата)
Високофункционално графично натоварване –70% общо (–

(0,3 сек време за реакция на системата) 81% мисля)
0 5 10 15
Време (сек)
Време на влизане Време за реакция на системата Мислете време
Фигура D.10 Потребителска транзакция с интерактивен компютър, разделена на време за влизане, време
за отговор на системата и време за мислене на потребителя за конвенционална система и графична
система. Времената за влизане са еднакви, независимо от времето за реакция на системата.
Времето за влизане беше 4 секунди за конвенционалната система и 0,25 секунди за графичната система.
Намаляването на времето за реакция всъщност намалява времето за транзакция с повече от намаляването на
времето за реакция. (От Брейди [1986].)
I/O бенчмарк Ограничение на времето за реакция Показател за пропускателна способност
TPC-C: Комплекс 90% от транзакцията трябва да Транзакции

Заявка OLTP отговаря на срока за отговор; 5 секунди с нови поръчки
за повечето видове транзакции на минута
TPC-W: Транзакционен 90% от уеб взаимодействията трябва да отговарят Уеб взаимодействия

Уеб бенчмарк на ограничението за време за отговор; 3 секунди в секунда
за повечето видове уеб взаимодействия
SPECsfs97 Средно време за реакция 40 ms NFS операции в

секунда
Фигура D.11 Ограничения на времето за реакция за три I/O бенчмарка.
1000 пъти по-бързо. Примери за дълги закъснения включват стартиране на приложение на настолен
компютър поради много дискови I/O или мрежови закъснения при кликване върху уеб връзки.
За да отразят значението на времето за реакция за производителността на потребителите, I/O
бенчмарковете също разглеждат компромиса между времето за реакция и пропускателната способност. Фигура D.11
показва границите на времето за реакция за три I/O бенчмарка. Отчитат максимум

пропускателна способност, като се има предвид, че или 90% от времената за отговор трябва да са по-малки от ограничение, или
че средното време за реакция трябва да бъде по-малко от ограничение.

Нека след това разгледаме тези показатели по-подробно.
Бенчмаркове за обработка на транзакции
Обработката на транзакции (TP или OLTP за онлайн обработка на транзакции) е главно

се отнася до I/O скоростта (броя достъпи до диска в секунда), за разлика от
скорост на данни (измерена като байтове данни в секунда). TP обикновено включва промени
до голямо количество споделена информация от много терминали, с TP системата
гарантиране на правилно поведение при повреда. Да предположим например, че една банка
компютърът се повреди, когато клиент се опита да изтегли пари от банкомат. TP
системата ще гарантира, че сметката е дебитирана, ако клиентът получи
пари и че сметката е непроменена, ако парите не са получени. авиокомпания
системите за резервации, както и банките са традиционни клиенти за TP.
Както бе споменато в Глава 1, две дузини членове на TP общността заговорничат, за да формират
еталон за индустрията и да избегнат гнева на своите правни
отдели, публикува доклада анонимно [Anon. et al. 1985]. Този доклад
доведе до Съвета за обработка на транзакции, който от своя страна доведе до осем референтни
показателя от основаването му. Фигура D.12 обобщава тези показатели.
Нека опишем TPC-C, за да дадем представа за тези показатели. TPC-C използва a
база данни за симулиране на среда за въвеждане на поръчки на доставчик на едро,
включително въвеждане и доставка на поръчки, записване на плащания, проверка на състоянието на
поръчките и наблюдение на нивото на наличност в складовете. Работи пет
едновременни транзакции с различна сложност, а базата данни включва девет
таблици с мащабируем диапазон от записи и клиенти. TPC-C се измерва в
транзакции на минута (tpmC) и в цената на системата, включително хардуер,
D.4 I/O производителност, мерки за надеждност и показатели D-19
Бенчмарк Размер на данните (GB) Показател за ефективност Дата на първите резултати
A: дебитен кредит (пенсиониран) 0,1–10 Транзакции в секунда Юли 1990 г
B: партиден дебитен кредит (пенсиониран) 0,1–10 Транзакции в секунда Юли 1991 г
C: сложна заявка OLTP 100–3000 Транзакции за нови септември 1992 г

(минимум 0,07 * TPM) поръчки на минута (TPM)
D: подкрепа за вземане на решения (пенсиониран) 100, 300, 1000 100, Запитвания на час декември 1995 г
H: ad hoc подкрепа за вземане на решения 300, 1000 Запитвания на час октомври 1999 г
R: подкрепа за вземане на решения за 1000 Запитвания на час август 1999 г

бизнес отчети (пенсиониран)
W: транзакционен уеб бенчмарк 50, 500 Уеб взаимодействия за секунда юли 2000 г
Приложение: бенчмарк за сървър на 2500 Взаимодействия на уеб юни 2005 г

приложения и уеб услуги услуги за секунда (SIPS)
Фигура D.12 Бенчмаркове на Съвета за обработка на транзакции. Обобщените резултати включват както представянето
показател и съотношението цена-производителност на този показател. TPC-A, TPC-B, TPC-D и TPC-R бяха оттеглени.
софтуер и тригодишна поддръжка за поддръжка. Фигура 1.16 на страница 39 in

Глава 1 описва най-добрите системи по производителност и цена-производителност за
TPC-C.
Тези TPC бенчмаркове бяха първите — и в някои случаи все още единствените
които имат тези необичайни характеристики:
Цената е включена в резултатите от бенчмарка. Цената на хардуер, софтуер,
и споразуменията за поддръжка са включени в подаването, което позволява оценки въз основа на

цена-производителност, както и висока производителност.
Наборът от данни обикновено трябва да се мащабира с увеличаване на пропускателната способност. The
бенчмарковете се опитват да моделират реални системи, в които търсенето на

системата и размерът на съхраняваните в нея данни нарастват заедно. Това прави не
смисъл, например, да има хиляди хора на минута достъп до стотици
на банкови сметки.
Резултатите от бенчмарка се одитират. Преди да могат да бъдат изпратени резултатите, те

трябва да бъдат одобрени от сертифициран TPC одитор, който прилага правилата на TPC, които
опитайте се да се уверите, че се изпращат само справедливи резултати. Резултатите могат да
бъдат оспорени и споровете разрешени, като се обърнете към TPC.
Пропускателната способност е показателят за производителност, но времето за реакция е ограничено. За
например, с TPC-C, 90% от времето за отговор на транзакция на нова поръчка трябва

бъде по-малко от 5 секунди.
Независима организация поддържа бенчмарковете. Такси, събрани от

TPC плаща за административна структура, включително главен оперативен офис.
Тази организация урежда спорове, провежда гласуване по пощата при одобрение на
промени в бенчмаркове, провежда срещи на борда и т.н.
Файлов сървър, поща и уеб тестове на системно ниво на SPEC
Усилието за сравнителен анализ на SPEC е най-известно с характеризирането на производителността

на процесора, но то създаде сравнителни показатели за файлови сървъри, сървъри за електронна поща
и уеб сървъри.
Седем компании се споразумяха за синтетичен бенчмарк, наречен SFS, за оценка на системи,

работещи с мрежовата файлова услуга (NFS) на Sun Microsystems. Този бенчмарк беше надстроен до SFS
3.0 (наричан още SPEC SFS97_R1), за да включва поддръжка за NFS версия 3, като използва TCP в допълнение
към UDP като транспортен протокол и прави комбинацията от операции по-реалистична. Измерванията
на NFS системи доведоха до синтетичен микс от четене, запис и файлови операции. SFS предоставя
параметри по подразбиране за сравнителна производителност. Например, половината от всички
записи се извършват в блокове от 8 KB, а половината се извършват в частични блокове от 1, 2 или 4
KB. За четения миксът е 85% пълни блокове и 15% частични блокове.
Подобно на TPC-C, SFS мащабира количеството съхранявани данни според отчетената производителност:
За всеки 100 NFS операции в секунда капацитетът трябва да се увеличи с 1 GB. Той също така
ограничава средното време за реакция, в този случай до 40 ms. Фигура D.13 показва средното време
за отговор спрямо пропускателната способност за две NetApp системи.
За съжаление, за разлика от TPC бенчмарковете, SFS не се нормализира за различни ценови
конфигурации.
SPECMail е еталон, който помага да се оцени производителността на пощенските сървъри при
доставчик на интернет услуги. SPECMail2001 е базиран на стандартните интернет протоколи SMTP и
POP3 и измерва пропускателната способност и времето за реакция на потребителя, като същевременно

мащабира броя на потребителите от 10 000 до 1 000 000.
7
34,089 47,927
6
2 Xeon 4 Xeon
5
136,048
4
m
е
яиецмке)аsраВ
р
з(
FAS3000 8 оптерона
3
FAS6000
100,295
2
4 оптерона
1
0
0 25 000 50 000 75 000 100 000 125 000 150 000
Операции/секунда
Фигура D.13 Производителност на SPEC SFS97_R1 за NetApp FAS3050c NFS сървъри в две
конфигурации. Два процесора достигнаха 34 089 операции в секунда, а четири
процесора направиха 47 927. Докладвани през май 2005 г., тези системи използват
операционната система Data ONTAP 7.0.1R1, 2,8 GHz Pentium Xeon микропроцесори, 2 GB
DRAM на процесор, 1 GB енергонезависима памет на система и 168 15K RPM, 72 GB, Fibre
Channel дискове. Тези дискове бяха свързани с помощта на два или четири дискови
контролера QLogic ISP-2322 FC.
SPECWeb е еталон за оценка на производителността на World Wide Web

сървъри, измерващи броя на едновременните потребителски сесии. SPECWeb2005
работното натоварване симулира достъп до доставчик на уеб услуги, където сървърът поддържа
начални страници за няколко организации. Има три натоварвания: Банкиране (HTTPS),
Електронна търговия (HTTP и HTTPS) и поддръжка (HTTP).
Примери за критерии за надеждност

Бенчмаркът TPC-C всъщност има изискване за надеждност. Бенчмаркираната система трябва да може
да се справи с повреда на един диск, което на практика означава
че всички податели изпълняват някаква RAID организация в своята система за съхранение.
Усилията, които са по-скорошни, са фокусирани върху ефективността на устойчивостта на
грешки в системите. Браун и Патерсън [2000] предлагат наличността да се измерва чрез

изследване на вариациите в показателите за качество на услугата на системата във времето
тъй като грешките се инжектират в системата. За уеб сървър очевидните показатели са
производителност (измерена като удовлетворени заявки за секунда) и степен на устойчивост на
грешки (измерена като брой грешки, които могат да бъдат толерирани от подсистемата за
съхранение, топологията на мрежовата връзка и т.н.).
Първоначалният експеримент инжектира единична повреда – като грешка при запис на диск
сектор––и записа поведението на системата, отразено в качеството на услугата
метрика. Примерът сравнява софтуерни RAID реализации, предоставени от
Linux, Solaris и Windows 2000 Server. SPECWeb99 беше използван за предоставяне на a
работно натоварване и за измерване на ефективността. За да инжектирате грешки, един от SCSI дисковете в
софтуерният RAID том беше заменен с емулиран диск. Това беше компютърен софтуер, работещ с
помощта на SCSI контролер, който се показва на други устройства на SCSI
шина като диск. Дисковият емулатор позволи инжектирането на грешки. Грешките
инжектираните включваха различни преходни грешки на диска, като например поправими грешки при четене,
и постоянни грешки, като повреди на дискови носители при запис.

Фигура D.14 показва поведението на всяка система при различни повреди. The
две горни графики показват Linux (вляво) и Solaris (вдясно). Тъй като RAID системите могат да
загубят данни, ако втори диск се повреди преди възстановяването да завърши, колкото по-дълго е
възстановяването (MTTR), толкова по-ниска е наличността. По-бърза реконструкция
предполага обаче намалена производителност на приложението, тъй като реконструкцията краде I/O
ресурси от работещи приложения. По този начин има избор на политика между поемане на удар на
производителността по време на реконструкция или удължаване на прозореца на уязвимостта и по
този начин намаляване на прогнозирания MTTF.
Въпреки че никоя от тестваните системи не документира своите политики за реконструкция
извън изходния код дори едно инжектиране на грешка успя да даде представа
в тези политики. Експериментите разкриха, че и Linux, и Solaris започват
автоматично преустройство на RAID тома върху горещ резерв, когато е активен
дискът е изваден от експлоатация поради повреда. Въпреки че Windows поддържа RAID
реконструкция, реконструкцията трябва да се стартира ръчно. По този начин, без
човешка намеса, Windows система, която не се възстанови след първия отказ
остава податлив на втори отказ, което увеличава прозореца на уязвимост. Поправя се бързо, след
като му бъде казано да го направи.
Linux Соларис
225 160
150
220
140
215 Реконструкция
130
210
Хвс
Хвс
ке
ке
уи
уи
донт
донт
еав
еав
120
Реконструкция
205
110
200
100
195 90
190 80
0 10 20 30 40 50 60 70 80 90 100 110 0 10 20 30 40 50 60 70 80 90 100 110
Време (минути) Време (минути)
Windows
200
190
180
уи
донт
еав Х
кевс
Реконструкция
170
160
150
0 5 10 15 20 25 30 35 40 45
Време (минути)
Фигура D.14 Еталонен показател за наличност за софтуерни RAID системи на същия компютър, работещ с Red Hat 6.0
Операционни системи Linux, Solaris 7 и Windows 2000. Обърнете внимание на разликата във философията относно скоростта на реконструкция на
Linux спрямо Windows и Solaris. Оста Y е поведението в посещения в секунда при изпълнение на SPECWeb99. Стрелата
показва времето на въвеждане на грешката. Редовете в горната част дават 99% доверителен интервал на производителност преди грешката
се вмъква. 99% доверителен интервал означава, че ако променливата е извън този диапазон, вероятността е само 1%
че тази стойност ще се появи.
Експериментите с инжектиране на грешки също предоставиха представа за друга наличност
политиките на Linux, Solaris и Windows 2000 относно автоматичното резервно използване, скоростите на
възстановяване, преходните грешки и т.н. Отново никоя система не документира техните политики.
По отношение на управлението на преходни повреди, експериментите с инжектиране на грешки разкриха
че внедряването на софтуерен RAID на Linux използва противоположен подход

D.5 Малка теория на опашките D-23
внедряването на RAID в Solaris и Windows. Внедряването на Linux е параноично – по-скоро ще изключи

диска по контролиран начин при първата грешка, вместо да чака да види дали грешката е
преходна. За разлика от тях, Solaris и Win-dows са по-прощаващи – те игнорират повечето
преходни грешки с очакването, че няма да се появят отново. По този начин тези системи са
значително по-устойчиви на преходни процеси от системата Linux. Обърнете внимание, че както
Windows, така и Solaris регистрират преходните грешки, като гарантират, че грешките се
докладват, дори ако не бъдат предприети действия. Когато грешките бяха постоянни, системите
се държаха по подобен начин.
D.5 Малка теория на опашките
При проектирането на процесори имаме прости изчисления на производителността, свързани с

CPI формулата в глава 1, или можем да използваме пълномащабна симулация за по-голяма точност
на по-висока цена. В I/O системите имаме и анализ на най-добрия случай като изчисление на
обратната страна на плика. Пълномащабната симулация също е много по-точна и има много повече
работа за изчисляване на очакваната производителност.
С I/O системите обаче разполагаме и с математически инструмент за насочване на I/O
дизайна, който е малко повече работа и много по-точен от анализа на най-добрия случай, но много по-
малко работа от пълномащабната симулация. Поради вероятностния характер на I/O събитията и
поради споделянето на I/O ресурси, можем да дадем набор от прости теореми, които ще помогнат за
изчисляване на времето за реакция и пропускателната способност на цяла I/O система. Тази
полезна област се нарича теория на опашките. Тъй като има много книги и курсове по темата, този
раздел служи само като първо въведение в темата. Въпреки това, дори тази малка сума може да
доведе до по-добър дизайн на I/O системи.
Нека започнем с подхода на черната кутия към I/O системите, както е показано на фигура D.15.
В нашия пример процесорът прави I/O заявки, които пристигат на I/O устройството, и заявките
„отпътуват“, когато I/O устройството ги изпълни.
Обикновено се интересуваме от дългосрочното или стабилно състояние на системата, а не от
първоначалните условия за стартиране. Да предположим, че не сме били. Въпреки че има
математика, която помага (вериги на Марков), с изключение на няколко случая, единственият начин
за решаване на получените уравнения е симулацията. Тъй като целта на този раздел е да покаже
нещо малко по-трудно от изчисленията на гърба на плика, но по-малко
Пристигания Заминавания
Фигура D.15 Третиране на I/O системата като черна кутия. Това води до просто, но важно
наблюдение: ако системата е в стабилно състояние, тогава броят на задачите, влизащи в системата,
трябва да е равен на броя на задачите, които напускат системата. Това състояние на балансиран
поток е необходимо, но не достатъчно за стабилно състояние. Ако системата е била наблюдавана или
измервана достатъчно дълго време и средното време на изчакване се стабилизира, тогава
казваме, че системата е достигнала стабилно състояние.
отколкото симулация, ние няма да обхващаме такива анализи тук. (Вижте препратките в
Приложение L за повече подробности.)
Следователно в този раздел правим опростяващото предположение, че оценяваме системи с множество
независими заявки за I/O услуга, които са в равновесие: Скоростта на въвеждане трябва да е равна на скоростта
на изхода. Предполагаме също, че има a
стабилно снабдяване със задачи, независимо колко дълго чакат за обслужване. В много
реални системи, като TPC-C, скоростта на потребление на задача се определя от други
характеристики на системата, като капацитет на паметта.
Това ни води до закона на Литъл, който свързва средния брой задачи в
система, средната скорост на пристигане на нови задачи и средното време за изпълнение на a

задача:
=
Среден брой задачи в системата Скорост на пристигане Средно× време за отговор
Законът на Литъл се прилага за всяка система в равновесие, стига да няма нищо вътре
черната кутия създава нови задачи или ги унищожава. Имайте предвид, че процентът на пристигане и
времето за отговор трябва да използва същата единица време; несъответствието във времевите единици е a
често срещана причина за грешки.
Нека се опитаме да изведем закона на Литъл. Да приемем, че наблюдаваме система за Timeobserve
минути. По време на това наблюдение записваме колко време е отнело всяка задача
обслужени и след това сумирайте тези времена. Броят задачи, изпълнени през
Timeobserve е Numbertask, а сумата от времето, прекарано от всяка задача в системата, е Timeaccumulated.
Имайте предвид, че задачите могат да се припокриват във времето, така че Timeaccumulated
Наблюдавано време. Тогава,
Натрупано време
= ------------------------------------
Среден брой задачи в системата
Наблюдавайте времето
Натрупано време
= ------------------------------------
Средно време за реакция
Числови задачи
Степен на пристигане = ----------------------------
Наблюдавайте времето
Алгебрата ни позволява да разделим първата формула:
Натрупано време Натрупано време

------------------------------------ = ------------------------------------ ----------------------------
Наблюдавайте времето Наблюдавайте времето
Ако заместим трите дефиниции по-горе в тази формула и разменим получените два термина от дясната страна,
получаваме закона на Литъл:
=
Среден брой задачи в системата Скорост на пристигане Средно× време за отговор
Това просто уравнение е изненадващо силно, както ще видим.
Ако отворим черната кутия, виждаме фигура D.16. Областта, в която се натрупват задачите, чакащи да
бъдат обслужени, се нарича опашка или чакаща линия. Устройството
извършването на заявената услуга се нарича сървър. Докато стигнем до последните две
страници от този раздел, ние приемаме един сървър.

Опашка сървър
Пристигания I/O контролер

и устройство
Фигура D.16 Моделът с един сървър за този раздел. В тази ситуация I/O заявка
„тръгва“, като се изпълнява от сървъра.
Законът на Литъл и поредица от определения водят до няколко полезни уравнения:
Timeserver— Средно време за обслужване на задача; средната скорост на обслужване е 1/Timeserver,

традиционно представена със символа µ в много текстове за опашка.
Timequeue— Средно време за задача в опашката. Timesystem
— Средно време/задача в системата или времето за отговор, което е сумата от Timequeue и

Timeserver. Степен на пристигане— Среден
брой пристигащи задачи/секунда, традиционно представлява

изпратен от символа λ в много текстове за опашка.
Lengthserver— среден брой задачи в услуга. Lengthqueue— Средна
дължина на опашката. Lengthsystem— среден брой
задачи в системата, който е сумата от

Lengthqueue и Lengthserver.
Едно често срещано недоразумение може да бъде изяснено чрез тези дефиниции: дали въпросът е
колко време задачата трябва да изчака в опашката, преди да стартира услугата (Timequeue) или
колко време отнема задачата, докато бъде завършена (Timesystem). Последният термин е това, което
имаме предвид под време за реакция, а връзката между термините е Timesystem = Timequeue +
Timeserver.
Средният брой задачи в услуга (Lengthserver) е просто процент на пристигане × Timeserver, което
е законът на Little. Използването на сървъра е просто средният брой обслужвани задачи, разделен на
скоростта на обслужване. За единичен сървър цената на услугата е 1 ⁄ Timeserver. Следователно
използването на сървъра (и в този случай средният брой задачи на сървър) е просто:
Използване на сървъра = ×
Процент на пристигане Timeserver
Използването на услугата трябва да бъде между 0 и 1; в противен случай биха пристигнали повече
задачи, отколкото биха могли да бъдат обслужени, което нарушава нашето предположение, че
системата е в равновесие. Обърнете внимание, че тази формула е просто повторение на закона на
Литъл. Използването се нарича още интензивност на трафика и се представя със символа ρ в много
текстове на теорията на опашките.
Пример Да предположим, че I/O система с един диск получава средно 50 I/O заявки за секунда. Да приемем, че средното време
за диск за обслужване на I/O заявка е 10 ms. Какво
е използването на I/O системата?
Отговор Използвайки уравнението по-горе, с 10 ms, представени като 0,01 секунди, получаваме:
50
= == ------- 0,01 сек × 0,50
Използване на сървъра Степен на пристигане Timeserver ×
сек
Следователно използването на I/O системата е 0,5.
Как опашката доставя задачи на сървъра се нарича дисциплина на опашката. The
най-простата и най-разпространена дисциплина е първи влязъл, първи излязъл (FIFO). Ако приемем
FIFO, можем да свържем времето на чакане в опашката със средния брой задачи в
опашка:
Timequeue = Lengthqueue × Timeserver + Средно време за завършване на обслужването на задачата, когато

пристига нова задача, ако сървърът е зает
Тоест, времето в опашката е броят на задачите в опашката, умножен по средната стойност
време за обслужване плюс времето, необходимо на сървъра да изпълни каквато и да е задача
обслужва се, когато пристигне нова задача. (Има още едно ограничение за пристигането
от задачи, които разкриваме на страница D-28.)
Последният компонент на уравнението не е толкова прост, колкото изглежда на пръв поглед. Нов
задачата може да пристигне във всеки един момент, така че нямаме основание да знаем колко дълго съществува
задача е била в сървъра. Въпреки че такива заявки са случайни събития, ако ние
знаем нещо за разпределението на събитията, можем да предвидим ефективността.
Поасоново разпределение на случайни променливи
За да оценим последния компонент на формулата, трябва да знаем малко за разпределенията на случайни
променливи. Една променлива е произволна, ако приема една от определен набор
на стойности с определена вероятност; това означава, че не можете да знаете точно какво следва
стойност ще бъде, но може да знаете вероятността за всички възможни стойности.
Заявките за услуга от I/O система могат да бъдат моделирани чрез произволна променлива, тъй като
операционната система обикновено превключва между няколко процеса, които генерират независими I/O
заявки. Ние също моделираме I/O сервизни времена
чрез случайна променлива предвид вероятностния характер на дисковете по отношение на търсене и
ротационни закъснения.
Един от начините за характеризиране на разпределението на стойностите на случайна променлива с
дискретни стойности е хистограма, която разделя диапазона между минималните и
максимални стойности в поддиапазони, наречени кофи. След това хистограмите изобразяват числото
във всяка кофа като колони.
Хистограмите работят добре за разпределения, които са дискретни стойности - например
броя I/O заявки. За разпределения, които не са дискретни стойности, като напр

време на изчакване на I/O заявка, имаме два избора. Или имаме нужда от крива, за да
начертайте стойностите в целия диапазон, така че да можем да оценим точно стойността, или
имаме нужда от много фина времева единица, така че да получим много голям брой кофи
преценете точно времето. Например, хистограма може да бъде изградена от дискова услуга
времена, измерени на интервали от 10 μs, въпреки че времената за обслужване на диска са наистина непрекъснати
uous.
Следователно, за да можем да решим последната част от предишното уравнение, трябва да го направим

характеризира разпределението на тази случайна променлива. Средното време и някои
мярката на дисперсията е достатъчна за тази характеристика.
За първия член използваме претегленото средно аритметично време. Нека първо
приемете, че след измерване на броя на срещанията, да речем ni , на задачи, вие
може да изчисли честотата на възникване на задача i:
ni
-------------------
н
f =
аз
ni
i =1
Тогава среднопретеглената аритметична е
Среднопретеглено аритметично време = f1 × T1 + f2 × T2 + . . . + fn × Tn
където Ti е времето за задача i , а fi е честотата на поява на задача i.
За да характеризират променливостта относно средната стойност, много хора използват стандарта
отклонение. Нека вместо това използваме дисперсията , която е просто квадратът на стандартното отклонение,
тъй като ще ни помогне да характеризираме вероятностното разпределение.
Като се има предвид среднопретеглената аритметична дисперсия може да се изчисли като
2
Дисперсия= f ( 1 ×Т1 + f++ × 2 … е n Tn
2 –
)
2 Т2 Среднопретеглено аритметично време2
Важно е да запомните единиците, когато изчислявате дисперсията. Да приемем,
разпределението е на времето. Ако времето е около 100 милисекунди, тогава повдигането му на квадрат дава
10 000 квадратни милисекунди. Това устройство определено е необичайно. Би било по-удобно, ако имахме
безединична мярка.
За да избегнем този проблем с единиците, ние използваме квадратния коефициент на дисперсия,
традиционно наричан C2 :
Дисперсия
C2 = -------------------------------------------------- ----------------------------
Среднопретеглено аритметично време2
Можем да намерим C, коефициента на дисперсия, като
Дисперсия Стандартно отклонение

°С = -------------------------------------------------- ------------------------ = -------------------------------------------------- --------------------------
Среднопретеглено аритметично време Среднопретеглено аритметично време
Опитваме се да характеризираме случайни събития, но за да можем да предвидим ефективността, се

нуждаем от разпределение на случайни събития, където математиката е проследима. Най-популярното такова
разпределение е експоненциалното разпределение, което има

стойност на C от 1.
Обърнете внимание, че използваме константа, за да характеризираме променливостта относно средната стойност.
Инвариантността на C във времето отразява свойството, което има историята на събитията
няма влияние върху вероятността събитие да се случи сега. Това забравено свойство е
наречен без памет и това свойство е важно предположение, използвано за прогнозиране
поведение при използване на тези модели. (Да предположим, че това свойство без памет не съществува;
тогава ще трябва да се тревожим за точните часове на пристигане на заявките спрямо
взаимно, което би направило математиката значително по-малко податлива!)
Едно от най-широко използваните експоненциални разпределения се нарича разпределение на

Поасон, кръстено на математика Симеон Поасон. Използва се за характеризиране на случайни събития в
даден интервал от време и има няколко желани математически
Имоти. Разпределението на Поасон се описва със следното уравнение
(наречена функция на вероятностната маса):
–a к
e × а
= ------------------
Вероятност( ) k
к!
където a = процент на събития × изминало време. Ако времето между пристиганията е експоненциално
разпределени и използваме скоростта на пристигане от по-горе за скоростта на събитията, броя на
пристигания във времеви интервал t е процес на Поасон, който има разпределение на Поасон
с a = процент на пристигане × t. Както бе споменато на страница D-26, уравнението за Timeserver

има друго ограничение за пристигане на задачата: важи само за процеси на Поасон.
И накрая, можем да отговорим на въпроса за продължителността на времето, необходимо за нова задача
изчакайте сървърът да изпълни задача, наречена средно остатъчно време за обслужване,
което отново предполага пристигане на Поасон:
= ⁄1 ×2 Средно аритметично×1( C2 ) +
Средно остатъчно работно време
Въпреки че няма да изведем тази формула, можем да се позоваваме на интуицията. Когато
разпределението не е произволно и всички възможни стойности са равни на средната, стандартното
отклонение е 0 и следователно C е 0. Средното остатъчно време за обслужване тогава е просто
половината от средното време за обслужване, както бихме очаквали. Ако разпределението е случайно
и е Поасон, тогава C е 1 и средното остатъчно време на работа е равно на
среднопретеглено аритметично време.
Пример Използвайки дефинициите и формулите по-горе, изведете средното време на изчакване в
опашка (Timequeue) по отношение на средното време за обслужване (Timeserver) и сървъра

използване.
Отговор Всички задачи в опашката (Lengthqueue) преди новата задача трябва да бъдат изпълнени
преди задачата да може да бъде обслужена; всеки отнема среден Timeserver. Ако една задача е при
сървъра, отнема средно остатъчно време за обслужване, за да завърши. Шансът на
сървърът е зает е използване на сървъра; следователно очакваното време за обслужване е сървър
използване × Средно остатъчно време за обслужване. Това води до нашата първоначална формула:
=
Timequeue Lengthqueue ×
Timeserver
+ Използване на сървъра×Средно остатъчно време за обслужване

Замяна на средното остатъчно време за обслужване с неговата дефиниция и Lengthqueue с
Степен на пристигане × Добив на Timequeue
= ⁄× × ( 1 C2
)+ ]
Използване на Timequeue Server × [ ( 1 2 Сървър за време
×
+ Степен на пристигане Timequeue ) Времеви сървър ×
Тъй като този раздел се занимава с експоненциални разпределения, C2 е 1. Така
= + ( × × Времеви сървър
Timequeue Използване на сървър Timeserver × Процент на пристигане Timequeue )
Пренареждайки последния член, нека заменим Скорост на пристигане × Сървър за време с използване на
сървъра:
= ×
+ × ( Скорост на пристигане Timeserver )
Времева опашка
Timequeue Използване на сървър Timeserver ×
= + ×
Използване на сървъра Timeserver × Времева опашка за използване на сървъра
Пренареждането на термините и опростяването ни дава желаното уравнение:
= + ×
Timequeue Използване на сървър Timeserver × Времева опашка за използване на сървъра
–
Timequeue Използване ×
на сървъра Timequeue = Време за използване на× сървърасървър
–
1 Използване на сървъра ) = Използване на сървър
× Timeserver
Timequeue × (
Използване на сървъра
=
Timequeue Timeserver × -------------------------------------------------- -----
–
( 1 Използване на сървъра )
Законът на Литъл може да се приложи и към компонентите на черната кутия, тъй като
те също трябва да са в равновесие:
= ×
Lengthqueue Скорост на пристигане Timequeue
Ако заместим Timequeue от по-горе, получаваме:
= × × -------------------------------------------------- -----
Lengthqueue Скорост на пристигане Timeserver –
Тъй като процент на пристигане × сървър за време = използване на сървъра, можем да опростим допълнително:
Използване на сървъра Използване на сървъра2

= × -------------------------------------------------- ----- = -------------------------------------------------- -----
Lengthqueue Използване на сървъра –
–
Това свързва броя на елементите в опашката с използването на услугата.
Пример За системата в примера на страница D-26, която има сървърно използване от 0,5,
какъв е средният брой I/O заявки в опашката?
Отговор Използвайки горното уравнение,
Използване на сървъра2 0,52 0,25

= -------------------------------------------------- ---- = == --------------------
---------- 0,5
–
Дължина на опашка
( 1 Използване на сървъра ) ( 1 0,5 – ) 0,50
Следователно в опашката има средно 0,5 заявки.

Както бе споменато по-рано, тези уравнения и този раздел се основават на област от приложната
математика, наречена теория на опашките, която предлага уравнения за прогнозиране на поведението
на такива случайни променливи. Реалните системи са твърде сложни, за да може теорията на
опашките да осигури точен анализ, следователно теорията на опашките работи най-добре, когато са
необходими само приблизителни отговори.
Теорията на опашките прави рязко разграничение между минали събития, които могат да бъдат
характеризирани чрез измервания с помощта на проста аритметика, и бъдещи събития, които са
прогнози, изискващи по-сложна математика. В компютърните системи ние обикновено предсказваме
бъдещето от миналото; един пример е най-скоро използваното заместване на блокове (вижте Глава
2). Следователно разликата между измерванията и прогнозираните разпределения често е
замъглена; ние използваме измервания, за да проверим вида на разпределението и след това
разчитаме на разпределението след това.
Нека прегледаме предположенията относно модела на опашка:
Системата е в равновесие.
Времената между две последователни пристигащи заявки, наречени времена между пристигане, са
експоненциално разпределени, което характеризира честотата на пристигане, спомената по-
рано.
Броят на източниците на заявки е неограничен. (Това се нарича модел на безкрайна популация в

теорията на опашките; моделите с ограничена популация се използват, когато нивата на
пристигане варират в зависимост от броя на заданията, които вече са в
системата.) Сървърът може да започне следващото задание веднага след завършване на
предишното. Няма ограничение за дължината на опашката и тя следва първи влязъл, пръв излязъл
дисциплина на реда, така че всички задачи в реда трябва да бъдат изпълнени.
Има един сървър.
Такава опашка се нарича M/M/1:
M = експоненциално произволно пристигане на заявка (C2 = 1), като M означава AA

Марков, математикът, който дефинира и анализира процесите без памет, споменати по-
рано M = експоненциално произволно
време за обслужване (C2 = 1), с M отново за Марков 1 = единичен сървър
Моделът M/M/1 е опростен и широко използван модел.

Предположението за експоненциално разпределение обикновено се използва в примери за
опашка по три причини – една добра, една справедлива и една лоша. Добрата причина е, че
суперпозицията на много произволни разпределения действа като експоненциално разпределение.
Много пъти в компютърните системи определено поведение е резултат от взаимодействие на много
компоненти, така че експоненциалното разпределение на времената между пристигане е правилният
модел. Справедливата причина е, че когато променливостта е неясна, експоненциалното
разпределение с междинна променливост (C = 1) е по-сигурно предположение от ниската променливост
(C 0) или високата променливост (голяма C). Лошата причина е, че математиката е по-проста, ако
приемете експоненциални разпределения.
Нека приложим теорията на опашките в няколко примера.
Пример Да предположим, че процесорът изпраща 40 I/O диска в секунда, тези заявки са експоненциално разпределени
и средното време за обслужване на по-стар диск е 20 ms. Отговор
следните въпроси:
1. Средно колко е използван дискът?
2. Какво е средното време, прекарано на опашка?
3. Какво е средното време за отговор на заявка за диск, включително опашката

време и време за обслужване на диска?
Отговор Нека повторим тези факти:
Средният брой пристигащи задачи/секунда е 40.
Средното дисково време за обслужване на задача е 20 ms (0,02 сек).
След това използването на сървъра е
= == ×
Използване на сървъра Скорост на пристигане Времеви сървър
40 0,02 × 0,8
Тъй като времето за обслужване е експоненциално разпределено, можем да използваме опростеното
формула за средното време, прекарано в чакане на опашка:

Timequeue=Timeserver × --------------------------------------------------
–
------
0,8 0,8
= 20 ms × ----------------= 20
== × ------- 20 4 × 1 0,8 – 80 ms
0,2
Средното време за реакция е
Времева система Timequeue = Timeserver + 80 20 ms 100 ms =+=
Така прекарваме средно 80% от времето си в чакане на опашката!
Пример Да предположим, че получаваме нов, по-бърз диск. Преизчислете отговорите на въпросите
по-горе, като приемем, че времето за обслужване на диска е 10 ms.
Отговор Дисковото използване е тогава
= == ×
Използване на сървъра Скорост на пристигане Времеви сървър
40 0,01 × 0,4
Формулата за средното време, прекарано в чакане на опашка:

Timequeue=Timeserver × --------------------------------------------------
–
1 Използване на сървъра
------
( )
0,4 0,4 2
10 10
= 10 ms × ---------------- -- 0,6 == × ------- = 6.7 ms
1 0,4 – 3
Средното време за реакция е 10 + 6,7 ms или 16,7 ms, 6,0 пъти по-бързо от
старо време за реакция, въпреки че новото време за обслужване е само 2,0 пъти по-бързо.
сървър
I/O контролер
сървър
Опашка
Пристигания
сървър
Фигура D.17 Моделът M/M/m с множество сървъри.
Досега приемахме единичен сървър, например единичен диск.

Много реални системи имат множество дискове и следователно могат да използват множество сървъри, като
на фигура D.17. Такава система се нарича M/M/m модел в теорията на масовото обслужване.
Нека дадем същите формули за M/M/m опашката, използвайки Nservers за представяне
броя на сървърите. Първите две формули са лесни:
Честота на пристигане Timeserver ×

Използване = -------------------------------------------------- ---------
N сървъри
= ×
Lengthqueue Скорост на пристигане Timequeue
Времето за чакане на опашката е
Ptasks Nservers
Timequeue Timeserver
= × -------------------------------------------------- --------------
N сървъри × (
1 Използване – )
Тази формула е свързана с тази за M/M/1, с изключение на това, че заместваме използването на

единичен сървър с вероятност задачата да бъде поставена на опашка, а не да бъде
незабавно обслужен и разделете времето в опашката на броя на сървърите.
Уви, изчисляването на вероятността задачите да са в опашката е много по-сложно, когато има N
сървъри. Първо, вероятността да няма задачи в

системата е
–1
N сървъри Nсървъри–1 н
( N сървъри × Използване) ( N сървъри × Използване )
= 1+ -------------------------------------------------- ----------------- -------------------------------------------------- ------
Prob0 задачи
N сървъри! –
1 Използване ×() + н!
n =1
Тогава вероятността да има толкова или повече задачи, колкото имаме сървъри
N сървъри
N сървъри × Използване
Пробни задачи = × Prob0 задачи
-------------------------------------------------- ---------------
N сървъри –
Nservers! 1 Използване ×()
Обърнете внимание, че ако Nservers е 1, Probtask³Nservers опростява обратно до Utilization и получаваме

същата формула като за M/M/1. Нека опитаме пример.
Пример Да предположим, че вместо нов, по-бърз диск, добавим втори бавен диск и дублираме
данните, така че четенията да могат да се обслужват от двата диска. Да приемем, че
заявките са всички четения. Този път преизчислете отговорите на предишните въпроси
използвайки M/M/m опашка.
Отговор Средното използване на двата диска е тогава
Честота на пристигане Timeserver × 40 0,02 ×

Използване на сървъра = == ----------------------
-------------------------------------------------- --------
0,4
N сървъри 2
Първо изчисляваме вероятността да няма задачи в опашката:
1 –1
2 н
= 1+ ( 2 Използване × )
-------------------------------------------------- ( 2 Използване × )
----------------------------------------------
Prob0 задачи – +
2! 1 Използване ×() н!
n=1
2 –1 –1
(2 0,4 × 0,640
= ) 1++ ------------------------------
( 0,4 2)× = 1 + ------------- 0,800 +
×1 (0,4
2 )– 1,2
= 0,533 0,800+[] + =
–1 2,333–1 1
Използваме този резултат, за да изчислим вероятността за задачи в опашката:
2
2 Използване ×
Пробни задачиN = ×
--------------------------------------------------
– Prob0 задачи
( 2!1) Използване ×
сървъри
2
(2 0,4 × ) 0,640
= ------------------------------ 2,333–1 × = -------------
× 2.333–1
2 1 0,4 × ( ) – 1.2
= 0,533 2,333 ⁄ = 0,229
И накрая, времето на чакане на опашката:
Пробни задачи
N сървъри
=
Timequeue Timeserver × -------------------------------------------------- --------------
N сървъри × ( 1 Използване – )
0,229 0,229
= 0,020 × ------------------------ 0,020
= × -------------
2 1 0,4 ×1,2 ( ) =– 0,020 0,190 × =
0,0038
Средното време за реакция е 20 + 3,8 ms или 23,8 ms. За това натоварване две
дисковете намаляват времето за изчакване на опашката с коефициент 21 спрямо един бавен диск и a
коефициент 1,75 спрямо един бърз диск. Средното време на обслужване на система с a
единичен бърз диск обаче все още е 1,4 пъти по-бърз от един с два диска, тъй като
времето за обслужване на диска е 2,0 пъти по-бързо.
Би било чудесно, ако можем да обобщим модела M/M/m към множество опашки и множество
сървъри, тъй като тази стъпка е много по-реалистична. Уви, тези модели са много трудни за
решаване и използване, така че няма да ги разглеждаме тук.
D.6 Междусекторни въпроси
Връзки от точка до точка и комутатори, заместващи шини
Връзките от точка до точка и комутаторите стават все по-популярни, тъй като законът на Мур
продължава да намалява цената на компонентите. В комбинация с по-високите изисквания за I/O
честотна лента от по-бързи процесори, по-бързи дискове и по-бързи локални мрежи, намаляващото
предимство на разходите на автобусите означава, че дните на автобусите в настолните и
сървърните компютри са преброени. Тази тенденция започна при високопроизводителните
компютри в последното издание на книгата и до 2011 г. се разпространи в хранилището. Фигура
D.18 показва старите базирани на шина стандарти и техните заместители.
Броят на битовете и честотната лента за новото поколение е за посока, така че те се удвояват
и за двете посоки. Тъй като тези нови дизайни използват много по-малко кабели, обичаен начин
за увеличаване на честотната лента е да се предложат версии с няколко пъти по-голям брой
кабели и честотна лента.
Блокиране на сървъри срещу файлове
Досега до голяма степен пренебрегвахме ролята на операционната система в съхранението. По

начин, аналогичен на начина, по който компилаторите използват набор от инструкции,
операционните системи определят какви I/O техники, реализирани от хардуера, действително
ще бъдат използвани. Операционната система обикновено предоставя файловата абстракция
върху блоковете, съхранени на диска. Термините логически единици, логически томове и
физически томове са свързани термини, използвани в системите на Microsoft и UNIX за
обозначаване на подмножество колекции от дискови блокове.
Логическата единица е елементът на съхранение, експортиран от дисков масив, обикновено

изграден от подмножество от дискове на масива. Логическа единица се появява на сървъра
Макс I/O
Стандартен Ширина (битове) Дължина (метри) Тактова честота MB/сек устройства
(Паралелно) ATA 0,5 133 MHz 133

Сериен ATA 82 2 3 GHz 300 2?
SCSI 16 12 80 MHz 320 15

Серийно прикачване на SCSI 1 10 (DDR) 375 16,256
PCI 32/64 2 0,5 33/66 MHz 533
PCI Express 0,5 3 GHz 250 ??
Фигура D.18 Паралелни I/O шини и техните заместители от точка до точка. Имайте предвид, че честотната
лента и кабелите са за всяка посока, така че честотната лента се удвоява при изпращане и в двете посоки.
D.6 Междусекторни въпроси D-35
като един виртуален „диск“. В RAID дисков масив логическата единица е конфигурирана като
конкретно RAID оформление, като например RAID 5. Физическият том е файлът на устройството,
използван от файловата система за достъп до логическа единица. Логическият том осигурява
ниво на виртуализация, което позволява на файловата система да разделя физическия том на
множество части или да разделя данните на множество физически томове. Логическата единица
е абстракция на дисков масив, който представя виртуален диск на операционната система,
докато физическите и логическите томове са абстракции, използвани от операционната
система за разделяне на тези виртуални дискове на по-малки, независими файлови системи.
След като разгледахме някои от термините за колекции от блокове, сега трябва да
попитаме: Къде трябва да се поддържа файловата илюзия: в сървъра или в другия край на
мрежата за съхранение?
Традиционният отговор е сървърът. Той има достъп до хранилището като дискови блокове
и поддържа метаданните. Повечето файлови системи използват файлов кеш, така че сървърът
трябва да поддържа последователност на достъпа до файлове. Дисковете могат да бъдат директно
прикачени - намерени в сървър, свързан към I/O шина - или прикрепени през мрежа за
съхранение, но сървърът предава блокове данни към подсистемата за съхранение.
Алтернативният отговор е, че самата дискова подсистема поддържа файловата абстракция,
а сървърът използва протокол на файловата система, за да комуникира със съхранението.
Примерни протоколи са мрежова файлова система (NFS) за UNIX системи и обща интернет
файлова система (CIFS) за Windows системи. Такива устройства се наричат мрежови устройства
за съхранение (NAS), тъй като няма смисъл съхранението да бъде директно свързано към сървъра.
Името е нещо като погрешно наименование, тъй като мрежа за съхранение като FC-AL може също да
се използва за свързване към блокиращи сървъри. Терминът filer често се използва за NAS
устройства, които предоставят само файлова услуга и съхранение на файлове. Network
Appliance беше една от първите компании, които направиха файлове.
Движещата сила зад поставянето на съхранение в мрежата е да се улесни много компютри да
споделят информация и операторите да поддържат споделената система.
Асинхронни I/O и операционни системи
Дисковете обикновено прекарват много повече време в механични забавяния, отколкото в прехвърляне на
данни. По този начин естественият път към по-висока входно/изходна производителност е паралелизмът,
опитвайки се да получите много дискове за едновременен достъп до данни за програма.
Простият подход към I/O е да поискате данни и след това да започнете да ги използвате.
След това операционната система превключва към друг процес, докато пристигнат желаните
данни, и след това операционната система превключва обратно към искащия процес.
Такъв стил се нарича синхронен I/O - процесът изчаква, докато данните бъдат прочетени от
диска.
Алтернативният модел е процесът да продължи след заявка и не се блокира, докато не се

опита да прочете исканите данни. Такъв асинхронен I/O позволява на процеса да продължи да
прави заявки, така че много I/O заявки да могат да работят едновременно. Асинхронният вход/
изход споделя същата философия като кеш паметта в неправилни процесори, които постигат по-
голяма честотна лента чрез множество неизпълнени събития.
D.7 Проектиране и оценка на I/O система—

Интернет архивният клъстер
Изкуството на проектирането на I/O система е да се намери дизайн, който отговаря на целите за цена,
способност за зависимост и разнообразие от устройства, като същевременно се избягват тесните места
в I/O производителността и надеждността. Избягването на тесни места означава, че компонентите
трябва да бъдат балансирани между основната памет и I/O устройството, тъй като производителността
и надеждността - и следователно ефективната цена-производителност или надеждността на разходите
- могат да бъдат толкова добри, колкото и най-слабата връзка в I/O верига. Архитектът трябва също
така да планира разширяване, така че клиентите да могат да приспособят I/O към своите приложения.
Тази разширяемост, както в броя, така и в типовете I/O устройства, има своята цена в по-дълги I/O
шини и мрежи, по-големи захранвания за поддръжка на I/O устройства и по-големи шкафове.
При проектирането на I/O система ние анализираме производителността, цената, капацитета и
наличността, като използваме различни схеми на I/O свързване и различен брой I/O устройства от
всеки тип. Ето една поредица от стъпки, които трябва да следвате при проектирането на I/O система.
Отговорите за всяка стъпка могат да бъдат продиктувани от изискванията на пазара или просто от
целите за цена, производителност и наличност.
1. Избройте различните типове I/O устройства, които да бъдат свързани към машината, или избройте
стандартните шини и мрежи, които машината ще поддържа.
2. Избройте физическите изисквания за всяко I/O устройство. Изискванията включват размер,

мощност, конектори, шинни слотове, разширителни шкафове и т.н.
3. Избройте цената на всяко I/O устройство, включително частта от цената на всеки контролер,
необходим за това устройство.
4. Избройте надеждността на всяко I/O устройство.
5. Запишете нуждите от ресурси на процесора на всяко I/O устройство. Този списък трябва
включват:
Тактови цикли за инструкции, използвани за иницииране на I/O, за поддържане на работата на I/O
устройство (като обработка на прекъсвания) и за завършване на I/O
Тактовата честота на процесора спира поради изчакване I/O да приключи използването на паметта,
шина или кеш
Цикли на часовника на процесора за възстановяване от I/O дейност, като например кеш

флъш
6. Избройте изискванията за памет и I/O шина за всяко I/O устройство. Дори когато процесорът не
използва памет, честотната лента на основната памет и I/O връзката е ограничена.
7. Последната стъпка е оценка на производителността и наличността на различните начини за

организиране на тези I/O устройства. Когато можете да си го позволите, опитайте се да избягвате
единични точки на провал. Производителността може да бъде правилно оценена само със симулация,
въпреки че може да бъде оценена с помощта на теорията на опашките. Надеждността може да се
изчисли, като се приеме, че I/O устройствата се повредят независимо и че времето до повреда е
D.7 Проектиране и оценка на входно/изходна система— Интернет архивен клъстер D-37
експоненциално разпределени. Наличността може да бъде изчислена от надеждността чрез оценка

на MTTF за устройствата, като се вземе предвид времето от повреда до ремонт.
Като се имат предвид вашите цели за цена, производителност и наличност, вие избирате най-
добрата организация.
Целите за цена-производителност влияят върху избора на I/O схема и физически дизайн.
Производителността може да се измерва или като мегабайти в секунда, или като I/Os в секунда, в
зависимост от нуждите на приложението. За висока производителност единствените ограничения
трябва да бъдат скоростта на I/O устройствата, броя на I/O устройствата и скоростта на паметта и
процесора. За ниска цена по-голямата част от разходите трябва да бъдат самите I/O устройства.
Целите за наличност зависят отчасти от цената на недостъпността за организацията.
Вместо да създаваме дизайн на хартия, нека оценим реална система.
Интернет архивният клъстер
За да направим тези идеи по-ясни, ще направим оценка на цената, производителността и наличността

на голям клъстер, ориентиран към съхранение в Интернет архива. Интернет архивът стартира
през 1996 г. с цел да направи исторически запис на Интернет, както се променя с времето. Можете да
използвате интерфейса на Wayback Machine към Интернет архива, за да извършите пътуване във
времето, за да видите как е изглеждал уеб сайтът на даден URL адрес някъде в миналото. Той съдържа
над един петабайт (1015 байта) и нараства с 20 терабайта (1012 байта) нови данни на месец, така че
разширяемото хранилище е изискване. В допълнение към съхраняването на историческите записи,
същият хардуер се използва за обхождане на мрежата на всеки няколко месеца, за да се получат
моментни снимки на интернет.
Клъстери от компютри, свързани с локални мрежи, са се превърнали в много икономична
изчислителна машина, която работи добре за някои приложения. Клъстерите също играят важна роля в
интернет услуги като търсачката на Google, където фокусът е повече върху съхранението, отколкото
върху изчисленията, какъвто е случаят тук.
Въпреки че е използвал различен хардуер през годините, Internet Archive се премества към нов
клъстер, за да стане по-ефективен по отношение на мощността и пространството. Основният градивен
елемент е 1U възел за съхранение, наречен PetaBox GB2000 от Capricorn Technologies. През 2006 г. той
използва четири 500 GB Parallel ATA (PATA) дискови устройства, 512 MB DDR266 DRAM, един 10/100/1000
Ethernet интерфейс и 1 GHz C3 процесор от VIA, който

A9 БГ Computer Architecture a Quantitative Approach (5th Edition)

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

A9 БГ Computer Architecture a Quantitative Approach (5th Edition)

Uploaded by

Copyright:

Available Formats

Machine Translated by Google

Machine Translated by Google

В похвала на компютърната архитектура: Количествен подход

„5-то издание на Computer Architecture: A Quantitative Approach продължава наследството,

— Кръсте Асанович, Калифорнийски университет, Бъркли

— Джеймс Хамилтън, Amazon Web Services

— Джеймс Ларус, Microsoft Research

— Джон Никълс, NVIDIA

„Новото издание на този вече класически учебник подчертава възхода на изричния

— Кунле Олукотун, Станфордски университет

„Петото издание на Computer Architecture: A Quantitative Approach изследва различните

— Андрю Н. Слос, инженер-консултант, ARM Автор на

Дейвид А. Патерсън преподава компютърна архитектура в Калифорнийския университет, Бъркли, откакто

С приноси от Norman P. Jouppi HP

Калифорнийски университет, Бъркли Шенг Ли

Томас М. Конте Питърсън в Тенеси

Държавен университет в Северна Каролина Тимъти М. Пинкстън

José Duato Университет на Южна Калифорния

Universitat Politècnica de València и Simula Parthasarathy Ranganathan HP Labs

Амстердам • Бостън • Хайделберг • Лондон

Придобиващ редактор: Тод Грийн

Morgan Kaufmann е отпечатък на Elsevier

© 2012 Elsevier, Inc. Всички права запазени.

Библиотеката на Конгреса на каталогизираните в публикацията данни

Данни за каталогизиране в публикацията на Британската

библиотека Каталожен запис за тази книга е достъпен от Британската библиотека.

За информация относно всички публикации на MK

посетете нашия уебсайт на адрес www.mkp.com

Отпечатано в Съединените американски щати

Набор от: diacriTech, Ченай, Индия

На Андреа, Линда и четиримата ни сина

Тази страница умишлено е оставена празна

от Луис Андре Барозу, Google Inc.

Първото издание на Hennessy и Patterson's Computer Architecture: A Quanti-tative Approach

Завърналите се клиенти на тази книга ще оценят отново работата на двама изключителни

Глава 1 Основи на количествения дизайн и анализ

Глава 2 Проектиране на йерархията на паметта

2.8 Заключителни бележки: Поглед напред 2.9 129

Глава 3 Паралелизъм на ниво инструкция и неговото използване

3.1 Паралелизъм на ниво инструкции: Концепции и 148

Глава 4 Паралелизъм на ниво данни във векторни, SIMD и GPU архитектури

4.1 Въведение 4.2 262

Глава 5 Паралелизъм на ниво нишка

5.1 Въведение 5.2 344

5.4 Разпределена споделена памет и базирана на директория 378

Глава 6 Компютри с мащаб на склад за използване на ниво на заявка и

6.1 Въведение 6.2 432

Приложение A Принципи на набора от инструкции

A.1 Въведение A.2 А-2

Приложение B Преглед на йерархията на паметта

B.1 Въведение B.2 Б-2

B.4 Виртуална памет B.5 Б-40

Защита и примери за виртуална памет B.6 Заблуди и Б-49

бележки B.8 Историческа Б-59

перспектива и препратки Упражнения от Amr Zaky Б-59

Приложение C Конвейерна обработка: основни и междинни понятия

C.1 Въведение С-2

C.2 Основното препятствие при тръбопровода — опасности от С-11

тръбопровода C.3 Как се прилага тръбопровода? С-30

C.4 Какво прави тръбопровода труден за внедряване? С-43

C.5 Разширяване на MIPS конвейера за обработка на многоциклови операции С-51

Междусекторни въпроси C.8 С-70

Заключителни бележки C.10 С-81

Историческа перспектива и препратки С-81