Файл: Архитектура вычислительных систем Способы ускорения традиционных архитектур вс.rtf
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 29.11.2023
Просмотров: 69
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Мультипоточность данных.
Многопоточностью (multithreading) называется способность операционной системы поддерживать в рамках одного процесса выполнение нескольких потоков. Традиционный подход, при котором каждый процесс представляет собой единый поток выполнения, называется однопоточным подходом. Две левые части рис. 10 иллюстрируют однопоточные подходы. MS DOS является примером операционной системы, способной поддерживать не более одного однопоточного пользовательского процесса. Другие операционные системы, такие, как разнообразные разновидности UNIX, поддерживают процессы множества пользователей, но в каждом из этих процессов может содержаться только один поток. В правой половине рис. 10 представлены многопоточные подходы. Примером системы, в которой один процесс может расщепляться на несколько потоков, является среда выполнения Java. Нас будет интересовать использование нескольких процессов, каждый из которых поддерживает выполнение нескольких потоков. Подобный подход принят в таких операционных системах, как OS/2, Windows 2000 (W2K), Linux, Solaris, Mach, и ряде других.
Рис. 10. Потоки и процессы [ANDE97] Выполнение машинных команд
В многопоточной среде процесс определяется как структурная единица распределения ресурсов, а также структурная единица защиты. С процессами связаны следующие элементы.
Виртуальное адресное пространство, в котором содержится образ процесса.
Защищенный доступ к процессорам, другим процессам (при обмене информацией между ними), файлам и ресурсам ввода-вывода (устройствам и каналам).
В рамках процесса могут находиться один или несколько потоков, каждый из которых обладает следующими характеристиками.
Состояние выполнения потока (выполняющийся, готовый к выполнению и т.д.).
Сохраненный контекст не выполняющегося потока; один из способов рассмотрения потока — считать его независимым счетчиком команд, работающим в рамках процесса.
Стек выполнения.
Статическая память, выделяемая потоку для локальных переменных.
Доступ к памяти и ресурсам процесса, которому этот поток принадлежит; этот доступ разделяется всеми потоками данного процесса.
На рис. 11 продемонстрировано различие между потоками и процессами с точки зрения управления последними. В однопоточной модели процесса в его представление входит управляющий блок этого процесса и пользовательское адресное пространство, а также стеки ядра и пользователя, с помощью которых осуществляются вызовы процедур и возвраты из них при выполнении процесса. Когда выполнение процесса прерывается, содержимое регистров процессора сохраняется в памяти. В многопоточной среде с каждым процессом тоже связаны управляющий блок и адресное пространство, но теперь для каждого потока создаются свои отдельные стеки, а также свой управляющий блок, в котором содержатся значения регистров, приоритет и другая информация о состоянии потока.
Рис. 11. Однопоточная и многопоточная модели процесса
Таким образом, все потоки процесса разделяют между собой состояние и ресурсы этого процесса. Они находятся в одном и том же адресном пространстве и имеют доступ к одним и тем же данным. Если один поток изменяет в памяти какие-то данные, то другие потоки во время своего доступа к этим данным имеют возможность отследить эти изменения. Если один поток открывает файл с правом чтения, другие потоки данного процесса тоже могут читать из этого файла.
Перечислим основные преимущества использования потоков с точки зрения производительности:
-Создание нового потока в уже существующем процессе занимает намного меньше времени, чем создание совершенно нового процесса. Исследования, проведенные разработчиками операционной системы Mach, показали, что скорость создания процессов по сравнению с такой же скоростью в UNIX-совместимых приложениях, в которых не используются потоки, возрастает в 10 раз [TEVA87].
-Поток можно завершить намного быстрее, чем процесс.
-Переключение потоков в рамках одного и того же процесса происходит намного быстрее.
-При использовании потоков повышается эффективность обмена информацией между двумя выполняющимися программами. В большинстве операционных систем обмен между независимыми процессами происходит с участием ядра, в функции которого входит обеспечение защиты и механизма, необходимого для осуществления обмена. Однако благодаря тому, что различные потоки одного и того же процесса используют одну и ту же область памяти и одни и те же файлы, они могут обмениваться информацией без участия ядра.
Итак, если приложение или функцию нужно реализовать в виде набора взаимосвязанных модулей, намного эффективнее реализовать ее в виде набора потоков, чем в виде набора отдельных процессов.
Примером приложения, в котором можно удачно применить потоки, является файловый сервер. При получении каждого нового файлового запроса программа управления файлами может порождать новый поток. Из-за того, что серверу приходится обрабатывать очень большое количество запросов, за короткий промежуток времени будут создаваться и удаляться множество потоков. Если такая серверная программа работает на многопроцессорной машине, то на разных процессорах в рамках одного процесса могут одновременно выполняться несколько потоков. Кроме того, из-за того, что процессы или потоки файлового сервера должны совместно использовать данные из файлов, а следовательно, координировать свои действия, рациональнее использовать потоки и общую область памяти, а не процессы и обмен сообщениями.
Потоковая конструкция процесса полезна и на однопроцессорных машинах. Она помогает упростить структуру программы, выполняющей несколько логически различных функций.
В [LETW88] приводится четыре следующих примера использования потоков в однопользовательской многозадачной системе.
Работа в приоритетном и фоновом режимах. В качестве примера можно привести программу электронных таблиц, в которой один из потоков может отвечать за отображение меню и считывать ввод пользователя, а другой — выполнять команды пользователя и обновлять таблицу. Такая схема часто увеличивает воспринимаемую пользователем скорость работы приложения, позволяя пользователю начать ввод следующей команды еще до завершения выполнения предыдущей.
Асинхронная обработка. Элементы асинхронности в программе можно реализовать в виде потоков. Например, в качестве меры предосторожности на случай отключения электричества можно сделать так, чтобы текстовый редактор каждую минуту сбрасывал на диск содержимое буфера оперативного запоминающего устройства. Можно создать поток, единственной задачей которого будет создание резервной копии и который будет планировать свою работу непосредственно с помощью операционной системы. Это позволит обойтись без помещения в основную программу замысловатого кода, обеспечивающего проверку соблюдения временного графика или координацию ввода и вывода.
Скорость выполнения. Многопоточный процесс может производить вычисления с одной порцией данных, одновременно считывая с устройства ввода-вывода следующую порцию. В многопроцессорной системе несколько потоков одного и того же процесса могут выполняться одновременно.
Модульная структура программы. Программы, осуществляющие разнообразные действия или выполняющие множество вводов из различных источников и выводов в разные места назначения, легче разрабатывать и реализовывать с помощью потоков.
Планирование и диспетчеризация осуществляются на основе потоков; таким образом, большая часть информации о состоянии процесса, имеющей отношение к его выполнению, поддерживается в структурах данных на уровне потоков. Однако есть несколько действий, которые затрагивают все потоки процесса и которые операционная система должна поддерживать именно на этом уровне. Если процесс приостанавливается, то при этом предполагается, что его адресное пространство будет выгружено из основной памяти. Поскольку все потоки процесса используют одно и то же адресное пространство, все они должны одновременно перейти в состояние приостановленных. Соответственно прекращение процесса приводит к прекращению всех составляющих его потоков.
Сокращенные системы команд
Компьютеры с сокращенным набором команд (КСНК) или в английском варианте RISC-Reduced Instruction Set Computer как направление развития архитектуры ЭВМ воплощает подход, связанный с возвращением к принципам аппаратного управления выполнением команд с целью повышения производительности. Система команд первого и частично второго поколений машин содержали не более пятидесяти команд. Основная проблема, по которой набор команд не расширялся - это цена аппаратуры (и управляющая, и обрабатывающая части процессора реализовывались аппаратно), а также необходимость программирования в кодах (программист не мог запомнить большое количество команд). Период доминирования аппаратного управления: 50-е - начало 60-х годов можно назвать «эра аппаратчиков».
С середины 60-х до 80-х годов доминирует микропрограммное управление выполнением команд, воплощающее «эру программистов», основным лозунгом которой было: «Больше команд хороших и разных!». Этот лозунг соответствовал основным требованиям к процессорам того времени:
Минимизация длины кода программы
вычислительный среда кэш команда
Упрощения реализации компиляторов за счет снижения семантического разрыва между ЯВУ и машинными командами.
Это вызвало рост набора команд компьютеров за счет увеличения их сложности и увеличения числа форматов от 50 до 300 команд (рекордсменом был Vaх11/780, у него было 303 команды). Компьютеры с большим набором команд и разнообразием их форматов получили название CISC компьютеров (Complex Instruction Set Computer – машины со сложным набором команд). Для них характерно увеличение сложности и соответственно размеров микропрограммного устройства управления, которое интерпретировало выполнение этих команд. К этому времени благодаря технологическим достижениям тактовая частота процессоров стала достигать 100Мгц и повышение производительности требовало размещения всех частей процессора на одном кристалле для сокращения длины соединений его элементов. В то же время микропрограммное управление из-за своей сложности стало занимать до шестидесяти процентов площади кристалла, что либо не допускало использования эффективных средств арифметической обработки данных, либо требовало размещения частей процессора на разных кристаллах. Все это приводило к существенному ограничению производительности, увеличивало сроки разработки и снижало выход годных кристаллов.
В 80-х годах рядом исследователей было замечено, что при выполнении большинства программ наиболее активно используется около 30% сравнительно простых команд арифметики и управления. Постепенно стало формироваться направление развития архитектуры компьютеров, требующее чтобы система команд процессора содержала минимальный набор наиболее часто используемых и наиболее простых команд (возврат к примерно 50 командам). Это направление получило название - КСНК (компьютеры с сокращенным набором команд) или RISC (Reduced Instruction Set Computer) – и имеет лозунг: «Меньше команд, выше скорость выполнения!». В результате в конце 80-х г.г. благодаря развитию технологии производства СБИС и их удешевлению, а также развитию методов и опыта разработки оптимизирующих компиляторов постепенно сложились основные принципы (или законы) RISC-архитектур:
Основной набор команд не должен интерпретироваться микрокомандами, а должен выполняться аппаратным обеспечением. Все команды должны иметь одинаковую длину и минимальное число форматов (обычно не более 2-3), это упрощает логику управления при выборе и при исполнении команды. Любая команда основного набора должна выполняться за один машинный цикл, обратно пропорциональный тактовой частоте процессора (стандартом является команда сложения регистра с регистром, занимающая от 3 – 10нс.); это достигается одновременным (параллельным) выполнением максимально возможного числа команд путем конвейеризации или использования нескольких обрабатывающих узлов. Обращение к памяти производиться только по специально выделенным командам работы с памятью типа: Load – загрузка и Store – сохранение, а вся обработка данных должна вестись в регистровом формате; при этом количество регистров должно быть велико (100 и более). Система команд должна обеспечивать поддержку компиляции с конкретного языка программирования (компиляторы для RISC на порядок сложнее, чем компиляторы для CISC).
Многопоточностью (multithreading) называется способность операционной системы поддерживать в рамках одного процесса выполнение нескольких потоков. Традиционный подход, при котором каждый процесс представляет собой единый поток выполнения, называется однопоточным подходом. Две левые части рис. 10 иллюстрируют однопоточные подходы. MS DOS является примером операционной системы, способной поддерживать не более одного однопоточного пользовательского процесса. Другие операционные системы, такие, как разнообразные разновидности UNIX, поддерживают процессы множества пользователей, но в каждом из этих процессов может содержаться только один поток. В правой половине рис. 10 представлены многопоточные подходы. Примером системы, в которой один процесс может расщепляться на несколько потоков, является среда выполнения Java. Нас будет интересовать использование нескольких процессов, каждый из которых поддерживает выполнение нескольких потоков. Подобный подход принят в таких операционных системах, как OS/2, Windows 2000 (W2K), Linux, Solaris, Mach, и ряде других.
Рис. 10. Потоки и процессы [ANDE97] Выполнение машинных команд
В многопоточной среде процесс определяется как структурная единица распределения ресурсов, а также структурная единица защиты. С процессами связаны следующие элементы.
Виртуальное адресное пространство, в котором содержится образ процесса.
Защищенный доступ к процессорам, другим процессам (при обмене информацией между ними), файлам и ресурсам ввода-вывода (устройствам и каналам).
В рамках процесса могут находиться один или несколько потоков, каждый из которых обладает следующими характеристиками.
Состояние выполнения потока (выполняющийся, готовый к выполнению и т.д.).
Сохраненный контекст не выполняющегося потока; один из способов рассмотрения потока — считать его независимым счетчиком команд, работающим в рамках процесса.
Стек выполнения.
Статическая память, выделяемая потоку для локальных переменных.
Доступ к памяти и ресурсам процесса, которому этот поток принадлежит; этот доступ разделяется всеми потоками данного процесса.
На рис. 11 продемонстрировано различие между потоками и процессами с точки зрения управления последними. В однопоточной модели процесса в его представление входит управляющий блок этого процесса и пользовательское адресное пространство, а также стеки ядра и пользователя, с помощью которых осуществляются вызовы процедур и возвраты из них при выполнении процесса. Когда выполнение процесса прерывается, содержимое регистров процессора сохраняется в памяти. В многопоточной среде с каждым процессом тоже связаны управляющий блок и адресное пространство, но теперь для каждого потока создаются свои отдельные стеки, а также свой управляющий блок, в котором содержатся значения регистров, приоритет и другая информация о состоянии потока.
Рис. 11. Однопоточная и многопоточная модели процесса
Таким образом, все потоки процесса разделяют между собой состояние и ресурсы этого процесса. Они находятся в одном и том же адресном пространстве и имеют доступ к одним и тем же данным. Если один поток изменяет в памяти какие-то данные, то другие потоки во время своего доступа к этим данным имеют возможность отследить эти изменения. Если один поток открывает файл с правом чтения, другие потоки данного процесса тоже могут читать из этого файла.
Перечислим основные преимущества использования потоков с точки зрения производительности:
-Создание нового потока в уже существующем процессе занимает намного меньше времени, чем создание совершенно нового процесса. Исследования, проведенные разработчиками операционной системы Mach, показали, что скорость создания процессов по сравнению с такой же скоростью в UNIX-совместимых приложениях, в которых не используются потоки, возрастает в 10 раз [TEVA87].
-Поток можно завершить намного быстрее, чем процесс.
-Переключение потоков в рамках одного и того же процесса происходит намного быстрее.
-При использовании потоков повышается эффективность обмена информацией между двумя выполняющимися программами. В большинстве операционных систем обмен между независимыми процессами происходит с участием ядра, в функции которого входит обеспечение защиты и механизма, необходимого для осуществления обмена. Однако благодаря тому, что различные потоки одного и того же процесса используют одну и ту же область памяти и одни и те же файлы, они могут обмениваться информацией без участия ядра.
Итак, если приложение или функцию нужно реализовать в виде набора взаимосвязанных модулей, намного эффективнее реализовать ее в виде набора потоков, чем в виде набора отдельных процессов.
Примером приложения, в котором можно удачно применить потоки, является файловый сервер. При получении каждого нового файлового запроса программа управления файлами может порождать новый поток. Из-за того, что серверу приходится обрабатывать очень большое количество запросов, за короткий промежуток времени будут создаваться и удаляться множество потоков. Если такая серверная программа работает на многопроцессорной машине, то на разных процессорах в рамках одного процесса могут одновременно выполняться несколько потоков. Кроме того, из-за того, что процессы или потоки файлового сервера должны совместно использовать данные из файлов, а следовательно, координировать свои действия, рациональнее использовать потоки и общую область памяти, а не процессы и обмен сообщениями.
Потоковая конструкция процесса полезна и на однопроцессорных машинах. Она помогает упростить структуру программы, выполняющей несколько логически различных функций.
В [LETW88] приводится четыре следующих примера использования потоков в однопользовательской многозадачной системе.
Работа в приоритетном и фоновом режимах. В качестве примера можно привести программу электронных таблиц, в которой один из потоков может отвечать за отображение меню и считывать ввод пользователя, а другой — выполнять команды пользователя и обновлять таблицу. Такая схема часто увеличивает воспринимаемую пользователем скорость работы приложения, позволяя пользователю начать ввод следующей команды еще до завершения выполнения предыдущей.
Асинхронная обработка. Элементы асинхронности в программе можно реализовать в виде потоков. Например, в качестве меры предосторожности на случай отключения электричества можно сделать так, чтобы текстовый редактор каждую минуту сбрасывал на диск содержимое буфера оперативного запоминающего устройства. Можно создать поток, единственной задачей которого будет создание резервной копии и который будет планировать свою работу непосредственно с помощью операционной системы. Это позволит обойтись без помещения в основную программу замысловатого кода, обеспечивающего проверку соблюдения временного графика или координацию ввода и вывода.
Скорость выполнения. Многопоточный процесс может производить вычисления с одной порцией данных, одновременно считывая с устройства ввода-вывода следующую порцию. В многопроцессорной системе несколько потоков одного и того же процесса могут выполняться одновременно.
Модульная структура программы. Программы, осуществляющие разнообразные действия или выполняющие множество вводов из различных источников и выводов в разные места назначения, легче разрабатывать и реализовывать с помощью потоков.
Планирование и диспетчеризация осуществляются на основе потоков; таким образом, большая часть информации о состоянии процесса, имеющей отношение к его выполнению, поддерживается в структурах данных на уровне потоков. Однако есть несколько действий, которые затрагивают все потоки процесса и которые операционная система должна поддерживать именно на этом уровне. Если процесс приостанавливается, то при этом предполагается, что его адресное пространство будет выгружено из основной памяти. Поскольку все потоки процесса используют одно и то же адресное пространство, все они должны одновременно перейти в состояние приостановленных. Соответственно прекращение процесса приводит к прекращению всех составляющих его потоков.
Сокращенные системы команд
Компьютеры с сокращенным набором команд (КСНК) или в английском варианте RISC-Reduced Instruction Set Computer как направление развития архитектуры ЭВМ воплощает подход, связанный с возвращением к принципам аппаратного управления выполнением команд с целью повышения производительности. Система команд первого и частично второго поколений машин содержали не более пятидесяти команд. Основная проблема, по которой набор команд не расширялся - это цена аппаратуры (и управляющая, и обрабатывающая части процессора реализовывались аппаратно), а также необходимость программирования в кодах (программист не мог запомнить большое количество команд). Период доминирования аппаратного управления: 50-е - начало 60-х годов можно назвать «эра аппаратчиков».
С середины 60-х до 80-х годов доминирует микропрограммное управление выполнением команд, воплощающее «эру программистов», основным лозунгом которой было: «Больше команд хороших и разных!». Этот лозунг соответствовал основным требованиям к процессорам того времени:
Минимизация длины кода программы
вычислительный среда кэш команда
Упрощения реализации компиляторов за счет снижения семантического разрыва между ЯВУ и машинными командами.
Это вызвало рост набора команд компьютеров за счет увеличения их сложности и увеличения числа форматов от 50 до 300 команд (рекордсменом был Vaх11/780, у него было 303 команды). Компьютеры с большим набором команд и разнообразием их форматов получили название CISC компьютеров (Complex Instruction Set Computer – машины со сложным набором команд). Для них характерно увеличение сложности и соответственно размеров микропрограммного устройства управления, которое интерпретировало выполнение этих команд. К этому времени благодаря технологическим достижениям тактовая частота процессоров стала достигать 100Мгц и повышение производительности требовало размещения всех частей процессора на одном кристалле для сокращения длины соединений его элементов. В то же время микропрограммное управление из-за своей сложности стало занимать до шестидесяти процентов площади кристалла, что либо не допускало использования эффективных средств арифметической обработки данных, либо требовало размещения частей процессора на разных кристаллах. Все это приводило к существенному ограничению производительности, увеличивало сроки разработки и снижало выход годных кристаллов.
В 80-х годах рядом исследователей было замечено, что при выполнении большинства программ наиболее активно используется около 30% сравнительно простых команд арифметики и управления. Постепенно стало формироваться направление развития архитектуры компьютеров, требующее чтобы система команд процессора содержала минимальный набор наиболее часто используемых и наиболее простых команд (возврат к примерно 50 командам). Это направление получило название - КСНК (компьютеры с сокращенным набором команд) или RISC (Reduced Instruction Set Computer) – и имеет лозунг: «Меньше команд, выше скорость выполнения!». В результате в конце 80-х г.г. благодаря развитию технологии производства СБИС и их удешевлению, а также развитию методов и опыта разработки оптимизирующих компиляторов постепенно сложились основные принципы (или законы) RISC-архитектур:
Основной набор команд не должен интерпретироваться микрокомандами, а должен выполняться аппаратным обеспечением. Все команды должны иметь одинаковую длину и минимальное число форматов (обычно не более 2-3), это упрощает логику управления при выборе и при исполнении команды. Любая команда основного набора должна выполняться за один машинный цикл, обратно пропорциональный тактовой частоте процессора (стандартом является команда сложения регистра с регистром, занимающая от 3 – 10нс.); это достигается одновременным (параллельным) выполнением максимально возможного числа команд путем конвейеризации или использования нескольких обрабатывающих узлов. Обращение к памяти производиться только по специально выделенным командам работы с памятью типа: Load – загрузка и Store – сохранение, а вся обработка данных должна вестись в регистровом формате; при этом количество регистров должно быть велико (100 и более). Система команд должна обеспечивать поддержку компиляции с конкретного языка программирования (компиляторы для RISC на порядок сложнее, чем компиляторы для CISC).