Разработчики RISC-V повторят ошибки, допущенные при развитии архитектур Arm и x86

Я не ожидаю чуда. АРМ будет таким же говном, только хуже. Скорее всего более анально-огороженным.

Ждем наш эльбрус-арм, с конвейером и исходниками.

...наш эльбрус-арм...

В таком случае, это будет уже не Эльбрус.

...наш...

А Байкал уже не торт?

Флаг переноса имеется или объяснение почему он не нужен?

Ждем наш эльбрус-арм, с конвейером и исходниками.

Народ, вы не поняли. Itatium закрыли не из-за того, что он не справился с рынком, а банально нет сильных прогеров, которые смогут осислить и поддерживать длинное слово. Тоже самое и с Эльбрусом. Мы если откроем, то никто на западе не сможет поддерживать его, так как СИЛЬНА СЛОЖНА!!! После чтения и просмотра интервью эльбрусовцев, то мне стало это ясно.

эльбрус-арм

Или ты что-то другое имела ввиду?..

АРМ будет таким же говном, только хуже.

ARM уже такое же говно, если не хуже. Анально огороженное.

АРМ будет таким же говном, только хуже. Скорее всего более анально-огороженным.

RISC-V ещё и зоопарк форков ISA добавит к этому до кучи ) На x86 один дистрибутив на все анально-огорженные платы, на arm более-менее один юзерспейс на все платы, но уже анально-огороженное китайское oem ядро. На risc-v к каждой плате будет свой китайский хелловорлд и свой китайский анально-огороженный тулчейн.

АРМ будет таким же говном, только хуже.

ARM уже такое же говно, если не хуже. Анально огороженное.

Да нет, ноутбучные чипы от Qualcomm оказались примерно на уровне с x86. Там тот же UEFI для загрузки, например. GRUB из коробки работает.

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

Это ошибка? Вроде нет. Видео не смотрел, но я не понимаю, о каких именно ошибках Лойнус говорит.

банально нет сильных прогеров, которые смогут осислить
осислить

Что-то на сексистском.

Прогеры особо не помогут с той проблемой, что порядок исполнения зависит от заранее непредсказуемых входных данных. Если не ошибаюсь, они там уже начили вкорячивать out of order execution, и какой смысл париться с vliw тогда не особо понятно. Если что, все процессоры давно не декодируют по одной инструкции а разом по 32 байт например, выходит почти что vliw, только со всратой кодировкой команд, что опять же уже давно подкостылено в железе.

нет сильных прогеров, которые смогут осислить и поддерживать длинное слово

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

Им надо перестать страдать хернёй и делать динамический анализ с out of order исполнением на стороне железа.

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

Itanium закрыли, потому что VLIW говно и не может. Дело не в прогерах, дело в убогости самой идеи.

по 32 байт например

бвахахах… сильно больше, на самом деле.

-- Мистер Торвальдс, а можно услышать какие именно ошибки?
-- Я же сказал - все.

Так есть же pgo. Строй профиль, по профилю оптимизируй

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

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

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

Потому что надо не прогу для х86 компилировать vliw компилятором, а сначала переписать её на уровне исходника.

Pgo даст усреднённый результат для тех данных, на которых был запущен. Динамический анализ подстраивается под конкретную ситуацию.

Не поможет. Эльбрусовцы пыжатся сколько лет и всё никак.

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

А нахера нужен VLIW, если чтобы показать тот же результат, что ARM и x86, под него нужно специальных прогеров выращивать? Минусы налицо, где плюсы-то? Или это просто всратый илитизм ради всратого илитизма? Мол, смарите, посоны, нашу железку погроммировать в три раза сложнее, а вы все лохи позорные со своими армами!

Не поможет. Эльбрусовцы пыжатся сколько лет и всё никак.

А ты в курсе, что нормальные прогеры работают в Blizzard? Только они оптимизируют свой код под старьё. Остальные люди говнокодят и говорят, а шо, у них деняк не будет на хорошее железо? Я свой кроссорд оптимизировал в 40 раз, хотя у меня всё работало. Вместе работы непосредственно с таблицей, я создал массив сетки, создаю кроссворд тами только потом результат вывожу. А зачем мне это было делать, ведь у всех людём железо хорошее для таких вот вычислений? Правильно, это говорит об уровне прогера и всё.

А ты в курсе, что нормальные прогеры работают в Blizzard? Только они оптимизируют свой код под старьё.

Ты ремастер WarCraft 3 видел? Там игровое меню на электроне было и лагало как сучка.

Ты ремастер WarCraft 3 видел? Там игровое меню на электроне было и лагало как сучка.

Если это было после покупки их M$, то ожидаемо.

А конкретнее?

Подозреваю что вручную оптимизированный VLIW будет эффективнее (на ту же потребляемую мощность) чем x86 оптимизированный всякими предсказаниями ветвлений итд.

С конвейером нельзя, конвейер для узких.

Подозреваю что вручную оптимизированный VLIW будет эффективнее (на ту же потребляемую мощность) чем x86 оптимизированный всякими предсказаниями ветвлений итд.

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

Это было до. И тот Близзард давно мертв. Они ремастер д2 и то на стороне заказывали

Так традиционный подход он не бесплатный. Спекулятивное исполнение == дыры. Спекулятивное исполнение == откат при ошибках предсказания. А без спекулятивного исполнения нечем растить однопоточную производительность. Частоты растут очень медленно. Так что здесь два стула со своими особенностями

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

Нынче МС компилятор об 4-строчные циклы на Си спотыкается. Приходится перефразировать, чтоб дошло.

Спекулятивное исполнение == дыры.

С анонса Meltdown прошло уже 6 лет. Хоть один пример эксплуатации подобной дыры был?

Частоты растут очень медленно.

Оооо это ваще отдельная тема. У VLIW частоты просто в полной жопе. Ни один VLIW даже за 3GHz не смог перешагнуть: ни Itanium, ни Ололбус, ваще никто. Самый последний Itanium с 8 ядрами на 32nm процессе при частоте 2.66GHz жрал 170W. Для сравнения, самый жручий Xeon на 32nm (E5-2687W, тоже 8 ядер) кушал 150W и при этом работал на частоте 3.1GHz. Другие из того же поколения до 3.6GHz доходили, но там ядер меньше и соответственно потребление ниже.

Так что внезапно VLIW даже тут дико сосёт.

Так что здесь два стула со своими особенностями

Тут нет двух стульев. VLIW – это кривая табуретка, причём перевёрнутая.

В том отрывке я не слышал, чтобы Линус упоминал эти пункты.

Одно исключение на тысячу. Даже весь из себя «народный» RPi ничем не лучше общей массы армоты, что уже говорить об остальных.

В статье написано «ошибки будут совершены» - ок, а какие? А нету нигде.

VLIW – это кривая табуретка, причём перевёрнутая

NVIDIA заявляет, что ускоритель задач машинного зрения в Jetson это VLIW. Инженеры в NVIDIA идиоты?

Itanium

Разве Itanium это VLIW? У Itanium инструкции связаны в пачки, которые могут быть достаточно длинные. У VLIW все слова одинакового размера. У Itanium если инструкция из пачки использует регистр, в который записывали в предыдущей пачке, процессор ждёт вычисленного значения. У VLIW если вычисления не закончены, чтение из регистра просто вернёт предыдущее значение. Поэтому если в обновлении Itanium какая-то инструкция станет выполняться дольше или быстрее (в циклах), программы продолжат работать. В VLIW всё сломается.

конвейер для узких

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

А что за ошибки то?

Из этих дыр есть что-то реально эксплуатируемое?

И тот Близзард давно мертв

D4 вроде норм получилось. Сам играл - мне понравилось.

Это была шутка не столько про конвейеризацию в контексте нашего доморощенного in-order VLIW, сколько про политику.

NVIDIA заявляет, что ускоритель задач машинного зрения в Jetson это VLIW. Инженеры в NVIDIA идиоты?

Ну тут речь вроде про процессоры общего назначения.

так как СИЛЬНА СЛОЖНА

Интересно, а ИИ технологии тут не помогут?

А без спекулятивного исполнения нечем растить однопоточную производительность

Которая сама по себе представляет из себя костыль к кодерам, не умеющим распараллеливать свои алгоритмы. А если от костылей избавиться, то нужно просто много ядер без спекулятивной ерунды. Энергопотребление скорее всего даже выиграет т.к. спекулятивные операции (иногда ошибающиеся) делаться не будут, да и сама логика их реализации потреблять не будет, а полезных действий будет сделано столько же.

С анонса Meltdown прошло уже 6 лет. Хоть один пример эксплуатации подобной дыры был?

Только идиот будет ждать пока ему проэксплуатируют дыру, чтоб её закрыть.

Интересно, а ИИ технологии тут не помогут?

Настоящий псевдоИИ, поняв бесполезность человеческого бытия, сбросится с лестницы и на этом их помощь закончится.

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

Ты на делфи начинал программировать чтоль? В основном оттуда с подобными на первое решениями выходят.

Ты на делфи начинал программировать чтоль?

Ага, заметно что ле?... :D

Круг замкнулся, ты пришёл к VLIW :) Который тоже страдает от ошибок предсказаний

Подозреваю что вручную оптимизированный VLIW будет эффективнее (на ту же потребляемую мощность) чем x86 оптимизированный всякими предсказаниями ветвлений итд.

Возможно, если там не будет IFов