Перейти к содержанию
    

Ну что, каковы перспективы микроэлектроники в России?

В 29.06.2022 в 19:44, makc сказал:

 Зато для больших процессоров с RV64G этот подход, по заявлениям специалистов, весьма оправдан, т.к. позволяет более эффективно реализовывать механизмы спекулятивного исполнения и предсказания ветвлений, т.е. в целом получать большую производительность.

Дорого из такой "пушки" по "воробьям" лупить. Особенно когда битовые операции проворачивать надо. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В 29.06.2022 в 19:44, makc сказал:

Они просто умножили всё на 1.5 для получения равных с Кортексами параметров и вуяля - получился конкурентоспособный продукт.

PS: я не против RISC-V, мы его применяем и вполне успешно. Но нужно учитывать его "фамильные" особенности и делать на это скидку (ну или запас по флешу/МГц).

+1

У меня тут на армах два проекта на днях внезапно вылезли за 128к. Теперь при возможности буду внешнюю ПЗУ закладывать.

С RISC-V практически не знаком, но есть ощущение, что не все так гладко.

Не понятно, насколько хорошо компиляторы сжимают код, а оптимизировать на асме самому - времени столько нет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

On 6/25/2022 at 2:28 PM, repstosw said:

1) Мульти-ядерные процессоры.   От 10 и больше ядер.  Частота одного ядра - ограничена технологическими возможностями заводов.

 

технологическими возможностями ограничено так же и количество ядер и их сложность (число транзисторов)

про riscv : возьмите syntacore-овское бесплатное ядро (32 бит) - без мозготраха запускается. не хуже cortex m0 думаю 

отечественная разработка

-----------------

но про экономику - вангую что контора либо закроется, либо релоцируется вскорости

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

59 минут назад, dxp сказал:

Это общие слова. Хотелось бы конкретики.

Это не общие слова, это моё личное экспертное заключение исходя из трехлетнего опыта использования различных реализаций RISC-V: SCR-1, PicoRV32 и Mиландровского ядра от CloudBear. Можете не принимать их во внимание, ваше право. За подробностями предлагаю сходить в том числе на Хабр.

Что касается конкретного примера проблем, то я привёл его выше. Вы никак не" соптимизируете на ассемблере" операции, требующие использования регистра флагов, о котором я уже упомянул выше. Чтобы получить схожую производительность  нужно гнать по частоте раза в полтора-два и тогда можно будет говорить о сравнимой производительности, но вылезет другая проблема - потребление. Именно поэтому SiFive сейчас пытается продвигать различные расширения для системы команд RV32*, чтобы была возможность отчасти купировать эти проблемы.

1 час назад, dxp сказал:

И что значит "для МК"?

Для МК это значит "для микроконтроллеров", т.е. SoC со встроенным флешом и SRAM, без больших кешей и с частотами до 200 МГц (грубо говоря).

1 час назад, dxp сказал:

Правильно ли я понимаю, что, например, для application processors это вполне эффективная система команд?

Я об этом также написал выше. Но у этих ядер уже есть большие кеши, суперскалярная архитектура и т.п. "фишки", которые позволяют нивелировать проблемы системы команд, так ярко проступающие в области микроконтроллеров.

1 час назад, dxp сказал:

Это в обоих случаях руками написанный на асме код? Или таки через компилятор пропущенный?

Компилятор gcc 10.x, но это не принципиально в виду того, что я сказал выше. Оптимизация на асме даёт прирост только тогда, когда есть возможность реализовать какой-то хитрый приём в части использования комбинации команд, до которой компилятор не дошёл своим скудным умом. Наиболее хорошо это заметно на CISC типа x86, куда слабее это работает на RISC и в основном предполагается использование определённой системы расширенных команд, позволяющих ускорить выполнение определённых операций засчёт загрузки выделенных вычислительных блоков или т.п. аппаратных ускорителей. Но если говорить в общем об RV32IMC, то там нет никаких блоков для реализации подобной магии.

1 час назад, dxp сказал:

Вот странно. У меня сведения про эффективность именно ISA и то, как она эффективно приводит к более компактному и быстрому кремнию как раз обратные.

Что считать критерием эффективности? Если площадь кристалла и получаемое число МГц (попугаев), то она безусловно эффективна. Но вот на прикладном уровне всё оказывается не так однозначно.

1 час назад, dxp сказал:

ISA молодая, микроахритектур мало (в сравнении с ARM), инструментарий тоже ещё не дорос (под ARM компиляторы уже вылизаны давно). Но это дело времени.

Компилятор в моих экспериментах был по сути один и тот же - gcc. Другого распространенного нет. У gcc в вариантах ARM и RISC-V по сути отличаются бэкэнды, т.к. основная логика компилятора и оптимизатора практически одинаковы, поэтому надежды на "дорастание" нет приблизительно никакой, покуда не появится новых крутых расширений системы команд. А они появляются весьма медленно... Поэтому выводы весьма неутешительные.

1 час назад, dxp сказал:

Из первых рук (SiFive) доходила инфа, что их ядро стоит в SoC на базе PolarFire (Microchip нынче), по "калибру" это аналог Cortex-A53. При этом компактнее (следовательно дешевле по кремнию) и экономичнее на 15% при приблизительно равной производительности.

Application Processors - это другая категория, как я уже сказал выше.

1 час назад, baumanets сказал:

Дорого из такой "пушки" по "воробьям" лупить. Особенно когда битовые операции проворачивать надо. 

Безусловно. Но своя ниша у RISC-V безусловно есть и я рад, что это семейство архитектур развивается.

Что интересно, если выбирать между тормозным Microblaze условным SCR-1 или PicoRV32, то я выберу MB, поскольку несмотря на несколько большие затраты ресурсов он даёт заметно более компактный код и лучшую производительность при сходных частотах. И это несмотря на то, что у MB нет поддержки "сжатых" команд.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В 29.06.2022 в 21:06, makc сказал:

Что интересно, если выбирать между тормозным Microblaze условным SCR-1 или PicoRV32, то я выберу MB, поскольку несмотря на несколько большие затраты ресурсов он даёт заметно более компактный код и лучшую производительность при сходных частотах. И это несмотря на то, что у MB нет поддержки "сжатых" команд.

Вывод из этого можно сделать такой. 

Своя процессорная архитектура с системой команд нам нужна как воздух. 

А у нас всё "цельнотянутые" "осваивают".

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В 30.06.2022 в 12:30, baumanets сказал:

Вывод из этого можно сделать такой. 

Своя процессорная архитектура с системой команд нам нужна как воздух. 

А у нас всё "цельнотянутые" "осваивают".

Хмм...А какие перспективы теперь (в сложившихся обстоятельствах) "своей" архитектуры? Можете поинтересоваться у МЦСТ. Пока не вижу адекватного предложения от производителей ЭРИ.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

18 минут назад, baumanets сказал:

 Своя процессорная архитектура с системой команд нам нужна как воздух. 

То есть, Вы хотите, чтобы мы пытались сделать то, чего китайцы не осилили?

А зачем нам такие риски? Берите ПЛИС и делайте какую угодно архитектуру и систему команд.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В 30.06.2022 в 12:49, byRAM сказал:

То есть, Вы хотите, чтобы мы пытались сделать то, чего китайцы не осилили?

А зачем нам такие риски? Берите ПЛИС и делайте какую угодно архитектуру и систему команд.

Берите wine. И гоняйте на нём виндовые игры в Linux.)) 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

On 6/30/2022 at 1:56 PM, baumanets said:

Берите wine. И гоняйте на нём виндовые игры в Linux.)) 

аналогия неудачная, коммерчески успешная Valve так и делает

https://www.opennet.ru/opennews/art.shtml?num=57359

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

4 часа назад, baumanets сказал:

Вывод из этого можно сделать такой. 

Своя процессорная архитектура с системой команд нам нужна как воздух. 

А у нас всё "цельнотянутые" "осваивают".

Тогда предлагаю для начала не использовать "цельнотянутые" компиляторы типа gcc и реализовать свой компилятор для уже существующих архитектур, а потом вернуться к этому разговору... Не сочтите за грубость, но вам не кажется, что ваше заявление это чистой воды проявление NIH-синдрома, которым так тяжело и часто страдают программисты?

В чем смысл изобретения велосипеда, в самом факте изобретения? Ну так всё получится как всегда: скопируют описание ISA RISC-V, назовут архитектурой "Донбай" и распилят на этом бюджет. Вместо того чтобы участвуя в международной кооперации предложить, реализовать и продвинуть расширения для имеющегося RISC-V, которые бы могли поднять его на новый уровень и устранить узкие места. Китайцы, между прочим, именно так и делают. Метод мягкой силы...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

On 6/30/2022 at 4:37 PM, makc said:

Вместо того чтобы участвуя в международной кооперации предложить, реализовать и продвинуть расширения для имеющегося RISC-V, которые бы могли поднять его на новый уровень и устранить узкие места. Китайцы, между прочим, именно так и делают.

китайцев много и работают они в разных направлениях

https://habr.com/ru/company/selectel/blog/668554/

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

3 часа назад, baumanets сказал:

Берите wine. И гоняйте на нём виндовые игры в Linux.)) 

Да, ваша ирония реально неудачно зашла на фоне технологии MicroBlaze Xilinx  :biggrin:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

On 6/30/2022 at 1:30 PM, baumanets said:

Своя процессорная архитектура с системой команд нам нужна как воздух. 

какое-то бредовое неверное утверждение.

индусы на BSV нафигачили кучу RISCV коров (апликейшен уровня, то есть с OOO, виртуализацией и т.п.)  - SHAKTI , Chromite

китайцы https://github.com/OpenXiangShan и даже на верилоге https://github.com/T-head-Semi/

а нам без своей архитектуры не получается... ну-ну

-------------------

off

копаюсь сейчас в европейском ariane / cva6 - ну вот что можно сказать - у них всегда можно поучится стилю кодирования (SV), не один раз уже думал "а чё так можно было?". есть конструкции, который xcelium 2022 не берет, а в стандарте типа можно 

BSV / chisel все таки решил оставить, слишком модный подход. 

самый простой из rv64imafdc по-моему у Гейслера на VHDL - но у него с тэйпаутами и тестированием не понятно, нужно собирать архитектурные тесты сo spike-ом - я пока к этому не готов

 

 

On 6/30/2022 at 6:45 PM, sasamy said:

китайцев много и работают они в разных направлениях

https://habr.com/ru/company/selectel/blog/668554/

я смотрел не самый топовый их опенкор, а openc906 - 64х бит, но микроархитектура попроще - без ооо, пайплайн покороче, юнитов поменьше и т.п.

у них дофига расширений (имхо, бестолковых, но я не компилерописатель) ISA - то есть нужно их компилер брать.

может это и есть RISC-X ? сообщество, кстати, на китайском, я по-крайней мере, англиского не нашел

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

19 часов назад, sasamy сказал:

китайцев много и работают они в разных направлениях

https://habr.com/ru/company/selectel/blog/668554/

Это далеко не первая попытка китайцев создания своего процессора со своей архитектурой, да вот только продукцию они делают на американских ммкропроцессорах.

В изоляции создавать такие вещи совсем непросто, тем более в России.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

On 7/1/2022 at 1:48 PM, byRAM said:

Это далеко не первая попытка китайцев создания своего процессора со своей архитектурой, да вот только продукцию они делают на американских ммкропроцессорах.

В изоляции создавать такие вещи совсем непросто, тем более в России.

предположу, что вам вряд ли известна архитектура алибабаевских серверов. я слышал от (как мне кажется, достаточно продвинутого в этой области) гугловского инженеро-манагера, что у них все абсолютно свое - свои протоколы и свое железо, которое управляется с ними. там, конечно, процессорные ядра далеко не самое важное IP, но тем не менее вовсю используют RISCV. что-то, я выше давал ссылку, выдают в опенсорс  

в Allwiner-ах то ли уже эти алибабаевские ядра, то ли собираются в следующих поколениях Sifive (американские) выкинуть и поставить свои

https://www.cnx-software.com/2021/04/13/allwinner-d1-linux-risc-v-sbc-processor/

мне сейчас какую-то нонейм китайскую плату с китайским RISCV процем показали - но из-за моей неспособности китайский интернет читать - что там за ядро - хз

--------------

ну то есть сделать годное ядро - это посильная задача (смотрим тот же syntacore - их yadro купил (?)) - то есть это вполне фаблес задача, для которой не нужно трильярд баксов в котлован закопать. то есть фаблес - это имхо единственный способ для РФ хоть как-то участвовать в производстве полупроводников (если конечно с геополитикой проблемы кончатся) . и опять же процессорное ядро делать - то есть микроархитектуру - это разумная задача, имеющая не только академический, а и коммерческий выхлоп (потенциально) . а изобретать какую-то свою архитектуру вместо RISCV - бессмысленная трата времени. проще говоря: инструкшин декодер это настолько малая часть кода в большом процессоре, что абсолютно пофиг riscv там или уникальная_отечественная_архитектура_с_блэкджеком_и_социально_безответственными_тетками

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Гость
Эта тема закрыта для публикации ответов.
×
×
  • Создать...