среда, 9 октября 2013 г.

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

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

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

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

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

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

5 комментариев:

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

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

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

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

      Удалить
  2. Насколько я понимаю, специфичное представление чисел, строк и пр. — это оптимизация, а семантически они всё равно объекты. Т.е. интерпретатор загодя не знает, что у него будет — «объект вообще» или какой-то примитивный тип, и вынужден готовиться к худшему.
    Это плохо с точки зрения производительности.
    Презентация как раз о том, как можно эту неопределённость устранить по мере исполнения и делать меньше операций.
    Ограничения, я так понял, в самом RPython-е, а не в коде, который им парсят (по крайней мере, когда большая Ruby будет реализована). Ну и никто не мешает подобный фреймворк наваять на Ruby, просто на Python-е он уже написан =)

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

      Удалить