![image](https://habrastorage.org/files/d9a/bde/163/d9abde163cff492785353f52f04fd08d.jpg)
Отличная новость вышла в минувшую пятницу. Ижевский радиозавод выпустил первые российские ПК.
О том, что они запущены в производство, писали еще полгода назад. Но то, что их можно «пощупать», стало известно только сейчас.
Для меня это IT-новость года. И вот почему.
Во-первых, надо с чего-то начинать. Научиться делать законченные высокотехнологичные вещи — само по себе достижение. Раз начав, можно инкрементально двигаться дальше. Кстати, цена в 200-400 тыс за ПК — копеечная. Для опытной партии это смешные деньги.
Во-вторых, мне кажется, что сейчас то время, когда пора заканчивать ныть про «элементную базу». Не хочу быть неправильно понятым. Элементная база — это важно. Но гораздо важнее другое.
Элементная база сейчас доступна в виде сервиса. Можно «напечатать» все, что угодно, в Китае. Или даже у нас, как видите. Пусть даже в меньших объемах и на устаревших технологиях.
И этого уже достаточно для многих приложений. Потому что сейчас супер-пупер современная элементная база — и даже микроархитектура! — не имеет такого значения, как 15 лет назад. Технологии даже 10-летней давности приемлемы для решения большого количества современных задач.
Это все потому, что миром стал править софт. Хороший софт способен компенсировать недостатки «плохого» железа. Все вокруг постепенно становится «программно-определяемым», software-defined. Сегодня мы уже движемся к software-defined networking, software-defined storage, software-defined data center. В конечном итоге, будем иметь software-defined everything. Если хотите, будет software-defined microprocessing. Кстати, мы его уже почти имеем. Пока что в лабораториях, но и на рынок он непременно прорвется.
Однако причем здесь ПК на базе Эльбруса? На мой взгляд, Эльбрус идет по правильному пути (в сложившихся условиях, конечно же). Они делают архитектуру, которую Россия может себе позволить. Это архитектура со статическим планированием (широкая команда, так называемая). Она позволяет иметь простое железо, но компенсирует эту простоту софтом.
Широкая команда?
На тему «широкой команды», «статического планирования», «динамического планирования» и на многие другие темы мне два года назад удалось побеседовать с Борисом Бабаяном, создателем первых Эльбрусов. Если перечисленные слова являются для вас новыми и вы хотите узнать, откуда всё пришло и куда идет, рекомендую обратиться к ссылкам:
Железо на службе у алгоритма
Железо на службе у алгоритма (продолжение)
Железо на службе у алгоритма
Железо на службе у алгоритма (продолжение)
Россия сейчас не может позволить себе суперскалярную архитектуру. Это слишком сложное железо. Но в России умеют писать софт! Многократно доказано.
Думаю, что построение первых российских ПК именно на основе широкой команды — логично и закономерно.
Правда, от статического планирования в дальнейшем придется уйти. Прошу прощения у всех фанатов широкой команды, но это тупиковое направление развития. Машина должна быть динамической.
Правильно в широкой команде только то, что она software-defined. (Кстати, использование в Эльбрусах двоичной трансляции для обеспечения переносимости приложений с архитектуры x86 — это тоже часть программно определяемого подхода к построению микропроцессорных архитектур).
Софт — это то, о чем сейчас в России должен думать каждый разработчик железа, как бы парадоксально это ни звучало. Если мы это осознаем и примем, нас ждет большее будущее в вычислительной технике.
UPDATE. По комментариям вижу, что был неверно понят многими людьми. Я не имел в виду, что «можно взять плохое железо, написать под него хорошие пользовательские приложения и тем самым получить неплохую производительность». Говоря о софте, я подразумеваю не пользовательские приложения, а middleware, которое в некотором смысле, является частью архитектуры машины. По отношению к широкой команде, таким софтом является компилятор. На него полностью перекладывается планирование исполнения программы. Железо в планировании не участвует.
На мой взгляд, как можно больше функций железа нужно стремиться переложить на подобное middleware. В идеале, оно должно проектироваться совместно с железом (так называемый software-hardware co-design). У такого подхода есть множество плюсов. Но это уже за рамками поста…