Почему VLIW это плохо.
Originally posted by thesz at Почему VLIW это плохо.
Надо просуммировать, ибо считать Эльбрус 2СМ хорошим процессором в смысле качества архитектуры я смысла не вижу.
VLIW, Very Large Instruction Word, выдает несколько RISC-подобных команд за один такт. Команды эти двух-трёх операндные, наподобие команд MIPS. Команды группируются в длинное слово разными способами, ни один из которых не является хорошим.
Выдача длинного слова на выполнение не производится до тех пор, пока аргументы ВСЕХ команд длинного слова не готовы. То есть, если одна команда использует результат команды деления (с переменным числом тактов, для наглядности), то все команды длинного слова будут стоять в ожидании.
Источников непредсказуемой задержки у нас не так уж и много - это деление и обращение к памяти. Обращение к памяти в некоторых случаях может быть предсказано, таких случаев не много. В основном, это простая линейная алгебра и простая обработка сигналов. Все остальные задачи будут требовать устойчивости к задержкам обращения в память.
Практически все VLIW процессоры плохо работают на обычном коде, представленном в SPECint.
В обзоре Эльбруса он отставал на 7Zip от Intel Core i7 в семь раз, примерно. Отличие тактовых частот было почти 12 раз. Если бы мы замедлили Intel Core i7 до тактовой частоты Эльбруса, то его конвейер сократился бы до 5 шагов (с 20) и скорость выполнения увеличилась бы вчетверо, если не больше. А это означает, что на тактовой частоте Эльбруса гипотетический медленный i7 с длинным конвейером работал бы примерно в полтора раза медленней, а с укороченным - примерно втрое быстрее.
Команды в VLIW группируются либо по числу устройств (и дополняются NOOP до нужного числа), либо присутствует специальный бит остановки. Оба способа плохи с точки зрения двоичной совместимости. Если вы сделаете процессор с меньшим числом исполнительных устройств, то вы не можете просто так выполнять код процессора с большим числом исполнительных устройств. Потому, что одна команда может переписывать регистр, используемый другой командой длинного слова. И если вы начнёте выполнять команды последовательно, то результат будет другим, нежели при параллельном выполнении. Или вам придётся так распределять регистры, чтобы команды не пересекались по зависимостям, что не улучшает эффективности использования регистров.
Практически все VLIW процессора не имеют прямой и обратной двоичной совместимости.
Последнее прямо запрещает делать линейки процессоров с одной системой команд, как делает ARM и даже Intel. В результате VLIW это практически всегда один представитель.
VLIW требует гигантского регистрового файла. Его никто не смог сделать быстрым и небольшим (что помогает сделать его быстрым). Даже Intel с его бешеными ресурсами имеет Itanium на частоте в полтора гигагерца, когда i7 на тех же процессах давно работает на частоте вдвое большей.
Плотность кода VLIW меньше RISC в несколько раз. RISC вдвое менее плотный, чем CISC x86. Это настолько серьёзная проблема, что для VLIW DSP делают специальные компиляторы, что часть программы выдают в виде стекового кода, для компактности.
Последнее. Составление расписания выдачи инструкций базового блока (не функции и не программы!) является NP-сложной задачей. Это когда и вычисление расписания, и проверка его на оптимальность являются NP-полными задачами.
В результате, если вы делаете VLIW процессор, вы сразу ставите на нём крест, как на процессоре общего назначения. MS Word на нём будет работать плохо, процессор для телефона и для сервера вы так не сделаете.
Все эти данные известны с 2006 года, примерно.
Поэтому Эльбрус 2СМ хорош, как пример реальной системы с реализованными для него сложными протоколами периферии. Мы можем. Как процессор он плох. Но это не мешает ему быть замечательным примером, что мы можем.
Надо просуммировать, ибо считать Эльбрус 2СМ хорошим процессором в смысле качества архитектуры я смысла не вижу.
VLIW, Very Large Instruction Word, выдает несколько RISC-подобных команд за один такт. Команды эти двух-трёх операндные, наподобие команд MIPS. Команды группируются в длинное слово разными способами, ни один из которых не является хорошим.
Выдача длинного слова на выполнение не производится до тех пор, пока аргументы ВСЕХ команд длинного слова не готовы. То есть, если одна команда использует результат команды деления (с переменным числом тактов, для наглядности), то все команды длинного слова будут стоять в ожидании.
Источников непредсказуемой задержки у нас не так уж и много - это деление и обращение к памяти. Обращение к памяти в некоторых случаях может быть предсказано, таких случаев не много. В основном, это простая линейная алгебра и простая обработка сигналов. Все остальные задачи будут требовать устойчивости к задержкам обращения в память.
Практически все VLIW процессоры плохо работают на обычном коде, представленном в SPECint.
В обзоре Эльбруса он отставал на 7Zip от Intel Core i7 в семь раз, примерно. Отличие тактовых частот было почти 12 раз. Если бы мы замедлили Intel Core i7 до тактовой частоты Эльбруса, то его конвейер сократился бы до 5 шагов (с 20) и скорость выполнения увеличилась бы вчетверо, если не больше. А это означает, что на тактовой частоте Эльбруса гипотетический медленный i7 с длинным конвейером работал бы примерно в полтора раза медленней, а с укороченным - примерно втрое быстрее.
Команды в VLIW группируются либо по числу устройств (и дополняются NOOP до нужного числа), либо присутствует специальный бит остановки. Оба способа плохи с точки зрения двоичной совместимости. Если вы сделаете процессор с меньшим числом исполнительных устройств, то вы не можете просто так выполнять код процессора с большим числом исполнительных устройств. Потому, что одна команда может переписывать регистр, используемый другой командой длинного слова. И если вы начнёте выполнять команды последовательно, то результат будет другим, нежели при параллельном выполнении. Или вам придётся так распределять регистры, чтобы команды не пересекались по зависимостям, что не улучшает эффективности использования регистров.
Практически все VLIW процессора не имеют прямой и обратной двоичной совместимости.
Последнее прямо запрещает делать линейки процессоров с одной системой команд, как делает ARM и даже Intel. В результате VLIW это практически всегда один представитель.
VLIW требует гигантского регистрового файла. Его никто не смог сделать быстрым и небольшим (что помогает сделать его быстрым). Даже Intel с его бешеными ресурсами имеет Itanium на частоте в полтора гигагерца, когда i7 на тех же процессах давно работает на частоте вдвое большей.
Плотность кода VLIW меньше RISC в несколько раз. RISC вдвое менее плотный, чем CISC x86. Это настолько серьёзная проблема, что для VLIW DSP делают специальные компиляторы, что часть программы выдают в виде стекового кода, для компактности.
Последнее. Составление расписания выдачи инструкций базового блока (не функции и не программы!) является NP-сложной задачей. Это когда и вычисление расписания, и проверка его на оптимальность являются NP-полными задачами.
В результате, если вы делаете VLIW процессор, вы сразу ставите на нём крест, как на процессоре общего назначения. MS Word на нём будет работать плохо, процессор для телефона и для сервера вы так не сделаете.
Все эти данные известны с 2006 года, примерно.
Поэтому Эльбрус 2СМ хорош, как пример реальной системы с реализованными для него сложными протоколами периферии. Мы можем. Как процессор он плох. Но это не мешает ему быть замечательным примером, что мы можем.