Каждый раз, когда на рынке появляется новая архитектура процессоров, всё повторяется. Когда Arm стала серверной платформой, они повторили все те ошибки, которые Линус видел десятилетием или двумя ранее на x86
Народ, вы не поняли. Itatium закрыли не из-за того, что он не справился с рынком, а банально нет сильных прогеров, которые смогут осислить и поддерживать длинное слово. Тоже самое и с Эльбрусом. Мы если откроем, то никто на западе не сможет поддерживать его, так как СИЛЬНА СЛОЖНА!!! После чтения и просмотра интервью эльбрусовцев, то мне стало это ясно.
АРМ будет таким же говном, только хуже. Скорее всего более анально-огороженным.
RISC-V ещё и зоопарк форков ISA добавит к этому до кучи ) На x86 один дистрибутив на все анально-огорженные платы, на arm более-менее один юзерспейс на все платы, но уже анально-огороженное китайское oem ядро. На risc-v к каждой плате будет свой китайский хелловорлд и свой китайский анально-огороженный тулчейн.
Среди недостатков RISC-V — относительно незрелая экосистема с инструментами, программным обеспечением и поддержкой, которые всё ещё находятся в стадии развития по сравнению с устоявшимися архитектурами. Кроме того, возможны проблемы совместимости между различными редакциями.
Это ошибка? Вроде нет. Видео не смотрел, но я не понимаю, о каких именно ошибках Лойнус говорит.
Прогеры особо не помогут с той проблемой, что порядок исполнения зависит от заранее непредсказуемых входных данных. Если не ошибаюсь, они там уже начили вкорячивать out of order execution, и какой смысл париться с vliw тогда не особо понятно. Если что, все процессоры давно не декодируют по одной инструкции а разом по 32 байт например, выходит почти что vliw, только со всратой кодировкой команд, что опять же уже давно подкостылено в железе.
нет сильных прогеров, которые смогут осислить и поддерживать длинное слово
Дело в том, что статический анализ во время компиляции сосёт. Это хорошо видно на примере Эльбруса, у которого некоторые программы в режиме эмуляции x86 работают быстрее, чем когда откомпилированы в родные инструкции.
Им надо перестать страдать хернёй и делать динамический анализ с out of order исполнением на стороне железа.
Народ, вы не поняли. Itatium закрыли не из-за того, что он не справился с рынком, а банально нет сильных прогеров, которые смогут осислить и поддерживать длинное слово.
Itanium закрыли, потому что VLIW говно и не может. Дело не в прогерах, дело в убогости самой идеи.
Прогеры особо не помогут с той проблемой, что порядок исполнения зависит от заранее непредсказуемых входных данных
Помогут ещё как. Прогер это не тот кто тебе сортировку пузырьком правильно закодит, а тот кто начнёт с выбора алгоритма сортировки, места, где она производится, и вообще подумает нельзя ли обойтись другими путями, и только потом закодит выбранное им решение.
Сейчас очень модно писать без применения мозга, ожидая что компилятор и железо сами за тебя всё оптимизируют, такие «прогеры» во VLIW не годятся да.
Сейчас очень модно писать без применения мозга, ожидая что компилятор и железо сами за тебя всё оптимизируют, такие «прогеры» во VLIW не годятся да.
А нахера нужен VLIW, если чтобы показать тот же результат, что ARM и x86, под него нужно специальных прогеров выращивать? Минусы налицо, где плюсы-то? Или это просто всратый илитизм ради всратого илитизма? Мол, смарите, посоны, нашу железку погроммировать в три раза сложнее, а вы все лохи позорные со своими армами!
Не поможет. Эльбрусовцы пыжатся сколько лет и всё никак.
А ты в курсе, что нормальные прогеры работают в Blizzard? Только они оптимизируют свой код под старьё. Остальные люди говнокодят и говорят, а шо, у них деняк не будет на хорошее железо? Я свой кроссорд оптимизировал в 40 раз, хотя у меня всё работало. Вместе работы непосредственно с таблицей, я создал массив сетки, создаю кроссворд тами только потом результат вывожу. А зачем мне это было делать, ведь у всех людём железо хорошее для таких вот вычислений? Правильно, это говорит об уровне прогера и всё.
Подозреваю что вручную оптимизированный VLIW будет эффективнее (на ту же потребляемую мощность) чем x86 оптимизированный всякими предсказаниями ветвлений итд.
Подозреваю что вручную оптимизированный VLIW будет эффективнее (на ту же потребляемую мощность) чем x86 оптимизированный всякими предсказаниями ветвлений итд.
Не будет. На всех бенчмарках даже с ручной оптимизацией VLIW показывает худшую производительность как на Ватт мощности, так и в принципе.
Так традиционный подход он не бесплатный. Спекулятивное исполнение == дыры. Спекулятивное исполнение == откат при ошибках предсказания. А без спекулятивного исполнения нечем растить однопоточную производительность. Частоты растут очень медленно. Так что здесь два стула со своими особенностями
С анонса Meltdown прошло уже 6 лет. Хоть один пример эксплуатации подобной дыры был?
Частоты растут очень медленно.
Оооо это ваще отдельная тема. У VLIW частоты просто в полной жопе. Ни один VLIW даже за 3GHz не смог перешагнуть: ни Itanium, ни Ололбус, ваще никто. Самый последний Itanium с 8 ядрами на 32nm процессе при частоте 2.66GHz жрал 170W. Для сравнения, самый жручий Xeon на 32nm (E5-2687W, тоже 8 ядер) кушал 150W и при этом работал на частоте 3.1GHz. Другие из того же поколения до 3.6GHz доходили, но там ядер меньше и соответственно потребление ниже.
Так что внезапно VLIW даже тут дико сосёт.
Так что здесь два стула со своими особенностями
Тут нет двух стульев. VLIW – это кривая табуретка, причём перевёрнутая.
NVIDIA заявляет, что ускоритель задач машинного зрения в Jetson это VLIW. Инженеры в NVIDIA идиоты?
Itanium
Разве Itanium это VLIW? У Itanium инструкции связаны в пачки, которые могут быть достаточно длинные. У VLIW все слова одинакового размера. У Itanium если инструкция из пачки использует регистр, в который записывали в предыдущей пачке, процессор ждёт вычисленного значения. У VLIW если вычисления не закончены, чтение из регистра просто вернёт предыдущее значение. Поэтому если в обновлении Itanium какая-то инструкция станет выполняться дольше или быстрее (в циклах), программы продолжат работать. В VLIW всё сломается.
VLIW не запрещает использовать конвейеризацию. Проблемы будут только с инструкциями, которые выполняются разное число циклов в зависимости от входных данных.
А без спекулятивного исполнения нечем растить однопоточную производительность
Которая сама по себе представляет из себя костыль к кодерам, не умеющим распараллеливать свои алгоритмы. А если от костылей избавиться, то нужно просто много ядер без спекулятивной ерунды. Энергопотребление скорее всего даже выиграет т.к. спекулятивные операции (иногда ошибающиеся) делаться не будут, да и сама логика их реализации потреблять не будет, а полезных действий будет сделано столько же.
Подозреваю что вручную оптимизированный VLIW будет эффективнее (на ту же потребляемую мощность) чем x86 оптимизированный всякими предсказаниями ветвлений итд.