ARM капец в скором будущем?

аж целых 2000 ноутбуков? ну всё, ARM-капец близок!

ведь очевидно

алибабашное ядро

CPU – Alibaba XuanTie C906 64bit RISC-V core with 32 KB I-cache + 32 KB D-cache

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

примерный аналог cortex-a53

экспонаты изначально для музеев

Ну вряд ли этими устройствами сделают конец ARM. Но теоретически, возможность отказаться от arm или от x86 конечно есть. Допустим крупные вендоры сделают ставку на risc-v, доработают его для всех своих нужд, и просто начнут делать устройства на нём, в том же духе, как сейчас используется Linux для всего. При таком подходе разработчики вроде amd, samsung будут делать дизайны и производить чипы, а производители устройств вроде hp, huawei, того же samsung - будут производить устройства с готовыми чипами или делать чипы по дизайнам разработчиков. И естественно это будет закат одновременно как arm, так и x86. Но едва ли это будет хорошо для пользователей, потому что каждый чип будет как apple m1, в значительной степени кастомный. И пока не понятно, надо ли это вендорам, выгодно ли это им или их устраивает существующий порядок дел.

Я вам даже больше скажу.

https://3dnews.ru/1026872/yadro-riscv-na-chastote-52-ggts-ustanovilo-rekord-po-proizvoditelnosti-na-vatt-i-oboshlo-apple-m1-na-dva-poryadka

На два порядка! На самом деле, очень сомнительно.

Для сравнения, процессор Apple M1 в том же тесте CoreMark показывает результат 10 000 баллов.

Да ну, весь процессор!

Ноуты с Apple M1 оказались способными конкурировать с предыдущими моделями на Интеле, для которых:

https://www.eembc.org/viewer/?benchmark_seq=13387

CoreMark 239,026

Очевидно, с процессором на 10000 баллов так бы не вышло.

Apple M1 может достигать 30000 на одно из своих производительных ядер:

CoreMark 1.0 : 30866.579211 / GCCApple LLVM 12.0.0 (clang-1200.0.32.27) -O2 -DMULTITHREAD=1 -DUSE_PTHREAD -DPERFORMANCE_RUN=1 / Heap

https://news.ycombinator.com/item?id=25263243

Это при производительности на те же два порядка ниже? А когда её поднимут до приемлемой, энегоэффективность пробьёт днище. Пора уже понять что бесплатный сыр только в мышеловке, а все легкодоступные улучшения давно выжаты.

Жду BeagleV!

Кто-то кстати объяснит почему OpenSPARC не взлетел?

На самом деле, очень сомнительно

Поэтому я жду публичный релиз и независимые тесты.

Но сам факт, что уже есть высокопроизводительный прототип, радует.

Их ядро в 2-3 раза медленнее ядра M1 и пока только в этом случае энергоэффективнее, и не в 100 раз, а всего где-то в 3,3 раза.

Продвижение RISC-V однозначно радует. Но вот такие статьи приносят больше вреда чем пользы.

Но едва ли это будет хорошо для пользователей, потому что каждый чип будет как apple m1, в значительной степени кастомный.

В RISC-V есть набор стандартных расширений и метод их идентификации. Не вижу проблем с кастомностью. В x86 тоже везде разный набор расширений и даже есть разный несовместимый набор расширений от Intel, AMD (3D Now!), VIA.

Поделятся ли чинчонги технологиями

Конечно же поделятся. За деньги ничего не жалко.

ведь очевидно процессоры должны быть лучше эльбрусовых затычек.

Это почему?

Кто-то мешает Китай делать мощные процессоры на Мипс?

Риск-в разве чем-то пиинципиально в этом плане от МИПС?

несовместимый набор расширений от Intel, AMD

На практике нету. Амд давно дропнуло поддержку 3dnow и других собственных расширений в своих процах. Про via вообще смешно.

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

Тут всё зависит от выгоды вендоров. Если им выгодно будет более-менее стандартные наборы делать, то всё ок. Если нет, то проблем будет предостаточно. Разница с x86 в том, что в рамках семейства процессоров или нескольких семейств стандартизация прямо во всем поля. Тут же может быть ситуация, когда чипы одного года выпуска и одного производителя - будут сильно разные по составу и нужно будет надеяться на то, что производитель позаботился о программной поддержке в апстриме. Но опять же, это всё зависит от того что выгодно будет производителю. Поживём - увидим.

Риск-в разве чем-то пиинципиально в этом плане от МИПС?

RISC-V – это по сути следующая версия MIPS. MIPS Technologies прекратили разработку MIPS и перешли на RISC-V.

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

Зачем? Это надо будет делать свои компиляторы или переделывать существующие, а потом это всё поддерживать. Для стандартного RISC-V уже есть готовые компиляторы Clang и GCC, а также эмуляторы и прочие инструменты разработки. Проще договориться с авторами спецификации RISC-V и компиляторов чтобы они стандартизировали необходимое расширение.

Даже на основе Linux часто готовят ядра китайцы и не только так, что только в виде блобов это можно есть и обновления бывают в течении полугода-года.

В ядре Линукс «stable API nonsense», так что всё ОК. Делать драйвера под Линукс без блобов и старых версий ядра крайне затруднительно.

MIPS Technologies не имеет ничего общего с RISC-V

Вы хоть викингов почитайте :)

А переходить на эту архитектуру могут все.

https://www.eejournal.com/article/wait-what-mips-becomes-risc-v/

https://en.wikipedia.org/wiki/Berkeley_RISC

Это почему?

потому что эльбрус это VLIW, а для процессоров общего назначения, а не DSP, этот подход сакс

Спасибо за подтверждения моих слов.

Эээ….
В общем то я согласен.
По моим ламерским понятиям программу нужно перекомпилировать под каждую новую версию VLIW процессора чтобы получить ожидаемую производительность.

Что и продемонстрировал интеловский Итаник

Но достичь уровня Эльбрус за год-два не получится, по моему

По моим ламерским понятиям программу нужно перекомпилировать под каждую новую версию VLIW процессора чтобы получить ожидаемую производительность.

Зависит от конкретной архитектуры VLIW процессора.

Перекомпиляция для новой версии E2K не обязательна. Работать будет соизмеримо росту тактовой частоты и улучшения подсистемы памяти. Если же хочется задействовать новые операции (явно или через оптимизации компилятором), то необходимо пересобрать, так же как и для x86/ARM/etc.

Для IA-64 желательно пересобрать под каждую новую микроархитектуру, в отличии от E2K.

проблема VLIW - то, что это самое длинное слово далеко не всегда можно задействовать на 100%. В итоге получается неэффективно

Для IA-64 желательно пересобрать под каждую новую микроархитектуру, в отличии от E2K

Хмм.
Насколько мне известно - «желательно пересобрать под каждую новую микроархитектуру» относится ко всем VLIW процессорам.
Видимо кроме Эльбрус, но это не точно.

Не согласен. Проблема in-order VLIW в непредсказуемости доступа в память и сопутствующих простоев конвейера.

IA-64 в первую очередь EPIC, а потом уже VLIW.

E2K ближе к классическим VLIW, но со своими заморочками.

Для IA-64 желательно пересобрать под каждую новую микроархитектуру, в отличии от E2K

Не успел поправить
Насколько мне известно - «желательно пересобрать под каждую новую микроархитектуру» относится ко всем VLIW процессорам так как изменяются параметры обработки данных и какие-то данные становытся нужны раньше, какие-то позже чем в предыдущем варианте соответственно производительсть становится меньше чем ожидалось так как нужно заргрущить дополнительные VLIW и новые инструкции нипричём.

Кроме Эльбрус, но это не точно.

IA-64 в первую очередь EPIC, а потом уже VLIW.

Вау!

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

Я же написал, что это зависит от конкретной архитектуры. Каким местом ты читаешь?

Если в ISA явно указаны задержки операций, кол-во каналов/портов не меняется и их функционал не расширяется, то большого выигрыша в производительности после перекомпиляции не получишь. В случае E2K функционал расширялся только в v4 (каналы 2 и 5 получили по FPU). Эльбрусы никогда не показывали пиковые FLOPS на реальных задачах. Должно очень сильно повести, чтобы кол-во и соотношение операций в алгоритме идеально легли на аппаратные возможности. Единственное, что действительно помогло бы улучшить производительность, так это улучшения УОМ в v5 для невыровненного линейного доступа в память для некоторых случаев. Больше толку от новых операций, но оптимизировать/пересобирать нужно вне зависимости от ISA.

В IA-64 иная ситуация. В новой версии микроархитектуры могут очень сильно перелопатить задержки и количество доступных аппаратных устройств. ISA никак не ограничивает это дело. Всё из-за выбранной модели явного параллелизма (EPIC) со скрытыми задержками операций. Попытка усидеть на двух стульях одновременно. В последних версиях микроархитектура уже частично стала OoOE, так что это слегка потеряло актуальность. VLIW тут постольку-поскольку. Последовательность независимых инструкций может распространятся на несколько бандлов. Формально в EPIC процессор можно подавать и RISC последовательность, правда сильно это ему не поможет. Сама модель исполнения неудачная.

Да и какая тебе разница? Тебе же это в общем то совсем не интересно.

ведь очевидно процессоры должны быть лучше эльбрусовых затычек.

Кому очевидно? Как скалярщина может быть очевидно лучше или хуже vliw?

E2K ближе к классическим VLIW

Это в чём выражается?

Если сильно упростить, то проще аппаратура — сложнее компилятор.

Не нужно упрощать. Меня интересует утверждение о том, что e2k ближе к VLIW, чем к EPIC. Я смотрел на описания e2k и ia64, и что-то заявление о близости к чему-то там плохо ложится на то, что я читал.

Эльбрусы никогда не показывали пиковые FLOPS на реальных задачах

Ну это же другое дело!

Я говорил о случаях когда компилятор хорошо оптимизировал код и в результате от VLIW есть польза.

Не будет никакого ни ARM-капца, ни x86-капца, ни вообще каких либо глобальных телодвижений.

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

Толку от того, что чинчонги поделятся технологиями ?

Ну соберут на этой «технологии» очередную фуфлятину, которая заикается при загрузке торрентов ибо lan-over-usb. Ну возможно запустят на ней Linux определенной версии. Ну и забьют через пару месяцев на поддержку, как уже раньше бывало, потому что эти конторы слишком худые, чтобы поддерживать то, что они выпускали год назад.

Может быть x86 и не такой хороший как хотелось бы. Однако сегодня я взял дискету с MS-DOS 6.22 и запустил его на процессоре 2020 года выпуска, и оно запустилось. Софт 1994 года, да.

А поди запусти один и тот же Линукс на ARM’ах к примеру 2019 года. Хрен там. То u-boot не такой, то script.bin не там, то boot.scr не сгенерен. Под каждый высер своя программа-прошивальщик, свои правила, вставь кабель, зажми левую с конца кнопку, передерни три раза бла бла бла. Нафиг этот гембель на десктопах.

Он продемонстрировал, что перекомпиляция не помогает.

Но таких случаев зафиксировано не было.

В классическом VLIW явно доступны все аппаратные ресурсы, их задержки и прочие упрощения аппаратуры. В компилятор стараются вынести как можно больше работы. Если к такому процессору прикрутить OoOE, то это уже не классический VLIW (какими их изначально планировали). То есть ISA будет под классический VLIW (читай только фасад), но микроархитектура уже будет сложной, а все упрощения ISA (обычно выражены в кодировке) становятся рудиментами.

EPIC не столько про кодирование инструкций (aka VLIW/CISC/RISC/etc), сколько про модель исполнения. В классическом VLIW в такт запускается ровно 1 бандл как то позволяет кодирование операций. В EPIC исполняется группа бандлов (в IA-64 обычно по 3 операции на бандл по 2 бандла в такт). В группе между операциями нет RAW зависимостей (помимо доступа в память, управления потоком исполнения и прочих исключений), то есть такая ситуация является UB:

{ // group 0
   add r0 = r1, r2
   op1
   op2
}
{
   add r3 = r4, r0 // undefined behaviour, used r0 in the same group 0
   op4 rN = ... ;; // stop group 0
   op5 r5 = r6, r0 // OK, group 1
}
{ // group 1, bundle 0
   ...

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

Это всё очень поверхностно, т.к. существуют разные подходы к исполнению самих бандлов (группы операций одновременно поступающих в декодер, хотя и это не обязательно). Например в E2K доступ в память также упорядочен в ШК/бандле. Но возможны и более современные подходы по внедрению зависимых (читай bypass’у вычисленных значений в этой же группе) операций в одной группе. Например такое:

{
   ld_i64 r0 = [addr]
   add r1 = r0, 0x10
   st_i64 [addr] = r1 // *addr += 0x10
   br label
}

Это позволяет 1 бандлом (1 такт) выполнить такую группу операций, а не запускать 3 бандла (3 такта). Уже сильнее отходит от изначальных идей заложенных в VLIW, но не так сильно как EPIC.

E2K очень старая архитектура. Она физически не могла далеко отойти от первоначальных (классических) идей. В E2K очень много разных фич на все случаи жизни. Объединяет их одно, они все работают в связке с программным обеспечением. Это сродни споров вокруг ARM, и того что он якобы не RISC.

Если же проводить параллели по VLIW составляющей IA-64, то он очень похож на E2K (хоть и сильно проще в этом, делали одни и те же люди), но по модели запуска операций кардинально от него отличается (как я понимаю это хотелка Intel). Вот и получается EPIC + VLIW.

Может быть x86 и не такой хороший как хотелось бы. Однако сегодня я взял дискету с MS-DOS 6.22 и запустил его на процессоре 2020 года выпуска, и оно запустилось. Софт 1994 года, да.

Можно подробней? ДОС понял работающий в режиме Legacy BIOS UEFI? Смог загрузится по подключенному через usb флоппи-риадеру? Если все так хорошо, зачем нужен FreeDOS?

ДОС понял работающий в режиме Legacy BIOS UEFI?

Есть совместимость с legacyBIOS.

Смог загрузится по подключенному через usb флоппи-риадеру?

На корпоративных материнских платах выводят аппаратный COM.

Из всего этого я могу заключить, что в твоём понимании EPIC и VLIW — ортогональные понятия. И высказывание «что-то там ближе к VLIW, чем к EPIC» примерно настолько же осмысленное, как и «до забора ближе, чем до вечера».

Можно подробней? ДОС понял работающий в режиме Legacy BIOS UEFI? Смог загрузится по подключенному через usb флоппи-риадеру? Если все так хорошо, зачем нужен FreeDOS?

Я не говорил, что все хорошо. Я говорил что на современном процессоре работает софт 26-летней давности. Что в мире АРМов - рассказать ?)

что-то там ближе к VLIW, чем к EPIC

Ближе к классическому VLIW. Я пишу не про кодирование нескольких операций в одну большую инструкцию, а про изначальную концепцию заложенную в это понятие.

Термин не новый. Не понимаю, почему это вызывает такие трудности в понимании.

The authors show that the advantages of the VLIW-in-the-large computing model with respect to the classical VLIW approach are …

Date of Conference: 27-29 Nov. 1990 https://ieeexplore.ieee.org/document/151422/

Clustering is a well-known technique for improving the scalability of classical VLIW processors.

Date of Conference: 9-14 Oct. 2011 https://ieeexplore.ieee.org/document/6062029

То u-boot не такой, то script.bin не там, то boot.scr не сгенерен.

UEFI решает эти проблемы. Его даже в U-Boot завезли. И железо от Apple на ARM использует UEFI если не ошибаюсь.

UEFI решает эти проблемы. Его даже в U-Boot завезли. И железо от Apple на ARM использует UEFI если не ошибаюсь.

Чтобы UEFI что-то там решил - он должен сперва загружаться процессором. Если u-boot загрузился, то прикольно, дальше все и без UEFI заработает. Давайте чтоб без лишней демагогии, перейдем к практике: передо мной лежит Xiaomi на Snapdragon 625. Киньте ссылку на ISO линукса, который я могу за’dd’шить на microSD-карту, ребутнуть телефон и загрузица с карты. Ессесно без перепрошивки загрузчиков, рекавери, дроча с чрутом и тд. Ванильный линукс на ARM плиз!

передо мной лежит Xiaomi на Snapdragon 625

Там UEFI? Нет? Вот в этом и проблема: в убогих не стандартизированных U-Boot, а не в ARM. С помощью UEFI и таблицы устройств FDT можно сделать единый образ для разного железа так что драйверы будут выбираться в зависимости от конкретного железа.

Это кстати наглядная демонстрация что будет если дать волю фанатам свободы в духе Линукса в плане разработки железа. Хорошо что CoreBoot не получил популярности, а то и на x86 был бы такой же бардак.

Понятия классического VLIW и более современного EPIC близки, но между ними есть разница о которой уже сказал numas13, но в том числе и во временных рамках. Собственно Intel/HP и ввели понятие EPIC, когда E2k уже был.

Можно ли e2k относить к epic это дискуссия бесполезная, но ia64 и e2k может быть и схожи на первый взгляд, они далеко не равны друг другу.

Термин не новый. Не понимаю, почему это вызывает такие трудности в понимании.

Itanium это VLIW?

А тебе вопрос такой. Что такое EPIC? Что такого должно быть в архитектуре процессора, чтобы можно было сказать, что это не VLIW, а EPIC? Были ли вообще процессоры EPIC процессоры, кроме Itanium?

Т.е. конторы зарабатывающие деньги VLIW процессорах это миф?