Для поиска мемоизуемых ФП интерпретатор имеет режим работы, в котором, одновременно с вычислением значения программы, ведется накопление истории вызовов всех ФП в программе. По окончании работы программы строится таблица, в которой для каждой ФП сохраняется общее кол-во ее вычислений и кол-во различных аргументов, с которыми вызывалась данная ФП. Чем больше отношение первого числа ко второму, тем выше оценка, получаемая ФП. Также на окончательное решение мемоизовать ФП или нет влияет оценка ее структурной сложности. Чем выше эта оценка, тем больше шансов у ФП быть мемоизуемой. В данный момент интерпретатор записывает предлагаемые для мемоизации названия ФП в файл настроек funcs.xml.

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

Как мы поддерживаем любое кол-во машин в кластере и процессоров на машине?

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

Вреальности кол-во одновременно работающих на разных узлах (как компьютерах, так и процессорах) интерпретаторов на данный момент ограничивается алгоритмом поиска пересылаемых ФП и свойствами самой программы (закон Амдала). Задача нахождения оптимального порога оценки стоимости структурной сложности ФП как функции от имеющегося кластера пока стоит открытой.

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

Массивы в языке FPTL

На данный момент у нас есть реализация встроенной в язык поддержки работы с массивами на одномашинном одноядерном интерпретаторе. Мы планируем перенести эту возможность и в сетевой интерпретатор.

Компилятор программ языка FPTL

Основной целью проекта по созданию компилятора с языка FPTL является поиск оптимизаций для интерпретатора языка. Компилятор переводит программы с языка FPTL на исходный код на языке Java. Затем он вызывает компилятор, поставляемый в комплекте JDK для окончательной обработки программы.

{

return arg1 + 1;

}

else

{

if ((arg1 == 0))

{

return ACK(arg0 - 1, 1);

}

else

{

return ACK(arg0 - 1, ACK(arg0, arg1 - 1));

}

}

}

Вкомпиляторе реализованы следующие оптимизации:

Замена хвостовой рекурсии на итерацию (на данный момент заменяется только внешний, реально хвостовой вызов функции). Это дает ускорение за счет меньшей нагрузки на стек, а также возможность работы с данными большей размерности за счет не ухода в стек при рекурсивном вычислении функций.

Вычисление константных выражений (реализовано для большинства встроенных функций). Все константные выражения в программе вычисляются на этапе компиляции. К константным относятся и арифметические тождества типа “a / a = 1,

если a != 0”

В части случаев происходит замена выражений String + String (сложение строк) на использование класса StringBuilder. Это очень сильно оптимизирует алгоритмы, составляющие результат в строке (обычно рекурсивно).

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

Все данные – классы, появляющиеся в программе в виде констант, анализируются, и, при необходимости, выносятся в static-часть класса для экономии на их постоянной инициализации во время выполнения программы. Иногда, например, при проверке условия выхода из рекурсии, такие данные без этой оптимизации могут создавать очень большое кол-во раз. В таких случаях эта оптимизация выгодна.

Делаются следующие простые преобразования частных случаев условного оператора: “if(condition)var=true else var=false => var=condition”; “if(condition)var=false else var=true => var=!condition”; “if (condition) branch else branch => branch”. В последнем случае требуется полное совпадение обоих ветвей условного оператора.

Если функция condition условного оператора является одной из двух булевских констант, то генерируется лишь соответствующая ветвь условного оператора.

Функции из исходной программы, реально не используемые в коде, не компилируются. Это дает некоторую экономию на размере получаемых классов, и, соответственно, на потребление памяти средой выполнения Java.

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