Производителям и без всяких законов нужно предустаналивать rustore - если появятся смартфоны с ним в качестве основного магазина с возможностью обновления в фоне, то они просто вытеснят всех остальных с рынка, т.к. обновление каждого приложения с ручным подтверждением утомляет
Это не код существует для процессоров, а ровно наоборот - процессоры создаются , чтобы запускать код.
Мода на упряжь с телегой впереди лошади как раз пошла от экосистем на спекулятивных OoO-процессорах :) Из-за все новых проявлений дыр в средствах обхода архитектурных недостатков приходится патчить и допиливать весь стек ПО - от микрокода и биоса до прикладного софта (например, было добавлено разделение данных разных сайтов по разным процессам и загрубление таймеров в браузерах)
Даже если и появится несколько ускорителей в Э, то это число не идет ни в какое сравнение с числом ускорителей в процессорах legacy-подхода, причем каждый из них имеет набор болячек. Такое наслоение заплат просто поддерживать и тестировать затратно.
>Ну так лицензируйте нужные патенты, раз все так, как вы говорите, все же как тт справляются. (Это вообще намёк на то, что патенты действуют ограниченное время и далеко не все о чем вы говорите ими покрыто).
Ниже уже заметили, что причина для отказа в лицензировании партнерам и не нужна вовсе. по поводу ограниченности патентов во времени - к моменту истечения патента технология уже будет морально устаревшей.
>чтобы называть имеющиеся подходы- legacy, вам бы неплохо начать с доказательства
Да хотя бы одно сравнение затрат на RnD ставит все существующие чипы в разряд legacy - вложения в экосистему Э на порядки ниже таковых в мейнстримовые экосистемы, но производительность Э уже достигла соизмеримых значений ;-)
Потому что это будет растратой с нулевым преимуществом перед любым современным ARM, x86 или чем нибудь там ещё.
У VLIW Э премущество в полной независимости от средств обхода архитектурных недостатков процессоров legacy-подхода -
Во-первых все детали реализации OoO, предсказателей переходов, параллельных декодеров инструкций в современных процессорах покрыты патентами в три слоя. Т.е. трудно создать быстрый процессор в рамках legacy-подхода без риска подпасть под патентные риски(см этот пост п. 7.)
Во-вторых Эльбрусы не нуждается в постоянном патчинге дыр в этих костылях-ускорителях по всему стеку – от микрокода и Биоса до ос с компиляторами
>e2k — это не GPCPU
Какой-нибуль другой из отечественных GPCPU способен на такое?
Причем это крутится на предыдущем камне в эмуляции с сопутствующими потерями.
>Тогда тут надо уточнить, что родной Интел должен быть года этак из 2005-го (это если мы говорим про Эльбрус-16С). Плюс/минус, конечно же.
То что эмулируемый на эльбрусе интел такой же как интел из 2005 года — это в смысле по поддерживаемым наборам инструкций (SSE, AVX и т.п.) и/или по производительности?
доп:
Если по скорости, то это не так — в эмуле даже на 8с удается запускать достаточно тяжелый Final Fantasy XV
А вот с cyberpank были проблемы, мб каких-нибудь avx не хватает?
> Или Амазона
Взломов и утечек может и не было, но на кошельках пользователей облаков проблемы legacy-архитекур точно отразились: www.opennet.ru/opennews/art.shtml?num=55186
Предложенные методы позволили поднять производительность обработчика JSON на основе библиотеки libreactor в окружении Amazon EC2 (4 vCPU)…
Отключение защиты от уязвимостей, вызванных спекулятивным выполнением инструкций. Использование параметров при загрузке ядра «nospectre_v1 nospectre_v2 pti=off mds=off tsx_async_abort=off» позволило поднять производительность на 28%, а пропускная способность возросла с 347k req/s до 446k req/s
Видно, что для некоторых сценариев из-за заплаток от дыр в оптимизаторах на чипе придется увеличивать бюджеты на хостинг, т.к. нужно больше узлов для достижения прежнего уровня производительности. А на Э же вовсе невозможна эксплуатация уязвимостей этих оптимизаторов ввиду их отсутствия как таковых.
>проектировать железо дорого и сложно.
>Ха-ха-ха.
В сегодняшних условиях многомесячных очередей на доступ к мощностям кремниевых фабов, подход к проектированию чипов с вынесением из кремния всего чего можно на сторону софта смотрится все более разумным
>Если бы наша экономика была бы капиталистической, эльбрусы бы выпилились с рынка
Вы выпали из трендов, сегодня в мире нигде разработка микроэлектроники не обходится без дотации:
США субсидируют локализацию современного производства микросхем
ЕС выделяет гранды на развитие независимых суперкомпьютеров
>Архитектура должна разрабатываться с учетом современных реалий: многопроцессорные системы с out-of-order исполнением. Не нужны древние архитектуры, рассчитанные на in-order процессоры.
Если же учесть то, что «зеленая» повестка шагает по миру, все может оказаться совсем наоборот — это древняя in-order без сопутствующих затрат энергии на оптимальное исполнение кода соответствует всем современным реалиям =)
Оптимизировать бинарники можно с помощью техники многофазной сборки - PGO, но для проектов придется выделять допресурсы на написание скриптов прогона основных сценариев использования программы. еще и отслеживать ситуации с провалами производительности, когда по каким-то причинам в финальной сборке не применилась нужная информация из тестовых прогонов.
>Идеальный вариант - это вложить силы в разработку нормального RISC/CISC процессора А разве распространенные архитектуры сами же не попали в тупик - процессоры вынуждены иметь в своем составе набор сопроцессоров на все случаи жизни и даже стали появляться чипы со встроенными ПЛИС(!) Хватит ли ресурсов у отечественных чип-мейкеров тянуть эту мету GP CPU, чтобы оставаться конкурентными?
>С чего бы RISC-V сырая архитектура? и софта уже выше крыши. Рано называть платформу развитой тогда когда, например, тот же OpenJDK доступен только в виде интерпретатора Zero https://github.com/openjdk/jdk/tree/master/src/hotspot/cpu
Сейчас вы находите здесь -> - портировать основной тулчейн: JS, JVM, PHP, .NEt Core, Python ( сюда же основные модули, которые использует каждый первый питонист - numpy, pandas, ...) ... - PROFIT!11
Производителям и без всяких законов нужно предустаналивать rustore - если появятся смартфоны с ним в качестве основного магазина с возможностью обновления в фоне, то они просто вытеснят всех остальных с рынка, т.к. обновление каждого приложения с ручным подтверждением утомляет
Мода на упряжь с телегой впереди лошади как раз пошла от экосистем на спекулятивных OoO-процессорах :)
Из-за все новых проявлений дыр в средствах обхода архитектурных недостатков приходится патчить и допиливать весь стек ПО - от микрокода и биоса до прикладного софта (например, было добавлено разделение данных разных сайтов по разным процессам и загрубление таймеров в браузерах)
>раз есть предсказатель ветвлений
Даже если и появится несколько ускорителей в Э, то это число не идет ни в какое сравнение с числом ускорителей в процессорах legacy-подхода, причем каждый из них имеет набор болячек. Такое наслоение заплат просто поддерживать и тестировать затратно.
>Ну так лицензируйте нужные патенты, раз все так, как вы говорите, все же как тт справляются. (Это вообще намёк на то, что патенты действуют ограниченное время и далеко не все о чем вы говорите ими покрыто).
Ниже уже заметили, что причина для отказа в лицензировании партнерам и не нужна вовсе.
по поводу ограниченности патентов во времени - к моменту истечения патента технология уже будет морально устаревшей.
>чтобы называть имеющиеся подходы- legacy, вам бы неплохо начать с доказательства
Да хотя бы одно сравнение затрат на RnD ставит все существующие чипы в разряд legacy - вложения в экосистему Э на порядки ниже таковых в мейнстримовые экосистемы, но производительность Э уже достигла соизмеримых значений ;-)
У VLIW Э премущество в полной независимости от средств обхода архитектурных недостатков процессоров legacy-подхода -
Во-первых все детали реализации OoO, предсказателей переходов, параллельных декодеров инструкций в современных процессорах покрыты патентами в три слоя. Т.е. трудно создать быстрый процессор в рамках legacy-подхода без риска подпасть под патентные риски(см этот пост п. 7.)
Во-вторых Эльбрусы не нуждается в постоянном патчинге дыр в этих костылях-ускорителях по всему стеку – от микрокода и Биоса до ос с компиляторами
Машины на этом проце научились сбрасывать частоты в простое, появилась поддержка перехода в ждущий режим?
Мб чтобы опыт и кадры наработать к моменту появления фабрик?
под Э в Альте >15000 пакетов, среди них нет этого самого пакета спутниковой интерферометрии?
не совсем уж с нуля, на самом деле есть от чего отталкиваться:
habr.com/ru/news/t/685350
Штрафы оборотные будут вводить за утечки, недавно просто на Хабре был https://habr.com/ru/news/t/668456/
Субсидируется разница между коммерческой и льготной кредитной ставкой, а не тело кредита
Какой-нибуль другой из отечественных GPCPU способен на такое?
Причем это крутится на предыдущем камне в эмуляции с сопутствующими потерями.
То что эмулируемый на эльбрусе интел такой же как интел из 2005 года — это в смысле по поддерживаемым наборам инструкций (SSE, AVX и т.п.) и/или по производительности?
доп:
Если по скорости, то это не так — в эмуле даже на 8с удается запускать достаточно тяжелый Final Fantasy XV
А вот с cyberpank были проблемы, мб каких-нибудь avx не хватает?
Взломов и утечек может и не было, но на кошельках пользователей облаков проблемы legacy-архитекур точно отразились:
www.opennet.ru/opennews/art.shtml?num=55186
Видно, что для некоторых сценариев из-за заплаток от дыр в оптимизаторах на чипе придется увеличивать бюджеты на хостинг, т.к. нужно больше узлов для достижения прежнего уровня производительности. А на Э же вовсе невозможна эксплуатация уязвимостей этих оптимизаторов ввиду их отсутствия как таковых.
>Ха-ха-ха.
В сегодняшних условиях многомесячных очередей на доступ к мощностям кремниевых фабов, подход к проектированию чипов с вынесением из кремния всего чего можно на сторону софта смотрится все более разумным
Вы выпали из трендов, сегодня в мире нигде разработка микроэлектроники не обходится без дотации:
Зачем России идти против мировой меты и пытаться играться в рынок?
Если же учесть то, что «зеленая» повестка шагает по миру, все может оказаться совсем наоборот — это древняя in-order без сопутствующих затрат энергии на оптимальное исполнение кода соответствует всем современным реалиям =)
Лоббисты этого закона и закидывают регулятора жалобами, кто же еще это может быть?
Оптимизировать бинарники можно с помощью техники многофазной сборки - PGO, но для проектов придется выделять допресурсы на написание скриптов прогона основных сценариев использования программы. еще и отслеживать ситуации с провалами производительности, когда по каким-то причинам в финальной сборке не применилась нужная информация из тестовых прогонов.
>Идеальный вариант - это вложить силы в разработку нормального RISC/CISC процессора
А разве распространенные архитектуры сами же не попали в тупик - процессоры вынуждены иметь в своем составе набор сопроцессоров на все случаи жизни и даже стали появляться чипы со встроенными ПЛИС(!)
Хватит ли ресурсов у отечественных чип-мейкеров тянуть эту мету GP CPU, чтобы оставаться конкурентными?
>С чего бы RISC-V сырая архитектура? и софта уже выше крыши.
Рано называть платформу развитой тогда когда, например, тот же OpenJDK доступен только в виде интерпретатора Zero
https://github.com/openjdk/jdk/tree/master/src/hotspot/cpu
даже для того Эльбруса запилен JIT-порт
PHP тоже доступен только как интерпретатор: https://wiki.php.net/rfc/jit#proposal
c .NET Core все глухо
А вот с JS v8 jit-движком v8 получше - несколько месяцев назад добавлена поддержка risc-v
Путь к развитой платформе:
-Собрать ядро линукс, сишку, cpp, системные библиотеки
- DOOM!!! https://twitter.com/ultraembedded/status/1284515315062317061
Сейчас вы находите здесь -> - портировать основной тулчейн: JS, JVM, PHP, .NEt Core, Python ( сюда же основные модули, которые использует каждый первый питонист - numpy, pandas, ...)
...
- PROFIT!11