Pull to refresh

Comments 2

Всё это конечно хорошо. Красивая теория, есть какой то прототип, который даже работает.
Однако все это разбивается о суровую жизненную реальность, если мы говорим о применимости такого подхода в разработке реального софта.

Во первых, сейчас еденицей трансляции компилятора является файл. Т.е если вы напишете конвертор из внутреннего представления 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) и уверен, что таким путём можно решить множество вопросов при создании нового оборудования и процессов. Нет смысла считать себя Богом — любая мат. модель — это только модель и её назначение — определить только существенные, главные параметры реального процесса (не любые, конечно, а ВЫБРАННЫЕ — то, что в данное время интересует исследователя). и я всегда говорю — я сделал ТО, следующие могут ПОЙТИ ДАЛЬШЕ..!


Где-то вначале я задал смешной вопрос (ответ на поверхности — так мне казалось) о форме огибающей кривой интенсивности вычислений — на что похожа? Ответа так и не получил — думать народ разучился!.. Это кривая закона Пуассона, конечно (ибо вычисления, естественно, суть выпуклый пример процесса массового обслуживания)...

Only those users with full accounts are able to leave comments. Log in, please.