Из чего состоит счетчик компьютера
Windows счетчики производительности предоставляют высокоуровневый уровень абстракции с согласованным интерфейсом для сбора различных системных данных, таких как процессор, память и статистика использования диска. Системные администраторы используют счетчики производительности для мониторинга проблем с производительностью или поведением. Разработчики программного обеспечения используют счетчики производительности для проверки использования ресурсов своих компонентов.
Windows счетчики производительности оптимизированы для обнаружения и сбора административных и диагностических данных. Они не подходят для сбора данных высокой частоты или профилирования приложений, так как они не предназначены для сбора более одного раза в секунду. Для доступа к системным сведениям с более низкими затратами можно использовать более прямые API, например вспомогательные функции состояния процесса, GlobalMemoryStatusEx, GetSystemTimes или GetProcessTimes. Для профилирования можно собирать журналы трассировки событий Windows с данными профилирования системы с помощью tracelog.exe с -critsec помощью , -eflag -dpcisr или -ProfileSource параметров или использовать профилирование счетчиков оборудования.
Не путайте счетчики производительности Windows с API QueryPerformanceCounter. Windows счетчики производительности обеспечивают высокоуровневую абстракцию для многих видов системных сведений. Функция QueryPerformanceCounter предоставляет оптимизированный доступ к метке времени высокой точности.
Основные понятия
Система счетчиков производительности Windows организована по потребителям, поставщикам, наборам счетчиков, счетчикам, экземплярам и значениям счетчиков.
Потребитель — это программный компонент, который использует данные о производительности. Windows включает несколько встроенных средств, которые используют данные о производительности. К ним относятся диспетчер задач, монитор ресурсов, Монитор производительности, typeperf.exe, logman.exe и relog.exe. Разработчики могут создавать скрипты и приложения, которые обращаются к счетчикам производительности с помощью API счетчиков производительности.
Поставщик — это программный компонент, который создает и публикует данные о производительности. Поставщик публикует данные для одного или нескольких наборов счетчиков. Например, система базы данных может зарегистрировать себя в качестве поставщика данных производительности.
- Поставщик версии 1 — это программный компонент, который публикует данные о производительности с помощью библиотеки DLL производительности, которая выполняется в процессе потребителя. Поставщик версии 1 устанавливается в систему через .ini файл. Архитектура поставщика версии 1 не рекомендуется. Новые поставщики должны использовать архитектуру поставщика версии 2.
- Поставщик версии 2 — это программный компонент, который публикует данные о производительности с помощью API поставщика счетчиков производительности. Поставщик версии 2 устанавливается в систему с помощью xml-файла манифеста .man .
Набор счетчиков — это группировка данных о производительности в поставщике. Набор счетчиков имеет имя и один или несколько счетчиков. Сбор данных из набора счетчиков возвращает несколько экземпляров. В некоторых Windows API наборы счетчиков называются объектами производительности. Например, поставщик данных производительности для системы базы данных может предоставлять набор счетчиков для статистики по каждой базе данных.
Счетчик — это определение одного фрагмента данных производительности. Счетчик имеет имя и тип. Например, набор счетчиков "статистика по базе данных" может содержать счетчик с именем "транзакции в секунду" с типом PERF_COUNTER_COUNTER .
Экземпляр — это сущность, о которой передаются данные о производительности. Экземпляр имеет имя (строку) и одно или несколько значений счетчика. Например, набор счетчиков "статистика по каждой базе данных" может содержать один экземпляр для каждой базы данных. Имя экземпляра будет именем базы данных, и каждый экземпляр будет содержать значения счетчиков для счетчиков "транзакции в секунду", "использование памяти" и "использование диска".
Значение счетчика — это значение одного фрагмента данных счетчика производительности. Значение счетчика — это целое число без знака, 32-разрядное или 64-разрядное в зависимости от типа соответствующего счетчика. При разговоре об экземплярезначение счетчика иногда может вызываться счетчиком или значением.
Может быть полезно связать термины счетчика производительности с более знакомыми терминами электронной таблицы. Набор счетчиков похож на таблицу. Счетчик похож на столбец. Экземпляр похож на строку. Значение счетчика похоже на ячейку в таблице.
Наборы счетчиков с одним экземпляром всегда содержат данные для одного экземпляра. Это распространено для наборов счетчиков, сообщающих о глобальной статистике системы. Например, Windows имеет встроенный набор счетчиков с одним экземпляром с именем Memory, который сообщает об использовании глобальной памяти.
Наборы счетчиков с несколькими экземплярами содержат данные для переменного числа экземпляров. Это распространено для наборов счетчиков, которые сообщают о сущностях в системе. Например, Windows имеет встроенный набор счетчиков с несколькими экземплярами с именем "Сведения о процессоре", который сообщает один экземпляр для каждого установленного ЦП.
Потребители периодически собирают и записывают данные из набора счетчиков поставщика. Например, потребитель может собирать данные один раз в секунду или один раз в минуту. Собранные данные называются примером. Пример состоит из меток времени вместе с данными для экземпляров набора счетчиков. Данные для каждого экземпляра включают имя экземпляра (строку) и набор значений счетчика (целые числа, по одному значению для каждого счетчика в наборе счетчиков).
Имена экземпляров обычно должны быть уникальными в образце, т. е. поставщик не должен возвращать два экземпляра с тем же именем, что и часть одного примера. Некоторые старые поставщики не следуют этому правилу, поэтому потребители должны иметь возможность допускать неуниковые имена экземпляров. Имена экземпляров не зависят от регистра, поэтому экземпляры не должны иметь имена, отличающиеся только в случае.
В целях обратной совместимости набор счетчиков Process возвращает имена неуникированных экземпляров на основе имени EXE-файла. Это может привести к путанице результатов, особенно если процесс с неуникальным именем запускается или завершает работу, так как обычно это приведет к сбою данных из-за неправильного сопоставления имен экземпляров между примерами. Потребители набора счетчиков Process должны иметь возможность допускать эти неуниковые имена экземпляров и результирующий сбой данных.
Имена экземпляров должны быть стабильными в примерах, т. е. поставщик должен использовать одно и то же имя экземпляра для одной сущности при каждом сборе набора счетчиков.
Каждый счетчик имеет тип. Тип счетчика указывает тип необработанного значения счетчика (32-разрядное целое число без знака или 64-разрядное целое число без знака). Тип счетчика также указывает, что представляет необработанное значение счетчика, которое определяет способ обработки необработанного значения для создания полезной статистики.
Хотя некоторые типы счетчиков просты и имеют необработанное значение, которое напрямую полезно, многие типы счетчиков требуют дополнительной обработки для создания полезного форматированного значения. Для создания форматированного значения некоторые типы счетчиков требуют необработанных значений из двух выборок, некоторые типы счетчиков требуют меток времени, а некоторые типы счетчиков требуют необработанных значений из нескольких счетчиков. Пример:
- PERF_COUNTER_LARGE_RAWCOUNT — это 64-разрядное необработанное значение, которое не требует использования обработки. Он подходит для значений до точки во времени, таких как "Байты используемой памяти".
- PERF_COUNTER_RAWCOUNT_HEX — это 32-разрядное необработанное значение, требующее использования только простого шестнадцатеричного форматирования. Он подходит для сведений о точке во времени или для идентификации таких сведений, как "Флаги" или "Базовый адрес".
- PERF_COUNTER_BULK_COUNT — это 64-разрядное необработанное значение, указывающее количество событий и используемое для вычисления скорости возникновения событий. Чтобы быть полезным, этот тип счетчика требует двух выборок, разделенных по времени. Форматированное значение — это частота событий, т. е. количество раз, когда событие произошло в секунду в течение интервала между двумя выборками. В двух примерах s0 и s1 форматированное значение (скорость событий) вычисляется как (s1.EventCount - s0.EventCount)/(s1.TimestampInSeconds - s0.TimestampInSeconds) .
Ожидается, что поставщики будут вести себя так, как если бы они не были без отслеживания состояния, т. е. сбор данных из набора счетчиков не должен заметно влиять на состояние поставщика. Например, поставщик не должен сбрасывать значения счетчиков до 0 при сборе набора счетчиков и не следует использовать метку времени предыдущей коллекции для настройки значений в текущей коллекции. Вместо этого он должен предоставлять простые необработанные значения счетчиков с точными типами, чтобы потребитель смог вычислить полезную статистику на основе необработанных значений и меток времени.
Память (ОЗУ)
ОЗУ (оперативное запоминающее устройство, англ. RAM) — это большая группа этих самых регистров, соединённых вместе. Память у такого хранилища непостоянная и данные оттуда пропадают при отключении питания. ОЗУ принимает адрес ячейки памяти, в которую нужно поместить данные, сами данные и флаг записи/чтения, который приводит в действие триггеры.
Прим. перев. Оперативная память бывает статической и динамической — SRAM и DRAM соответственно. В статической памяти ячейками являются триггеры, а в динамической — конденсаторы. SRAM быстрее, а DRAM дешевле.
Обзор таймеров в архитектуре PC
Источников времени в системе может быть несколько. Прикладные программы редко обращаются к каким-либо из них напрямую. Вместо этого используются всевозможные API, предлагаемые использованным языком программирования (например, C++11 < chrono >), средой исполнения (например, gettimeofday из POSIX или QueryPerformanceCounter на MS Windows), или даже системными вызовами используемой операционной системы.
Самой ОС также необходимо знать время и уметь отмерять его отрезки для планирования работы пользовательских потоков, учёта потреблённых ими ресурсов, профилировки производительности, управления энергопотреблением и т.п. При этом сама ОС работает напрямую с интерфейсами, предоставляемыми аппаратурой. Так как таймеров присутствует много, современные ОС умеют выбирать один «центрально» используемый в начале загрузки, исходя из своих представлений о «качестве» обнаруженных устройств (например, на некоторых системах часть таймеров может быть занесена в «чёрный список» из-за известных проблем в работе) или же настроек пользователя (параметр clocksource у ядра Linux и опции useplatformclock, tscsyncpolicy, disabledynamictick у BCDEDIT в Windows).
Опишу наиболее часто встречаемые устройства, являющиеся часами и таймерами в PC.
Общераспространённые
Часы реального времени (Real Time Clock, RTC) — источник текущей даты и времени для нужд ОС. Типичное разрешение этого таймера — одна секунда. Все системы, удовлетворяющие стандарту ACPI, имеют чип RTC, совместимый с Motorola MC146818, присутствовавшем в оригинальном IBM PC/AT с 1984 года. В современных системах RTC обычно интегрирован в набор системной логики южного моста на материнской плате (что означает довольно большую задержку при чтении). Энергонезависимость этого таймера обеспечивается специальной батарейкой. Принципы программирования RTC вызывают ностальгию по BCD-числам и проблеме Y2K.
Это удивительно, но первые системы IBM PC не имели в себе RTC. При каждом старте компьютера MS-DOS выдавала запрос на установку текущей даты и времени.
И даже в наше время не каждая вычислительная система способна хранить время между перезагрузками. Например, оригинальная RaspberryPi не имеет встроенного RTC (это было сделано для уменьшения стоимости), и правильная установка текущей даты/времени при загрузке системы зависит от синхронизации с сетевыми NTP-серверами.
Programmable Interval Timer (PIT) 8253 или 8254 от Intel — стандартный счётчик и таймер, имеющийся в PC с самого начала существования этой платформы (1981 год). Как и RTC, изначально был отдельной микросхемой, а ныне является частью системной логики. Довольно интересное устройство, содержащее три таймера (хотя последние два всегда были зарезервированы под задачи обновления ОЗУ и работу PC-спикера соответственно) и позволяющее запрограммировать их в различные режимы: периодические прерывания, однократное (one-shot) прерывание по таймауту, меандр и т.д.
Первый канал PIT до сих пор может использоваться ОС как источник прерываний для работы вытесняющего планировщика задач. Однако по современным меркам он не очень удобен в работе: низкая частота осциллятора 1193181,8 Гц (странное значение — это историческое наследие от частоты развёртки NTSC), ширина счётчика всего 16 бит (частое переполнение) при ширине регистров статуса и команд всего в восемь бит (т.е. приходится передавать или читать значение по частям), да и доступ к регистрам через медленный и негибкий механизм PIO (команды IN/OUT процессора).
Local APIC (advanced programmable interrupt controller), встроенный во все современные процессоры Intel (начиная с архитектуры P54C) и который в своём составе имеет ещё и таймер. Более того, каждый логический процессор имеет свой собственный LAPIC, что может быть удобно для выполнения работы, локальной для текущего ядра, без необходимости управления ресурсами. Однако, данное устройство не имеет фиксированной известной частоты; последняя скорее привязана к частоте ядра. Поэтому перед использованием программе необходимо её вычислить (калибровать), а для этого нужно дополнительное референсное устройство. Режимы, поддерживаемые LAPIC: однократное прерывание, периодические прерывание, и период, определяемый TSC.
Таймер в составе ACPI, почему-то называемый Performance Monitoring Timer (PMTIMER) — ещё одно устройство, которое поддерживается всеми системами, реализующими стандарт ACPI, с 1996 года. Данный таймер имеет частоту 3.579545 МГц, ширина регистра-счётчика может быть 24 или 32 бита. Сам таймер всегда активен при включенном питании системы и не зависит от режима работы центрального процессора.
High Precision Event Timer (HPET) — устройство, созданное как замена устаревшему PIT. Согласно стандарту, HPET должен содержать осциллятор, работающий с фиксированной частотой по крайней мере в 10 МГц, величину которой можно программно прочитать из его статусного регистра, и монотонно увеличивающий значение счётчик шириной в 64 бита. Также он должен содержать минимум три компаратора шириной в 32 или 64 бита, которые и используются для генерации прерываний по истечении запрограммированных периодов времени. Как и PIT, он способен работать в периодическом режиме или в режиме однократного прерывания. При этом метод его программирования (MMIO вместо PIO) удобнее и быстрее, чем у PIT, что вместе с повышенным разрешением, позволяет задавать интервалы более точно и с меньшей задержкой. Требуемая стабильность генератора равна 0,05% для интервалов длиннее 1 мс и 0,2% для промежутков короче 100 мкс; много это или мало — зависит от приложений.
Несмотря на то, что HPET уже давно присутствует в PC (с 2005 года), операционные системы не торопятся начать его использовать. Частично это вызвано не самым удобным способом задания интервалов с помощью возрастающего счётчика вместо убывающего — из-за немгновенности операций существует риск «не успеть» и задать событие в прошлом. Зачастую ОС используют таймер из APIC или PMTIMER, или же функциональность TSC, использующую такты процессора в качестве источника времени.
Трудная судьба инструкции RDTSC
История TSC достаточно интересна и поучительна, чтобы остановиться на ней подольше.
Сама идея очень прозрачная — использовать в качестве источника времени сам процессор, а точнее его тактовый генератор. Текущий номер такта сохраняется в регистре TSC (timestamp counter).
С помощью TSC можно как узнавать время от начала работы, так и замерять интервалы времени с помощью двух чтений. TSC также работает как будильник в связке с APIC в режиме TSC deadline.
- RDTSC (Read TimeStamp Counter — прочесть метку времени) появилась в Intel® Pentium™. Она записывает в пару регистров EDX:EAX 64-битное число тактов, прошедших с момента последнего включения питания/перезагрузки текущего ядра процессора. В отличие от всех ранее описанных устройств, которые доступны только привилегированному коду, RDTSC по умолчанию может исполняться на любом уровне привилегий (хотя ОС может динамически отключить поддержку RDTSC в пользовательском режиме, и тогда она будет вызывать исключение).
- RDMSR [0x10] — чтение модель-специфичного регистра (MSR) IA32_TIMESTAMP_COUNTER также возвращает текущее TSC. Данная инструкция допускается только в привилегированном режиме, и некоторые ОС активно используют именно её для чтения TSC (хотя лично мне непонятно, почему). Полезное свойство состоит в том, что через MSR значение TSC можно не только читать, но и изменять, используя инструкцию WRMSR.
- RDTSCP — Наличие её можно установить, проверив соответствующий лист CPUID. О двух её отличиях от RDTSC будет сказано чуть ниже.
Что ж, TSC — вполне естественная штука с простой логикой и простым сценарием использования, которая должна обладать многими полезными свойствами: высокое разрешение (один такт ЦПУ), низкая задержка при чтении (десятки тактов), редкие переполнения (64-битного счётчика должно хватать минимум на 10 лет), монотонность чтений (ведь счётчик всегда увеличивает своё значение), равномерность (процессор всегда работает), согласованность с другими таймерами (при старте системы можно выставить нужное значение записью в MSR).
Разве что-то могло пойти не так? На пути к успешному использованию TSC в качестве основного средства измерения времени в PC встала последующая эволюция процессоров. Новые возможности, появившиеся в процессорах после Pentium, «испортили» RDTSC и много лет мешали использовать её как основной таймер в популярных ОС. Так, в 2006 году один из Linux-разработчиков Ingo Molnar писал:
Мы наблюдали, что в течение 10 лет ни одной реализации gettimeofday, основанной на TSC и работающей в общем случае, не было написано (а я написал первую версию для Pentium, так что и я в этом повинен), и что лучше мы обойдёмся без неё.
We just observed that in the past 10 years no generally working TSC-based gettimeofday was written (and i wrote the first version of it for the Pentium, so the blame is on me too), and that we might be better off without it.
Отмечу, что со временем в архитектуру IA-32 вносились коррективы, устранявшие проявившиеся недостатки, и в настоящий момент TSC может (пока опять не сломали) быть использован в том качестве, в котором он задумывался.
- Внеочередное исполнение (Out of Order Execution, OoO). Начиная с Intel® Pentium™ Pro (1995 г.), процессор может исполнять машинные инструкции в порядке, отличном от использованного в программе, или даже параллельно (если они не зависят друг от друга). Это означает, что исполнение RDTSC может быть задержано или, наоборот, выполнено раньше, чем того требует последовательный программный порядок. Из-за этого, например, невозможно понять, сколько каких инструкций исполнилось между двумя вызовами RDTSC — нельзя надёжно измерить длительность участка кода. В результате не гарантируется монотонность показаний.
RDTSC не является инструкцией, сериализующей поток исполнения. Поэтому обычно используется «забор» из сериализующих команд вокруг неё, например, CPUID. Это, конечно, не выглядит очень изящно. В последующих обновлениях архитектуры появилась RDTSCP — инструкция, частично сериализующая поток исполнения, поэтому она не нуждается в дополнительных барьерах. У неё есть ещё одно хорошее свойство, но о нём чуть позже. - Управление энергопотреблением. Значение TSC увеличиваетсся каждый такт процессора. Всегда ли такт имеет один и тот же период, и всегда ли следующий такт следует сразу за предыдущим? Для Intel® Pentium™ это выполнялось. Для современных процессоров ответы на оба вопроса отрицательные. Процессор довольно значительную долю времени может быть приостановлен для экономии энергии (C-состояния). Исполняя инструкции, он может использовать динамическое изменение частоты для экономии энергии (P-состояния) или наоборот, для максимизации производительности (Turbo-состояния). Из этого следует, что просто счётчик тактов не будет обладать ни равномерностью, ни согласованностью.
И для этой проблемы было представлено (начиная с Nehalem) решение в виде т.н. invariant TSC, темп изменения которого не зависит от C- и P-состояний отдельных ядер. - Многопроцессорность и многоядерность. В системе с несколькими потоками, ядрами или процессорами у каждого из логических процессоров будет свой TSC. Это создаёт не одну, а целых две сложности.
Во-первых, значения, возвращаемые RDTSC на различных логических процессорах, могут оказаться сдвинутыми из-за неодновременности моментов инициализации ядер. Более того, из-за неустранимого дрейфа частот отдельных таймеров эта разница могла непредсказуемым образом флуктуировать в процессе работы.
Во-вторых, перестаёт работать возможность надёжно измерять время в пользовательских приложениях. Без дополнительных ухищрений вроде прописывания affinity в любой момент программа может быть вытеснена с одного процессора и затем продолжена на другом. Если процесс, желающий измерить длительность между двумя событиями, в процессе работы был перемещён ОС с одного ядра на другое, два чтения RDTSC, выполненные им, не будут связаны.
Для компенсации первой проблемы в последних поколениях процессоров для TSC заводится единый источник сигнала. Показания TSC со всех ядер при этом должны быть одинаковыми.
Для устранения второго недостатка RDTSCP обладает ещё одним свойством, позволяющим пользовательскому приложению детектировать миграцию в процессе измерения интервала времени. Кроме значения TSC в EDX:EAX она возвращает значение отдельного модель-специфичного регистра IA32_TSC_AUX в ECX. Обе записи происходят атомарно, т.е. TSC и TSC_AUX всегда берутся с одного логического процессора. В начале работы ОС должна выставить уникальные значения TSC_AUX на всех процессорах системы. Совпадение считанных ECX для двух вызовов RDTSCP гарантирует, что они были выполнены на одном процессоре; в противном случае на разницу двух TSC полагаться нельзя, и измерение следует повторить. Вообще этот механизм может иметь и другие применения; например, с помощью него можно оповещать приложение не только о факте миграции, но и просто о вытеснении, также способном исказить результаты измерений времени. Вместо прикладных программ могут выступать и «привилегированные»: гипервизор Xen использует данный механизм для нотификации DomU систем о миграции между машинами.
Прочие устройства
Выше я описал наиболее часто распространённые и используемые устройства по определению времени. Конечно же, конкретные системы могут иметь дополнительные устройства, уникальные для процессора, интегрированной логики или даже в форме специализированных периферийных устройств (например, сверхточные атомные часы). Степень их доступности из программ зависит от того, существует ли драйвер для конкретного устройства в выбранной ОС. Так, пробежавшись по исходникам Linux, я нашёл как минимум ещё два поддерживаемых источника времени для сборок x86: устройство NatSemi SCx200 в системах AMD Geode, и Cyclone для систем IBM x440. К сожалению, в Интернете не очень много документации по ним.
- PowerPC. Спецификации для 32- и 64-битных систем постулируют наличие регистра TB (time base) шириной в 64 бита, доступного на чтение пользовательским приложениям и на чтение/запись из супервизора. Изменения TB должны монотонно не убывать и не обязаны быть равномерными, а их частота зависит от реализации. Также из режима супервизора доступен 32-битный регистр DEC (decrementer), позволяющий программировать прерывание через промежуток времени. Его значение убывает до нуля с той же самой частотой, с которой возрастает TB.
- ARM. В целом наличие средств измерения времени сильно зависит от выбранного семейства. На архитектуре ARM11 регистр CCNT может быть использован для чтения текущего номера такта; однако ширина его всего 32 бита, что означает переполнение примерно каждые 10 секунд на системе с частотой в 400 МГц. На системах Cortex M3 присутствует устройство Systick шириной 24 бита, а скорость его изменения специфицируется значением из регистра TENMS.
- Intel ® IA-64 (Itanium). На данных системах в качестве счётчика тактов используется 64-битный регистр ar.itc (interval time counter). Для программирования периодов времени может использоваться набор регистров cr.itm (interval timer match), cr.itv (interval timer vector). Первый задаёт значение ITC, при котором сгенерируется прерывание, а второй определяет его номер.
- SPARC v9. Архитектура подразумевает наличие 63-битного регистра TICK. Последний 64-й бит этого регистра контролирует, разрешено ли непривилегированному приложению читать время.
Аудитория разработчиков
Поставщики счетчиков производительности обычно реализуются как драйверы в режиме ядра или службы пользовательского режима. Поставщики счетчиков производительности обычно записываются в C или C++.
Заключение
Я надеюсь, что из этой заметки стало понятно, что работа со временем внутри компьютера на системном уровне на самом деле далека от тривиальной. Требования к устройствам, поставляющим время, зависят от решаемой задачи, и не всегда легко найти полностью подходящий вариант. При этом сами устройства зачастую содержат «архитектурные особенности», способные сломать голову несчастному программисту.
Однако это всё архитектурная присказка к симуляционной сказке. На самом деле мне хотелось рассказать о том, как можно моделировать весь этот зоопарк устройств. В следующей статье я опишу, как проявляется капризная природа времени при создании виртуальных окружений — симуляторов и мониторов виртуальных машин. Спасибо за внимание!
В общем виде задачу о производительности можно представить в виде трех частей: сбор данных, анализ полученных данных и создание черного ящика для упреждающего мониторинга проблемной системы.
Начнем со всем давно известного Performance Monitor. Это стандартная утилита, которая входит во все современные редакции Windows. Вызывается либо из меню, либо из командной строки или строки поиска в Windows 8/10 вводом команды perfmon. После запуска утилиты мы видим стандартную панель, в которой можем добавить и удалить счетчики, изменить представление и масштабировать графики с данными.
Также есть сборщики данных, с помощью которых производится сбор данных о производительности системы. При определённых навыках и сноровке операции по добавлению счетчиков и настройке параметров сбора данных можно производить из графического интерфейса. Но когда возникает задача настройки сбора данных с нескольких серверов, разумнее использовать утилиты командой строки. Вот этими утилитами мы и займемся.
Первая утилита — это Typeperf, которая может выводить данные со счетчиков производительности на экран или в файл, а также позволяет получить список счетчиков, установленных в системе. Примеры использования.
Выводит на экран загрузку процессора с интервалом 1 сек.:
Выводит в файл названия счётчиков производительности, связанные с объектом PhysicalDisk:
В нашем случае мы можем использовать утилиту Typeperf, чтобы создать файл с нужными нам счетчиками, который в дальнейшем будем использовать как шаблон для импорта счетчиков в сборщик данных.
Следующая утилита – Logman. Данная утилита позволяет создавать, изменять и управлять различными сборщиками данных. Мы будем создавать сборщик данных для счетчиков производительности. Вот, например, краткая справка по команде Logman, которая относится к счетчикам производительности и управлению сборщиком данных.
Разберем несколько примеров, которые нам понадобятся в дальнейшем.
Создадим сборщик данных с именем DataCollector_test, импортировав счетчики производительности из файла test.xml:
Создание файла для сбора данных производительности с включённым циркулярным режимом и заданным размером:
Изменение пути файла с данными производительности по умолчанию:
Запуск коллектора данных DataCollector_test:
Остановка коллектора данных DataCollector_test:
Отметим, что все эти действия можно производить с удаленным компьютером.
Рассмотрим еще одну утилиту — Relog, которая позволяет производить манипуляции с файлом данных после работы сборщика данных. Вот ее описание:
Ниже несколько сценариев применения этой утилиты.
Извлечение данных счетчиков производительности из файла logfile.blg с применением фильтра со списком счетчиков counters.txt и записью результата в бинарный формат:
Извлечение списка счетчиков производительности из logfile.blg в текстовый файл counters.txt:
Напрямую работать с этой утилитой мы не будем, но информация о ней в дальнейшем поможет в случае возникновения проблем в файле PowerShell, который генерирует утилита PAL.
Отметим еще один момент, некоторые системы анализа требуют данные с наименованиями счетчиков производительности на английском языке. Если интерфейс нашей системы на русском языке, то нам необходимо проделать следующие манипуляции: завести локального пользователя, дать ему права на сбор данных (обычно дают права локального администратора), войти в систему под ним и в свойствах системы изменить язык интерфейса.
Обязательно выйти из системы и зайти во второй раз под этим пользователем для инициализации английского интерфейса и выйти из системы. Далее указать в сборщике данных, что сбор данных будет производиться от имени этого пользователя.
После этого имена счетчиков и файлов будут на английском языке.
Также отметим возможность сбора данных для SQL Server с помощью утилиты из состава продукта. Это SQLDIAG, которая обрабатывает журналы производительности Windows, журналы событий Windows, трассировки SQL Server Profiler, сведения о блокировках SQL Server и сведения о конфигурации SQL Server. Указать, какие типы сведений нужно собирать с помощью программы SQLdiag, можно в файле конфигурации SQLDiag.xml.
Вот так выглядит окно этого инструмента.
В итоге, процесс сбора данных для SQL может выглядеть так. С помощью PSSDIAG мы формируем xml-файл. Далее посылаем этот файл клиенту, который запускает SQLDIAG c нашим xml-файлом на удаленном сервере и присылает нам для анализа результат работы в виде blg-файла, который мы будем анализировать в следующей части.
Данная утилита написана Clint Huffman, который является PFE-инженером Microsoft и занимается анализом производительности систем. Также он является одним из авторов авторизованного курса Vital Sign, который читается в Microsoft и доступен для корпоративных заказчиков, в том числе в России на русском языке. Утилита распространяется свободно, ссылку на нее я приведу ниже.
Вот так выглядит стартовое окно утилиты.
На вкладке Counter Log задаётся путь к файлу данных со счетчиками производительности, собранными ранее. Также мы можем задать интервал, за который будет производиться анализ.
На вкладке Threshold File находится список шаблонов, которые можно экспортировать в формат xml и использовать как список счетчиков для сборщика данных. Обратите внимание на большой выбор шаблонов для анализа производительности для различных систем. Пример загрузки из командной строки был показан выше. Самое ценное, что в этих заранее подготовленных шаблонах установлены граничные значения для этих параметров, которые будут использованы в дальнейшем для анализа собранных данных.
Вот так, например, выглядят граничные значения для счётчиков дисковой производительности:
Мы можем создавать свои шаблоны с использованием нужных счетчиков, которые будут подстроены под нужды нашей организации.
Действуем по следующему алгоритму: на рабочей станции запускаем утилиту PAL, переходим на вкладку Threshold File и экспортируем шаблон в виде xml-файла. На основании этого файла на сервере создаем сборщик данных и запускаем сборку информации.
После сбора данных копируем полученный файл на рабочую станцию, чтобы анализом не нагружать сервер, возвращаемся на вкладку Counter Log, указываем путь к файлу. Снова переходим на Threshold File и выбираем тот самый шаблон, который экспортировали для сборщика данных.
Переключаемся на вкладку Question и указываем объем оперативной памяти на сервере, на котором был осуществлён сбор данных. В случае 32-битной системы заполним UserVa.
Переходим к вкладке Output Options, на которой задаем интервал разбиения для анализа. Значение по умолчанию AUTO делит интервал на 30 равных частей.
Вкладка File Output выглядит довольно обычно, указываем на ней путь к файлам итоговых отчетов в формате HTML или XML.
Вкладка Queue показывает итоговый скрипт на PowerShell. В общем можно сказать, что утилита собирает параметры, которые она подставляет в скрипт PAL.PS1.
Итоговая вкладка задает параметры исполнения. Можно одновременно запустить несколько скриптов и указать число потоков на процессоре. Хотелось бы акцентировать внимание, что обработку blg делает не утилита, а скрипт PowerShell, и это открывает возможности для полной автоматизации анализа логов. Например, каждые сутки перезапускается сборщик данных, в результате освобождается текущий blg-файл и создаётся новый. Старый файл копируется на специальный сервер, где будет запускаться скрипт, обрабатывающий данный файл. После этого готовый HTML- или XML-файл с результатами перемещается в определённую директорию или высылается на почтовый ящик.
Также файл с данными должен быть с названиями счетчиков на английском. Выше я указывал, как это сделать. После нажатия Finish запустится скрипт PowerShell, время работы которого зависит от объёма данных и быстродействия рабочей станции.
Итогом работы утилиты будет отчет в выбранном формате, в котором есть графики и числовые данные, позволяющие понять, что происходило в системе за заданный период с учетом граничных значений алертов в шаблоне на вкладке Threshold File. В общем, анализ HTML-файла позволит на начальном этапе определить проблемные места в системе и понять, куда двигаться дальше, как в плане более тонкого мониторинга, так и в плане модернизации или переконфигурирования системы. В блоге Clint Huffman есть скрипт, которым можно конвертировать файл шаблона с граничными условиями в более понятный формат.
Иногда возникает необходимость в превентивном мониторинге проблемной системы. Для этого мы создадим «черный ящик», в который будем записывать данные производительности. Вернемся к скриптам, описанным ранее.
Создадим сборщик данных c именем BlackBox, импортировав счетчики производительности из файла SystemOverview.xml, который выгрузили из утилиты PAL или создали самостоятельно:
Создание файла для сбора данных производительности с включённым циркулярным режимом и заданным размером 600 МБ (около 2 суток при стандартном наборе счетчиков):
Изменение пути файла с данными производительности по умолчанию:
Запуск коллектора данных BlackBox:
Данный скрипт создает задачу перезапуска сборщика данных в случае перезапуска системы:
На всякий случай поправим свойства диспетчера данных, чтобы не заполнить место на диске, так как после перезапуска сборщика данных создается новый файл с лимитом 600 МБ.
Отметим, что скопировать файл с данными можно только при остановленном сборщике данных. Остановить же последний можно скриптом или с помощью графического интерфейса.
Остановка коллектора данных BlackBox:
На этом закончим часть, посвященную сбору и первичному анализу производительности.
Приступая к работе
- Используйте средства счетчика производительности , если вы хотите собирать или просматривать данные о производительности из системы.
- Используйте API сбора счетчиков производительности , если требуется написать скрипт или программу, которая собирает данные о производительности из локальной системы.
- Используйте классы счетчиков производительности WMI , если требуется собирать данные о производительности из локальной или удаленной системы с помощью WMI.
- Используйте API поставщика счетчиков производительности , если требуется опубликовать данные о производительности из программного компонента.
Хранение информации — регистры и память
Как говорилось ранее, процессор выполняет поступающие на него команды. Команды в большинстве случаев работают с данными, которые могут быть промежуточными, входными или выходными. Все эти данные вместе с инструкциями сохраняются в регистрах и памяти.
Тактирование процессора
Быстродействие компьютера определяется тактовой частотой его процессора. Тактовая частота — количество тактов (соответственно и исполняемых команд) за секунду.
Частота нынешних процессоров измеряется в ГГц (Гигагерцы). 1 ГГц = 10⁹ Гц — миллиард операций в секунду.
Чтобы уменьшить время выполнения программы, нужно либо оптимизировать (уменьшить) её, либо увеличить тактовую частоту. У части процессоров есть возможность увеличить частоту (разогнать процессор), однако такие действия физически влияют на процессор и нередко вызывают перегрев и выход из строя.
Поток инструкций
Современные процессоры могут параллельно обрабатывать несколько команд. Пока одна инструкция находится в стадии декодирования, процессор может успеть получить другую инструкцию.
Однако такое решение подходит только для тех инструкций, которые не зависят друг от друга.
Если процессор многоядерный, это означает, что фактически в нём находятся несколько отдельных процессоров с некоторыми общими ресурсами, например кэшем.
Конечно же, достаточный набор свойств источника зависит от способа использования в программах. Например, одно устройство может предоставлять низкое разрешение и высокую длительность считывания, но при этом быть энергонезависимым и очень стабильным, а другое позволять измерять очень короткие промежутки времени, но при этом быстро переполняться, да ещё и не быть синхронизированным ни с чем больше.
Регистры
Регистр — минимальная ячейка памяти данных. Регистры состоят из триггеров (англ. latches/flip-flops). Триггеры, в свою очередь, состоят из логических элементов и могут хранить в себе 1 бит информации.
Прим. перев. Триггеры могут быть синхронные и асинхронные. Асинхронные могут менять своё состояние в любой момент, а синхронные только во время положительного/отрицательного перепада на входе синхронизации.
По функциональному назначению триггеры делятся на несколько групп:
- RS-триггер: сохраняет своё состояние при нулевых уровнях на обоих входах и изменяет его при установке единице на одном из входов (Reset/Set — Сброс/Установка).
- JK-триггер: идентичен RS-триггеру за исключением того, что при подаче единиц сразу на два входа триггер меняет своё состояние на противоположное (счётный режим).
- T-триггер: меняет своё состояние на противоположное при каждом такте на его единственном входе.
- D-триггер: запоминает состояние на входе в момент синхронизации. Асинхронные D-триггеры смысла не имеют.
Для хранения промежуточных данных ОЗУ не подходит, т. к. это замедлит работу процессора. Промежуточные данные отсылаются в регистры по шине. В них могут храниться команды, выходные данные и даже адреса ячеек памяти.
Принцип действия RS-триггера
Арифметико-логическое устройство
Это устройство, как ни странно, выполняет все арифметические и логические операции, например сложение, вычитание, логическое ИЛИ и т. п. АЛУ состоит из логических элементов, которые и выполняют эти операции.
Большинство логических элементов имеют два входа и один выход.
Ниже приведена схема полусумматора, у которой два входа и два выхода. A и B здесь являются входами, S — выходом, C — переносом (в старший разряд).
Схема арифметического полусумматора
Архитектура API производительности
Потребители счетчиков производительности включают:
-
, такие как диспетчер задач, монитор ресурсов, Монитор производительности и typeperf.exe.
- Предоставляемые корпорацией Майкрософт высокоуровневые поверхности API, которые предоставляют данные счетчиков производительности, такие как классы производительности WMI.
- Собственные приложения или скрипты, использующие API-интерфейсы потребителя счетчика производительности.
Большинство потребителей счетчиков производительности используют API из PDH.dll для сбора данных о производительности. PDH управляет множеством сложных аспектов сбора счетчиков производительности, таких как анализ запросов, сопоставление экземпляров в нескольких примерах и вычисление отформатированных значений из необработанных данных счетчика. Реализация PDH использует API реестра при использовании данных от поставщика версии 1 и использует API-интерфейсы потребителя версии 2 при использовании данных от поставщика версии 2.
Некоторые старые потребители счетчиков производительности используют API реестра для сбора данных о производительности из специального HKEY_PERFORMANCE_DATA раздела реестра. Это не рекомендуется для нового кода, так как обработка данных из реестра является сложной и подверженной ошибкам. Реализация API реестра напрямую поддерживает сбор данных от поставщиков версии 1. Он косвенно поддерживает сбор данных от поставщиков версии 2 через уровень перевода, использующий API-интерфейсы потребителя версии 2.
Некоторые потребители счетчиков производительности используют функции потребителя PerfLib версии 2 для прямого доступа к данным от поставщиков версии 2. Это сложнее, чем использование данных с помощью API PDH, но этот подход может быть полезен, если API PDH нельзя использовать из-за проблем производительности или зависимостей. Реализация PerfLib версии 2 напрямую поддерживает сбор данных от поставщиков версии 2. Он не поддерживает сбор данных от поставщиков версии 1.
Windows OneCore не включает PDH.dll и не поддерживает использование данных счетчика производительности через API реестра. Потребители, работающие на OneCore, должны использовать функции потребителя PerfLib версии 2.
Поставщики версии 1 реализуются в виде библиотеки DLL поставщика, загружаемой в процесс потребителя. Реализация API реестра управляет загрузкой библиотеки DLL поставщика, вызовом библиотеки DLL для сбора данных о производительности и выгрузки библиотеки DLL соответствующим образом. Библиотека DLL поставщика отвечает за сбор данных о производительности соответствующим образом, например с помощью обычных api Windows, RPC, именованных каналов, общей памяти или других механизмов взаимодействия между процессами.
Поставщики версии 2 реализуются как программа пользовательского режима (часто служба Windows) или драйвер в режиме ядра. Обычно код поставщика данных производительности интегрируется непосредственно в существующий компонент (т. е. драйвер или служба сообщает статистику о себе). Реализация PerfLib V2 управляет запросами и ответами через расширение ядра PCW.sys, поэтому поставщику обычно не нужно реализовывать взаимодействие между процессами для предоставления данных о производительности.
Windows API счетчиков производительности и средства включают ограниченную поддержку доступа к счетчикам производительности с других компьютеров через удаленный реестр (для поставщиков версии 1) и RPC (для поставщиков версии 2). Часто эту поддержку трудно использовать с точки зрения элементов управления проверкой подлинности (средства и API могут проходить проверку подлинности только как текущий пользователь), а также с точки зрения конфигурации системы (необходимые конечные точки и службы отключены по умолчанию). Во многих случаях лучше получить доступ к счетчикам производительности удаленных систем через WMI , а не через встроенную поддержку удаленного доступа.
Устройство управления
Устройство управления (УУ) помогает процессору контролировать и выполнять инструкции. УУ сообщает компонентам, что именно нужно делать. В соответствии с инструкциями он координирует работу с другими частями компьютера, включая второй основной компонент — арифметико-логическое устройство (АЛУ). Все инструкции вначале поступают именно на устройство управления.
Существует два типа реализации УУ:
- УУ на жёсткой логике (англ. hardwired control units). Характер работы определяется внутренним электрическим строением — устройством печатной платы или кристалла. Соответственно, модификация такого УУ без физического вмешательства невозможна.
- УУ с микропрограммным управлением (англ. microprogrammable control units). Может быть запрограммирован для тех или иных целей. Программная часть сохраняется в памяти УУ.
УУ на жёсткой логике быстрее, но УУ с микропрограммным управлением обладает более гибкой функциональностью.
Требования к среде выполнения
Сведения о требованиях времени выполнения для определенного элемента программирования см. в разделе Requirements на справочной странице этого элемента.
Счетчик - устройство для подсчета числа входных импульсов. Счетчик можно реализовать на нескольких триггерах.
по модулю счёта:
с произвольным постоянным модулем счёта;
с переменным модулем счёта;
по направлению счёта:
по способу формирования внутренних связей:
с последовательным переносом;
Символом счетчиков на схемах служат буквы СТ (от англ. counter — счетчик), после символа проставляют число, характеризующее модуль счета (например, 2 или 10 — СТ2, СТ10).
Основными эксплуатационными показателями счетчика являются емкость и быстродействие. Емкость счетчика, численно равная коэффициенту счета, равна числу импульсов за один цикл.
В суммирующих счетчиках каждый входной импульс увеличивает число на его выходе на единицу, в вычитающих счетчиках каждый входной импульс уменьшает это число на единицу. Наиболее простые счетчики - двоичные. Счетчики можно реализовать на триггерах, которые соединяют последовательно. Выход каждого триггера действует на тактовый вход следующего. Для того чтобы реализовать суммирующий счетчик, необходимо счетный вход очередного триггера подключать к инверсному выходу предыдущего. Для того чтобы изменить направление счета (реализовать вычитающий счетчик), используют следующие способы:
а). считывание выходных сигналов счетчика не с прямых, а с инверсных выходов триггеров;
б). изменение структуры связей в счетчике. Подача на счетный вход следующего триггера сигнала не с инверсного, а с прямого выхода предыдущего триггера.
Реверсивный счетчик может работать в качестве суммирующего и вычитающего. Эти счетчики имеют дополнительные входы для задания направления счета. Режим работы определяется управляющими сигналами на этих входах. В программе EWB такие счетчики представлены ИМС 74163 и 74169 (К155ИЕ18, ИЕ17).
Главное достоинство счетчиков с последовательным переносом — простота схемы. Увеличение разрядности осуществляется подключением дополнительных триггеров к выходу последнего триггера. Основной недостаток счетчиков с последовательным переносом — сравнительно низкое быстродействие, поскольку триггеры срабатывают последовательно, один за другим. Счетчики этого класса в библиотеке EWB не представлены.
Счетчики с последовательным переносом представляют собой цепочку триггеров, в которой импульсы, подлежащие счету, поступают на вход первого триггера, а сигнал переноса передается последовательно от одного разряда к другому.
Счетчики с параллельным переносом состоят из синхронных триггеров. Счетные импульсы подаются одновременно на все тактовые входы, а каждый из триггеров цепочки служит по отношению к последующим только источником информационных сигналов. Срабатывание триггеров параллельного счетчика происходит синхронно, и задержка переключения всего счетчика равна задержке одного триггера. В таких счетчиках используются JK- и D-триггеры. В схемном отношении они сложнее счетчиков с последовательным переносом. Число разрядов у этих счетчиков обычно невелико (4. 6), поскольку с повышением числа разрядов число внутренних логических связей быстро растет.
Счетчики с параллельным переносом (их чаще называют синхронными) в библиотеке EWB представлены счетчиками 74160, 74162, 74163 и 74169 (аналоги — К155ИЕ9, ИЕН, ИЕ18, ИЕ17 соответственно).
Счетчики с параллельным переносом применяются в быстродействующих устройствах. Они обладают более высокой помехоустойчивостью, так как в паузах между импульсами триггеры счетчика блокированы. К их недостаткам следует отнести меньшую нагрузочную способность отдельных разрядов из-за дополнительной нагрузки внутренними связями. Каскад, предшествующий счетчику, должен иметь достаточную мощность, чтобы управлять входами нескольких триггеров.
Проектирование счетчика сводится к определению числа триггеров и организации связей между ними и логическими элементами, а также вычислению разрешающей способности счетчика (максимальной частоты счета).
Вопрос №36
Узлы как структурная единица ЭВМ, их типы.
Основные узлы ЭВМ.
Основными узлами ЭВМ являются :
- центральный процессор (ЦП)
- оперативная память (ОЗУ)
- постоянное запоминающее устройство (ПЗУ)
- внешняя память (ВЗУ)
- устройства Ввода (УВв)
- устройства Вывода (УВыв)
Все устройства ЭВМ подсоединены к единой ИНФОРМАЦИОННОЙ
Основные узлы ЭВМ объединены в следующую схему.
УУ |
АЛУ |
Ц П |
Системные программы |
ПЗУ |
Программа Данные Результаты |
ОЗУ |
Системная шина |
Устройства ВВОДА |
ВНЕШНЯЯ ПАМЯТЬ |
Устройства ВЫВОДА |
1. Центральный процессор
Главным элементом любой ЭВМ является ЦЕНТРАЛЬНЫЙ ПРОЦЕССОР . ЦП сосотоит из - Устройства Управления (УУ) - Арифметико-Логического устройства (АЛУ) |
Назначение ЦП : 1) Управление узлами компьютера
2) Обработка информации, которая сводится к
выполнению арифметических операций.
УУ - управляет работой ЭВМ, путем исполнения команд ПРОГРАММЫ. Рабочая программа хранится в ОЗУ. |
(АЛУ) Арифметико-логичеcкое устройство главный исполнительный орган ЭВМ. Назначение АЛУ - О Б Р А Б О Т К А ИНФОРМАЦИИ. Обработка информации сводится к выполнению арифметических операций. АЛУ выполняет над числами арифметические(+,-,умножить, делить) и логические( > , < , не равно и др.) операции |
Оперативная память (ОЗУ)
Назначение ОЗУ ОЗУ предназначена для хранения рабочей программы во время ее выполнения, а также данных, которые эта программа должна обработать и результатов обработки |
Вместе с программой в ОЗУ хранятся :
- ИСХОДНЫЕ ДАННЫЕ , которые программа обрабатывает
Пример: Вы рисуете на компьютере с помощью программы PAINT.
Где в этот момент хранится программа Paint и рисунок ? >
В оперативной памяти. Работающая программа и результат ее работы
находится в ОЗУ!
Рабочая программа находится в ОЗУ .
Недостатки ОЗУ ОЗУ современных ЭВМ является ЭНЕРГОЗАВИСИМОЙ. При выключении питания содержимое ОЗУ теряется. |
Главное достоинство ОЗУ ВЫСОКОЕ БЫСТРОДЕЙСТВИЕ . ОЗУ выполнена из электронных элементов, поэтому быстродействие ОЗУ сопоставимо с быстродействием ЦП. Это значит, что время чтения (записи) двоичного числа из (в) ОЗУ примерно равно времени , за которое ЦП выполняет одну операцию над парой чисел. |
Ответ : В принципе можно, но при этом резко упадет быстродействие ЭВМ (в 10 000 раз). Операции чтения записи с диска выполняются примерно в 10 000 раз медленнее, чем из электронных ячеек. |
Магнитная память обладает низким быстродействием (по сравнению с электронной памятью). Операции чтения записи с диска выполняются примерно в 10 000 раз медленнее, чем из электронных ячеек.
Если бы рабочая программа располагалась на диске, то ЦП большую часть времени пришлось бы простаивать в ожидании, пока будет прочитана очередная команда.
Работа компьютера сводится к чтению и исполнению команд программы. Поэтому быстродействие ЭВМ не может превысить, скорость чтения команд программы.
Чарльз Бэбидж - первый конструктор автоматической вычислительной машины, предполагал хранить программу на картонных картах.
1) До запуска все программы хранятся в .exe файлах на магнитном диске (винчестере). 2)После запуска программа копируются из .exe файла в ОЗУ. Зачем это делается? Для поддержки высокого быстродействия ЭВМ. (Что бы быстродействие ЭВМ было высоким, рабочая программа должна храниться в быстрой памяти, т.е. в ОЗУ) 3)После завершения выполнения очередной программы она удаляется из ОЗУ, тем самым освобождая место для запуска других программ. (программа удаляется только из ОЗУ, но остается в файле на диске) |
Ведь после выключения питания или перезагрузки ОЗУ очищается и не содержит никакой информации.
Первой в ОЗУ попадает ОПЕРАЦИОННАЯ СИСТЕМА. Она копируется из файлов на магнитном диске в ОЗУ.
Но чтобы выполнить это копирование, нужно запустить программу, специально для этого предназначенную. Ведь на компьютере все делается только с помощью программ.
Таковой программой является начальный загрузчик. ОН хранится в ПЗУ. НАЧАЛЬНЫЙ ЗАГРУЗЧИК стартует первым сразу при включении компьютера и копирует в ОЗУ ОС. Далее ОС включается в работу и управляет компьютером.
Инструмент проще, чем машина. Зачастую инструментом работают руками, а машину приводит в действие паровая сила или животное.
Компьютер тоже можно назвать машиной, только вместо паровой силы здесь электричество. Но программирование сделало компьютер таким же простым, как любой инструмент.
Процессор — это сердце/мозг любого компьютера. Его основное назначение — арифметические и логические операции, и прежде чем погрузиться в дебри процессора, нужно разобраться в его основных компонентах и принципах их работы.
Два основных компонента процессора
Команды (инструкции)
Команды — это фактические действия, которые компьютер должен выполнять. Они бывают нескольких типов:
- Арифметические: сложение, вычитание, умножение и т. д.
- Логические: И (логическое умножение/конъюнкция), ИЛИ (логическое суммирование/дизъюнкция), отрицание и т. д.
- Информационные: move , input , outptut , load и store .
- Команды перехода: goto , if . goto , call и return .
- Команда останова: halt .
Прим. перев. На самом деле все арифметические операции в АЛУ могут быть созданы на основе всего двух: сложение и сдвиг. Однако чем больше базовых операций поддерживает АЛУ, тем оно быстрее.
Инструкции предоставляются компьютеру на языке ассемблера или генерируются компилятором высокоуровневых языков.
В процессоре инструкции реализуются на аппаратном уровне. За один такт одноядерный процессор может выполнить одну элементарную (базовую) инструкцию.
Группу инструкций принято называть набором команд (англ. instruction set).
Выполнение инструкций
Инструкции хранятся в ОЗУ в последовательном порядке. Для гипотетического процессора инструкция состоит из кода операции и адреса памяти/регистра. Внутри управляющего устройства есть два регистра инструкций, в которые загружается код команды и адрес текущей исполняемой команды. Ещё в процессоре есть дополнительные регистры, которые хранят в себе последние 4 бита выполненных инструкций.
Ниже рассмотрен пример набора команд, который суммирует два числа:
- LOAD_A 8 . Это команда сохраняет в ОЗУ данные, скажем, . Первые 4 бита — код операции. Именно он определяет инструкцию. Эти данные помещаются в регистры инструкций УУ. Команда декодируется в инструкцию load_A — поместить данные 1000 (последние 4 бита команды) в регистр A .
- LOAD_B 2 . Ситуация, аналогичная прошлой. Здесь помещается число 2 ( 0010 ) в регистр B .
- ADD B A . Команда суммирует два числа (точнее прибавляет значение регистра B в регистр A ). УУ сообщает АЛУ, что нужно выполнить операцию суммирования и поместить результат обратно в регистр A .
- STORE_A 23 . Сохраняем значение регистра A в ячейку памяти с адресом 23 .
Вот такие операции нужны, чтобы сложить два числа.
Все данные между процессором, регистрами, памятью и I/O-устройствами (устройствами ввода-вывода) передаются по шинам. Чтобы загрузить в память только что обработанные данные, процессор помещает адрес в шину адреса и данные в шину данных. Потом нужно дать разрешение на запись на шине управления.
У процессора есть механизм сохранения инструкций в кэш. Как мы выяснили ранее, за секунду процессор может выполнить миллиарды инструкций. Поэтому если бы каждая инструкция хранилась в ОЗУ, то её изъятие оттуда занимало бы больше времени, чем её обработка. Поэтому для ускорения работы процессор хранит часть инструкций и данных в кэше.
Если данные в кэше и памяти не совпадают, то они помечаются грязными битами (англ. dirty bit).
Читайте также: