shikhalev.org

Последние записи

ТехнологииПрограммированиеАбстракции

2013.11.11 • Иван Шихалев

На полях: RTTI для статики

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

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

RTTIоптимизацияразмышлизмыстатическая типизацияязыки программирования

4 комментария   Добавить комментарий

ТехнологииПрограммированиеАбстракции

2013.10.09 • Иван Шихалев

Возвращаясь к размышлизму...

Или снова об оптимизации скриптовых языков. В предыдущей заметке я это всё как-то сумбурно описал. Вкратце: для условного веб-сервиса минута инициализации много «дешевле», чем секунда обработки запроса. Поэтому, проведя собственно инициализацию, имеет смысл оптимизировать с ее учетом дальнейшую работу. И для скриптовых языков это вполне возможно, в отличие от компилируемых. А вот как это мне представляется в плане практики:

  • Составляем граф переходов для загруженной программы. Естественно, учитываем на данном этапе все возможные переходы.

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

    По идее, нам надо выделить самый главный цикл, а циклы в инициализации и финализации нас уже не интересуют. Скорее всего, его таки можно выделить, но в общем случае — проблематично.

  • Когда исполнение доходит до такой точки невозврата, включаем оптимизацию дальнейшего кода:

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

Естественно, это всё не отменяет классической алгоритмической оптимизации, JIT-компиляции и т.д. после сокращения всего ненужного. И естественно, всё это не будет работать при «eval(string)» внутри циклов, но так делать в любом случае не стоит…

оптимизацияразмышлизмыскриптовые языкиязыки программирования

5 комментариев   Добавить комментарий

ТехнологииПрограммированиеАбстракции

2013.05.17 • Иван Шихалев

Об оптимизациях скриптовых языков...

Подумалось: а ведь скриптовые интерпретируемые языки вполне способны на не­ко­то­рых задачах обгонять компилируемые и сильно, если программу не исполнять, а вычислять как формулу — это же совершенно не обязательно делать по-порядку. Можно «раскрыть скобки», «привести подобные», «сократить»… Соременные компиляторы, собственно, так и делают, но они могут зафиксировать только параметры, известные на этапе компиляции, а для прочих приходится учитывать все возможные комбинации значений, тогда как при ка­ж­дом конкретном запуске программы их подмножество существенно ограничено. Многие вещи — такие как: переменные среды, параметры командной строки и т.д. — определяются при старте и далее могут считаться константами, соответственно, упрощаются выражения от них и т.д.

Понятно, что это упрощение дальнейших выражений не бесплатное: скорее всего, скажем, удаление неиспользуемых ветвлений будет требовать больше ресурсов, чем вычисление этих условий по ходу дела, но ежели эти условия и другие выражения должны вычисляться многократно… Скажем, для вебсервера время старта куда менее критично, чем время отклика на запрос.

Что для этого нужно? Во-первых, структурированное внутреннее представление, с которым можно манипулировать как с фор­му­лой — это не текст и не байт-код (в Ruby свежих версий именно так). Во-вторых, необходимо как-то определять наличие побочных эффектов (в Ruby это, пожалуй, может быть довольно просто реализовано для собственно ruby-методов, а вот с мо­ду­ля­ми, загружаемыми как .so и .dll будет проблема. Впрочем, достаточно к нескольким системным фунциям типа define_method добавить соответствующие описательные параметры). И в-третьих, желательна жесткая инкапсуляция данных, так что Ruby для этой цели подходит, а вот, скажем, JavaScript — намного хуже.

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

оптимизацияразмышлизмыскриптовые языкиязыки программирования

Нет комментариев   Добавить комментарий