Предлагаю вернуться немного назад и попробовать разобрать ситуацию с отечественными микропроцессорами. Здесь уже выкладывали видео без подробного текстового сопровождения с очевидным результатом обсуждения:
посмотрел 6 минут, уже несколько фактов вранья увидел. Стоит ли смотреть дальше?
с мизерным количеством комментариев. Видео из исходной заметки уже снесли, актуальная версия тут
Что есть сказать про данное видео, кроме эмоциональных всплесков "все пропало, российскую микроэлектронику убивают"? Попробую изложить тезисно то, что происходит.
1. Согласно постановлению правительства РФ № 719 уже с 1 января 2021 года на российских процессорах должны строиться российские системы хранения данных (СХД), с 1 июля 2021 года — портативные компьютеры, а с 1 января 2022-го — серверы, настольные ПК, моноблоки, мониторы, принтеры, сканеры и факсы, а также твердотельные накопители и материнские плат.
В самом тексте и в изменениях постановления данный тезис мной не обнаружен, нет времени разбираться в юридических хитросплетениях
2. Решено (в настоящее время на портале regulation.gov.ru опубликован проект постановления правительства), что вычислительная техника не обязательно будет строиться на российском центральном процессоре, чтобы считаться «отечественной», и такое положение вещей сохранится вплоть до 1 января 2023 года.
3. Особое значение во всей этой истории имеет отмена конкурсов на разработку новых отечественных процессоров на общую сумму более 21 млрд руб
4. В РФ появились, вспоминаем тот самый пакет Яровой, разработчики и производители систем хранения данных (СХД) с использованием отечественных процессоров, например, компания "Промобит". Создан консорциум российских разработчиков систем хранения данных РОССХД
5. В связи с переносом сроков необходимости наличия отечественных процессоров в вычислительных системах большую долю прибыли компании, сделавшие ставку на работу с отечественными процессорами, потеряют.
6. На фоне отмененного конкурса на разработку микропроцессоров (не микроконтроллеров, это важно!) появляется информация о планах перехода на открытую платформу RISC5
Как сообщило издание «Ведомости» и уточнили в CNews, 8-ядерный 2-ГГц процессор на архитектуре RISC-V будет совместно разрабатываться структурами «Ростеха» с компанией Yadro «ИКС холдинга» Алишера Усманова (ведущий разработчик — компания Syntacore, одно из подразделений компании Yadro). Структуры «Ростеха» готовы инвестировать в проект 18 млрд рублей, а ещё 9,8 млрд рублей будет получено из бюджета
7. Производства кристаллов даже по технологии 60 нм в РФ не существует, и не скоро появится.
Чем эта тема сопровождается?
В июле появляются статьи о бесперспективности Эльбруса, в том числе и на афтершоке. Выходит видео на ютюбчике о злостных врагах отечественной микроэлектроники.
Как к этому относиться, решительно не понятно. Но упомянутая в ролике история про принятие стандарта IBM в СССР заставляет задуматься. Кроме хайпа, здесь есть что-то еще. Камрад И-23 посветил этому в свое время материал. Что это, повторение истории, кстати, компания строящая СХД на импортных процессорах использует IBM Power, или внутриотраслевые споры мало касающиеся обывателей?
Комментарии
позвольте не согласится... из того что есть в нетах и заявлениях интела. кристалы сейчас строятся на технологи 14 нанометров. меньше не реально транзисторы на кремнии слишком сильно шумят из за температур. росскийские процесоры уступают в эмулировинии винды, и то не значительно а в полтора два раза, уровень 15- 17 года... если не игры играть а инфраструктуру строить то пофиг. ОС и прикладное ПО... так а кто даст - то ... это надо поднимать весь БРИКС и клепать... а так...
Не эмуляции, а трансляции.
Это несколько иное.
Эти "14 нанометров" — на самом деле не 14, а в разы крупнее; красивые циферки в названии — для маркетинга.
По поводу СХД я бы посмотрел на RAIDIX. По сути — стандарт де факто для систем среднего и выше размера стал, с возможностью иерархического хранения. Если, конечно, денег не слишком много.
Изначально использовал платформу Intel, но теперь имеет вариант и под Эльбрус.
Построен на модифицированном Linux. Чисто программное решение, однако, совместимое с не очень большим набором периферии.
В чём преимущество по сравнению, например, с Lustre? Просто интересно.
Lustre - с открытым исходным кодом, работает с очень большим набором периферии (фактически - всё, что поддерживает Linux), петабайтный масштаб хранилища данных.
Кстати, а какой заявленный максимальный масштаб для RAIDIX? У RAIDIX это нигде не написано на поверхности (или я не увидел при беглом осмотре).
В узких применениях можем пока и вне РФ производство чипов т.е. это не РФ чипы.
По системам скажем наблюдения прогресс есть:
https://aftershock.news/?q=node/772226
Аэродиск это кот в мешке.
Любая покупка сложной системы - кот в мешке. Я зхнаю о выходе из строя СХД HP в частности магнитооптика ни разу сколько заявлено не работала в ФТИ. В руках держал.
SureStore чисто на словах. Реально или летит или вам её ломают извне, когда захотят.
HP отрадясь никогда своим массивы не делал. У них всегда был OEM. Первый OEM это VA и EVA от DEC'а по наследству досталась вполне себе ничего массивы но надо правильно готовит. Далее Hitachi AMS, XP, UPS, VPS и т.д. хорошие массивы с понятной и предсказуемой производительностью но очень слабыми инструментами управления. Далее 3par отличный массив быстрый надежный без единой точки отказа, с хорошим софтом опять таки с понятной и предсказуемой производительностью. HP SureStore насколько я помню это библиотека (для долговременного хранения) либо на лентах либо оптики и никакого отношения к дисковым системам (о коих рассказывается на видео) не имеет.
Я говорю о системах нативных типа Hitachi, EMC, NetApp, IBM DS8000, 3par. Это дисковые системы с предсказуемой производительностью на определенных задачах. С понятной надежностью и логикой работы.
Аэродиск, Хуавей (не линейка дорадо), возможно еще что-то есть- к таким не относится.
Я исхожу из первичного железа хранения данных. На тот момент это была магнитооптика. Оно НЕ надёжно. Часть данных была утеряна. Позднее я терял данные в "вечных" "Золотых" в десятки лет гарантией CD-R DVD-R вербатимов при соблюдении условий хранения. Так что ленты при 50-60% влажности с перемоткой раз в год были надёжнее чем это.
Физически надёжней это голографическая запись разработанная в ГОИ, сначала на халькогенидных стёклах с возможностью перезаписи, потом уже на кварце с нагревом и парой лазеров писать. Последние теоретически десятки тысяч лет дать могут. Сколько практически - проверять надобно. Верить словам - выбрасывать деньги и время, а главное ценные данные на ветер.
Можно и во времени, структуре пространства хранить, у вас немного этим один из ЛАИшников занимался. Ну не совсем правильно однако ж можно и за то порадоваться - у них финансирование несравнимо с тем что в США получают на такие разработки. Там десятки ТОНН золотого эквивалента в год. Это вам не истребитель или ракета и тем более ваши бронекоробки наземные - это система превосходства АБСОЛЮТНОГО по сравнению с ЛЮБЫМИ обычными вооружениями и системами управления. Что угодно можно делать, пока более сильный не приходит и не ставит под контроль. Касаемо брони - чем выше плотность тем лучше действовать некоторые системы будут и это не ракеты и лазеры.
Кроме производства кристаллов, требуется ещё и инфраструктура программная.
У Risc-V достаточно удачный набор команд, обширная поддержка community.
А вот Эльбрус - это штука, которая должна умереть. И чем раньше она умрёт, тем лучше будет.
Современный процессор должен умень отлично выполнять C/C++/C#/Java код. Всё остальное - на сопроцессорах и спец. блоках.
Причём при грамотной санации - большинство наработок Эльбруса останутся (материнская плата, все периферийные блоки).
Так он и выполняет. Оптимизации компилятора всегда эффективнее, чем угадывающий ветку выполнения конвейер. Причём код на Эльбрусе без дополнительных усилий получается реального времени (при последовательных запусках одинакового кода на одинаковых данных он выполняется одинаковое количество тактов).
Таки нет. Оптимизация компилятора пишется ручками, красиво и круто когда на ассемблере пишешь вставочку, геморрой и все равно плохо когда так пишешь много кода. Написание нормальной оптимизации в VLIW - очень тяжелая задача. И ради чего? Обнаружить что основная задержка получается при чтении этих слишком длинных команд из памяти?
Все эти мастадонтные концепции себя не оправдывают. Думать что мы умнее интел не стоит.
А оптимизация в кристалле является божественным откровением? Так же ручками, но с жёстким ограничением на сложность алгоритма и время его выполнения.
Вот руками VLIW ассемблер писать не очень хорошая идея. Впрочем, как и RISC.
А написание нормальной аппаратной оптимизации — невозможная задача. Есть разница?
???
Одна команда (длинная) — один такт. Всегда.
Похоже, это ключевая фраза. Причём вне зависимости от того, какая российская электроника обсуждается. Нельзя думать, что мы умнее светлых эльфов. Золотой телец покарает.
Вот руками VLIW ассемблер писать не очень хорошая идея. Впрочем, как и RISC.
Буквально месяц назад изучал Risc-V набор команд. Восновном это требовалось, для того, чтобы понимать, что gcc нагенерировал.
Так вот - писать на ассемблере Risc-V просто и приятно. Из-за того, что набор команд простой - компилятор делает то-же самое что и человек. Без всяких хитрых изысков.
Да, RISC-V - сказка для тех, кто хочет в ассемблер. Забыть Intel и ARM как страшный сон.
Многословно очень из-за простого набора. И оптимизирующий компилятор делает далеко не то же самое, что человек. Раскрутку циклов, подстановку функций и алгоритмическое сокращение никто не отменял.
Да, конечно никто в трезвом уме и твёрдой памяти не будет писать на ассемблере для процессора, который специально был оптимизирован для того, чтобы компиляторам/JIT с C/C++/Java/C# было удобно.
Но вот насчёт "многословно" - не соглашусь. Все базовые операции - арифметика/сравнения/условные переходы/обращение в память делаются на Risc-V в одну инструкцию. Там даже есть 16-ти битные команды, чтобы ещё сильнее сэкономить в размерах на частоиспользуемых операциях.
Они не понимают потому что сами ни строчки не написали.. Тут рассуждают с позиции политической, а не технической. Нам тоже эльбрусовцы предлагали написать им что нам нужно от их железа такого особенного. А мне нечего писать. Я не люблю делать из кода новогоднюю ёлку! Хочется, чтобы просто грамотно написанный на плюсах код просто эффективно работал. И уж если припрет то немножко можно навести лоска в самых критических местах. А если предлагается везде развешивать директивы компилятору, что и как он там должен оптимизировать, и без этого хорошо написанный код работать нормально не будет, то это безобразие, а не аппаратная платформа!
Дешевое кодерское бахвальтсво здесь вижу я.
Если припрет получится не только елка, но целая сосна)
Это не так. Самая большая проблема быстродействия программ - это попадание в кеш. Если программа одна, то да, этим можно управлять на уровне разработчика. Если это современный Linux-сервер с кучей параллельных процессов - то нет. Суперскалярный процессор с OOE сделает локальную оптимизацию гораздо лучше, чем любой компилятор. Потому что процессор знает реальное текущее состояние кешей, а компилятор - нет.
И чем больше будет разрыв в тактовой частоте процессора и памяти, и чем более многозадачной будет система - тем больше будет преимущество локальной оптимизации суперскаляра над статической оптимизацией под VLIW. Не говоря уже о том, что под каждую версию VLIW-процессора надо эти оптимизации делать заново, т.е. перекомпилировать код, а под RISC5 это делать не нужно, каждый процессор сам о себе позаботится.
И чем это поможет? Данные у разных программ разные, не выполнить команду, от того, что её данных нет в кэше, процессор не может. Опережающее выполнение в любом случае тянет данные в кэш.
JIT на VLIW может вообще несколько потоков в один такт одного процессора трамбовать. Максимальный эффект, разумеется, будет достигнут на долгих задачах.
Не больше, чем под любой другой процессор. Если у нового процессора количество регистров и ширина слова не уменьшилась, то будет совместимо.
Если необходима скорость, всё равно придётся под количество регистров и размер кэша перекомпилировать.
Например, в случае с HyperThreading на том же ядре выполняется другая нитка, у которой кеш уже мог быть прогрет.
Если HyperThreading нет, то спекулятивное выполнение других команд в любом случае ускорит работу. Как и спекулятивное выполнение команды загрузки из памяти.
Это умеет делать любой современный суперскаляр. I7 - 4 команды за такт, Apple начина с A14 - 8 команд за такт. С OOE разумеется.
На i7 проверил это лично.
Количество логических регистров не меняют, размер кеша не уменьшают. Так что перекомпилировать надо крайне редко и только реально нужные для производительности места, которых не так много. В отличие от VLIW, когда перекомпилировать надо всегда, при любом добавлении новых мощностей.
В целом, пока по Эльбрусу ситуация такая: несмотря на многолетние усилия, JVM JIT работает процентов на 20 медленнее Intel'а в пересчете на мегагерцы. При том, что и разница в частоте между процессором и памятью у Эльбруса лучше (меньше), чем у Интела соответствующего поколения. Про остальное компилируемое разница больше, вплоть до "разы". И это в пересчете на мегагерцы.
Жаль, кстати, что сравнений Эльбруса с ARM нет. Было б интересно.
Из разных потоков? Без переключения контекста?
Ну да, есть HyperThreading, который делает то что надо, но за счёт полного второго набора регистров.
Почему? Если просто тактовая частота или кэш увеличились, ничего не надо. Точнее под кэш надо в том же объёме, что и под любой другой процессор (структуры данных всё-таки от размера кэша зависят, если предполагается условно-однопоточное долгое вычисление).
Да. За пару лет сделать лучше, чем то, что Sun и Oracle делали десятилетиями, почти нереально.
Сишный компилятор для Эльбруса достаточно хорош. Где там разы для программ на Си?
Проект Java JIT для Эльбрус начался в конце 2012-ого. Скоро 10 лет будет.
Это да. То есть никакие функциональные изменения ядра невозможны. Добавить АЛУ или еще что-то - невозможно. В суперскаляре можно добавлять АЛУ и увеличивать параллелизм без перекомпиляции кода.
Не совсем. Декодинг, OOE - вторыми не делаются. АЛУ - это дешево в смысле транзисторов. Дорого - это кеш и управление. Но они и дают ту самую скорость.
По C разрывов "в разы" нет, это да.
Он всё равно шёл по остаточному принципу. Примерно как LLVM. Так как если нужна скорость, то люди пишут на Си/Си++, вот его и оптимизировали. А JIT довели до состояния, чтобы он все операции JVM выполнял и особо не оптимизировали.
Согласен. Но вот насчёт жёсткой необходимости этого сомневаюсь. Там, где принципиально «без перекомпиляции» уже и так JIT.
Там целый доклад был про то как ребята трахались с JIT.
https://www.youtube.com/watch?v=PYzsn8Mt7mE
В докладе замечательное утверждение про то, что быстрее, чем делает их компилятор Си, написать ассемблерный код невозможно.
У Risc-V 32 регистра. Это достаточно много, чтобы даже в функции средних размеров все временные переменные поместились в регистры. Для простых функций вообще не требуется работа со стеком! Даже адрес возврата, и тот в регистре.
IT на VLIW может вообще несколько потоков в один такт одного процессора трамбовать.
Тут сложно прокомментировать. Это что - несколько потоков выполняются абсолютно синхронно? Дальше хочется написать язвительный коментарий по этому поводу, но пытаюсь пока сдерживаться.
Скорее всего, тут имеются в виду не thread'ы, а "потоки вычислений" - независимые параллельные цепочки расчетов внутри одной программы.
Куски вычислений в разных потоках. Если регистров и кэша хватает на все, зачем тратить время на переключение контекста.
Синхронизировать куски из разных потоков - это утопия. Впрочем для очень узкого класса расчетных задач с минимальными обертками (подготовка данных/загрузка). - может быть такое и можно сделать. Но смысла в этом немного, такое считают на GPU или по крайней мере пишут на OpenCL с компиляцией в процессор.
Нет, на практике угадывать ветку выполнения значительно выгоднее, чем в статике это делать.
Тем более у Эльбруса очень длинный конвеер, и неверный переход очень больно бъёт по нему. Естественно как и у всех VLIW - при переходе от одного семейства к другому - требуется перекомпилция кода, либо будет сильное падение производительности.
Набор инструкций Risc-V специально оптимизировался под короткий конвеер и возможность Out-of-Order выполнения.
Простенький Risc-V выполняющий одну инструкцию за такт можно сделать даже на 3 стадии конвеера!
Из-за того, что у Risc-V 32 регистра и команды сделанны максимально независимыми друг от друга, то и out-of-order выполнение делается со значительно меньшими трудозатратами.
Это Ваше личное мнение, или мнение некоего сообщества? То есть все годы и средства поддержки МЦСТ является напрасными. Когда интересно пришли к этому мнению? И кто отвечает за поддержку бесперспективного проекта? Вот просто взять и выкинуть десятилетия работы? Сомнительно, что созданная периферия окупит такие решения.
Одни вопросы.
Ну, это НИОКР. Думали, что сделают прорывной процессор, а оказался чемодан без ручки. Так бывает.
Школу поддержали, процесс разработки от начала до конца прошли - это огромный плюс. А то, что получили недоCray 90-х - 90-ые еще долго будут аукаться в высокотехнологичных разработках.
Когда спрашивал про Эльбрус у людей, которые разбираются, то мнение было такое: "Это хороший проект, чтобы готовить кадры, но не более."
Архитектура ужасная. Недаром от VLIW в процессорах общего назначения отказались уже везде. Даже в видеокартах идёт отказ от VLIW.
И процессор - это всего лишь процессор. Имеется ввиду периферийные блоки внутри самого чипа. Кэш, общение с шиной данных и другими устройствами.
Компетенции никуда не денутся. Причем многие люди, которых заставляли делать Эльбрус явно взохнут с облегчением, когда перепрофилируются на более стандартную архитектуру, в которой меньше проблемных мест.
Уверен, в Союзе при переходе к IBMсовместимости тоже так говорили, куда пришли всем известно. Это не значит, что сегодня это будет неверным решением, но история то все равно ничему не учит.
Разница принципиальна!
Risc-V - это не проприетарный набор команд. Проведу аналогию. Вот не могут в России разработать свою операционную систему (и софт к ней). Используют Linux (в том числе и на Эльбрусах).
Аналогично Risc-V это открытый набор команд.
Глупо ради "самостийности" клепать болты нестандартных размеров.
Не возражения для.
Если бы в СССР гнули свою линию, пришли бы к метрическому IT. Но сидим мы все на дюймовой IT)
Подобные фразы весьма некорректны и требуют безусловно пруфов. Мы же на аналитическом ресурсе или где?)))
К сожалению на Facebook, у людей которые общаются с Yuri Panchul
Все без исключения процессоры исполняют сугубо машинный код и никакой связи ни с си, ни с крестами и прочей жавой не имеют. Языки программирования отдельно, процессоры отдельно. Связаны они исключительно через программу-транслятор с некоторого языка программирования в язык, котороый процессор "понимает" -- в двоичный машинный код.
Кстати, из Вашего странного списка только си и си-кросс-кросс стандартизированы более-менее четко и недвусмысленно. Остальные языки, упомянутые Вами, вообще никак.
Имеют, ещё как имеют.
Набор современных команд процессора оптимизирован под эти языки.
Поясню на примере. Обычный код языка Си можно скомомпилировать для работы на видеокарте, но это будет достаточно медленный и грустный код. Аналогично код GLSL можно выполнить на процессоре, но это будет тоже не быстро.
Разные железки и языки оптимизированны под разные задачи. С высоты различий между Си и GLSL, отличия семейства языков Java/C#/C/C++ - только в синтаксическом сахаре (и модели хранения данных).
+
А ещё непонятно, почему вместо стандартного MIPS, от байкала везде тащили именно этот уродский с т.з. поддержки Эльбрус. Возможно, если-б сразу сделали упор на MIPS мы-бы не оказались в столь странной позе. Интересно, чем вообще там люди руководствовались.
Думаю у них основная мысль была - потенциальные санкции.
Это сейчас понятно, что Эльбрус тупиковый путь. А 20 лет назад Intel пилила свой Itanium и вполне считала его перспективным. Но у неё достало силы воли (и компетентности) вовремя закрыть проект. У наших - недостатло.
Были жеж попытки запретить лицензировать ARM для китайцев.
С архитектурой Risc-V такое не пройдёт.
Кстати MIPS как компания поддерживает Risc-V.
Почему сейчас, любой грамотный IT'шник мог сделать из двух входных:
1. пропиетарная архитектура и система комманд
2. отсутствие своего, исключительного набора ПО (т.е. изначально был видень только путь освоения OSS)
простой и совершенно очевидный вывод -- писать свои компиляторы и стэк системного ПО накладно, долго и решению поставленной цели (импорт-замещение) никак не способствует.
да, я в курсе, более того, это показывает что люди готовы отказаться от своей архитектуры чтобы оставаться в мейнстрим и не сдохнуть. А ведь MIPS у многих, архитектура до недавнего времени совершенно живенькая, поддержка инструментального ПО чуть-ли не полная и это не считая того, что китайцы уже лет 10 выпускают на ней свои процы и готовые машинки. И проблем с лицензированием небыло.
Вопрос был в возможностях. По суперскаляру компетенций не было ни в СССР, ни тем более в РФ. Что умели с учетом современного состояния производства и проектирования микроэлектроники - из себя выжали. Получилось неплохо, если сравнивать с процессорами соответствующего технологичного процесса. Компетенции по сквозной разработке процессоров с нуля и систем, в том числе общего назначения. приобрели. Плюс параллельно игрались с MIPS, ARM, Sparc, RISC-V. Если сейчас перестанут вливать в e2k деньги напрямую, а начнут вливать в закупку серверов/других решений на базе отечественных процессоров с конкуренцией между разработчиками - будет норм.
В RISC5 открыта только ISA, то есть система команд. Для создания процессора его-таки надо проектировать, и ноу-хау там можно применять не меньше. чем в Эльбрусе. А так даже больше - суперскаляр сложнее VLIW, как ни крути. То есть формально никакого ущемления потенциала российских разработчиков нет. Никого же не смущала реализация системы команд x86 в Эльбрусе.
Т.е. частные инвестиции Дерипаски в Syntacore ничем не хуже для страны госинвестиций в Эльбрус. Другой вопрос, каков будет реальный баланс иностранного влияния и рисков безопасности при разработке и производстве этих чипов. Но с учетом того, что все равно все производство в ЮВА, базовые библиотеки тоже не наши, большой разницы между Эльбрусом и будущим RISC5 чипом от Дерипаски не видно. А с гражданской точки зрения RISC5 гораздо перспективнее Эльбруса - уже готовая огромная экосистема софта, понятные перспективы при уменьшении техпроцесса и росте частот.
Всерьез рассчитывать на какие-то коммерческие перспективы российского риск5 (которого просто нет, а бабло не заменит десятилетия разработки) слишком оптимистично!
На российском рынке - вполне. В госкомпаниях и корпорациях железо на серверах заменять и заменять. Да и на рабочих станциях тоже.
Условный ФНС миллиарды на сервера тратит ежегодно.
И насчет десятилетий разработки - это не факт. Что там есть в рукаве у Syntacore - пока неизвестно. Но ребята на рынке давно.
Страницы