Суперкомпиляторы и суперинтерпретаторы

Mar 22, 2008 12:31

Я вот думаю, что современный подход к нейронным сетям (в которых сеть заставляют моделировать объект, а не просто "распознавать") и суперкомпиляторы (в которых делается модель программы, замещающая исходную программу в тот момент, когда результаты их исполнения оказываются эквивалентными) -- это один и тот же подход примата моделирования над ( Read more... )

Leave a comment

Comments 32

vvagr March 22 2008, 09:43:57 UTC
Надо думать по другому.

Компилятор - это построение модели объекта. Объект - программа.

А интерпретатор - часть модели, и интерпретируемая программа - часть модели. Объект же - из предметной области.

Reply

ailev March 22 2008, 10:14:35 UTC
Ты путаешь компилятор и суперкомпилятор: компилятор не строит модель программы, он осуществляет эквивалентные преобразования (трансформацию) программы из одного языка в другой. Компилятор на выходе получает ту же самую программу. Суперкомпилятор строит модель, у него на выходе -- другая (совсем!) программа, результаты выполнения которой идентичны исходной. Вот про суперкомпилятор можно говорить, что речь идет о моделировании (а не трансформации текста).

А у тебя какое-то нестандартное понимание модели. Интерпретатор у тебя -- часть модели чего?! Текста программы?! А кто тогда запускает модель в работу (исполняет ее)? И этот тип рассуждения еще нужно как-то помечать специально, чтобы не путать с традиционным рассуждением о моделировании в суперкомпиляции, чтобы людей не запутывать.

Reply

vvagr March 22 2008, 10:27:27 UTC
Я тебе предлагаю взгляд на проблему интерпретации, потому про компиляцию писал просто для сравнения.

Интерпретатор - часть модели предметной области. Инфраструктура модели. Ты же спрашивал - как понимать процесс интерпретации как моделирование. Я тебе и ответил.

При суперкомпиляции есть два процесса моделирования - моделирование предметной области на языке А и моделирование программы на языке А программой на языке Б.

При интерпретации - моделирование есть, но оно идёт в один такт. Кстати, наверняка есть системы, моделирующие далее вполне рабочую модель в интерпретаторе.

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

Reply

ailev March 22 2008, 11:49:41 UTC
Это ты воспроизводишь стандартное рассуждение про метамоделирование aka стек (мета)моделей. Не имеет отношения к указываемой мной проблеме различий в типе одной из моделей в стеке.

Компиляция-на-лету, а также инкрементальная компиляция тоже давно известны, и они понятно как обходятся с точками суперпозднего связывания (а именно -- их не трогают ;)

Суперкомпиляция выгодна тогда, когда на вход подается вся программа (ибо как раз основные оптимизации в суперкомпиляции происходят не с участками программы "от вызова до вызова", а именно в изменении всей структуры). Так что твое замешивание всего стека метамоделей непонятно какое отношение имеет к обсуждаемой проблеме.

Reply


avlasov March 22 2008, 09:50:04 UTC
А они неплохо параллельно развиваются. Да и совместные проекты делают - те же JIT'ы.
В контексте динамической компиляции не трудно сделать и суперкомпилятор для экстремально позднего связывания - просто генерировать специализированный код в момент связывания или чуть позже. Либо применять хинты/эвристики.
Можно и строготипизированные языки адаптировать под экстремально позднее связывание.

Reply


rssh March 22 2008, 10:28:18 UTC
Как бы сказать -- суперкомпиляуия своидит сложную программу к несколько более простой. Как-бы упрощает текст. Позднее свзязывание уменьшает сложность текстов за счет перененсения выбора из альтернатив на уровень структуры ыпрограммы. Тексты которые раньше были сложными теперь можно записать проще. Но сложность текстов определяется все таки не задачей а способностями человека генерировать сложные тексты. Которые тоже можно упрощать (если можно как-то зафиксировать контекст времени выполнения). Т. е. актуальность суперкомпиляции с наличием позднего связывания слабо связана. Ну и использование структурного аналища для суперкомпиляции развивается тоже (вместо анализа if-ов аналищируем структуру иерархии),
но это немного другая история.

Reply


vitus_wagner March 22 2008, 11:43:38 UTC
Компиляторы (в том числе и супер) и интерпретаторы - просто имеют принципиально разные области применения. Не надо писать на компилируемых языках то, где нужно сильно позднее связывание (интерфейсы пользователя, мобильные агенты и т.д.), но не надо и писать на интерпретируемых языках реализации криптоалгоритмов.

Reply

slobin March 22 2008, 12:10:11 UTC
"Позднее связывание" + "компиляция" = "поздняя компиляция". Just in Time, Ahead of Time -- умных слов много. Почему-то на моих задачках Питон, пропущенный через такой вот поздний компилятор, оказывается строго вторым после чистых C и впереди компилируемых Ocaml и C++. Надо будет попробовать криптоалгоритм на нём написать и замерить.

... Ненавижу романтику и электронику ...

Reply

avlasov March 22 2008, 16:31:01 UTC
А что за задачи если не секрет?

Reply

slobin March 22 2008, 20:29:16 UTC
"Всякая фигня" (© анекдот). Парсинг текста, последующая обработка -- то, что всю жизнь писали на языках типа Перла или Питона и называли не "программами", а "скриптами". Оно и было на Питоне, но захотелось побыстрее. Переписанное вручную на чистом Си быстрее стало, но в XXI веке вручную распределять память? На Окамле и Плюсах выигрыша почти на было. Пинон+писхо, ну и переписать отдельные места кода, которые он иначе не смог скомпилить и оставил интерпретируемыми, оказалось самым удачным вариантом.

... Morning waits at the end of the world ...

Reply


slobin March 22 2008, 12:04:41 UTC
сеть заставляют моделировать объект

На Lambda the Ultimate была вчера ссылка на статью про что-то похожее. Правда, саму статью я ещё не прочитал, прочитал только аннотацию. Насколько я понял, идея там такая: у программистов в голове есть интуитивное понятие "алгоритма", который реализует программа. Разные программы могут реализовывать один и тот же алгоритм. ⇒ Алгоритм есть класс эквивалентности программ. И авторы статьи доказывают аргументируют, что ввести такую эквивалентность разумным образом нельзя. Ссылка и обсуждение здесь. (Не путать с проблемой эквивалентности алгоритмов, которая изучена давно и хорошо).

... Жители антиутопии чаще всего счастливы ...

Reply


Leave a comment

Up