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

"Оценка изменения производительности 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) +2

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

Опустим множитель кило, в 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) +3

Кому неплохо Представь себе, в 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)

Тем временем, можно взять любой язык с зелёными потоками, хоть 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)

Производительность питона -- последнее что имеет значение на практике Не удивлё, Аноним (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) –3

Доля рынка языков для непрограммистов , Аноним (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) +1

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

А что кстати мешает питону официально перейти на 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 , Аноним (58), 12:14 , 10-Окт-25, (30) +2
Потому, что между cpython и pypy есть отличия , Аноним (77), 18:19 , 10-Окт-25, (69)

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

Ну то есть ничего особо не поменялось , 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)

обычно заканчивается переполнением стека , Аноним (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)

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2, #44

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5, #6, #8

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #9

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

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

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

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #20

9. Сообщение от Имя (?), 10-Окт-25, 09:50 –5 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #11

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

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

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #15, #18, #53, #74

11. Сообщение от Аноним (5), 10-Окт-25, 10:17 +3 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #17, #21, #70

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

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

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #13, #16, #30, #69

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #26

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #22, #24, #40, #41, #51

15. Сообщение от Аноним (14), 10-Окт-25, 10:47 +1 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #29

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #73

18. Сообщение от Shellpeck (?), 10-Окт-25, 11:09 –1 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #42, #47

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

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

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

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

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

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

21. Сообщение от Имя (?), 10-Окт-25, 11:24 +1 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #23

22. Сообщение от Аноним (5), 10-Окт-25, 11:26 +1 +/–

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #45, #78

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #27, #52

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #28

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #31

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

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

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

30. Сообщение от Аноним (58), 10-Окт-25, 12:14 +2 +/–

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

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

31. Сообщение от Аноним (5), 10-Окт-25, 12:20 +2 +/–

> Поддержка и баги это следствие малой пользовательской базы и малого количества разработчиков.
> А вот минусы 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ообщить модератору
Родитель: #28

32. Сообщение от Аноним (58), 10-Окт-25, 12:26 –2 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #36, #63

35. Сообщение от User (??), 10-Окт-25, 12:50 +1 +/–

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

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

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #39

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

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

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

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

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

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

40. Сообщение от Имя (?), 10-Окт-25, 13:18 +1 +/–

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

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

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

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

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

42. Сообщение от Аноним (41), 10-Окт-25, 13:54 +1 +/–

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

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

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #58

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #50, #56, #62

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

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

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

47. Сообщение от Аноним (44), 10-Окт-25, 14:24 +1 +/–

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

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

48. Сообщение от Аноним (44), 10-Окт-25, 14:27 +1 +/–

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #66

50. Сообщение от User (??), 10-Окт-25, 14:33 +3 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #54

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

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

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

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

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

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

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

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

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

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

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

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

55. Сообщение от Аноним (53), 10-Окт-25, 15:16 –1 +/–

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

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

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

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

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

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #77

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

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

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

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #71

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

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

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

64. Сообщение от Аноним (62), 10-Окт-25, 17:35 –1 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #65, #67

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #68

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

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

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

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #75

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

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

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

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

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

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

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

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

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

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

Это лишь показывает, насколько питон отвратителен.
>Взять любой мачурный язык, так дай бог если 5% ускорения в вакууме между релизами завозят
Потому, что они изначально сделаны хорошо.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Партнёры:

Хостинг:

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

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

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

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

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

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

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

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

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

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

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

10. Сообщение от Аноним (10), 10-Окт-25, 09:56	–3 +/–
Python лучше всех - доля рынка эта вещь упрямая!
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #15, #18, #53, #74

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

12. Сообщение от Аноним (12), 10-Окт-25, 10:22	+/–
А что кстати мешает питону официально перейти на PyPy?
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #13, #16, #30, #69

13. Сообщение от Аноним (5), 10-Окт-25, 10:24	+/–
> А что кстати мешает питону официально перейти на PyPy? То, что он хорош только в попугаеметрах.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #12 Ответы: #26

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

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

16. Сообщение от Аноним (16), 10-Окт-25, 11:04	+1 +/–
Ограниченная область применения
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #12

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

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

19. Сообщение от vitalif (ok), 10-Окт-25, 11:09	+/–
Ну то есть ничего особо не поменялось.)
Ответить \| Правка \| Наверх \| Cообщить модератору

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

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

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

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

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

26. Сообщение от Аноним (26), 10-Окт-25, 11:47	+/–
А чем плох в реальных задачах?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #13 Ответы: #27, #52

27. Сообщение от Аноним (5), 10-Окт-25, 11:53	+/–
> А чем плох в реальных задачах? Все минусы жита, плохая поддержка в существующем коде, потенциальные баги.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #26 Ответы: #28

28. Сообщение от Аноним (26), 10-Окт-25, 12:06	+/–
Поддержка и баги это следствие малой пользовательской базы и малого количества разработчиков. А вот минусы jit в студию.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #27 Ответы: #31

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

30. Сообщение от Аноним (58), 10-Окт-25, 12:14	+2 +/–
Сделано не ими. И PyPy, решая ту же проблему, не нуждается во всяких LLVM.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #12

31. Сообщение от Аноним (5), 10-Окт-25, 12:20	+2 +/–
> Поддержка и баги это следствие малой пользовательской базы и малого количества разработчиков. > А вот минусы 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ообщить модератору
Родитель: #28