План SiFive по компьютерам на базе Linux и RISC-V

И это значит что я должен заплатить 500$ (на самом деле 1000$ по ценам маусера) за 1 из 100 рекламных процессоров компании которая продаёт IP-ядра? В том числе продаёт IP-ядра на «свободных» RISC-V?

Ты можешь сам заказать RISC-V процессор у фабрики, если тебе не нравится эта контора. Не знаю какая у тебя площадь кристалла будет и техпроцесс, но порядок цен на подготовку чего-то типа RV64GC с минимальной обвязкой - в районе $200К.

В эту стоимость идут топовые DSP от TI которые бывают только в штучных экземплярах на складах.

Вот только у TI свои мощности и даже топовые DSP таки выпускаются отнюдь не партиями по 1000 штук. А на складах их нету потому что спрос маленький.

500 баксов за эту микруху дофига.

Ну так закажи сам, если цена не нравится, в чём проблема? Или там Интелю, например, расскажи что $500 за микруху дофига.

100$ ещё можно было бы оправдать маленькой партией.

K210 выпущенный миллионами стоит даже ещё меньше - $10. Потому что выпущен миллионами.

А так эта цена, по которой SiFive продаёт свою чудо технологию

За сколько хотят, за столько и продают. Ты тоже можешь заказать RISC-V и продавать по той цене, по которой сочтёшь приемлемым.

Процы с AES-NI и SIMD жрут меньше

Жрут меньше только точно таких же процессоров без AES-NI и SIMD. И те и другие жрут больше менее специализированных и более простых девайсов RISC.

А если сделать в кремнии OISC - то он вообще будет жрать меньше их всех вместе взятых, занимать ничтожную площадь и стоить сотые доли цента.

перформят быстрее

Конечно. А если на каждый используемый алгоритм расчёта сделать свой однотактный вычислитель, то вообще самолёт будет.

Header это разьём, который на плате.

жрут больше менее специализированных и более простых девайсов RISC.

Что за мифические risc? В реальных arm есть криптографические/simd/и тд инструкции. Без них жрёт больше и перформит медленнее.

если сделать в кремнии OISC

Вот когда сделаешь, и когда он на практике нагнёт имеющиеся процы - тогда принесёшь.

Что за мифические risc?

Любые RISC жрут меньше аналогичных CISC. Инструкции AES-NI о которых ту упомянул, существуют только на x86, самых прожорливых процессорах, которые есть CISC. На RISC криптография иначе называется.

В реальных arm есть криптографические/simd/и тд инструкции. Без них жрёт больше и перформит медленнее.

Даже если у тебя код состоит только из SIMD и криптографических команд, то жрать по сравнению с процессором без них он всё равно будет больше. Конкретные задачи которые можно решить этими инструкциями, очевидно выполнять будет быстрее.

Какая разница как называется? Принцип тот же.

Относительно осуществлённых полезных вычислений жрёт меньше.

Вот когда сделаешь, и когда он на практике нагнёт имеющиеся процы - тогда принесёшь.

Его можно вообще на макетке их дискретной логики собрать. А нагнёт он все остальные процессоры по занимаемой площади кристалла и, соответственно, по ужору. Вот только итоговая производительность будет ваще пипец говно. Может быть в каких-нибудь применениях где не нужно скорости, зато очень важно потребление и прокатит. Хотя в таких случаях принято использовать 1-битные, а не одноинструкциевые процессоры. Или 4-хбитные - они дают хороший баланс между ужором, ценой, производительностью и сложностью программирования.

Какая разница как называется? Принцип тот же.

Ну AES-NI, о которых ты упомянул, имеют отношение только к CISC.

Относительно осуществлённых полезных вычислений жрёт меньше.

Разумеется, ведь сделав конкретные криптографические вычисления за 1 такт на более прожорливом процессоре, по потреблению энергии на результат можно уделать менее жрущий, который будет вычислять то же самое 1000 тактов.

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

А для задач типа майнинга вообще лучше использовать ASIC который заточен на единственную задачу. ASIC в этом случае уделает вообще всё - и RISC, и CISC и VLIW и всё что угодно. Вот только ничего другого ASIC не умеет и будет просто жрать электричество вхолостую, если не давать ему задач.

Неправда же. Можно один транзистор раскочегарить так, чтоб он жрал больше целой схемы.

На более низких частотах жор может быть ниже, даже если схема сложнее.

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

простаивать и жрать

В процессорах давно на лету отключают неиспользуемые части ядра.

В процессорах давно на лету отключают неиспользуемые части ядра.

И так постоянно, да? То включают, то выключают. Офигенный способ просрать лишнее время и электричество.

Ну с чего просрать-то лол, если отключенное меньше жрёт.

На более низких частотах жор может быть ниже, даже если схема сложнее.

Атомы так и не взлетели.

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

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

Другой вопрос, что конкретно на писюках, конкретно гуйня с вебом, внезапно теперь требует ужасно сложных вычислений, а ужор не так уж и важен. Да и пользователь готов платить много денег. Поэтому на писюках пока CISC безальтернативен. Во всех других областях, объём которых на порядки больше писюков, от CISC давно отказались, в том числе и из-за ужора и из-за цены. Очевидно, производительности при этом более чем хватает.

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

Посмотрим, что там Apple выкатит на ARM’ах, и как оно будет себя вести, может и на писюках CISC подвинут.

Ну с чего просрать-то лол, если отключенное меньше жрёт.

А при включении заряжать все нужные затворы чтобы привести схему в проинициализированное состояние - святым духом будешь?

И так по 100500 раз в секунду.

И так по 100500 раз в секунду

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

Атомы

А причём тут атомы?

обычных задачах

Что за обычные задачи? Специализированные инструкции могут использоваться не так редко, например SIMD в strlen() в glibc и тд.

производительности при этом более чем хватает

Не знаю, за производительные процессоры отваливают любые бабки.

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

На сегодня нет годного решения чтобы простаивающий узел ничего вообще не потреблял. Так что если он есть, то он будет жрать.

А причём тут атомы?

Попытка сделать маложрущий дешёвый CISC за счёт частоты в том числе.

Что за обычные задачи? Специализированные инструкции могут использоваться не так редко, например SIMD в strlen() в glibc и тд.

Поэтому, например, в ARM рассчитанные на strlen добавили Neon. А там где strlen не особо актуален, Neon’а нету, зато кристалл меньше и дешевле, и ужор меньше.

Кстати, SIMD вообще-то далеко не всегда даёт ощутимый прирост в скорости. Потому что тут уже имеет значение и скорость общения процессора с RAM.

Не знаю, за производительные процессоры отваливают любые бабки.

Вот только рынок менее производительных процессоров на порядки больше. Да и даже с производительными процессорами стоимость не пропорциональна скорости, я, например, не вижу вообще никакого смысла платить в несколько раз больше даже за 10% прироста производительности. Хотя, может быть кому-то многократные затраты на эти 10% могут и окупиться, хотя я с трудом представляю область, где это реально оправдано. Скорее тут больше маркетинг, чем реальная необходимость.

На сегодня нет

Что за годное решение? В реальных процессорах всё так и сделано, жор уменьшается.

менее производительных

Но они и кардинально дешевле. Кроме того, даже мобильные процы неумолимо только наращивают производительность.

В реальных процессорах всё так и сделано, жор уменьшается.

Уменьшается по сравнению с чем? С таким же процессором где отключения нет, или по сравнению с таким же процессором где вообще нет этого узла?

Но они и кардинально дешевле. Кроме того, даже мобильные процы неумолимо только наращивают производительность.

Ну да. При этом у них ещё и ужор меньше чем у аналогичных CISC. Мобильность требует экономичности по питанию. И этот фактор более значим, чем цена. Сегодня потребитель готов платить за телефончик любые деньги, их хватит даже чтобы распоследний i7 в телефон засунуть. Вот только батарейка при этом станет очень тяжёлой, и потребитель внезапно расхочет платить за телефон массой в килограмм.

Там где нет этого узла энергоэффективность хуже, когда он используется, когда узел не используется, он отключается и жрёт меньше. Это проверено и известно. Жор в отключенном состоянии, про который ты говоришь пока что чисто гипотетический и в любом случае является гораздо меньшим, чем жор если узла нет, или если его не отключать.

А при включении заряжать все нужные затворы чтобы привести схему в проинициализированное состояние

для энергосбережения не питание отключают а тактирование

https://ru.wikipedia.org/wiki/Clock_gating

Теоретически есть ещё https://en.wikipedia.org/wiki/Power_gating

Вон на 4-й малине пытаются поднять дискретку AMD/NV. Новое вообще без вариантов, оно гвоздями к x86 прибито. Со старым тоже есть проблемы (где драйверы полностью открыты) но хотя бы из-за исходников есть шанс решить - там драйверы тоже ожидают фич х86 платформы

для энергосбережения не питание отключают а тактирование

Тогда утечки. И чем меньше техпроцесс, тем больше утечка.

На сегодня нет годного решения чтобы простаивающий узел ничего вообще не потреблял. Так что если он есть, то он будет жрать.

асинхронщина и dataflow, ячейки C-Mueller-а, например

в смысле, Mueller C-gate async CPU ещё , Dataflow architerture и далее Systolic arrays (< wavefront processors), TTA BMDFM

сколько гигагерц тактовой частоты у твоего карандаша, $username?

почему вообще нужна синхронная схема с единой тактовой частотой, а не потоковый процессор систолических матриц в dataflow архитектуре, например?

почему разные части одной схемы не могут работать с разными тактовыми частотами, экономя электроэнергию и включаясь только когда по квиткам придёт поток данных в узел, чтобы обработать его?

в таком dataflow процессоре нужен не синхронный язык программирования, а некоторая хитрая схема из жгутиков, проводочков и квадратиков словно истинный метапрог SISAL какой-нибудь, например – транспилируемый в C, например, SAC

ещё по асинхронным схемам и автоматам есть такие вот интересные авторы (наверное, просто однофамильцы): раз два.

у первого есть обзор про ячейки C-element Muller, у второго в монографии вообще интересно про автоматы третьего рода, с памятью – целую теорию и новое научное направление открыл.

На сегодня нет годного решения чтобы простаивающий узел ничего вообще не потреблял.

Асинхронная логика:

…

отсутствие периодов вынужденного простоя в ожидании очередного синхроимпульса.

А если сделать в кремнии OISC

ога. или на VHDL хотя бы.

Почему не взять свободный PowerPC, sparc? Япошки 32 ядерные свободные спарки у себя клепают, даже мы sparc процы делаем.

Под PowerPC и sparc все вылезано.

Зачем risc-v? Чем он продвинуте других свободных архитектур процессоров?

Ситуация меняется стремительно: https://twitter.com/SipeedIO/status/1324632751157374977