Сегодня Россия находится в сложной ситуации не только с производством микропроцессоров, но и с разработкой его архитектуры. Тайваньские фабрики официально до сих пор закрыты для нас, а единственная российская процессорная архитектура, использующаяся в процессорах Эльбрус, не очень подходит для ПК.
Но либо тайваньские фабрики рано или поздно откроются, либо в России начнут производить рентгеновские литографы для оборудования ими литографических линий отечественных фабрик, либо так и будем продолжать ввозить из-за рубежа малыми партиями кремниевые пластины, резать их тут и корпусировать. Так что вопрос с производством так или иначе рано или поздно решится.
А вот что делать с архитектурой микропроцессора? Есть ли возможность как-то адаптировать её к десктопным применениям? Или надо начать всё сначала и разработать новую архитектуру с учётом уже полученного опыта?
В идеале, архитектуру процессора и систему его команд нужно разрабатывать с прицелом на наиболее эффективное её применение сегодня и с прицелом на два-три ближайших десятилетия. А для этого нужно понимать, какие математические задачи стоят перед современными компьютерами и каким образом лучше построить алгоритмику их решений.
То есть, «железо» надо подтаскивать к задачам и математическим приёмам их решения, а ПО подтягивать к «железу» для наиболее эффективного выполнения необходимых алгоритмов на нём. То есть, для получения максимального вычислительного эффекта должна быть максимально возможная взаимоувязка «железа» и «софта».
Всё это так или иначе приводит нас к мысли, что микропроцессорная архитектура у нас в России должна быть одна, пусть по разному реализованная в «железе» разными компаниями, как это происходит, скажем, у AMD и Intel, а чуть ранее у Cyrix и ещё нескольких производителей. Тогда разработчики ПО смогут отказаться от кроссплатформенности, соблюдение которой отжирает уйму времени и рождает унифицированный, а значит, не самый эффективный код.
Но как определиться с этой архитектурой, когда в стране и особого то выбора в настоящий момент нет? Пытаться надстраивать Эльбрус системой аппаратного распараллеливания кода с введением параллельной системы команд? Развивать процессор на архитектуре RISC-V? Разрабатывать новую, ещё более эффективную архитектуру? Делать гибридный процессор с ядрами всех доступных архитектур?
Давайте подумаем, какие требования нужно предъявлять к российскому микропроцессору, если начинать его разрабатывать с нуля?
- Поскольку Россия практически всегда отставала от лидеров по аппаратной части, то нет причин надеяться, что когда-нибудь мы выбьемся по этой линии в лидеры. Возможно, это произойдёт на какой-то промежуток времени для узкоспециализированных процессоров, но не для процессоров массового сегмента. А значит, архитектура процессора должна быть заточена под невысокие частоты «толстых» техпроцессов (плюс ко всему такие процессоры будут дешевле). То есть, процессор должен хорошо параллелить задачи и уметь быстро между ними переключаться.
- Концепция VLIW хорошо подходит под распараллеливание кода, но требует сложного компилятора и высокой квалификации программиста, ибо компилятором хорошо параллелится только специально адаптированный и подготовленный для этого код. При этом в объёме растут и исходники, и сами бинарники. В связи с этим, такие программы требуют очень много оперативной памяти. Ещё одной неприятностью архитектуры E2K является то, что процессор медленно переключается между задачами. Это приводит к тому, что такая архитектура неприменима в будущих ПК. Другое дело, что другой своей архитектуры у нас нет, а пока это так, следует всячески развивать и продвигать эту. Но мы же говорим о будущем.
- Помимо своей архитектуры команд процессор должен аппаратно реализовывать эмуляцию x86 и RISC-V, как наиболее вероятной общемировой системы команд. Эмуляция x86 реализована в Эльбрусе, и работает довольно эффективно, что на практике доказывает возможность этого и для RISC-V. Разумеется, нативная система команд должна быть заметно эффективнее RISC-V для определённого нами целевого использования компьютера и имея ввиду низкие частоты процессора.
- Возможно, имеет смысл рассмотреть реализацию не стандартного набора команд процессора, а только тех команд, которые легко реализуются аппаратно, включая большое количество каких-нибудь, казалось бы, малологичных для человека но простых для аппаратной реализации команд, из которых компилятор, вооружённый ИИ, сможет конструировать реальные алгоритмы. Возможно, такой подход окажется более эффективным — надо проверить, даст ли повышение тактовой частоты за счёт исключения аппаратнонагруженных команд выигрыш за счёт использования дополнительного количества простых нестандартных команд, которыми сможет воспользоваться только ИИ, выстроив из них уже стандартные алгоритмы.
- Вышеприведённая концепция не должна быть догмой, и если какое-то программное решение эффективнее реализовать сложной командой, то её обязательно нужно вводить. Не должно быть никакой борьбы за чистоту философии — исходить надо из эффективности в каждом отдельном случае, а не каких-то надуманных правил или общего стиля.
- Поскольку в ближайшие годы мы ожидаем активное внедрение в программные продукты ИИ, то в процессоре должен быть нейромодуль для выполнения простейших нейросетевых функций. Встраивать что-то особенно мощное я не вижу смысла в связи с тенденцией перехода к неразрываемым соединениям компьютеров с сетью Интернет, за счёт чего все серьёзные ИИ-функции будут осуществляться дистанционно со специализированных серверов. Но какие-то автономные специализированные функции, требующие быстрой реакции, вполне могут запускаться локально. Что касается более мощных локальных ИИ-функций типа удаления шума с фотографий и т.п., то они вполне могут запускаться на графических ядрах мощной видеокарты. Если честно, я не очень уверен в необходимости наличия нейросетевого ядра, учитывая наличие графических ядер и высокой доступности Интернета, но таковое ядро в России уже разработано (архитектуры NMC5 от НТЦ «Модуль»), и его можно использовать.
Ну и несколько соображений по техпроцессу. Мы знаем, что первый техпроцесс, который можно будет реализовать с использованием ожидающегося рентгеновского литографа, будет 90 нм. Затем будут дорабатывать до 28 нм и ниже.
Кстати, как сообщил ИФМ РАН, в настоящее время в Фонд перспективных исследований подан аванпроект по теме: «Обоснование технической возможности создания отечественного рентгеновского проекционного литографа». Подписание договора ожидается в марте 2025 года.
Так вот, если мы не будем пытаться натягивать на свой рентгеновский литограф уже имеющиеся в мире техпроцессы, допиливая их напильником, а будем создавать своё, то можем задуматься над тем, чтобы использовать новые наработки для новых техпроцессов, адаптируя их к старым. Кстати, я об этом писал ещё в 2022 году.
Например, что нам мешает на техпроцессе 28 нм или даже 90 нм использовать в конструкции транзисторов технологию FinFET? А GAAFET?
А что будет, если на техпроцессе 28 нм комплементарные пары транзисторов располагать друг над дружкой, как это планируется делать для техпроцессов тоньше 0,5 нм? Что будет с теплоотводом? А может, тепло можно отводить через графен?
Заключение
На сегодня всё. Ставьте нравлики, проверьте свою подписку на канал (может слетать) и делитесь своим мнением в комментариях. Удачи! :-)