О неулучшаемой архитектуре процессоров
Читая интервью Бориса Бабаяна, обратил внимание на его фразу о «неулучшаемой архитектуре процессора».
Можно ли сделать такую? Чтобы после её изобретения наступил теоретический тупик? Да, занятная задача.
Цитирую одного из «отцов» Эльбруса:
Суперскаляр я раскритиковал, вместо него мы разработали свой подход, который дальше уже просто неулучшаемый.
Конечно, теоретически это трудно доказать, но и трудно опровергнуть.
Как я всегда говорю, вычислительная техника — это схема архитектуры из конечного числа дискретных компонентов. Их много, но конечное число.
Теоретически конечное число дискретных элементов имеет конечное число реализаций, хотя и баснословно большое.
Из этого конечного числа реализаций — одна наилучшая. Ее просто нужно найти.
Прежде, чем обсудить эти «улучшения», которые могут в каких-то случаях упереться в «неулучшаемость», давайте рассмотрим, что является лучшим с точки зрения процессоров.
Многие года гонка процессоров шла только в одном направлении — кто быстрее.
Достичь большей производительности стремились любой ценой. Ради этого можно было пойти на всё:
и на огромную потребляемую мощность, и на жидкостное охлаждение, и на цены с шестью нулями.
Исторически позже появились и другие направления развития.
Например, появились архитектуры, в которых борются за энергоэффективность: за единицу потреблённой энергии исполнить наибольшее количество команд.
Есть так же архитектуры, которые выбрали «золотую середину», они борются за хорошую производительность при хорошей энергоэффективности.
К первому направлению (с известными допусками и условностями) можно отнести архитектуру x86, ко второму — ARM, к третьему — MIPS.
В этой статье пойдёт речь о первом направлении развития — скорости исполнения.
Во времена учёбы в альма-матер у нас была курсовая работа, посвящённая проектированию отдельных узлов процессора, выполняющих какие-либо команды.
Мне в задании досталась команда левого логического сдвига. Мои однокурсники с разной степенью успеха начали рисовать схемы: триггеры, регистры, счётчики…
А мне было лень.
Как всякий ленивый человек, начал искать, нельзя ли придумать что-нибудь по-проще,
Несколько дней лени привели меня к идее, что ничего побитно сдвигать не надо.
У команды — два операнда. Некоторый набор входных данных даёт на выходе некий набор результатов.
Два регистра с 264 вариантами значений дают на выходе 232 варианта результата.
А для 232 вариантов результата нужно просто иметь в схеме такое же количество дешифраторов.
Каждый из них должен опознать свою комбинацию битов на входе, чтобы выдать свою выходную последовательность битов.
Поскольку логических вентилей в этой схеме было более, чем много, то нарисовать всё это не хватило бы никакой бумаги.
Лень и тут подсказала выход. Ведь пишут же математики «X1, X2, ... Xn».
Вот и я нарисовал первый дешифратор, второй, многоточия и последний дешифратор.
Плюс к этому дорисовал подачу сигнала, что результат готов. Вот и всё, курсовое работа выполнена.
Представляя свою работу, отметил достоинство такой схемы: результат вычисляется за один такт!
Борис Яковлевич Никитин, мой преподаватель, сперва удивился, потом похвалил за нестандартный подход и сделал вывод, что тема понята глубоко.
Отметил, что такой принцип работы применяется в некоторых спецвычислителях.
Так я повторно открыл кем-то уже открытую Америку.
Можно дальше порассуждать о такой схеме с дешифраторами. Подобный подход применим ко всем операциям.
Это своего рода мемоизация, имеющая место быть в функциональных языках. Вместо того, чтобы всё вычислять, можно просто всё помнить.
Поэтому в теории входные значения можно за один такт преобразовывать в выходные. Один такт — это и есть теоретический предел.
Бабаян говорит о неулучшаемости, которую трудно доказать, но и трудно опровергнуть.
Так вот представленные выше рассуждения делают доказательство лёгким, а опровержение невозможным.
Однако легко получить встречный резонный вопрос: а возможно ли воплотить на кристалле процессор с такой «дешифраторной» архитектурой?
Такая схема потребует миллиарды миллиардов логических вентилей и нереализуема при современном состоянии электронной промышлености.
Однако теоретический тупик вполне научно обозрим.
Так же внимательный читатель может заметить, что изложенные выше рассуждения исходят из наивного предположения,
что на выход логического вентиля можно посадить миллиарды входов дешифраторов.
Естественно, это невозможно. Нужны всякие повторители-усилители сигнала.
Если порассуждать о пользе и практическом применении такой архитектуры, то её элементы вполне применимы.
На «ускорение» напрашиваются самые «дорогостоящие» машинные операции — умножение и особенно деление.
Можно разбить операнды на куски, допустим, по 8 бит. Это значительно облегчит схему, сделает реализуемой по современным технологиям.
P.S. Лет 15 спустя после упомянутой курсовой работы встретил Бориса Яковлевича.
А он жалуется, что его предмет «Теоретические основы вычислительной техники» больше не преподают.
Он возмущался: «Как можно изучать вычислительную технику, не зная её основ?!»
Что ж, «обучение навыкам» вместо обретения «бесполезных знаний» начали задолго до Грефа.
Но это — тема совсем другой истории.
Опубликовано: 2020.12.29, последняя правка: 2021.01.07 14:01
Отзывы
2021/01/06 09:59, MihalNik #
Процессор вообще не достаточно точное понятие в смысле неопределенности решаемых задач. Так что неулучшаемое точно им не будет в том, смысле, в каком это слово понимается 99,99% людьми, хоть как-то понимающих архитектуру.
2021/01/06 15:34, Автор сайта #
Наверное, можно создать неулучшаемую архитектуру для определённой системы команд. Но это будет теоретическая модель, в которую реальная жизнь внесёт свои поправки. Было бы интересно подумать о неулучшаемой системе команд и о создании на её базе неулучшаемой архитектуры :)неопределенности решаемых задач Для узкого круга задач иногда создаются специализированные процессоры. В статье есть ссылка на спецвычислитель 5Э53. Он выигрывал у универсальных процессоров, которые ориентированы на очень широкий круг задач. Добавить свой отзыв
Написать автору можно на электронную почту mail(аt)compiler.su
|