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

"Оценка изменения производительности 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.me/opennews/art.shtml?num=64029
Ответить \| Правка \| Cообщить модератору

Оглавление

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

Видимо мсье не понимает что это такое в принципе, но обязательно должен высказат, Аноним (2), 09:14 , 10-Окт-25, (2) +16

А при глубоком понимании что, те же циферки какой-то иной смысл будут иметь , Аноним (92), 21:15 , 10-Окт-25, (92)

На 20 При отставании от C в 60 тысяч раз Это успех , Аноним (44), 14:20 , 10-Окт-25, (44) +1

Опустим множитель кило, в 60 раз , Аноним (58), 16:34 , 10-Окт-25, (58)

Не в шестьдесят, а в почти полные семьдесят , Аноним (77), 19:04 , 10-Окт-25, (77)

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

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

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

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

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

Это лишь показывает, насколько питон отвратителен Потому, что они изначально сде, Аноним (77), 18:29 , 10-Окт-25, (73)

Ну если у тебя задача параллельная, где много чего-то ждут чего-то, а потом дела, Имя (?), 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) +3

Для любых У тебя есть только N физических ядер Далее яитаем про thread pool, s, Витюшка (?), 15:12 , 10-Окт-25, (54) –1

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

Проблема не в зелёных потоках, а в gil , Аноним (77), 18:24 , 10-Окт-25, (71)

Дело не в самом параллелизме, а в том, что когда у тебя нет вот этого ждут чего, Имя (?), 19:29 , 10-Окт-25, (78)

А в том и дело, что параллелизм в питоне не работает без асинхронного кода Ты н, Аноним (5), 19:48 , 10-Окт-25, (80)

Мне даже интересно, а что это за такой use case, когда у тебя работа с файлом тр, Имя (?), 20:36 , 10-Окт-25, (87)
И вообще, с чего ты это взял Я не говорю сейчас про запросы куда-то, с ними всё, Имя (?), 20:48 , 10-Окт-25, (90)

Затем, что у тебя есть замечательный gil, и он не даст выполняться python коду , Аноним (5), 21:17 , 10-Окт-25, (94)

Питонопроблемы А всё из-за того, что в питоне цветные функции Вот условный oca, Аноним (77), 20:14 , 10-Окт-25, (81)

Допустим у тебя есть какой-то такой условный алгоритм делаем что-то, ждём, пото, Имя (?), 20:43 , 10-Окт-25, (88)

Тем временем, можно взять любой язык с зелёными потоками, хоть ocaml, хоть go, х, Аноним (77), 18:23 , 10-Окт-25, (70)

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)

Так это же хорошо Питон - объективно плохой язык Может быть, после очередного , Аноним (77), 20:17 , 10-Окт-25, (82)

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

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

Там, где нужна производительность, давно скомпилированный нативный код вызываетс, Аноним (5), 11:26 , 10-Окт-25, (22) +1
Где нужен перворманс там не питон выбирают Так что на практике ему достаточно н, Аноним (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) –4

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

Для неОпрограммистов, Аноним (58), 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) +2

В бэкенде что-то не особо , Аноним (53), 15:07 , 10-Окт-25, (53)
Слава богу, на спад идёт Питон плохо приживается , Илья (??), 18:49 , 10-Окт-25, (74)

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

То, что он хорош только в попугаеметрах , Аноним (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) +3

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

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

Если бы команды объединили усилмя, различия бы устранили , Аноним (58), 18:50 , 10-Окт-25, (75)

Эти различия не на пустом месте образовались И исправить их можно только выпуст, Аноним (77), 20:19 , 10-Окт-25, (83)

Ну то есть ничего особо не поменялось , vitalif (ok), 11:09 , 10-Окт-25, (19)
Я на графиках на другое обратил внимание При прочих равных, производительность , Аноним (58), 12:26 , 10-Окт-25, (32) –2

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

Традиционное фибоначчи-в-вакууме, ага Нет бы - ну не знаю - какую 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)

Уровень опеннетсперктизы Питон тоже компилируется , Ангним (?), 18:04 , 10-Окт-25, (66)

Так речь о скрипте для cpython Когда питон компилируется тот же cython , там п, Аноним (5), 18:14 , 10-Окт-25, (68)

Ээээ ну вот cython не пробовал - а с nuitka ой прироста по скорости считай чт, User (??), 20:29 , 10-Окт-25, (85)

Но есть нюанс , User (??), 20:27 , 10-Окт-25, (84)

обычно заканчивается переполнением стека , Аноним (44), 14:27 , 10-Окт-25, (48) +1

В нормальных языках хвостовая рекурсия оптимизируется начиная с первого релизног, Аноним (77), 18:27 , 10-Окт-25, (72)

Зачем-то питон форсят в веб, он там не нужон, пых лучше же намного А всякое ML , Аноним (53), 15:16 , 10-Окт-25, (55) –1

Истину глаголишь Самый лучший веб это php или perl , Аноним (62), 17:35 , 10-Окт-25, (64) –1

Нет, это битрикс , Аноним (5), 17:39 , 10-Окт-25, (65)
Хуже Perl а только Brainfuck Это write-only язык Хорошо что он помер , Аноним (67), 18:10 , 10-Окт-25, (67)

То, что PyPy быстрее Node js, приятно удивило Хотя, казалось бы, размеры пользо, someanon (?), 16:30 , 10-Окт-25, (57)

Ну он раньше появился, аж в 2002 году И сишка в rpython быстрее плюсов в нодовс, Аноним (53), 16:43 , 10-Окт-25, (59)

micropython всё равно вне конкуренции Хотя, казалось бы, у него ресурсов меньше, Аноним (61), 17:23 , 10-Окт-25, (61)
Удивительно, насколько отвратительные языки набрали популярность То есть совреме, Аноним (77), 19:03 , 10-Окт-25, (76) –1

Пока что питон в десятки раз меньше го памяти потребляет в рантайме на ровно тех, Аноним (5), 19:31 , 10-Окт-25, (79)

Наглая ложь Простейший код import sysfor i in 1, 2, 4, 8 print i, sys getsiz, Аноним (77), 21:16 , 10-Окт-25, (93)

Скрыто модератором, Аноним (86), 20:36 , 10-Окт-25, (86)
Согласен Ну вот могу вспомнить опыт программирования на Python в 2000-х мне над, Аноним (91), 21:05 , 10-Окт-25, (91)

Довольно жалко всё это Больше всего меня расстраивает что они катастрофически у, Аноним (89), 20:46 , 10-Окт-25, (89)

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

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

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

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

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

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

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

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

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

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

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

А при глубоком понимании что, те же циферки какой-то иной смысл будут иметь?

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

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

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

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

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

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

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

Опустим множитель кило, в 60 раз.

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

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

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

Не в шестьдесят, а в почти полные семьдесят.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сообщение от Аноним (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ообщить модератору

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

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

Это лишь показывает, насколько питон отвратителен.
>Взять любой мачурный язык, так дай бог если 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 л..." +3 +/–

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>Физические ядра тут не помогут, у питона не потоки, а гринтреды
Проблема не в зелёных потоках, а в gil.

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

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

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

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

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

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

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

А в том и дело, что параллелизм в питоне не работает без асинхронного кода. Ты не распарреллелишь requests, потому что питон однопоточный. Pycurl засегфолтит питон и не масштабируеся нормально, перерасход ресурсов повсюду. И aiohttp тот же бахает сколько угодно без ограничений.
А работа с файлами эт чо, вебня? Конечно, нет.

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

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

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

Мне даже интересно, а что это за такой use case, когда у тебя работа с файлом требует async? Ну кроме того, что у тебя проект на async и приходится всё на нём использовать. Открыл файл, поработал с ним, закрыл. Чего там ждать?

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

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

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

> А в том и дело, что параллелизм в питоне не работает без асинхронного кода
И вообще, с чего ты это взял? Я не говорю сейчас про запросы куда-то, с ними всё понятно. Но если у тебя просто несколько потоков должны тупо молотить байты и всё, безо всяких ожиданий, то с чего бы там не работал параллелизм без async, если он работает? Или к примеру в одном потоке GUI, в другом или нескольких других - фоновые задачи. Зачем там async?

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

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

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

Затем, что у тебя есть замечательный gil, и он не даст выполняться python коду. Мультизадачность питона та ещё шутка. Только код, освобождающий gil, выполняется параллельно (hence асинхронные батарейки). Помимо этого, есть уровень операционной системы, и на нём тоже должны задействоваться асинхронные компоненты, иначе очень быстро словишь бутылочное горлышко уже на другом уровне (те самые залипающие сокеты).

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

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

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

>а если нет, то сам async становится лишней вознёй
Питонопроблемы. А всё из-за того, что в питоне цветные функции. Вот условный ocaml или go позволяет иметь бесцветные функции, из-за чего это не превращается в проблему. Если не нравятся эти языки, возьмите какой-то другой.
>и тем более странным выглядит желание некоторых фанатиков бездумно перетащить в async все библиотеки, думая видимо, что async "эта крута"
Если питонистов не смущает скорость работы их кода, пускай хотя-бы сложности смущаются и переходят на нормальные языки.

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

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

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

>А всё из-за того, что в питоне цветные функции. Вот условный ocaml или go позволяет иметь бесцветные функции, из-за чего это не превращается в проблему
Допустим у тебя есть какой-то такой условный алгоритм: делаем что-то, ждём, потом делаем ещё что-то. И так надо много-много раз и параллельно. Как это решается в этих языках так, что якобы по твоим словам не имеет проблем и позволяет одни функции назвать цветными, а другие прозрачными?

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

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

Сообщение от Аноним (77), 10-Окт-25, 18:23

>Ручная возня с запуском тредов ни разу не окупилась, они слишком неоптимальны в итоге.
Тем временем, можно взять любой язык с зелёными потоками, хоть ocaml, хоть go, хоть любой другой язык на ваш вкус.

Ответить | Правка | К родителю #11 | Наверх | 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ообщить модератору

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

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

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

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

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

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

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

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

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

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

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

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

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

Сообщение от Аноним (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 л..." –4 +/–

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

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

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

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

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

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

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

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

Сообщение от Аноним (58), 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 л..." +2 +/–

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

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

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

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

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

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

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

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

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

Слава богу, на спад идёт. Питон плохо приживается

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

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

Сообщение от Аноним (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 л..." +3 +/–

Сообщение от Аноним (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 +/–

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

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

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

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

Сообщение от Аноним (77), 10-Окт-25, 18:19

Потому, что между cpython и pypy есть отличия.

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

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

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

Если бы команды объединили усилмя, различия бы устранили.

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

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

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

Эти различия не на пустом месте образовались. И исправить их можно только выпустив условный python 4, обратно несовместимый с текущим кодом.

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

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

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

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

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

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

Сообщение от Аноним (58), 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ообщить модератору

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

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

Дарвин, конечно, сделан (когда-то давно) на ядре Mach, да только на том ядре крутится один-единственный процесс "система", внутри которой обычное юникс-ядро, то есть микроядерный ipc не используется.
Но в принципе ты прав, Hurd на современном железе совсем не медленный.

Ответить | Правка | К родителю #32 | Наверх | 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ообщить модератору

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

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

Уровень опеннетсперктизы.
Питон тоже компилируется.

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

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

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

> Уровень опеннетсперктизы.
> Питон тоже компилируется.
Так речь о скрипте для cpython. Когда питон компилируется (тот же cython), там производительность 1 в 1 с си.

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

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

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

Ээээ... ну вот cython не пробовал - а с nuitka'ой прироста по скорости считай что и нет - так, удобства поставки для развлечение.

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

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

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

"Но есть нюанс!"

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

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

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

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

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

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

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

В нормальных языках хвостовая рекурсия оптимизируется начиная с первого релизного компилятора/интерпретатора.

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

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

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

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

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

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

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

Истину глаголишь. Самый лучший веб это php или perl.

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

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

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

> Истину глаголишь. Самый лучший веб это php или perl.
Нет, это битрикс.

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

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

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

Хуже Perl'а только Brainfuck. Это write-only язык. Хорошо что он помер.

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

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

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

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

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

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

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

Ну он раньше появился, аж в 2002 году. И сишка в rpython быстрее плюсов в нодовском V8.

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

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

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

micropython всё равно вне конкуренции. Хотя, казалось бы, у него ресурсов меньше на оптимизацию.

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

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

Сообщение от Аноним (77), 10-Окт-25, 19:03

Удивительно, насколько отвратительные языки набрали популярность.
>Pypy, Node.js и Rust обогнали CPython 3.14 в первом тесте в 4.93, 4.88 и 69.82 раз
То есть современная версия питона с кучей оптимизаций тормознее в семьдесят раз по сравнению с нативной версии с ручным управлением памятью. Интересно, а насколько же тормозными были первые версии гвидобейсика?
В восьмидесятых(а то и раньше) уже были простые (без ручного управления памятью) компилируемые типобезопасные языки. То есть написание больших(по количеству строк кода) уже на момент появления питоном портилось, ведь ошибки всплывали во время выполнения.
Если брать небольшие скрипты, то на тот момент уже были скриптовые языки, и питон не был революцией и в этом плане.
А если добавить к этому, что языки появившиеся позже успели получить гораздо более производительные реализации, то становится решительно непонятно, зачем этот питон вообще нужен.
Однако, кроме скорости исполнения, которую крайне медленно, но всё же увеличивают, у питона остаётся второй недостаток, которые старательно игнорируют: гораздо большее потребление памяти. И с этим уже ничего больше не сделать, так как этот изъян врождённый. Ну не сможет динамически типизированный язык быть столь же компактым, как и статически типизированный.
А теперь самый важный недостаток питона, нулевой: кому-то в голову приходит писать на питоне не просто скрипты на несколько десятков строк, а полноценные большие программы. Какие-то из них питон убил своей обратной несовместимостью, ну а те, что дошли до наших дней продолжают тормозить.

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

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

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

Пока что питон в десятки раз меньше го памяти потребляет в рантайме на ровно тех же задачах. К слову о "компилируемых" языках. И эффективно шарит её. Смотрю на тебя раст.

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

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

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

>Пока что питон в десятки раз меньше го памяти потребляет в рантайме на ровно тех же задачах
Наглая ложь. Простейший код:
import sys
for i in [1, 2, 4, 8]: print(i, sys.getsizeof(int(2**((i*8)-1)-1)), sys.getsizeof(int(2**((i*8)-1)-1)) - 1)
Размер нативного знакового числа в байтах, размер в байтах в питоне, размер перерасхода
1 28 27
2 28 27
4 32 31
8 36 35
Таким образом, на одном единственном числе перерасход памяти на питон больше, чем размер самого большого 64-ёх битного числа, кроме того, с увеличением числа перерасход тоже растёт. В компилируемых языках у вас не будет столь огромного перерасхода. Как только появятся структуры сложнее, чем целочисленное число, потребление памяти вообще подскакивает в небеса.
class A:
  def __init__(self, val):
    self.val = val
sys.getsizeof(A(1)) # 48
sys.getsizeof('') # 41
Пустой объект, с одним числовым полем занимает целых 48 байт. Для сравнения, код на голанге
package main
import (
    "fmt"
    "unsafe"
)
func main() {
    a := int(123)
    b := int64(123)
    c := ""
    d := struct {
        FieldA int
    }{0}
    fmt.Printf("a: %T, %d\n", a, unsafe.Sizeof(a))
    fmt.Printf("b: %T, %d\n", b, unsafe.Sizeof(b))
    fmt.Printf("c: %T, %d\n", c, unsafe.Sizeof(c))
    fmt.Printf("d: %T, %d\n", d, unsafe.Sizeof(d))
}
Выводит
a: int, 8
b: int64, 8
c: string, 16
d: struct { FieldA int }, 8
Обратите внимание, размер структуры в голанге равен суммарному размеру её членов и ни байтом больше.
Всё вышесказанное, будет очевидно любому, кто имеет хотя бы минимальные знания о программировании.
>И эффективно шарит её. Смотрю на тебя раст.
Вы слишком некомпетентны, чтобы рассуждать о таких сложных вещах.

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

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

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

> То есть современная версия питона с кучей оптимизаций тормознее в семьдесят раз по сравнению с нативной версии с ручным управлением памятью.
Ну и ну! Интерпретируемый скриптовый язык оказался медленее компилируемого. Да быть такого не может!
Чел, ты это серьезно? Я прямо вижу, как ты при наваливании этой экспертизы сидишь и думаешь "господи, как же я хорош".
> В восьмидесятых(а то и раньше) уже были простые (без ручного управления памятью) компилируемые типобезопасные языки...
Ты забыл, что два дня назад уже делал этот же наброс, практически слово в слово?
https://www.opennet.me/openforum/vsluhforumID3/138032.html#50
Ты тогда ничего внятного не смог ответить на замечания (в частности, про Лисп 1965 года выпуска) - и в этот раз наверняка будет то же самое. Зачем ты копипастишь свои набросы? Чтобы плюсиков получить от собратьев по экспертизе - и молча уйти в закат?

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

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

Сообщение от Аноним (91), 10-Окт-25, 21:05

>Удивительно, насколько отвратительные языки набрали популярность
Согласен.
>Интересно, а насколько же тормозными были первые версии гвидобейсика?
Ну вот могу вспомнить опыт программирования на Python в 2000-х: мне надо было моделировать обработку цифрового сигнала с немедленной визуализацией нескольких очень длинных рядов одновременно, также надо было визуализировать поток данных от устройства в live-режиме.
Сначала я делал визуализацию в OpenOffice Calc, но он так тормозил, что отрисовывал картинку несколько секунд. Потом всё сделал на Python (с использованием numpy), но загрузка процессора 100% и потери данных и невозможные дёргания (lag'и).
Потом всё переписал на C++ и работало быстро, процессор не нагружался.

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

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

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

Довольно жалко всё это. Больше всего меня расстраивает что они катастрофически усложняют и раздувают код ускорениями для частных случаев (https://docs.python.org/3.11/whatsnew/3.11.html#pep-659-spec... например, полный кошмар), а по итогу получают 1% буст на синтетических бенчмарках, а на деле всё ещё медленнее даже перла который 20 лет уже не развивается. Питон настолько медленный что заметно замедляет даже workload'ы упирающиеся в базу или сеть - по сути я даже не знаю для чего его можно использовать. Даже наколеночный сайт на фласке - выставишь в сеть и его завалят AI боты.

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

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

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

Партнёры:

Хостинг:

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

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

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


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


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


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


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


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

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


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


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


	11. "Оценка изменения производительности CPython за последние 5 л..."	+3 +/–
	Сообщение от Аноним (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ообщить модератору


	73. "Оценка изменения производительности CPython за последние 5 л..."	+/–
	Сообщение от Аноним (77), 10-Окт-25, 18:29
	Это лишь показывает, насколько питон отвратителен. >Взять любой мачурный язык, так дай бог если 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 л..."	+3 +/–
	Сообщение от User (??), 10-Окт-25, 14:33
	Ээээ... для i\o bound задач?!
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


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


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


	71. "Оценка изменения производительности CPython за последние 5 л..."	+/–
	Сообщение от Аноним (77), 10-Окт-25, 18:24
	>Физические ядра тут не помогут, у питона не потоки, а гринтреды Проблема не в зелёных потоках, а в gil.
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


	80. "Оценка изменения производительности CPython за последние 5 л..."	+/–
	Сообщение от Аноним (5), 10-Окт-25, 19:48
	А в том и дело, что параллелизм в питоне не работает без асинхронного кода. Ты не распарреллелишь requests, потому что питон однопоточный. Pycurl засегфолтит питон и не масштабируеся нормально, перерасход ресурсов повсюду. И aiohttp тот же бахает сколько угодно без ограничений. А работа с файлами эт чо, вебня? Конечно, нет.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	87. "Оценка изменения производительности CPython за последние 5 л..."	+/–
	Сообщение от Имя (?), 10-Окт-25, 20:36
	Мне даже интересно, а что это за такой use case, когда у тебя работа с файлом требует async? Ну кроме того, что у тебя проект на async и приходится всё на нём использовать. Открыл файл, поработал с ним, закрыл. Чего там ждать?
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


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


	81. "Оценка изменения производительности CPython за последние 5 л..."	+/–
	Сообщение от Аноним (77), 10-Окт-25, 20:14
	>а если нет, то сам async становится лишней вознёй Питонопроблемы. А всё из-за того, что в питоне цветные функции. Вот условный ocaml или go позволяет иметь бесцветные функции, из-за чего это не превращается в проблему. Если не нравятся эти языки, возьмите какой-то другой. >и тем более странным выглядит желание некоторых фанатиков бездумно перетащить в async все библиотеки, думая видимо, что async "эта крута" Если питонистов не смущает скорость работы их кода, пускай хотя-бы сложности смущаются и переходят на нормальные языки.
	Ответить \| Правка \| К родителю #21 \| Наверх \| Cообщить модератору


	88. "Оценка изменения производительности CPython за последние 5 л..."	+/–
	Сообщение от Имя (?), 10-Окт-25, 20:43
	>А всё из-за того, что в питоне цветные функции. Вот условный ocaml или go позволяет иметь бесцветные функции, из-за чего это не превращается в проблему Допустим у тебя есть какой-то такой условный алгоритм: делаем что-то, ждём, потом делаем ещё что-то. И так надо много-много раз и параллельно. Как это решается в этих языках так, что якобы по твоим словам не имеет проблем и позволяет одни функции назвать цветными, а другие прозрачными?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	70. "Оценка изменения производительности CPython за последние 5 л..."	+/–
	Сообщение от Аноним (77), 10-Окт-25, 18:23
	>Ручная возня с запуском тредов ни разу не окупилась, они слишком неоптимальны в итоге. Тем временем, можно взять любой язык с зелёными потоками, хоть ocaml, хоть go, хоть любой другой язык на ваш вкус.
	Ответить \| Правка \| К родителю #11 \| Наверх \| 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ообщить модератору