1 (изменено: Freeman, 25.10.2015 в 13:51)

Тема: Суперкомпилятор и его инфраструктура

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

Оптимизации, применяемые суперкомпилятором

  • Фактическое использование:

    • Создание VMT из фактического использования и перекрытия методов в коде.

    • Оптимизация вызовов new с выбором заполнения экземпляра нулями в каждом конкретном случае, в зависимости от фактической инициализации свойств, указанной в теле new.

  • Разделяемые объекты:

    • Отслеживание достижимости объектов и автоматическое оборачивание разделяемых по владению объектов интерфейсом с подсчетом ссылок.

    • (Возможно) Отслеживание многопоточного кода и автоматическое оборачивание разделяемых по доступу объектов интерфейсом блокировки и синхронизации. Это будет или основа транзакций, или сами транзакции.

  • Исключения:

    • Спрямление вызовов raise..except, если обработчик исключения известен на этапе компиляции.

Чему противоречит суперкомпиляция

  • В суперкомпиляторе по определению невозможна раздельная сборка модулей в том виде, в каком она существует в традиционных компиляторах вроде Delphi. Суперкомпиляция переосмысливает понятие раздельной сборки, относя ее только к интерфейсам (БД кода), а машинный код всегда генерируется на самом последнем этапе.

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

Инфраструктура

Пункты ниже не относятся к теме суперкомпиляции, но влияют на архитектуру компилятора, поэтому приведены здесь ради единства.

  • Открытый API позволяет подключать предметно-ориентированные языки (DSL) подгружаемыми модулями (плагинами) к компилятору. Модули могут быть написаны на Канторе или быть двоичными DLL.

  • Языконезависимость обеспечивается на уровне входного языка, локализуемые строки хранятся отдельно от исходного кода (аналог resourcestring Delphi с бо́льшими возможностями).

  • Инфраструктура компилятора:

    • Выдает документацию из БД исходного кода, используя вики-комментарии и их объектную модель.

    • Позволяет делать переводы и правку локализаций отдельно от написания кода, ориентируется на непрограммистов (продвинутых пользователей, из командной строки).

2

Re: Суперкомпилятор и его инфраструктура

После прочтения статьи в блоге Intel подумалось, что в Канторе не просто так нет циклов. Если считать, что проблема развертывания и векторизации циклов -- одна из самых сложных при оптимизации программ, замена циклов объектной алгеброй -- заточка под суперкомпиляцию.

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

3 (изменено: Freeman, 03.02.2017 в 11:37)

Re: Суперкомпилятор и его инфраструктура

Почему в Канторе нет ссылок на код?

Мы уже говорили, что если ООП моделирует окружающий мир, то объектно-ориентированная ОС -- Вселенную. В этой Вселенной есть свои базовые физические понятия:

  • Состояние -- материя и энергия.

  • Пространство -- решаемые задачи.

  • Время -- код.

  • Гравитация -- компилятор.

На практике ведь именно код определяет машинное время, требуемое для решения задачи? А плохой код -- место, где решаемые задачи и код меняются местами, -- полный аналог черной дыры.

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

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

Чем меньше бюрократов в системе -- тем проще преодолевать расстояние до решения, разгоняясь до скорости света и совершая гравитационные маневры -- оптимизации. Поэтому в нашей Вселенной ссылок на код нет.

4

Re: Суперкомпилятор и его инфраструктура

Классная метафора!

5

Re: Суперкомпилятор и его инфраструктура

Наверное, тут тоже стоит отписаться.

После Ростова стало понятно, что в этой теме перепутаны понятия кодогенерации времени связывания и непосредственно частичных вычислений (суперкомпиляции) как таковой, имеющей вполне четкие признаки, которые я теперь знаю. Нужно будет как-то разделить темы. Думаю, по мере развития теорий сделаю.

Ранее я решил использовать термин частичные вычисления для описания научной и технической части проекта, а суперкомпиляцию оставить на популярные, "рекламные" тексты, продвижение. На деле эти термины означают одно и то же, просто частичные вычисления были предложены академиком Ершовым, а суперкомпиляция — Валентином Турчиным. Как понял, в российской академической среде они используются как взаимозаменяемые, и недопонимания не будет.