shikhalev.org

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

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

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

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

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

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

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

Комментарии

Комментарии не проходят премодерацию, автор сайта не может нести ответственность за их содержание.

Вот эта презентация тебе может быть интересна https://speakerdeck.com/alex/why-ruby-isnt-slow.

ответ на #74d2e8

Насколько я понял, там накладываются дополнительные ограничения. Кроме того, у меня возникло ощущение, что с системой типов в Ruby автор несколько путается (там на самом деле числа, булевы и nil представляются не как объекты)…

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

ответ на #ecb2da

Насколько я понимаю, специфичное представление чисел, строк и пр. — это оптимизация, а семантически они всё равно объекты. Т.е. интерпретатор загодя не знает, что у него будет — «объект вообще» или какой-то примитивный тип, и вынужден готовиться к худшему.

Это плохо с точки зрения производительности.

Презентация как раз о том, как можно эту неопределённость устранить по мере исполнения и делать меньше операций.

Ограничения, я так понял, в самом RPython-е, а не в коде, который им парсят (по крайней мере, когда большая Ruby будет реализована). Ну и никто не мешает подобный фреймворк наваять на Ruby, просто на Python-е он уже написан =)

ответ на #17506c

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

ответ на #74d2e8

Ну, и вдобавок, я скептически смотрю на всё, что исходит от Питона. Сугубо эстетическая несовместимость у меня с ним.

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

Будет добавлен комментарий верхнего уровня.

В тексте комментария можно использовать markdown-разметку, например, *курсив* или **полужирный**. HTML-разметку использовать нельзя.

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

В случае каких-то проблем с reCAPTCHA, пожалуйста, напишите мне на shikhalev@gmail.com.