Как стать автором
Обновить

Комментарии 6

Эффективность VLIW-машин далее в книге детально анализируется и Карцев, в частности, пишет, что "целесообразная величина n (количество процессоров) для вычислительных систем типа III лежит в пределах 2-6".

Пока эльбрусы 32 ядра обещают, такая книга не то что засекречена - запрещена будет.

желательно, чтобы длительность выполнения операции не зависела не только от операндов, но и от типа операции, потому что цикл работы системы и здесь подстраивается под наибольшее время работы любого из n процессоров…

Думаю, для процессора общего назначения это требование не реализуемо в принципе. Для специализированных процессоров расширения дело другое.

А вообще спасибо за находку. Помнится, мне случайно попалась статья 1960х годов из СССР о квадродеревьях для оптимизации доступа к большим растровым картам - японцы в 1990х этот подход и реализовали в автомобилях, получилась навигационная система в автомобиле с картой на DVD диске.

Спасибо за комментарий!

По поводу 2-6 процессоров. В книге, говоря современным языком, речь идет о функциональных узлах в составе одного VLIW-ядра. Интересно, что Карцев весьма консервативен в своей оценке. В этом смысле любопытно вспомнить, что в VLIW-проектах Фишера фигурировало до 30 параллельных RISC-операций!

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

В целом, речь идет об ограничениях для двух разных типов параллелизма. Если воспользоваться терминологией Карцева, то это параллелизм смежных операций (внутри ядра) и параллелизм независимых ветвей (на уровне системы ядер).

По поводу "не реализуемо в принципе". Цитата из учебника верна не только для VLIW, так работают in-order процессоры. Я с Вами согласен, что для специализированных процессоров такие решения наиболее применимы.

Кстати говоря, я добавил в статью некоторые подробности о комбинированной архитектуре Карцева. Надеюсь, это тоже будет интересно!

По-видимому, оптимизация программы методом трансляции может быть выполнена более эффективно, чем методом интерпретации, поскольку при трансляции можно обеспечить просмотр программы вперед на большее количество шагов".

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

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

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

Такие языки уже созданы - на том же питоне можно в несколько строк кода запустить вычисления на десятках и сотнях многоядерных хостов. Есть ленивые вычисления - можно работать с частью огромного датасета так, что код выполняется только на запрошенном кусочке, а только при необходимости запускается на всех данных параллельно (раз умеем по кусочку обрабатывать, уже несложно распараллелить). Так что делом занять все ядра не проблема, а вот калькулятору или текстовому редактору хорошо бы уметь обходиться одним ядром, а не пытаться с большим оверхедом распараллелиться…

Обнаружил очень интересный документик о VLIW. Ребята утверждают, что по сравнению с пятиступенчатой конвеерной архитектурой VLIW выигрывает в среднем в 1.4 раза (от 1.2 до 1.57)
Прикол в том, что VLIW у них базируется на RISC-V и 256-битных командах.
Так что VLIW еще рано хоронить.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории