Увидел свет (https://github.com/dropbox/pyston/releases/tag/v0.6) релиз проекта Pyston 0.6 (http://www.pyston.org), в рамках которого компанией Dropbox, в которой работает Гвидо ван Россум, развивается высокопроизводительная реализация языка Python, созданная с использованием наработок проекта LLVM. Реализация примечательна применением современных технологий JIT-компиляции и нацелена на достижение высокой производительности, близкой к производительности традиционных системных языков, таких как C++. Код Pyston написан на языке C++ и распространяется (https://github.com/dropbox/pyston) под лицензией Apache.
В отличие от проекта PyPy (https://www.opennet.ru/opennews/art.shtml?num=43218), также продвигающего идею применения JIT для ускорения выполнения Python-скриптов, в Pyston используется не трассирующий JIT, базирующийся на компиляции в машинный код часто выполняемых циклов, а применяемый в современных JavaScript-движках JIT на основе трансляции отдельных методов (method-at-a-time), который, по мнению инженеров Dropbox, является более перспективной технологией. Принцип работы Pyston сводится к разбору кода на языке Python и его трансляции в промежуточное представление LLVM (IR, Intermediate Representation). Далее IR-представление проходит обработку в оптимизаторе LLVM и передаётся для исполнения в JIT-движок LLVM, который преобразует IR-представление в машинный код.Для получения информации о типах переменных для программ на динамическом языке Python применяется техника вероятностного предсказания типов объектов с последующим уточнением правильности выбора типа в процессе выполнения. Таким образом Pyston постоянно варьирует выполнение между двумя ветками - быстрой, когда данные о предсказанных типах подтверждаются, и медленной, используемой в случае рассогласования данных о типе. Работа может осуществляться в многопоточном режиме, допускающем параллельное выполнение нескольких нитей кода на языке Python и избавленном от глобальной блокировки интерпретатора (GIL, global interpreter lock).
При подготовке новой версии основное внимание было уделено (https://blog.pyston.org/2016/11/11/pyston-0-6-released/) снижению потребления памяти. Одним из главных шагов для уменьшения потребления памяти стал уход от древовидного представления инструкций интерпретатора в пользу хранения в форме реального байткода. Инструкции теперь следуют одна за другой в памяти без дробления с использованием указателей. Кроме уменьшения размера потребляемой памяти подобный подход также позволяет достичь более агрессивного освобождения неиспользуемой памяти. Например, после компиляции при помощи LLVM JIT часто используемых функций, теперь можно освободить память, в которой размешался код, ранее подготовленный с применением встроенного JIT. Потребление памяти также сокращено за счёт повышения эффективности стадий анализа кода и устранению утечек памяти. В итоге, в некоторых тестах потребление памяти снизилось до двух раз, по сравнению с Pyston 0.5.1;В новом выпуске также представлена большая порция исправлений, устраняющих проблемы совместимости с CPython. Для упрощения замены CPython на Pyston проведена унификация структуры директорий и порядка следования записей в типе dict. Изменения позволили добиться выполнения в Pyston немодифицированных программ pip и virtualenv.
Что касается производительности, то несмотря на то, что специальных оптимизиаций не добавлялось, при оценке производительности операций при помощи библиотеки NumPy, Pyston уже приблизился к CPython, а в некоторых тестах даже немного обгоняет его.
URL: https://blog.pyston.org/2016/11/11/pyston-0-6-released/
Новость: https://www.opennet.ru/opennews/art.shtml?num=45547
Жрёт всего втрое больше памяти, чем cpython, и приближается к нему по производительности? Это успех!
Тоже не очень понимаю, в чём успех заключается
Хотя нет, они избавились от GIL - значит многопоточный код станет шустрее в разы ядер
> они избавились от GIL - значит многопоточный код станет шустрее в разы ядерв общем случае -- не станет. (а станет только для некоторых ситуаций)
GIL не мешает одновременной работе нескольких нитей, а всего-лишь препятствует одновременному выполнению ПИТОНОВСКИХ операций в них. (то есть -- так как большую часть времени код находится внутри Native-функций, избавление от GIL не сильно тут на что-то повлияет)
В реальном мире и реальном софте как раз основное время ты тратишь на питоновские операции.
Если ты пишешь вычислительный софт на python - то да. Но это вообще не лучший выбор языка.А, скажем, в вебдеве ровно наоборот.
> Если ты пишешь вычислительный софт на python - то да.Если ты пишешь вычислительный софт на python, то пишешь с использованием numpy или чего-то такого. Тогда GIL освобождается и приложение может задействовать несколько ядер.
Numpy работает почти одинаково, а Python-код в Pyston работает в разы быстрее.
И в отличии от PyPy тебе не нужно запускать в весь код в Pyston, а только отдельные функции.Типа:
@jit
def hard_work():
...
Я чего-то сильно не понимаю, или они бенчили numpy, который 99.9 времени проводит в сишных расширениях?
> Я чего-то сильно не понимаю, или они бенчили numpy, который 99.9 времени
> проводит в сишных расширениях?Я так понял, там речь шла именно о numpy:
> Aside: NumPy performance
> NumPy hasn’t been a priority for us, but from time to time we check on how well we can run it.
> We’ve focused on compatibility in the past, but for this post we took a look into performance as well.
> We don’t have any NumPy-specific optimizations, so we were happy to see this graph from PyPy’s numpy
> benchmark runner:Дело в том, что нормально запустить оный получилось только в 0.5
https://blog.pyston.org/2016/05/25/pyston-0-5-released/
> We are very happy to announce: we can run NumPy, unmodified.
> Specifically: on their latest release (v1.11), we run their entire test suite with one testИ как раз были проблемы со скоростью:
> Currently, we take about twice as long to run the NumPy test suite as CPython does.Так-то там ссылка на более "общие" (но не менее вакуумно-синтетические) бенчи:
http://speed.pyston.org/comparison/?exe=1+L+default,2+L+default,12+L+default&ben=35,39,36,37&env=2&hor=false&bas=none&chart=normal+bars
> развивается **высокопроизводительная реализация** языка Python, созданная с использованием наработок проекта LLVM
> Pyston уже приблизился к CPython, а в некоторых тестах даже немного обгоняет его.это победа :D
У них есть и нормальные бенчмарки не в numpy. А с numpy да, действительно победа, потому что у того же pypy большие проблемы с работой с numpy и с обычными сишными расширениями.
Уже видели промер на rubinius
А ведь допилят! ЗП у Ван Россума, по наитию, тысяч 20 уе в месяц, и DropBox не самая захудалая контора. Работай - не хочу. Это идеальный случай для СПО - фикси работа в проекте мирового уровня, когда тебе никто не гнебет за отвлекания.Кто не знает, DropBox - это единственное облако, которое поддерживает низкоуровневое постраничное обновление больших файлов (архивов в т.ч. зашифрованных, криптоконтейнеров итп). На практике это выливается в 10-кратную экономию трафика. То что DropBox написан на Питоне, конечно же, случайность (просто повезло). Хотя ни разу еще не сталкивался с необходимостью ускорения работы кода на Питоне - радуюсь новости.
> Хотя ни разу еще не сталкивался с необходимостью ускорения работы кода на ПитонеБлаженный
Может он просто в курсе, что тормозят программы, а не языки, и умеет их писать? Или, например, не пытался использовать чистый питон для числодробилок?
Дропбокс изначально весь сделан одним человеком, который написал на том, что лучше знает. А потом он внезапно взлетел.
Какой извилистый, сложный путь обратно к си...
Основной интерпретатор Python, внезапно, написан на C, поэтому и называется CPython.
так велосипедисты же!
важен сам процесс, а не результат.