Comments 18
Надо бы добавить, что PyPy работает с RPython (Restricted Python) — подмножеством языка Python, предназначенном для реализации интерпретаторов и других систем, которые могут быть переведены в эффективный низкоуровневый код.
Некоторые особенности RPython:
Статическая типизация. В отличие от Python, RPython требует, чтобы переменные сохраняли постоянные типы на протяжении всего выполнения.
Ограничения. Например, нет функций eval(), exec() и других динамических функций Python.
Ограничения в отражении. Ограничено использование getattr(), setattr() и других.
Отсутствие выражений генераторов. Нельзя использовать выражения генераторов или yield.
Структура модулей. Импорты должны быть на верхнем уровне.
RPython служит основой проекта PyPy, обеспечивая высокопроизводительную реализацию Python за счёт автоматизированной генерации кода
Соответственно, он сильно ограничен по библиотекам. Если нужен перформанс/статичность — зовите C++/Rust/C# (gRPC/FFI) или держите Python-микросервис
Соответственно, PyPy нишевая штука и преимущество python по библиотекам превращается в тыкву
PyPy написан на RPython, чтобы не быть совсем уж неприлично тормозным. Но как интерпретатор он старается быть максимально совместимым
Мне кажется, тесты однозначно показывают, что как волка не корми, медведь все равно сильнее.
Питон не про скорость выплнения математики.
Да, но не забивать же совсем на хоть какие-то попытки ускорения... А то как-то иногда совсем неприлично медленно было
Не сильнее. Но учитывая распространенность питона - даже небольшая экономия скорости\энергопотребления - это огромные цифры в целом
Для меня это выглядит так, или достаточно простой интерпретатор, не очень быстрый, c GIL, или на десятки процентов быстрее и без GIL, но гораздо сложнее.
Так вот сложный и "чуть быстрее" провоцирует плохую архитектуру, т.е. вместо того, чтобы подключить библиотеку или написать на Си, писать на питоне ресурсоемкие вещи и тратить гораздо больше ресурсов.
Если писать сортировки на Питоне, 50 или даже 100 процентов ускорения нигого не спасут.
я не буду заходить на территорию сложной математики, а взгляну с точки зрения бизнес-дядек.
Таймлайн такой - есть отдел продактов, они живут метриками и тестами. Они придумывают фичу и несут её разработке. Тут ценится time-to-market, через сколько фича/MVP будет готова. И питон тут офигеть как выигрывает со своей простотой. И идея "а давайте всё на Rust перепишем", ни когда не будет принята, пока ты не обоснуешь это экономически. Уже есть масса продуктов написанных на питоне, и они ежедневно растут, их хочется ускорять и развивать без таких глобальных изменений, а от того что ты перепишешь пару функций на C, глобального профита не будет, нужно прокачивать на уровне компилятора/интерпритатора.
масса продуктов написанных на питоне, и они ежедневно растут, их хочется ускорять и развивать без таких глобальных изменений, а от того что ты перепишешь пару функций на C, глобального профита не будет, нужно прокачивать на уровне компилятора/интерпритатора.
Все так, но с точностью до наоборот. От ускорения интерпретатора профит - единицы процентов. От написания узких мест на Си - выигрышь сотни и тысячи раз.
Конечно это зависит от области применения. Например, если наше приложение дергает данные из базы данных и отдает пользователю в виде веб странички, вигрыша не будет ни от улучшения интерпретатора на 1 процент, ни от переписывания на Си.
А вот если мы например дергаем из питона нейросетку, которая написана на Си, то выигрышь от того, что нейросетка написана не на питоне, а на Си - сотни тысяч раз.
То же самое с Numpy например.
Сейчас на голом питоне ни кто не пишет же, всегда есть какой то фреймворк/мидлвары/уровни абстракций. Да - тяжелый матан ты сразу пишешь на Numpy, тут вообще вопросов нет. Но вокруг того, что уже как бы написано на быстрых языках (сериализация, математика, обращение к бд) есть огромный пласт кода, который пишется в угоду удобства поддержки. Там всякий DDD, контроллеры-адаптеры-ормы-батарейки, километры того что написано на обычном питоне, выполняется в проекте. И чем больше rps на проект, тем сильнее тормозной эффект от чисто-питонячего кода.
В пример хочется привести выход php, кажется 7 версии, когда потом повыходили новости с заголовками типа "Известная компания освободила кучу серверных мощностей", хотя казалось бы, можно же было просто не пользоваться php?
Framework laptop running Ubuntu Linux 24.04 (Intel Core i5 CPU)
Просто интересно,где Miguel Grinberg брал Python 3.14 под Ubuntu 24.04?
Есть 2 варианта:
Собрать самому из сырцов Python-3.14.0.tar.xz
Поставить из ppa “deadsnakes” team
Я бы использовал pyenv.
говорят, что теперь там ещё появились официальные бинарные сборки для платформы Android
Может дополнительно стоит рассмотреть InterpreterPoolExecutor, как еще одну крутую фичу 3.14 для многопоточных тестов? Как понимаю, субинтерпретаторы быстрее чем ThreadPoolExecutor в вычислениях. Ради интереса запустил локально тест и получил x3.8 скорости на моей машине.
Синтетические тесты такие себе тесты. Добавили бы тест многопоточного сервиса с доступом к базе данных.
Вообще в век ИИ заботиться о повышении производительности надо переписыыванием проблемных мест на c++ или rust, что делатся за несколько минут. И внезапно код начинает работать в десятки раз быстрее.
Жаль, в сравнении нету PHP - одного из основных конкурентов. А вот Rust туда пихать бессмысленно, на мой взгляд - отрыв слишком велик.
Вышел Python 3.14. Насколько он быстр?