От переводчика: пару часов назад Гвидо в своём твиттере упомянул блог-пост своего коллеги, одного из (бывших) разработчиков Unladen Swallow, в котором тот рассказывает грустную историю яркой, но короткой жизни Unladen Swallow в Google.
Оригинал: Reid Kleckner — Unladen Swallow Retrospective
Я начал это писать, пока я был на PyCon, но понемногу уточнял текст с тех пор. Как бы то ни было, вот. :)
Как сейчас уже очевидно, никто больше всерьёз не занимается ни Unladen Swallow напрямую, ни портированием его на py3k. Почему?
Потеря интереса заказчиков
Основная причина — в том, что в Google так и не нашлось достаточного количества потенциальных пользователей для Unladen Swallow. Это вызвано несколькими причинами:
После того, как закончилась моя стажировка, я попытался сделать Unladen темой моей магистерской работы в MIT, но мой руководитель посчитал, что достигнутые на тот момент результаты не обещают хороших перспектив, и что концепции, которые я хотел применить, уже не считаются современными. Основные методики (от переводчика: имеются в виду методики генерации оптимизированного кода на основании слежения за процессом выполнения неоптимизированного) feedback-а уже реализовывал Urs Hölzle для Smalltalk, а методики tracing-а — Andreas Gil (из комментариев: на самом деле, Andreas Gal) для Java. Конечно, это не значит, что новых методик больше уже никому не изобрести, но на тот момент у меня свежих идей не было.
Потеря собственного интереса
В основном, всё вышеперечисленное было обдумано в первом квартале 2010-го года. Мы по-прежнему могли решить работать над Unladen в наше свободное время, но это было бы уже по-другому.
Во-первых, работать над проектом в одиночку далеко не настолько прикольно, как вместе с другими людьми, особенно если неочевидно, будут ли у вашего творения когда-нибудь пользователи.
Во-вторых, одна из основных причин нашего интереса была в том, что мы полагали, что PyPy никогда даже не попытается поддерживать расширения на C или обёрнутый SWIG-ом код. Мы были весьма удивлены, когда узнали, что проект PyPy начал движение именно в этом направлении. Это частично ослабило потребность в «сменном» JIT для CPython. Кроме того, когда проект был запущен, PyPy ещё не поддерживал 64-битную платформу, но со временем они добавили и эту поддержку.
И, в конце концов, комментарии в python-dev, которые мы читали, нас не обнадёживали. Люди предполагали, что, если Unladen Swallow попадёт в py3k, то этот код будет поддерживаться Google-ом, но эти предположения были уже беспочвенны. Если мёрж кода произошёл бы, похоже, это значило бы, что по умолчанию JIT был бы выключен, и через годик, из-за редкого использования и отсутствия поддержки, его пришлось бы опять убрать. Совсем немного разработчиков оказались заинтересованы в новом JIT-е. Мы так и не домёржили код, но мы надеялись, что, если мы закончим, то сможем воодушевить разработчиков CPython-а подхватить его.
Итак, с учётом всех вышеперечисленных причин, по которым никто из нас больше не занимается Unladen, что же мы поняли?
Выводы о LLVM
Во-первых, мы глубоко изучили плюсы и минусы использования LLVM для генерации кода JIT-ом. Наше первоначальное решение использовать LLVM было принято по причине того, что никто из нас не знал ассемблер x86 достаточно глубоко, но мы при этом хотели поддерживать и x86, и x86_64, и, может быть, даже ARM. Мы рассмотрели вариант переработать psyco, но отказались в основном из-за необходимости глубокого знания x86.
К сожалению, на данный момент LLVM слишком ориентирован на использование в качестве статического оптимизатора и бэкенда. Кодогенерация и оптимизация LLVM-а хороши, но слишком «дороги» в использовании. Оптимизации слишком ориентированы на работу с промежуточным представлением кода, генерируемым статическими C-подобными языками. Большинство основных методик оптимизации Python-а требуют высокоуровневого представления, как программа работала на предыдущих итерациях, что было затруднительно с LLVM.
Примером того, как применяется высокоуровневое представление в кодогенерации, является оптимизация работы со стеком Python-а. LLVM не способен оптимизировать чтение из стека Python-а между вызовами внешних функций (т.е. окружения CPython, а значит, фактически никогда). Чтобы решить эту проблему, нам в конце концов пришлось написать анализ алиасов, и это всё является характерным примером того, с чем сталкиваешься, если не создаёшь свой собственный кодогенератор.
Кроме того, к LLVM прилагаются и другие ограничения. К примеру, LLVM всерьёз не поддерживает back-patching (от переводчика: судя по всему, динамическую модификацию кода), которую PyPy использует для правки на лету выходов из веток проверки работающего кода. Это достаточно важное требование со значительным потреблением памяти, но с последним я бы поспорил, ибо по результатам работы Steven Noonan-а в рамках GSOC, потребление можно уменьшить, особенно учитывая, что потребление памяти у PyPy было выше.
Кроме того, я потратил лето на создание интерфейса между LLVM JIT и gdb. Это не было необходимо, но в результате получился полезный инструмент. Я не знаю, что сейчас используется для отладки PyPy, но мы можем воспользоваться полученным нами опытом и применить его к PyPy.
Результаты
Лично я, ещё до начала работы над этим проектом, прошёл курс по компиляторам и операционным системам, но приобретённый во время работы опыт принёс мне огромное количество новых навыков. Я теперь весьма хорошо разбираюсь в gdb, правил его под себя и даже отлаживал gdb посредством gdb. Теперь я знаю намного больше о x86, методиках оптимизации компиляторов, особенностям JIT, и это я использую в моей магистерской работе.
Я также весьма горжусь нашим макро-бенчмарковым набором реальных Python-овых приложений, который сейчас активно используется проектом PyPy: speed.pypy.org. Пожалуй, из всей моей связанной с производительностью Python-а деятельности он оказался самым полезным. Любое изменение производительности легко заметить по изменениям результатов до и после его появления.
Мы также принесли некоторую пользу и LLVM, тем самым помогая другим основанным на LLVM JIT-проектам, таким как Parrot и Rubinius. К примеру, я помог исправить 16-мегабайтовое ограничение на анализируемый JIT-ом код. Опять же, теперь для LLVM JIT имеется интерфейс gdb. Джефф также потратил много времени на то, чтобы C-шные функции можно было вкомпиливать прямо в сгенерированный JIT-ом код, а также на правку утечек памяти и добавление шаблона TypeBuilder-а для сборки C-шных типов в LLVM.
Поэтому, как бы мне ни хотелось, чтобы было больше ресурсов, и проект выжил бы, это всё принесло мне огромный опыт, нам удалось принести некоторую пользу LLVM и создать весьма полезный набор бенчмарков.
Оригинал: Reid Kleckner — Unladen Swallow Retrospective
Unladen Swallow: ретроспектива
Я начал это писать, пока я был на PyCon, но понемногу уточнял текст с тех пор. Как бы то ни было, вот. :)
Как сейчас уже очевидно, никто больше всерьёз не занимается ни Unladen Swallow напрямую, ни портированием его на py3k. Почему?
Потеря интереса заказчиков
Основная причина — в том, что в Google так и не нашлось достаточного количества потенциальных пользователей для Unladen Swallow. Это вызвано несколькими причинами:
- Для основного объёма Python-кода в Google высокая производительность не требуется. Python используется в основном для инструментов и прототипирования, в то время как основные приложения, ориентированные на конечных пользователей, написаны на Java и C++.
- Тех же внутренних пользователей, кому производительность была важна, смутили слишком сложные требования к развёртыванию Unladen Swallow. Для них не просто требовалось, чтобы Unladen Swallow был заменой CPython — любая новая реализация Python должна была заменить имеющуюся «под ключ». Мы думали, что, базируя исходный код на CPython, а не начиная разработку с абсолютного нуля, мы избежим этой проблемы, потому что все расширения на C и SWIG-обёртки продолжат работать как ни в чём не бывало. Тем не менее, даже переход с предыдущей версии CPython на Python 2.6 оказался слишком сложным.
- Наши потенциальные пользователи так или иначе нашли другие способы решения своих проблем с производительностью, которые для них оказались более удобными в развёртывании.
После того, как закончилась моя стажировка, я попытался сделать Unladen темой моей магистерской работы в MIT, но мой руководитель посчитал, что достигнутые на тот момент результаты не обещают хороших перспектив, и что концепции, которые я хотел применить, уже не считаются современными. Основные методики (от переводчика: имеются в виду методики генерации оптимизированного кода на основании слежения за процессом выполнения неоптимизированного) feedback-а уже реализовывал Urs Hölzle для Smalltalk, а методики tracing-а — Andreas Gil (из комментариев: на самом деле, Andreas Gal) для Java. Конечно, это не значит, что новых методик больше уже никому не изобрести, но на тот момент у меня свежих идей не было.
Потеря собственного интереса
В основном, всё вышеперечисленное было обдумано в первом квартале 2010-го года. Мы по-прежнему могли решить работать над Unladen в наше свободное время, но это было бы уже по-другому.
Во-первых, работать над проектом в одиночку далеко не настолько прикольно, как вместе с другими людьми, особенно если неочевидно, будут ли у вашего творения когда-нибудь пользователи.
Во-вторых, одна из основных причин нашего интереса была в том, что мы полагали, что PyPy никогда даже не попытается поддерживать расширения на C или обёрнутый SWIG-ом код. Мы были весьма удивлены, когда узнали, что проект PyPy начал движение именно в этом направлении. Это частично ослабило потребность в «сменном» JIT для CPython. Кроме того, когда проект был запущен, PyPy ещё не поддерживал 64-битную платформу, но со временем они добавили и эту поддержку.
И, в конце концов, комментарии в python-dev, которые мы читали, нас не обнадёживали. Люди предполагали, что, если Unladen Swallow попадёт в py3k, то этот код будет поддерживаться Google-ом, но эти предположения были уже беспочвенны. Если мёрж кода произошёл бы, похоже, это значило бы, что по умолчанию JIT был бы выключен, и через годик, из-за редкого использования и отсутствия поддержки, его пришлось бы опять убрать. Совсем немного разработчиков оказались заинтересованы в новом JIT-е. Мы так и не домёржили код, но мы надеялись, что, если мы закончим, то сможем воодушевить разработчиков CPython-а подхватить его.
Итак, с учётом всех вышеперечисленных причин, по которым никто из нас больше не занимается Unladen, что же мы поняли?
Выводы о LLVM
Во-первых, мы глубоко изучили плюсы и минусы использования LLVM для генерации кода JIT-ом. Наше первоначальное решение использовать LLVM было принято по причине того, что никто из нас не знал ассемблер x86 достаточно глубоко, но мы при этом хотели поддерживать и x86, и x86_64, и, может быть, даже ARM. Мы рассмотрели вариант переработать psyco, но отказались в основном из-за необходимости глубокого знания x86.
К сожалению, на данный момент LLVM слишком ориентирован на использование в качестве статического оптимизатора и бэкенда. Кодогенерация и оптимизация LLVM-а хороши, но слишком «дороги» в использовании. Оптимизации слишком ориентированы на работу с промежуточным представлением кода, генерируемым статическими C-подобными языками. Большинство основных методик оптимизации Python-а требуют высокоуровневого представления, как программа работала на предыдущих итерациях, что было затруднительно с LLVM.
Примером того, как применяется высокоуровневое представление в кодогенерации, является оптимизация работы со стеком Python-а. LLVM не способен оптимизировать чтение из стека Python-а между вызовами внешних функций (т.е. окружения CPython, а значит, фактически никогда). Чтобы решить эту проблему, нам в конце концов пришлось написать анализ алиасов, и это всё является характерным примером того, с чем сталкиваешься, если не создаёшь свой собственный кодогенератор.
Кроме того, к LLVM прилагаются и другие ограничения. К примеру, LLVM всерьёз не поддерживает back-patching (от переводчика: судя по всему, динамическую модификацию кода), которую PyPy использует для правки на лету выходов из веток проверки работающего кода. Это достаточно важное требование со значительным потреблением памяти, но с последним я бы поспорил, ибо по результатам работы Steven Noonan-а в рамках GSOC, потребление можно уменьшить, особенно учитывая, что потребление памяти у PyPy было выше.
Кроме того, я потратил лето на создание интерфейса между LLVM JIT и gdb. Это не было необходимо, но в результате получился полезный инструмент. Я не знаю, что сейчас используется для отладки PyPy, но мы можем воспользоваться полученным нами опытом и применить его к PyPy.
Результаты
Лично я, ещё до начала работы над этим проектом, прошёл курс по компиляторам и операционным системам, но приобретённый во время работы опыт принёс мне огромное количество новых навыков. Я теперь весьма хорошо разбираюсь в gdb, правил его под себя и даже отлаживал gdb посредством gdb. Теперь я знаю намного больше о x86, методиках оптимизации компиляторов, особенностям JIT, и это я использую в моей магистерской работе.
Я также весьма горжусь нашим макро-бенчмарковым набором реальных Python-овых приложений, который сейчас активно используется проектом PyPy: speed.pypy.org. Пожалуй, из всей моей связанной с производительностью Python-а деятельности он оказался самым полезным. Любое изменение производительности легко заметить по изменениям результатов до и после его появления.
Мы также принесли некоторую пользу и LLVM, тем самым помогая другим основанным на LLVM JIT-проектам, таким как Parrot и Rubinius. К примеру, я помог исправить 16-мегабайтовое ограничение на анализируемый JIT-ом код. Опять же, теперь для LLVM JIT имеется интерфейс gdb. Джефф также потратил много времени на то, чтобы C-шные функции можно было вкомпиливать прямо в сгенерированный JIT-ом код, а также на правку утечек памяти и добавление шаблона TypeBuilder-а для сборки C-шных типов в LLVM.
Поэтому, как бы мне ни хотелось, чтобы было больше ресурсов, и проект выжил бы, это всё принесло мне огромный опыт, нам удалось принести некоторую пользу LLVM и создать весьма полезный набор бенчмарков.
