Comments 3
Однако все это разбивается о суровую жизненную реальность, если мы говорим о применимости такого подхода в разработке реального софта.
Во первых, сейчас еденицей трансляции компилятора является файл. Т.е если вы напишете конвертор из внутреннего представления GCC или LLVM в ваш граф зависимостей, то вы не увидите всю программу.
Во вторых, превозносимая вами VLIW очень хреново работает с ветвящимся кодом. Предикаты спасают на очень низком уровне, а вот циклы и функции, завернутые в условия уже нет. Это все обходится версионностью кода, который приводит к гигантскому раздутию исполняемых файлов (а это память, проблемы с кэшем). Причем у современных x86/64 с этим особых проблем не наблюдается, предсказание и быстрое отбрасывание неправильно взятых переходов сильно сглаживает эту проблему.
С моей колокольни DataFlow анализ имеет больше перспектив чем автопараллелизация на таком уровне. Да, он более сложный, хотя бы потому что не статичный. И в современных языках с обилием указателей сложно правильно определить потоки для анализа. Но если решить эту задачу, сначала на виртуальной машине, а потом возможно и в железе, сам вопрос о том как правильно параллелить исчезнет. Кстати чисто теоретически в том же Rust эти потоки уже должны быть вложены в парадигму языка. Пока нет времени поковыряться внутри, но может быть это можно использовать для анализа.
Да, мечтаю и я увидеть работающий Data-Flow… Пока только (с 1996 г. в P6) Intel включает в свои разработки блок Dispatche/Execute Unit (DE), реализующий Data-Flow для ограниченного числа упреждающе считанного числа команд (кстати, то же в AMD — процессоры K5 etc). Похоже, в самом деле без массового производства ассоциативной памяти ничего не выйдет...
А насчёт "cуровой жизненной реальности" Вы вряд ли правы! Подобные описанной мной системы давно работают (насколько эффективно — вопрос). Любой компилятор фактически строит граф команд — остаётся его неглупо обработать. Совсем необязательно обрабатывать его сразу (многие миллионы инструкций) — это прекрасно делается частями (в моём тексте об этом есть). Прерывания обрабатываются традиционно, только вместо одной точки запоминается и восстанавливается конкретная VLIW-связка. Работа с сабрутинами нисколько не мешает предикации — она используется только ВНУТРИ подпрограммы. Насчёт longjump… не знаю пока!
А про использовании моей системы для ИССЛЕДОВАНИЯ алгоритмов Вы правильно упомянули — для этого и делалось всё..! Делалось для исследовательской студентов "Вышки" и МИРЭА, где я веду занятия. Студентов учат "программировать", но этому "и обезьяну научить можно" (словами Стругацких); моя же цель — "копнуть глыбже" (на уровень системного ПО — разработки компиляторов etc).
Не понимаю Ваш термин "прототип", честно говоря. При чём здесь прототип? Я представляю математическую модель процесса взаимодействия алгоритма с исполнительной системой (обработчиком команд = процессором)… и всё! Я с окончания ВУЗ'а занимаюсь математическим моделированием (http://vbakanov.ru/right_5.htm, http://vbakanov.ru/right_1.htm etc) и уверен, что таким путём можно решить множество вопросов при создании нового оборудования и процессов. Нет смысла считать себя Богом — любая мат. модель — это только модель и её назначение — определить только существенные, главные параметры реального процесса (не любые, конечно, а ВЫБРАННЫЕ — то, что в данное время интересует исследователя). и я всегда говорю — я сделал ТО, следующие могут ПОЙТИ ДАЛЬШЕ..!
Где-то вначале я задал смешной вопрос (ответ на поверхности — так мне казалось) о форме огибающей кривой интенсивности вычислений — на что похожа? Ответа так и не получил — думать народ разучился!.. Это кривая закона Пуассона, конечно (ибо вычисления, естественно, суть выпуклый пример процесса массового обслуживания)...
Перечитал с БОЛЬШИМ запаздыванием. Фраза "Всё это конечно хорошо" явственно напомнила классическое изречение дона Сэра (братья Стругацкие, ТРУДНО БЫТЬ БОГОМ, 1963) - "Это, скажет, - очень всё бла-ародно, а вот как там насчёт баб?.."...
Сколько стоит расписание