> Изначально VLIW - это широкое командное(ШК) слово,И во всех виденных вариантах это подавалось в блоки выполнения, которые не являются 100% независимыми и самодостаточными. Что и вызывало заморочки по части кодогенерации.
> максимум из 5 команд и только одна пятая команда могла выполнять сложные операции.
Да, это так называемый VLIW5. Потом некоторые относительно новые GPU 6000-й серии "оптимизировали", с аргументацией "все-равно все 5 блоков редко кто может прогрузить", обрубив до VLIW4 (аналогично по смыслу, но лишь 4 команды). Это сократило площадь чипа и удешевило оный. Сие пофиг играм (они и правда редко могут), но воздалось в сильно параллелящихся задачах. Не в лучшую сторону.
А еще кроме математики есть например управление ходом выполнения программы. Оно сделано по остаточному принципу и там какие-то отдельные ограничения, достаточно невкусные. Эта штука нацелена на массовое однотипное применение математики к большим массивам данных, без резких разворотов. Это хорошо работает для графики, но AMD же хочется GPGPU. Не надо быть академиком чтобы понять что упомянутая архитектура разборчива в алгоритмах и произвольно взятый алгоритм вовсе не обязан там работать хорошо. Оптимизация под такую штуку - отдельный и нишевой гемор, хоть и творит чудеса, когда програмер смог придро^W к странному стилю написания алгоритмов, где много математики которая хорошо параллелится и минимум execution flow control. Как несложно понять - это весьма специфичные простынки, не сильно похожие на обычные реализации алгоритмов, где програмер явным образом подыгрывает странноватой природе этой штуки. Все это стало мотивом к созданию GCN, который несколько улучшает ситуацию. Конечно если алгоритм напрочь не параллелится - GPU ему не поможет, но тем не менее, GCN имеет все шансы вести себя лучше на произвольно впиханых в него алгоритмах.
> Например все 5 могли производить сложения, а операцию синус
> могла делать только пятая.
Там вроде еще какие-то взаимозависимости есть, на предмет того какие команды в слове могут соседствовать. А управление ходом выполнения вообще все люто нагибает и есть куча ограничений. Отдельный SIMD-элемент не может такое делать независисмо.
> Мне неизвестно, как в Эльбрусе устроено ШК слово, но именно от его
> возможностей и будет зависеть сложность его программирования.
Вон итаник тоже VLIW был. И тоже страдал от подобных проблем.
> и возрастает сложность архитектуры в таком случае.
Именно. Так получается "честный 25-ядерник", а VLIWовость ему как-то и не очень требуется: можно "узкие" команды в каждый блок независимо толкать. Это, конечно, удобно программировать, но сложно произвести с разумным размером кристалла и потреблением. А если довести до абсолюта, как в GPU - пара тысяч упрощенных ALU в определенных задачах сильно вставляет десятку обычных ядер при той же площади кристалла и потреблении. Но как проц общего назначения - ни о чем. Вот и появляются гетерогенные вещицы типа APU, где есть и нормальный проц и такой вот акселератор к нему. Как раз APU смотрятся очень логично, давая возможности использовать плюсы обоих архитектур: то что плохо ложится на пачку простых ALU - на обычный проц, то что хорошо - на акселератор.
И кстати раз уж это доперло и до амд и до интеля и до много кого еще (ARM и то уже заикается про OpenCL) - не очень понятно почему местные тупят. В порядке инженерного бреда: взять ARM64 системным процом, а нечто VLIW-образное упростить/перемасштабировать/затвикать как амд с GCN, получив GPU/акселератор.
> У разработчиков Эльбруса свои компиляторы и они хорошо знают
> устройство своего процессора.
Свои компиляторы - это звиздато, но что ими компилить? Линь вон например без приключений собирается только gcc. Еще есть какие-то эксперименты насчет шланга, но там уже не без проблем. При том оба про VLIW знают чуть менее чем ничего. А проц без софта и/или с хреновенькой эмуляцией х86... вот все и приходит к тому что дубовое и тормозное страшило с "правильным", "отечественным" - даже не включают, поставив в темный угол. Так что по документам все как бы замечательно. А задачи ворочает по факту обычный х86 писюк с американским процом и виндовсом. При том такая фигня даже в критичных применениях.
> И насколько я знаю, сам процессор разрабатывался с учётом на высокоуровневые
> языки программирования.
VLIW просто специфичная штука, которая не особо хорошо дружит с уже существующими компилерами и софтом. Что и играет с ними дурную шутку. Хотя их подход имеет право на жизнь в теории, на практике VLIW означает много мороки на ровно месте. Без лютой и весьма специфичной оптимизации алгоритмов - результаты VLIW-образных процов отнюдь не поражает воображение. Поэтому на мое IMHO, VLIW имеет смысл не как общесистемный проц а как некая основа для акселератора в который таки вгрузят алгоритмы оптимизированные под массовый параллельный долбеж.
> Они портировали некоторые программы и ядро линукс тоже. Так что было на
> чём тестировать
При том я могу себе представить результаты этих тестов и насколько не доставляет соотношение цена/производительность в типовых задачах.
> А ещё по сравнению с предыдущей версией процессора они увеличили ШК слово
> на 2 инструкции - не просто же так они это сделали.
А вон амдшники сперва обрубили размер слова (VLIW5 -> VLIW4), а потом и вовсе донавесили добавочных блоков и оно стало несколько больше смахивать на более традиционные процы (GCN). Интел и трансмета вообще забили по сути.
> Если бы у них были трудности с заполнением 23 инструкций, то
> стали бы они добавлять ещё 2 ?
Не знаю. Я их процов не видел даже на картинке (что косвенно намекает об "успешности" и "всеобщей востребованности" архитектуры) и поэтому мне сложно это оценить напрямую. Говоря за амдшные GPU, чтобы они нормально считали, алгоритм должен быть скроен совершенно не так как скроена типичная ОС или программа. Это должна быть большая простыня математики, с абсолютным минимумом перетурбаций в ходе выполнения. Это мягко говоря не похоже на типичный код программ. И хотя оно "тоже си", но сами простынки оптимизнутые на скорость выполнения - выглядят очень специфично.
