forum.opennet.ru - "Оценка изменения производительности CPython за последние 5 лет" (57)

"Оценка изменения производительности CPython за последние 5 лет"

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Оценка изменения производительности CPython за последние 5 лет"	+/–
Сообщение от opennews (??), 10-Окт-25, 09:06
Мигель Гринбе (Miguel Grinberg), автор нескольких книг по Python-фреймворкам SQLAlchemy и Flask, опубликовал результаты тестирования производительности веток CPython с 3.9 по 3.14. Дополнительно аналогичные тесты проведены для Pypy 3.11 (реализация Python с JIT-компилятором), Node.js 24 и Rust 1.90... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=64029
Ответить \| Правка \| Cообщить модератору

Оглавление

Все-таки ускорили питон Не прошло и десяти лет А нет, прошло , Аноним (1), 09:06 , 10-Окт-25, (1) +1

Видимо мсье не понимает что это такое в принципе, но обязательно должен высказат, Аноним (2), 09:14 , 10-Окт-25, (2) +12
На 20 При отставании от C в 60 тысяч раз Это успех , Аноним (44), 14:20 , 10-Окт-25, (44) +1

Ну и кто там хотел избавиться от GIL Довольны , th3m3 (ok), 09:26 , 10-Окт-25, (3)

Само по себе не имеет значения Если асинхронный код в итоге выиграет, будет неп, Аноним (5), 09:33 , 10-Окт-25, (5) +1

Кому неплохо Представь себе, в Python не все вeб-мakаки на хайлоаде, а в осталь, Имя (?), 09:50 , 10-Окт-25, (9) –3

На локалхосте есть миллион и одна полезная задача, легко решающаяся асинхронным , Аноним (5), 10:17 , 10-Окт-25, (11) +1

ага, оптимизации в два раза в мульти-трединге между 3 13 и 3 14 просто показываю, Аноним (17), 11:08 , 10-Окт-25, (17) +1
Ну если у тебя задача параллельная, где много чего-то ждут чего-то, а потом дела, Имя (?), 11:24 , 10-Окт-25, (21) +1

Никогда не знаешь, когда она станет параллельной Сегодня 1 потока достаточно, а, Аноним (5), 11:37 , 10-Окт-25, (23)

Это если ты вообще не понимаешь что ты делаешь Тебе нужно запускать максимум по, Витюшка (?), 14:22 , 10-Окт-25, (45) –1

Ээээ для i o bound задач , User (??), 14:33 , 10-Окт-25, (50) +1

Скрыто модератором, Витюшка (?), 15:12 , 10-Окт-25, (54)

Нет, мне нужно запускать ничем неограниченное число потоков, пока я получаю уско, Аноним (5), 15:51 , 10-Окт-25, (56)

GIL им на хвост наступил , Соль земли2 (?), 09:46 , 10-Окт-25, (6)
Очень даже 3 14 без gil будет побыстрее более ранних версий за исключением 3 1, Аноним (8), 09:49 , 10-Окт-25, (8)

И опять без обратной совместимости, прощайте все батарейки , th3m3 (ok), 11:15 , 10-Окт-25, (20)

Производительность питона -- последнее что имеет значение на практике Не удивлё, Аноним (5), 09:31 , 10-Окт-25, (4) –1

Производительность программы не может не иметь значения Это буквально время, он, Аноним (14), 10:46 , 10-Окт-25, (14) –1

Там, где нужна производительность, давно скомпилированный нативный код вызываетс, Аноним (5), 11:26 , 10-Окт-25, (22)
Где нужен перворманс там не питон выбирают Так что на практике ему достаточно н, Аноним (24), 11:46 , 10-Окт-25, (24)
Куда торопишься, снова суетиться А жить когда , Имя (?), 13:18 , 10-Окт-25, (40) +1
Конечно может В скриптах производительность не имеет никакого значения Ну давай, Аноним (41), 13:50 , 10-Окт-25, (41)
Время _программиста_ дефицитный ресурс А cpu time для огромного количества зада, User (??), 14:37 , 10-Окт-25, (51)

В 3 14 free threading уже не особо и замедляет Явный прогресс , funny.falcon (?), 09:46 , 10-Окт-25, (7) +4
Python лучше всех - доля рынка эта вещь упрямая , Аноним (10), 09:56 , 10-Окт-25, (10) –1

Доля рынка языков для непрограммистов , Аноним (14), 10:47 , 10-Окт-25, (15) +1

Для неОпрограммистов, Аноним (29), 12:08 , 10-Окт-25, (29)

Миллиарды мух не могут ошибаться То, что не могло бы появиться без таких проек, Shellpeck (?), 11:09 , 10-Окт-25, (18) –1

Годы идут, а опеннетные эксперты все про миллиарды мух Ну да, выкидываем все, Аноним (41), 13:54 , 10-Окт-25, (42) +1
под капотом имеют библиотеки на C и Fortran, используя сабжа только как интерфей, Аноним (44), 14:24 , 10-Окт-25, (47) –1

В бэкенде что-то не особо , Аноним (53), 15:07 , 10-Окт-25, (53)

А что кстати мешает питону официально перейти на PyPy , Аноним (12), 10:22 , 10-Окт-25, (12)

То, что он хорош только в попугаеметрах , Аноним (5), 10:24 , 10-Окт-25, (13)

А чем плох в реальных задачах , Аноним (26), 11:47 , 10-Окт-25, (26)

Все минусы жита, плохая поддержка в существующем коде, потенциальные баги , Аноним (5), 11:53 , 10-Окт-25, (27)

Поддержка и баги это следствие малой пользовательской базы и малого количества р, Аноним (26), 12:06 , 10-Окт-25, (28)

code Номер объекта SCP-JITКласс объекта ЕвклидОсобые условия содержания SCP-J, Аноним (5), 12:20 , 10-Окт-25, (31) +2

Жрет дофига памяти Которая - в отличие от CPU - не то, чтобы хорошо разделяемы, User (??), 14:40 , 10-Окт-25, (52)

Ограниченная область применения , Аноним (16), 11:04 , 10-Окт-25, (16) +1
Сделано не ими И PyPy, решая ту же проблему, не нуждается во всяких LLVM , Аноним (29), 12:14 , 10-Окт-25, (30) +2

Ну то есть ничего особо не поменялось , vitalif (ok), 11:09 , 10-Окт-25, (19) –1
А где вы видели быстрых питонов , Аноним (25), 11:47 , 10-Окт-25, (25) –1

У кроликов , Аноним (29), 12:29 , 10-Окт-25, (33) +1

Я на графиках на другое обратил внимание При прочих равных, производительность , Аноним (29), 12:26 , 10-Окт-25, (32) –1

Странный вывод Автор тестил на том что было, а было у него 13th Gen Intel R Cor, Аноним (36), 12:54 , 10-Окт-25, (36)

Лучший Python это Go , Аноним (34), 12:42 , 10-Окт-25, (34)
Традиционное фибоначчи-в-вакууме, ага Нет бы - ну не знаю - какую fastapi django, User (??), 12:50 , 10-Окт-25, (35) +1

Чтобы что Чтобы ловить сайд эффекты производительности docker podman, fastapi, , Аноним (36), 12:59 , 10-Окт-25, (37)

Ну меня очень радуют верные выводы сделанные в тестах того же pypy - но очень , User (??), 13:12 , 10-Окт-25, (39)

Стандарт и жЫд не сильно отличаются, а кто-то мне втирал за скорость , Аноним (38), 13:09 , 10-Окт-25, (38)
очередного удвоения надоев на тему того как именно питон не тормозит , Аноним (-), 14:06 , 10-Окт-25, (43)
Больше всего мне здесь нравится график Rust Которого почти не видно , Витюшка (?), 14:24 , 10-Окт-25, (46)

Это удивительно - компилируемая программа оказалась быстрее интерпретируемого ск, Аноним (44), 14:30 , 10-Окт-25, (49)

обычно заканчивается переполнением стека , Аноним (44), 14:27 , 10-Окт-25, (48) +1
Зачем-то питон форсят в веб, он там не нужон, пых лучше же намного А всякое ML , Аноним (53), 15:16 , 10-Окт-25, (55)
То, что PyPy быстрее Node js, приятно удивило Хотя, казалось бы, размеры пользо, someanon (?), 16:30 , 10-Окт-25, (57)

Сообщения [Сортировка по времени | RSS]

1. "Оценка изменения производительности CPython за последние 5 л..." +1 +/–

Сообщение от Аноним (1), 10-Окт-25, 09:06

Все-таки ускорили питон? Не прошло и десяти лет. А нет, прошло.

Ответить | Правка | Наверх | Cообщить модератору

2. "Оценка изменения производительности CPython за последние 5 л..." +12 +/–

Сообщение от Аноним (2), 10-Окт-25, 09:14

> Все-таки ускорили питон? Не прошло и десяти лет. А нет, прошло.
Видимо мсье не понимает что это такое в принципе, но обязательно должен высказаться.

Ответить | Правка | Наверх | Cообщить модератору

44. "Оценка изменения производительности CPython за последние 5 л..." +1 +/–

Сообщение от Аноним (44), 10-Окт-25, 14:20

> Все-таки ускорили питон? Не прошло и десяти лет. А нет, прошло.
На 20%. При отставании от C в 60 тысяч раз. Это успех.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

3. "Оценка изменения производительности CPython за последние 5 л..." +/–

Сообщение от th3m3 (ok), 10-Окт-25, 09:26

Ну и кто там хотел избавиться от GIL? Довольны?)

Ответить | Правка | Наверх | Cообщить модератору

5. "Оценка изменения производительности CPython за последние 5 л..." +1 +/–

Сообщение от Аноним (5), 10-Окт-25, 09:33

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

Ответить | Правка | Наверх | Cообщить модератору

9. "Оценка изменения производительности CPython за последние 5 л..." –3 +/–

Сообщение от Имя (?), 10-Окт-25, 09:50

Кому неплохо? Представь себе, в Python не все вeб-мakаки на хайлоаде, а в остальных местах async особо и ни нужон

Ответить | Правка | Наверх | Cообщить модератору

11. "Оценка изменения производительности CPython за последние 5 л..." +1 +/–

Сообщение от Аноним (5), 10-Окт-25, 10:17

> Кому неплохо? Представь себе, в Python не все вeб-мakаки на хайлоаде, а
> в остальных местах async особо и ни нужон
На локалхосте есть миллион и одна полезная задача, легко решающаяся асинхронным кодом. Только он на треть медленнее в 1 поток я так прикидывал, но если задача параллельная, легко отыгрывается. Ручная возня с запуском тредов ни разу не окупилась, они слишком неоптимальны в итоге.

Ответить | Правка | Наверх | Cообщить модератору

17. "Оценка изменения производительности CPython за последние 5 л..." +1 +/–

Сообщение от Аноним (17), 10-Окт-25, 11:08

ага, оптимизации в два раза в мульти-трединге между 3.13 и 3.14 просто показывают насколько весь язык не заточен для мульти-треда и конь не валялся оптимизировать это все. Взять любой мачурный язык, так дай бог если 5% ускорения в вакууме между релизами завозят

Ответить | Правка | Наверх | Cообщить модератору

21. "Оценка изменения производительности CPython за последние 5 л..." +1 +/–

Сообщение от Имя (?), 10-Окт-25, 11:24

Ну если у тебя задача параллельная, где много чего-то ждут чего-то, а потом делают чего-то, то да, а если нет, то сам async становится лишней вознёй, и тем более странным выглядит желание некоторых фанатиков бездумно перетащить в async все библиотеки, думая видимо, что async "эта крута", и не совсем понимая, что это инструмент для довольно чётко очерченного круга задач

Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

23. "Оценка изменения производительности CPython за последние 5 л..." +/–

Сообщение от Аноним (5), 10-Окт-25, 11:37

Никогда не знаешь, когда она станет параллельной. Сегодня 1 потока достаточно, а завтра ты захочешь 1000 запускать. У меня так было много раз с requests, зачем ждать 300 секунд, если можно управиться за 3? Потом sqlalchemy и так далее, да, такие библиотеки "это крута", и позволяют повысить производительность кода в сотни раз совершенно без затрат и значительных изменений логики.

Ответить | Правка | Наверх | Cообщить модератору

45. "Оценка изменения производительности CPython за последние 5 л..." –1 +/–

Сообщение от Витюшка (?), 10-Окт-25, 14:22

Это если ты вообще не понимаешь что ты делаешь. Тебе нужно запускать максимум по одному потоку на ядро процессора.

Ответить | Правка | Наверх | Cообщить модератору

50. "Оценка изменения производительности CPython за последние 5 л..." +1 +/–

Сообщение от User (??), 10-Окт-25, 14:33

Ээээ... для i\o bound задач?!

Ответить | Правка | Наверх | Cообщить модератору

54. Скрыто модератором +/–

Сообщение от Витюшка (?), 10-Окт-25, 15:12

Для любых. У тебя есть только N физических ядер. Далее яитаем про thread pool, stealing work и далее. Нет, конечно, когда ре5чь идёт по python то там вообще плевать.

Ответить | Правка | Наверх | Cообщить модератору

56. "Оценка изменения производительности CPython за последние 5 л..." +/–

Сообщение от Аноним (5), 10-Окт-25, 15:51

> Это если ты вообще не понимаешь что ты делаешь. Тебе нужно запускать
> максимум по одному потоку на ядро процессора.
Нет, мне нужно запускать ничем неограниченное число потоков, пока я получаю ускорение на 1 физическом процессоре (а питон "однопоточный" нужно помнить). И асинхронный код тут замечательно масштабируется.
Ну вот сканирую я определённые данные на диске, что-то с ними делаю. Но ок как-то работает. А потом данных всё больше и больше и больше, да и не на одном диске внезапно, а значит всё можно обрабатывать параллельно. Если запустить пул тредов, где-то обработается быстрее, где-то медленнее, в итоге постоянно процессор простаивает и итоговое время больше, и это ещё мне нужно заботиться о раздаче заданий. С асинхронным кодом раскидал ивент лупы и они молотят на полную, я сразу получаю синхронизацию в точках, где она нужна, и всё остальное меня не заботит.
Больше всего профит при работе с сетью и базами данных как по мне, но в любом случае языки без асинхронных генераторов сегодня вообще не в тему.

Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

6. "Оценка изменения производительности CPython за последние 5 л..." +/–

Сообщение от Соль земли2 (?), 10-Окт-25, 09:46

GIL им на хвост наступил.

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

8. "Оценка изменения производительности CPython за последние 5 л..." +/–

Сообщение от Аноним (8), 10-Окт-25, 09:49

Очень даже. 3.14 без gil будет побыстрее более ранних версий (за исключением 3.11 наверно) даже в однопоточке. А в многопоточке без gil уж и подавно. Вопрос только когда это все там устаканится, ибо неявных багов там должно быть еще море. 3.14 еще пилить и пилить. Изменение слишком уж кардинальное, впору было бы питон4 называть.

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

20. "Оценка изменения производительности CPython за последние 5 л..." +/–

Сообщение от th3m3 (ok), 10-Окт-25, 11:15

И опять без обратной совместимости, прощайте все батарейки :)

Ответить | Правка | Наверх | Cообщить модератору

4. "Оценка изменения производительности CPython за последние 5 л..." –1 +/–

Сообщение от Аноним (5), 10-Окт-25, 09:31

Производительность питона -- последнее что имеет значение на практике. Не удивлён производительности жита, небось, и сравнивали шланговые билды с гццшными?

Ответить | Правка | Наверх | Cообщить модератору

14. "Оценка изменения производительности CPython за последние 5 л..." –1 +/–

Сообщение от Аноним (14), 10-Окт-25, 10:46

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

Ответить | Правка | Наверх | Cообщить модератору

22. "Оценка изменения производительности CPython за последние 5 л..." +/–

Сообщение от Аноним (5), 10-Окт-25, 11:26

Там, где нужна производительность, давно скомпилированный нативный код вызывается. И он освобождает gil. Ты так говоришь, будто на свете только pure-python реализации и всех заставляют ими пользоваться.
Да и вон портаж уже переписали на плюсы, сильно эффективнее чёт не стало, зато сопровождение ммм прелесть. А ведь это всего лишь ПМ.

Ответить | Правка | Наверх | Cообщить модератору

24. "Оценка изменения производительности CPython за последние 5 л..." +/–

Сообщение от Аноним (24), 10-Окт-25, 11:46

Где нужен перворманс там не питон выбирают. Так что на практике ему достаточно не быть таким дном как руби первой версии.

Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

40. "Оценка изменения производительности CPython за последние 5 л..." +1 +/–

Сообщение от Имя (?), 10-Окт-25, 13:18

Куда торопишься, снова суетиться? А жить когда?

Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

41. "Оценка изменения производительности CPython за последние 5 л..." +/–

Сообщение от Аноним (41), 10-Окт-25, 13:50

> Производительность программы не может не иметь значения
Конечно может. В скриптах производительность не имеет никакого значения.
> Это буквально время, оно самый дефицитный ресурс. То, что питонисты считают иначе, много о них говорит.
Ну давай, решай на компилируемом языке те задачи, для которых спользуется скрипты на коленке. Потом посчитаем, сколько ты угрохал на это время, лол. А заодно и сколько сэкономил быстродействием своей программы. Дефицитный ресурс, ага.

Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

51. "Оценка изменения производительности CPython за последние 5 л..." +/–

Сообщение от User (??), 10-Окт-25, 14:37

Время _программиста_ дефицитный ресурс.
А cpu time для огромного количества задач не то, чтобы "значения не имеет" - но где-то около.

Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

7. "Оценка изменения производительности CPython за последние 5 л..." +4 +/–

Сообщение от funny.falcon (?), 10-Окт-25, 09:46

В 3.14 free threading уже не особо и замедляет. Явный прогресс!

Ответить | Правка | Наверх | Cообщить модератору

10. "Оценка изменения производительности CPython за последние 5 л..." –1 +/–

Сообщение от Аноним (10), 10-Окт-25, 09:56

Python лучше всех - доля рынка эта вещь упрямая!

Ответить | Правка | Наверх | Cообщить модератору

15. "Оценка изменения производительности CPython за последние 5 л..." +1 +/–

Сообщение от Аноним (14), 10-Окт-25, 10:47

Доля рынка языков для непрограммистов.

Ответить | Правка | Наверх | Cообщить модератору

29. "Оценка изменения производительности CPython за последние 5 л..." +/–

Сообщение от Аноним (29), 10-Окт-25, 12:08

Для неОпрограммистов

Ответить | Правка | Наверх | Cообщить модератору

18. "Оценка изменения производительности CPython за последние 5 л..." –1 +/–

Сообщение от Shellpeck (?), 10-Окт-25, 11:09

Миллиарды мух не могут ошибаться...
То, что не могло бы появиться без таких проектов лучше бы и не появлялись.

Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

42. "Оценка изменения производительности CPython за последние 5 л..." +1 +/–

Сообщение от Аноним (41), 10-Окт-25, 13:54

> Миллиарды мух не могут ошибаться...
Годы идут, а опеннетные эксперты все про "миллиарды мух"...
> То, что не могло бы появиться без таких проектов лучше бы и не появлялись.
Ну да, выкидываем все научные рассчеты и ML, чтобы не ломать картину мира опеннетного эксперта.

Ответить | Правка | Наверх | Cообщить модератору

47. "Оценка изменения производительности CPython за последние 5 л..." –1 +/–

Сообщение от Аноним (44), 10-Окт-25, 14:24

> все научные рассчеты
под капотом имеют библиотеки на C и Fortran, используя сабжа только как интерфейс для ввода-вывода данных. Не в укор сабжу - многие другие научные проекты поступают так же.

Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

53. "Оценка изменения производительности CPython за последние 5 л..." +/–

Сообщение от Аноним (53), 10-Окт-25, 15:07

В бэкенде что-то не особо.

Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

12. "Оценка изменения производительности CPython за последние 5 л..." +/–

Сообщение от Аноним (12), 10-Окт-25, 10:22

А что кстати мешает питону официально перейти на PyPy?

Ответить | Правка | Наверх | Cообщить модератору

13. "Оценка изменения производительности CPython за последние 5 л..." +/–

Сообщение от Аноним (5), 10-Окт-25, 10:24

> А что кстати мешает питону официально перейти на PyPy?
То, что он хорош только в попугаеметрах.

Ответить | Правка | Наверх | Cообщить модератору

26. "Оценка изменения производительности CPython за последние 5 л..." +/–

Сообщение от Аноним (26), 10-Окт-25, 11:47

А чем плох в реальных задачах?

Ответить | Правка | Наверх | Cообщить модератору

27. "Оценка изменения производительности CPython за последние 5 л..." +/–

Сообщение от Аноним (5), 10-Окт-25, 11:53

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

Ответить | Правка | Наверх | Cообщить модератору

28. "Оценка изменения производительности CPython за последние 5 л..." +/–

Сообщение от Аноним (26), 10-Окт-25, 12:06

Поддержка и баги это следствие малой пользовательской базы и малого количества разработчиков. А вот минусы jit в студию.

Ответить | Правка | Наверх | Cообщить модератору

31. "Оценка изменения производительности CPython за последние 5 л..." +2 +/–

Сообщение от Аноним (5), 10-Окт-25, 12:20

> Поддержка и баги это следствие малой пользовательской базы и малого количества разработчиков.
> А вот минусы jit в студию.
Номер объекта: SCP-JIT
Класс объекта: Евклид
Особые условия содержания:
SCP-JIT должен быть изолирован в камере с имитацией выполнения (выделенный набор виртуальных машин 7). Ни одна производственная система не должна выполнять код, сгенерированный SCP-JIT, без одобрения 3-го уровня.
Специальный агент мониторинга (Process Sentinel) должен отслеживать использование процессора, памяти и памяти исполняемых файлов на хосте. Любые необъяснимые скачки времени компиляции, выделения памяти или создания исполняемых страниц немедленно инициируют карантин и откат к снимку AOT.
Трассировки профилирования и сегменты машинного кода, созданные SCP-JIT, должны храниться в архиве WORM и анализироваться на предмет недетерминированного поведения. Все тесты должны включать измерения при холодном старте и повторные испытания для выявления отклонений. Для сценариев развертывания, требующих детерминизма или низкой задержки, SCP-JIT запрещён; вместо этого будут использоваться артефакты AOT или изолированная эмуляция.
Описание:
SCP-JIT представляет собой адаптивный генератор кода, преобразующий промежуточный байт-код в машинные инструкции во время выполнения. При наблюдении он демонстрирует полезное эмерджентное поведение — значительное увеличение пропускной способности для длительных процессов — наряду с рядом опасных побочных эффектов, которые, если их не устранить, снижают стабильность работы.
Задокументированные аномалии / Основные недостатки:
Задержка запуска и прогрев
SCP-JIT требует циклов прогрева для отслеживания горячих путей перед созданием оптимизированного кода. Начальное выполнение медленнее; кратковременные или однократные процессы никогда не достигают оптимизированного устойчивого состояния и испытывают общую деградацию.
Увеличенный объём памяти
Страницы машинного кода, метаданные и буферы профилирования времени выполнения накапливаются, раздувая рабочие наборы. В условиях ограничений это приводит к подкачке, перегрузке сборщика мусора и повышению частоты сбоев.
Нагрузка на процессор и электропитание
Компиляция происходит в штатном режиме, потребляя циклы процессора и электроэнергию. Во время фаз интенсивной оптимизации происходит падение производительности и превышение лимитов на тепло/энергию.
Недетерминированная производительность
Решения по оптимизации принимаются на основе профилей времени выполнения; идентичные входные данные в разных запусках могут давать разные характеристики производительности, что затрудняет бенчмаркинг, планирование ресурсов и воспроизведение инцидентов.
Сложность отладки и наблюдения
Динамически генерируемый код и агрессивные оптимизации (встраивание, деоптимизация) скрывают стеки вызовов и изменяют поведение при проверке. Стандартные отладчики и профилировщики могут создавать ложные следы.
Расширение области безопасности
SCP-JIT выделяет области памяти для записи и исполнения и выполняет динамическую эмиссию кода — практики, которые увеличивают поверхность атаки и требуют усиленных политик и мер по снижению риска (аудит исполняемой памяти, целостность потока управления).
Пики задержки и джиттер
Фоновая компиляция, перекомпиляция или деоптимизация «на лету» могут приводить к периодическим всплескам задержки, неподходящим для сервисов реального времени или с низкой задержкой.
Ограничения развертывания и переносимости
Некоторые операционные среды запрещают генерацию кода во время выполнения или не имеют целевых бэкендов, что препятствует использованию SCP-JIT. Упаковка и верификация на нескольких архитектурах требуют дополнительных инженерных усилий.
Сложность настройки и предсказуемости
Правильная настройка пороговых значений, уровней компиляции и взаимодействия с GC требует экспертных знаний. Неправильная настройка может ухудшить производительность, а не улучшить ее.
Дополнение — Протоколы смягчения:
Используйте многоуровневую компиляцию и AOT с профилированием для холодных путей; ограничьте агрессивную оптимизацию фоновыми потоками; ограничьте объем памяти, используемой для сгенерированного кода; включите квоты компиляции и пороговые значения пауз компиляции; требуйте зашифрованного хранилища с проверкой целостности для выпущенного кода; Внедрение детерминированных тестовых программ для бенчмаркинга.
Уведомление от инженеров сайта: Используйте SCP-JIT только в тех случаях, когда длительные рабочие нагрузки и контролируемые среды оправдывают риски. Для кратковременных задач, систем реального времени или высокозащищённых песочниц предпочтительнее AOT или интерпретируемое выполнение.
Выдержка из журнала содержания (отредактировано):
«Процедура 7.2 вызвана после скачка загрузки ЦП на 120%, связанного с событием перекомпиляции «на лету». Карантин предотвратил каскадный сбой. Рекомендация: ограничить приоритет потока JIT-компилятора». — Ведущий инженер, Отдел стабильности выполнения
Конец файла.
кстати, целиком правда

Ответить | Правка | Наверх | Cообщить модератору

52. "Оценка изменения производительности CPython за последние 5 л..." +/–

Сообщение от User (??), 10-Окт-25, 14:40

Жрет дофига памяти (Которая - в отличие от CPU - не то, чтобы "хорошо разделяемый" ресурс) и "не дает"\"дает незначительную" прибавку к производительности - и задачи у тебя сильно не все cpu bound, и не весь тот cpu на hot path обрабатывается pure python кодом...

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

16. "Оценка изменения производительности CPython за последние 5 л..." +1 +/–

Сообщение от Аноним (16), 10-Окт-25, 11:04

Ограниченная область применения

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

30. "Оценка изменения производительности CPython за последние 5 л..." +2 +/–

Сообщение от Аноним (29), 10-Окт-25, 12:14

Сделано не ими.
И PyPy, решая ту же проблему, не нуждается во всяких LLVM.

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

19. "Оценка изменения производительности CPython за последние 5 л..." –1 +/–

Сообщение от vitalif (ok), 10-Окт-25, 11:09

Ну то есть ничего особо не поменялось.)

Ответить | Правка | Наверх | Cообщить модератору

25. "Оценка изменения производительности CPython за последние 5 л..." –1 +/–

Сообщение от Аноним (25), 10-Окт-25, 11:47

А где вы видели быстрых питонов?

Ответить | Правка | Наверх | Cообщить модератору

33. "Оценка изменения производительности CPython за последние 5 л..." +1 +/–

Сообщение от Аноним (29), 10-Окт-25, 12:29

У кроликов ;)

Ответить | Правка | Наверх | Cообщить модератору

32. "Оценка изменения производительности CPython за последние 5 л..." –1 +/–

Сообщение от Аноним (29), 10-Окт-25, 12:26

Я на графиках на другое обратил внимание. При прочих равных, производительность разных Питонов на MacOS несколько выше, чем на Linux. Darwin же основан на микроядре Mach? Значит, расхожее мнение о худшей производительности микроядерных ОС - миф?
Лично мне, это добавило надежд в отношении производительности Hurd.

Ответить | Правка | Наверх | Cообщить модератору

36. "Оценка изменения производительности CPython за последние 5 л..." +/–

Сообщение от Аноним (36), 10-Окт-25, 12:54

Странный вывод.
Автор тестил на том что было, а было у него 13th Gen Intel(R) Core(TM) i5-1340P (он об этом написал в комментах своего блога) и Apple M2. Отсюда и разница.

Ответить | Правка | Наверх | Cообщить модератору

34. "Оценка изменения производительности CPython за последние 5 л..." +/–

Сообщение от Аноним (34), 10-Окт-25, 12:42

Лучший Python это Go!

Ответить | Правка | Наверх | Cообщить модератору

35. "Оценка изменения производительности CPython за последние 5 л..." +1 +/–

Сообщение от User (??), 10-Окт-25, 12:50

Традиционное фибоначчи-в-вакууме, ага.
Нет бы - ну не знаю - какую fastapi\django'у по контейнерам с разными версиями интерпретатора подсобрать-да-нагрузить...

Ответить | Правка | Наверх | Cообщить модератору

37. "Оценка изменения производительности CPython за последние 5 л..." +/–

Сообщение от Аноним (36), 10-Окт-25, 12:59

Чтобы что? Чтобы ловить сайд эффекты производительности docker/podman, fastapi, django и какого-нибудь gunicorn? А потом делать неверные выводы?
В том то и суть, чтобы все это исключить.

Ответить | Правка | Наверх | Cообщить модератору

39. "Оценка изменения производительности CPython за последние 5 л..." +/–

Сообщение от User (??), 10-Окт-25, 13:12

> Чтобы что? Чтобы ловить сайд эффекты производительности docker/podman, fastapi, django
> и какого-нибудь gunicorn? А потом делать неверные выводы?
> В том то и суть, чтобы все это исключить.
Ну меня очень радуют "верные выводы" сделанные в тестах того же pypy - но очень огорчает несовпадение этих выводов с реальностью примерно во всех наблюдаемых вариантах практического использования.

Ответить | Правка | Наверх | Cообщить модератору

38. "Оценка изменения производительности CPython за последние 5 л..." +/–

Сообщение от Аноним (38), 10-Окт-25, 13:09

Стандарт и жЫд не сильно отличаются, а кто-то мне втирал за скорость :)

Ответить | Правка | Наверх | Cообщить модератору

43. "Оценка изменения производительности CPython за последние 5 л..." +/–

Сообщение от Аноним (-), 10-Окт-25, 14:06

> автор нескольких книг по Python-фреймворкам SQLAlchemy и Flask,
> опубликовал результаты тестирования
...очередного удвоения надоев на тему того как именно питон не тормозит :)

Ответить | Правка | Наверх | Cообщить модератору

46. "Оценка изменения производительности CPython за последние 5 л..." +/–

Сообщение от Витюшка (?), 10-Окт-25, 14:24

Больше всего мне здесь нравится график Rust. Которого почти не видно.

Ответить | Правка | Наверх | Cообщить модератору

49. "Оценка изменения производительности CPython за последние 5 л..." +/–

Сообщение от Аноним (44), 10-Окт-25, 14:30

> Rust обогнали CPython 3.14 в первом тесте в ... 69.82 раз, а во втором тесте в ... 36.15 раз
Это удивительно - компилируемая программа оказалась быстрее интерпретируемого скрипта.

Ответить | Правка | Наверх | Cообщить модератору

48. "Оценка изменения производительности CPython за последние 5 л..." +1 +/–

Сообщение от Аноним (44), 10-Окт-25, 14:27

> (глубокая рекурсия)
обычно заканчивается переполнением стека.

Ответить | Правка | Наверх | Cообщить модератору

55. "Оценка изменения производительности CPython за последние 5 л..." +/–

Сообщение от Аноним (53), 10-Окт-25, 15:16

Зачем-то питон форсят в веб, он там не нужон, пых лучше же намного. А всякое ML и прочее - ну это вообще неинтересная ниша.

Ответить | Правка | Наверх | Cообщить модератору

57. "Оценка изменения производительности CPython за последние 5 л..." +/–

Сообщение от someanon (?), 10-Окт-25, 16:30

То, что PyPy быстрее Node.js, приятно удивило. Хотя, казалось бы, размеры пользовательской базы и количество разработчиков несравнимы.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Оценка изменения производительности CPython за последние 5 л..."	+1 +/–
Сообщение от Аноним (1), 10-Окт-25, 09:06
Все-таки ускорили питон? Не прошло и десяти лет. А нет, прошло.
Ответить \| Правка \| Наверх \| Cообщить модератору


	2. "Оценка изменения производительности CPython за последние 5 л..."	+12 +/–
	Сообщение от Аноним (2), 10-Окт-25, 09:14
	> Все-таки ускорили питон? Не прошло и десяти лет. А нет, прошло. Видимо мсье не понимает что это такое в принципе, но обязательно должен высказаться.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	44. "Оценка изменения производительности CPython за последние 5 л..."	+1 +/–
	Сообщение от Аноним (44), 10-Окт-25, 14:20
	> Все-таки ускорили питон? Не прошло и десяти лет. А нет, прошло. На 20%. При отставании от C в 60 тысяч раз. Это успех.
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору

3. "Оценка изменения производительности CPython за последние 5 л..."	+/–
Сообщение от th3m3 (ok), 10-Окт-25, 09:26
Ну и кто там хотел избавиться от GIL? Довольны?)
Ответить \| Правка \| Наверх \| Cообщить модератору


	5. "Оценка изменения производительности CPython за последние 5 л..."	+1 +/–
	Сообщение от Аноним (5), 10-Окт-25, 09:33
	Само по себе не имеет значения. Если асинхронный код в итоге выиграет, будет неплохо.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	9. "Оценка изменения производительности CPython за последние 5 л..."	–3 +/–
	Сообщение от Имя (?), 10-Окт-25, 09:50
	Кому неплохо? Представь себе, в Python не все вeб-мakаки на хайлоаде, а в остальных местах async особо и ни нужон
	Ответить \| Правка \| Наверх \| Cообщить модератору


	11. "Оценка изменения производительности CPython за последние 5 л..."	+1 +/–
	Сообщение от Аноним (5), 10-Окт-25, 10:17
	> Кому неплохо? Представь себе, в Python не все вeб-мakаки на хайлоаде, а > в остальных местах async особо и ни нужон На локалхосте есть миллион и одна полезная задача, легко решающаяся асинхронным кодом. Только он на треть медленнее в 1 поток я так прикидывал, но если задача параллельная, легко отыгрывается. Ручная возня с запуском тредов ни разу не окупилась, они слишком неоптимальны в итоге.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	17. "Оценка изменения производительности CPython за последние 5 л..."	+1 +/–
	Сообщение от Аноним (17), 10-Окт-25, 11:08
	ага, оптимизации в два раза в мульти-трединге между 3.13 и 3.14 просто показывают насколько весь язык не заточен для мульти-треда и конь не валялся оптимизировать это все. Взять любой мачурный язык, так дай бог если 5% ускорения в вакууме между релизами завозят
	Ответить \| Правка \| Наверх \| Cообщить модератору


	21. "Оценка изменения производительности CPython за последние 5 л..."	+1 +/–
	Сообщение от Имя (?), 10-Окт-25, 11:24
	Ну если у тебя задача параллельная, где много чего-то ждут чего-то, а потом делают чего-то, то да, а если нет, то сам async становится лишней вознёй, и тем более странным выглядит желание некоторых фанатиков бездумно перетащить в async все библиотеки, думая видимо, что async "эта крута", и не совсем понимая, что это инструмент для довольно чётко очерченного круга задач
	Ответить \| Правка \| К родителю #11 \| Наверх \| Cообщить модератору


	23. "Оценка изменения производительности CPython за последние 5 л..."	+/–
	Сообщение от Аноним (5), 10-Окт-25, 11:37
	Никогда не знаешь, когда она станет параллельной. Сегодня 1 потока достаточно, а завтра ты захочешь 1000 запускать. У меня так было много раз с requests, зачем ждать 300 секунд, если можно управиться за 3? Потом sqlalchemy и так далее, да, такие библиотеки "это крута", и позволяют повысить производительность кода в сотни раз совершенно без затрат и значительных изменений логики.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	45. "Оценка изменения производительности CPython за последние 5 л..."	–1 +/–
	Сообщение от Витюшка (?), 10-Окт-25, 14:22
	Это если ты вообще не понимаешь что ты делаешь. Тебе нужно запускать максимум по одному потоку на ядро процессора.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	50. "Оценка изменения производительности CPython за последние 5 л..."	+1 +/–
	Сообщение от User (??), 10-Окт-25, 14:33
	Ээээ... для i\o bound задач?!
	Ответить \| Правка \| Наверх \| Cообщить модератору


	54. Скрыто модератором	+/–
	Сообщение от Витюшка (?), 10-Окт-25, 15:12
	Для любых. У тебя есть только N физических ядер. Далее яитаем про thread pool, stealing work и далее. Нет, конечно, когда ре5чь идёт по python то там вообще плевать.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	56. "Оценка изменения производительности CPython за последние 5 л..."	+/–
	Сообщение от Аноним (5), 10-Окт-25, 15:51
	> Это если ты вообще не понимаешь что ты делаешь. Тебе нужно запускать > максимум по одному потоку на ядро процессора. Нет, мне нужно запускать ничем неограниченное число потоков, пока я получаю ускорение на 1 физическом процессоре (а питон "однопоточный" нужно помнить). И асинхронный код тут замечательно масштабируется. Ну вот сканирую я определённые данные на диске, что-то с ними делаю. Но ок как-то работает. А потом данных всё больше и больше и больше, да и не на одном диске внезапно, а значит всё можно обрабатывать параллельно. Если запустить пул тредов, где-то обработается быстрее, где-то медленнее, в итоге постоянно процессор простаивает и итоговое время больше, и это ещё мне нужно заботиться о раздаче заданий. С асинхронным кодом раскидал ивент лупы и они молотят на полную, я сразу получаю синхронизацию в точках, где она нужна, и всё остальное меня не заботит. Больше всего профит при работе с сетью и базами данных как по мне, но в любом случае языки без асинхронных генераторов сегодня вообще не в тему.
	Ответить \| Правка \| К родителю #45 \| Наверх \| Cообщить модератору


	6. "Оценка изменения производительности CPython за последние 5 л..."	+/–
	Сообщение от Соль земли2 (?), 10-Окт-25, 09:46
	GIL им на хвост наступил.
	Ответить \| Правка \| К родителю #3 \| Наверх \| Cообщить модератору


	8. "Оценка изменения производительности CPython за последние 5 л..."	+/–
	Сообщение от Аноним (8), 10-Окт-25, 09:49
	Очень даже. 3.14 без gil будет побыстрее более ранних версий (за исключением 3.11 наверно) даже в однопоточке. А в многопоточке без gil уж и подавно. Вопрос только когда это все там устаканится, ибо неявных багов там должно быть еще море. 3.14 еще пилить и пилить. Изменение слишком уж кардинальное, впору было бы питон4 называть.
	Ответить \| Правка \| К родителю #3 \| Наверх \| Cообщить модератору


	20. "Оценка изменения производительности CPython за последние 5 л..."	+/–
	Сообщение от th3m3 (ok), 10-Окт-25, 11:15
	И опять без обратной совместимости, прощайте все батарейки :)
	Ответить \| Правка \| Наверх \| Cообщить модератору

4. "Оценка изменения производительности CPython за последние 5 л..."	–1 +/–
Сообщение от Аноним (5), 10-Окт-25, 09:31
Производительность питона -- последнее что имеет значение на практике. Не удивлён производительности жита, небось, и сравнивали шланговые билды с гццшными?
Ответить \| Правка \| Наверх \| Cообщить модератору


	14. "Оценка изменения производительности CPython за последние 5 л..."	–1 +/–
	Сообщение от Аноним (14), 10-Окт-25, 10:46
	Производительность программы не может не иметь значения. Это буквально время, оно самый дефицитный ресурс. То, что питонисты считают иначе, много о них говорит. Питон - это не язык создания программ, а клуб по интересам или секта.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	22. "Оценка изменения производительности CPython за последние 5 л..."	+/–
	Сообщение от Аноним (5), 10-Окт-25, 11:26
	Там, где нужна производительность, давно скомпилированный нативный код вызывается. И он освобождает gil. Ты так говоришь, будто на свете только pure-python реализации и всех заставляют ими пользоваться. Да и вон портаж уже переписали на плюсы, сильно эффективнее чёт не стало, зато сопровождение ммм прелесть. А ведь это всего лишь ПМ.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	24. "Оценка изменения производительности CPython за последние 5 л..."	+/–
	Сообщение от Аноним (24), 10-Окт-25, 11:46
	Где нужен перворманс там не питон выбирают. Так что на практике ему достаточно не быть таким дном как руби первой версии.
	Ответить \| Правка \| К родителю #14 \| Наверх \| Cообщить модератору


	40. "Оценка изменения производительности CPython за последние 5 л..."	+1 +/–
	Сообщение от Имя (?), 10-Окт-25, 13:18
	Куда торопишься, снова суетиться? А жить когда?
	Ответить \| Правка \| К родителю #14 \| Наверх \| Cообщить модератору


	41. "Оценка изменения производительности CPython за последние 5 л..."	+/–
	Сообщение от Аноним (41), 10-Окт-25, 13:50
	> Производительность программы не может не иметь значения Конечно может. В скриптах производительность не имеет никакого значения. > Это буквально время, оно самый дефицитный ресурс. То, что питонисты считают иначе, много о них говорит. Ну давай, решай на компилируемом языке те задачи, для которых спользуется скрипты на коленке. Потом посчитаем, сколько ты угрохал на это время, лол. А заодно и сколько сэкономил быстродействием своей программы. Дефицитный ресурс, ага.
	Ответить \| Правка \| К родителю #14 \| Наверх \| Cообщить модератору


	51. "Оценка изменения производительности CPython за последние 5 л..."	+/–
	Сообщение от User (??), 10-Окт-25, 14:37
	Время _программиста_ дефицитный ресурс. А cpu time для огромного количества задач не то, чтобы "значения не имеет" - но где-то около.
	Ответить \| Правка \| К родителю #14 \| Наверх \| Cообщить модератору

7. "Оценка изменения производительности CPython за последние 5 л..."	+4 +/–
Сообщение от funny.falcon (?), 10-Окт-25, 09:46
В 3.14 free threading уже не особо и замедляет. Явный прогресс!
Ответить \| Правка \| Наверх \| Cообщить модератору

10. "Оценка изменения производительности CPython за последние 5 л..."	–1 +/–
Сообщение от Аноним (10), 10-Окт-25, 09:56
Python лучше всех - доля рынка эта вещь упрямая!
Ответить \| Правка \| Наверх \| Cообщить модератору


	15. "Оценка изменения производительности CPython за последние 5 л..."	+1 +/–
	Сообщение от Аноним (14), 10-Окт-25, 10:47
	Доля рынка языков для непрограммистов.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	29. "Оценка изменения производительности CPython за последние 5 л..."	+/–
	Сообщение от Аноним (29), 10-Окт-25, 12:08
	Для неОпрограммистов
	Ответить \| Правка \| Наверх \| Cообщить модератору


	18. "Оценка изменения производительности CPython за последние 5 л..."	–1 +/–
	Сообщение от Shellpeck (?), 10-Окт-25, 11:09
	Миллиарды мух не могут ошибаться... То, что не могло бы появиться без таких проектов лучше бы и не появлялись.
	Ответить \| Правка \| К родителю #10 \| Наверх \| Cообщить модератору


	42. "Оценка изменения производительности CPython за последние 5 л..."	+1 +/–
	Сообщение от Аноним (41), 10-Окт-25, 13:54
	> Миллиарды мух не могут ошибаться... Годы идут, а опеннетные эксперты все про "миллиарды мух"... > То, что не могло бы появиться без таких проектов лучше бы и не появлялись. Ну да, выкидываем все научные рассчеты и ML, чтобы не ломать картину мира опеннетного эксперта.
	Ответить \| Правка \| Наверх \| Cообщить модератору