Вот, как просто! Балакиревская (автоматная) архитектура процессоров
Рано или поздно и Вы зададитесь вопросом, каким будет будущее процессоров. Достижения современных фабрик типа TSMC говорят, что достигнут максимум наших технологических возможностей. В результате каждый последующий технологический этап дается все большим трудом и многократно возрастающими затратами. Для транзисторов счет пошел на единицы атомов и потому, исчерпав возможность уменьшения их размеров, мы перешли к созданию многослойных «пирогов». Но и здесь не без проблем — например, отведение тепла или то же число слоев. Тем не менее, не все так плохо, т.к. есть варианты на уровне архитектур процессоров, которые не менее а, порой, даже более эффективны, чем новые технологические нормы. Об этом далее и поговорим…
Введение
Принстонская и Гарвардская архитектуры сформированы были на заре создания процессоров, но по сей день определяют основы вычислительных систем (подробнее см. [1]). Первая объединяет в единственном канале поток данных и команды программы, а вторая разделяет потоки команд, данных и стека. В результате для Принстонской архитектуры характерно наличие «бутылочного горлышка» и, соответственно, ограничение в производительности. Гарвардская же архитектура имеет множество параллельно работающих каналов, а это положительно влияет на скорость вычислительных процессов (подробнее см. [2]).
На уровне вычислительной модели, которую достаточно хорошо отражает структура языков программирования, различия упомянутых архитектур достаточно условно. Недостаток гарвардской архитектуры, связанный с неэффективным использованием памяти, на текущий момент фактически нивелирован аппаратными возможностями. Таким образом, увеличение числа каналов передачи данных не является уже проблемой и служит одним из важных ресурсов увеличения производительности вычислительных систем.
Но годы бегут, а, как и ранее, в современных программах можно выделить данные, команд, стек, ну и … все? Все остальное, что зачастую скрыто от глаз обычного программиста — многоуровневый кэш, длинные и короткие команды, предсказание команд и множество других «плюшек», в какой-то мере повышают производительность, но не настолько, чтобы это давало качественный скачек. Более того, эти механизмы могут даже негативно влиять на скорость вычислений. Серьезного прогресса теперь, похоже, можно достичь лишь путем изменения архитектуры вычислительной системы.
Ниже мы рассмотрим формальную модель, которая качественно изменяет архитектуру процессора и имеет все шансы увеличить вычислительную мощь системы. Речь пойдет об автоматном программировании (АП), модель которого рассмотрена достаточно подробно в [3]. Архитектуру на ее основе, которую по примеру упомянутых выше архитектур можно назвать по месту ее продвижения Балакиревской, мы далее и рассмотрим.
Функциональное разбиение
Разбиение программы на блоки позволяет организовать их эффективное чтение в промежуточную быструю память, с которой уже и работает центральный процессор. На роль таких блоков весьма хорошо подходят функции. Но, во-первых, они имеют большой разброс по размерам, а, во-вторых, существует большая вероятность, что в определенный момент будет работать только незначительная часть кода функции, что провоцирует большие накладные расходы на перемещение ее кода.
Технология автоматного программирования (АП) предлагает подход, естественным образом разбивающий программу на множество [небольших] функций, код которых при этом востребован в полном объеме. Такими функциями являются предикаты и действия автоматной программы. Можно ввести даже раздельную память для предикатов и действий. Так появляются уникальные возможности для тонкой оптимизации аппаратных средств, работающих с данными функциями.
Итак, имея общую медленную память, автоматные функции можно перемещать в быструю память и далее исполнять. В целях оптимизации из общего числа подобных функций можно выделять те, которые актуальны на текущем [дискретном] шаге исполнения программы. При этом предикаты будут актуальны всегда, а действия — лишь те, которые выбраны на текущем переходе автомата. Но даже, если ни одно из них не будет востребовано, это не сильно скажется на эффективности работы системы, т.к., например, при раздельных каналах памяти, загружаться действия будут параллельно предикатам.
Канал управления
Автоматная модель программ позволяет отделить логику управления программы от ее операторов и данных. И именно через это управление организуется эффективная блочная загрузка нужных функций. Выделение управления вводит в архитектуру еще один вид памяти и соответственно еще один канал передачи данных для таблиц переходов (ТП). Появляется возможность дальнейших оптимизаций, связанных с обработкой самих таблиц переходов автоматов и управления вычислительным процессом.
Для хранения ТП можно использовать более эффективную, чем обычная память, ассоциативную память [5]. Она, правда, дорогой ресурс, но поскольку она нужна в небольших объемах, то здесь ее применение вполне оправдано. Важно, что она используется здесь по своему прямому назначению: для поиска строки перехода по имени состояния программы и установки нового текущего состояния программы.
О параллелизме предикатов, действий и теневой памяти
Архитектура программ АП, кроме создания дополнительных каналов, формирует параллельные потоки исполнения кода внутри процессора. Это относится к [загруженным в быструю память] уже упомянутым предикатам и действиям. При этом предикаты автоматной программы параллельны по определению. Их можно запускать одновременно все или только те, которые необходимы в текущем состоянии автомата.
С действиями ситуация несколько сложнее. Имеет смысл загружать только те, которые актуальны для переходов из текущего состояния. Из них реально будут работать только действия активного перехода и, кстати, тоже параллельно. А чтобы корректно реализовать их параллелизм, действия должны использовать так называемую теневую память. Это еще один вид памяти, который поможет повысить эффективность работы вычислительной системы.
Заключение
Переход на автоматную архитектуру не отрицает имеющихся архитектур. Фактически идет речь о расширении последних. Совместное существование архитектур заключается в том, что на уровне функций работает обычная архитектура, а на уровне управления — автоматная. Но и при программной интерпретации автоматной модели, как в нынешней ситуации, АП зачастую более эффективно, чем существующие средства программирования, несмотря даже на поддержку последних аппаратными средствами. Речь идет о параллельном программировании — многопоточном и многоядерном.
Хотелось бы упомянуть предтечи автоматной архитектуры. Это, например, машины клеточных автоматов [6]. Схожие принципы положены в основу графических процессоров, да и собственно нейронные сети — это множество функционирующих параллельно нейронов, которые изначально замышлялись, как достаточно простые автоматные модели (см. определение нейронных сетей в [7]).
Подведем итог. Гарвардская архитектура «на пальцах» примерно в три раза эффективнее Принстонской. Автоматная по числу каналов должна быть в пять раз эффективнее Принстонской и почти в два раза — Гарвардской. Но все это без учета возможностей распараллеливания, которое вносят еще больший вклад в увеличение скорости процессора. Сюда же можно отнести работу с управлением и теневой памятью. Но еще есть новые механизмы синхронизация [автоматных] параллельных процессов на базе непосредственного доступа к их состояниям. Это заменяет нынешние тяжеловесные и неэффективные приемы синхронизации (семафоры, мютексы и т.п.). А, ведь, последние вносят, пожалуй, основной вклад в снижение скорости работы параллельных программ. Если бы не было нужды в синхронизации, то скорость вычислений увеличивалась бы пропорционально числу процессорных ядер. Однако практика подтверждает, что современное распараллеливание чаще негативно, чем позитивно, сказывается на скорости работы программ.
Ну, и как вы теперь смотрите на будущее процессоров? Если технологические возможности почти исчерпаны, то, может, пора изменить архитектурные принципы организации вычислений? Или, что точнее, перейти на более совершенные вычислительные модели. Модель автоматных программ этому пример. При этом она, в отличие, например, от того же функционального программирования, реализует «мягкий режим» перехода на новое мышление, не отказываясь от уже проверенной временем модели программирования.
Приложение. Пример автоматного алгоритма
На рис. 1 приведен алгоритм управления гильотиной, заимствованный из реального проекта системы управления линией прокатки металла. Функционально она мало чем отличается от своего аналога времен Великой французской революции. Технологический прогресс добавил ей датчики положения да сигналы управления электроприводом. И если раньше ею управлял человек (оставим в стороне его профессию), то сейчас его функции исполняет система управления. Ей в данном примере соответствуют два взаимодействующих и параллельно работающих автомата — контроль состояния датчиков гильотины и собственно управление гильотиной. Отметим, что в реальной системе к этим автоматам добавляется, порой, еще пара десятков таких же [параллельных] автоматов.
Приведенные автоматы демонстрируют описанные выше моменты распараллеливания программного кода в рамках автоматной архитектуры. Для сравнения автоматной модели с текущей моделью фон Неймана на рис. 3, 4 показаны эквивалентные автоматам модели в форме блок-схем. Они демонстрируют, как простой заменой модели управления можно перейти к качественно иной модели программирования. На фоне блок-схем преимущества автоматной модели достаточно очевидны. Не рассмотреть, что состояния автомата являются своеобразными точками распараллеливания алгоритмов и синхронизации параллельных процессов и оценить подобную возможность, не способны только программисты, мозг которых поражен многопоточным и «корутинным» мышлением.
Надо также отметить, что хотя известна формальная процедура, позволяющая для любой блок-схемы найти эквивалентный ей автомат, и, следовательно, [автоматически] выявить параллельно исполняемые блоки кода программы, тем не менее, важно и целесообразно изначально «мыслить» именно автоматными моделями. Именно это реализует ВКПа — технологии объектного визуального автоматного проектирования программ на языке С++.
Рис. 1. Модель управления гильотиной
Но даже если возможности аппаратных и программных средств достаточно ограничены, что присуще, например, программированию на базе ПЛК в рамках стандарта МЭК- 61131–3 (подробнее см. ГОСТ Р МЭК 61131–3–2016), существуют весьма простые приемы, которые, пусть и в ограниченном объеме, но позволяют насладиться возможностями АП даже в подобных случаях. Все это помогает реально «прощупать» возможности автоматной архитектуры, оставаясь в рамах существующих языков программирования и аппаратных архитектур. Но демонстрацией и обсуждением этого мы, надеюсь, займемся в другой раз.
Рис. 2. Блок-схема алгоритма управления гильотиной
Рис. 3. Блок-схема алгоритма контроля положения гильотины
Литература
1. Архитектура вычислительных машин. [Электронный ресурс], Режим доступа: https://prog-cpp.ru/comp-architecture/, свободный. Яз. рус. (дата обращения 18.07.2022).
2. Бэкус Дж. Можно ли освободить программирование от стиля фон Неймана? Функциональный стиль и соответствующая алгебра программ. [Электронный ресурс], Режим доступа: http://rkka21.ru/docs/turing-award/jb1977r.pdf, свободный. Яз. рус. (дата обращения 18.07.2022).
3. Автоматная модель управления программ. [Электронный ресурс], Режим доступа: https://habr.com/ru/post/484588/, свободный. Яз. рус. (дата обращения 18.07.2022).
4. Рылов С. Языки программирования стандарта МЭК 61131–3. [Электронный ресурс], Режим доступа: https://finestart.school/media/programming_languages, свободный. Яз. рус. (дата обращения 18.07.2022).
5. Фостер К. Ассоциативные параллельные процессоры: Пер. с англ. — М.: Энергоиздат, 1981. — 240 с.
6. Тоффоли Т., Марголус Н. Машины клеточных автоматов: Пер. с англ. — М.: Мир, 1991. — 280 с.
7. Минский М. Вычисления и автоматы. М.: Мир, 1971. — 364 с.
