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

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

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

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

Оглавление

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

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

А при глубоком понимании что, те же циферки какой-то иной смысл будут иметь , Аноним (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) –1

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

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

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

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

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

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

Ну если у тебя задача параллельная, где много чего-то ждут чего-то, а потом дела, Имя (?), 11:24 , 10-Окт-25, (21) +1

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

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

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

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

NVMe с 64 очередями передают привет , Аноним (97), 22:17 , 10-Окт-25, (97)

Нет, мне нужно запускать ничем неограниченное число потоков, пока я получаю уско, Аноним (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)

Вы предлагаете на время работы с файлом вешать программу целиком Вот запустится, Аноним (77), 23:26 , 10-Окт-25, (99)

Если с файлом нужно работать много долго, то этот код помещается в отдельный пот, Имя (?), 09:06 , 11-Окт-25, (120)

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

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

Я говорю конкретно об async, ключевом слове в языке python и о том, что оно под , Имя (?), 09:15 , 11-Окт-25, (121)

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

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

https habr com ru articles 466337 Всё просто В случае с Ocaml, Go или другого, Аноним (77), 23:20 , 10-Окт-25, (98)

Это интересно Благодарю за объяснение Python я врядли разлюблю, в основном за , Имя (?), 09:40 , 11-Окт-25, (122)

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

Питон определённо хороший язык, если использовать его вдумчиво и только в подход, Прохожий (??), 12:36 , 11-Окт-25, (126)

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

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

Там, где нужна производительность, давно скомпилированный нативный код вызываетс, Аноним (5), 11:26 , 10-Окт-25, (22) +2

Портаж кстати стал быстрее с третьим питоном, потому что туда воткнули функцию L, Bottle (?), 11:13 , 11-Окт-25, (124)

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

В 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) –2

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

В бэкенде что-то не особо , Аноним (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) +1

Ограниченная область применения , Аноним (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) –1

Странный вывод Автор тестил на том что было, а было у него 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) +1

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

Стандарт и жЫд не сильно отличаются, а кто-то мне втирал за скорость , Аноним (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)

Я не совсем понял юмора nuitka Собирает все блобы в кучу, ок, но код в итоге вы, Аноним (5), 21:28 , 10-Окт-25, (96)

Но есть нюанс , 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) –2

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

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

Увы, нет, не помер, Прохожий (??), 12:47 , 11-Окт-25, (127)

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

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

micropython всё равно вне конкуренции Хотя, казалось бы, у него ресурсов меньше, Аноним (61), 17:23 , 10-Окт-25, (61)

Это здорово, но по сути это отдельный язык, примерно так же, как D несовместим с, Bottle (?), 11:21 , 11-Окт-25, (125)

Удивительно, насколько отвратительные языки набрали популярность То есть совреме, Аноним (77), 19:03 , 10-Окт-25, (76) –3

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

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

Ну ты нашёл, что считать Давай ещё ресурсоёмкость массива и переменных в cython, Аноним (5), 21:22 , 10-Окт-25, (95)

Чините руки Вам выше наглядно показали почему вы не правы Либо у вас различает, Аноним (77), 23:34 , 10-Окт-25, (100)

Ну чепуха же В первом случае используются типичные батарейки и стандартная библ, Аноним (5), 23:42 , 10-Окт-25, (101)

Телепаты в отпуске Я надеюсь, вы меряете не сишные библиотеки, вызываемые питоно, Аноним (77), 01:11 , 11-Окт-25, (104)

Да ты не иначе как гений сравнивать нативные числовые типы CPU с безлимитными ч, Аноним (103), 01:04 , 11-Окт-25, (103) +2

А я просил безлимитные числа Нет Это гениальное решение - вначале из какой-ниб, Аноним (77), 01:39 , 11-Окт-25, (105) –2

Ты начал с ними сравнивать Случай, когда В СКРИПТОВОМ языке нужно экономить на с, Аноним (103), 02:07 , 11-Окт-25, (108)

Ну а как мне получить числа с фиксированной длиной в питоне Никак Через сложны, Аноним (77), 04:00 , 11-Окт-25, (112)
Кстати говоря, о математических расчётах 0 1 0 2-0 1 0 2Falsesys getsizeof 0 2 , Аноним (77), 04:48 , 11-Окт-25, (114)
Кстати говоря Даже в динамически типизированном языке имеет смысл хранить метад, Аноним (77), 05:04 , 11-Окт-25, (117)

Ну и ну Интерпретируемый скриптовый язык оказался медленее компилируемого Да б, Аноним (103), 20:36 , 10-Окт-25, (86)

Вопрос не только в том, что он медленее, вопрос в том, насколько А что вы хотите, Аноним (77), 00:48 , 11-Окт-25, (102) –2

Ты на полном серьезе искренне недоумеваешь, что интерпретируемый язык в N раз ме, Аноним (103), 01:46 , 11-Окт-25, (106)

Нет, я недоумеваю, почему питон до сих пор не вытеснен условным лиспом, js-ом, l, Аноним (77), 02:06 , 11-Окт-25, (107) –1

Господи, да что ж ты такой тугой При чем твой SML вообще Ты заявил, что Лисп по, Аноним (103), 02:26 , 11-Окт-25, (110)

Вы пропустили одно важное слово типобезопасный Ни алгол, ти фортран типобезоп, Аноним (77), 04:11 , 11-Окт-25, (113)

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

Классика же Сам Гвидо советует примерно так и делать переписывать проблемные ме, Бес (??), 02:09 , 11-Окт-25, (109) +1

Ну, мне приходится На несколько десятков тысяч строк, правда И оно работает И, Чтото знающий (?), 12:55 , 11-Окт-25, (128)

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

Питон хорош для прототипирования, скриптов или в качестве клея для запуска чего-, Аноним (67), 05:02 , 11-Окт-25, (115) +1

Госпаде, нафига их 2 Какой из них - правильный Почему бы не сделать один, но, Golangdev (?), 03:19 , 11-Окт-25, (111)

На Opennet данный вопрос звучит очень неожиданно 128578 Всё равно, что спросит, Аноним (119), 08:44 , 11-Окт-25, (119)

Справедливости ради, многообразие дистрибутивов Линукса в большинстве случаев вы, Чтото знающий (?), 13:07 , 11-Окт-25, (129)

Ну не два, больше, был ещё IronPython вроде как мёртв , Jython не помню жив ли, BrainFucker (ok), 09:56 , 11-Окт-25, (123)

Есть такая работа - питон ускорять Можно, конечно, пописать под SBCL с компиляц, enhance your python (-), 05:02 , 11-Окт-25, (116)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответить | Правка | Наверх | 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 –4 +/–

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

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

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

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 +1 +/–

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

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

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

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

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

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

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

Ответить | Правка | Наверх | 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 –2 +/–

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 +3 +/–

> Поддержка и баги это следствие малой пользовательской базы и малого количества разработчиков.
> А вот минусы 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 –1 +/–

Я на графиках на другое обратил внимание. При прочих равных, производительность разных Питонов на 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 +1 +/–

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответить | Правка | Наверх | 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 –1 +/–

> Все-таки ускорили питон? Не прошло и десяти лет. А нет, прошло.
На 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 +3 +/–

> все научные рассчеты
под капотом имеют библиотеки на 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 +2 +/–

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

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

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

Жрет дофига памяти (Которая - в отличие от 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 Ответы: #97

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

Зачем-то питон форсят в веб, он там не нужон, пых лучше же намного. А всякое 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 –1 +/–

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

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

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

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

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

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 –2 +/–

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 –1 +/–

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>Пока что питон в десятки раз меньше го памяти потребляет в рантайме на ровно тех же задачах
Наглая ложь. Простейший код:
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ообщить модератору
Родитель: #79 Ответы: #95, #103

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

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

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

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

Ну ты нашёл, что считать. Давай ещё ресурсоёмкость массива и переменных в cython для коллекции посчитай. Я прекрасно вижу как сотня интерпретаторов питона не создавала мне головной боли, и сотня статических блобов на го создаёт, когда вся задача скачать следующие чанки по ссылке.

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

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

> Ээээ... ну вот cython не пробовал - а с nuitka'ой прироста по
> скорости считай что и нет - так, удобства поставки для развлечение.
Я не совсем понял юмора nuitka. Собирает все блобы в кучу, ок, но код в итоге выполняется будто питон у меня без всяких оптимизаций и pgo собран. Т.е. реальный интерпретатор почему-то почти на 30% быстрее интерпретирует чем этот оттраслированный блоб исполняется. Не сомневаюсь, в попугаеметрах картина может быть иной.

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

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

NVMe с 64 очередями передают привет.

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

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

>что якобы по твоим словам не имеет проблем и позволяет одни функции назвать цветными, а другие прозрачными?
https://habr.com/ru/articles/466337/
Всё просто. В случае с Ocaml, Go или другого языка не имеющего цвета функций, не нужно помечать функции как async. И необходимости вызовать async функции только из async тоже нет. И исключения(в случае с Ocaml) не теряются где-то там внутри языка. В случае ocaml, если где-то пришёл promise, то его можно прозрачно дождаться, не переписывая кучу кода.
>Допустим у тебя есть какой-то такой условный алгоритм: делаем что-то, ждём, потом делаем ещё что-то. И так надо много-много раз и параллельно.
Для упрощения кода, асинхронные функции выглядят как синхронные, блокируя текущую нить. Суть в следующем: сначал запускаем несколько фоновых задач, а потом в них вызываем асинхронные функции как синхронные.
https://github.com/ocaml-multicore/eio/blob/7695d22387af7dc9...
Просто запускается сервер, а потом клиент. Они стартуют в своих нитях. Выглядит как обычный синхронный код.
Вот так происходит обращение в клиенте
https://github.com/ocaml-multicore/eio/blob/7695d22387af7dc9...
А вот так в сервере
https://github.com/ocaml-multicore/eio/blob/7695d22387af7dc9...

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

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

>Мне даже интересно, а что это за такой use case, когда у тебя работа с файлом требует async?
Вы предлагаете на время работы с файлом вешать программу целиком? Вот запустится работа с файлом, и сразу весь интерфейс программы заблокируется. Это уже не говоря про то, что программа может работать сразу с несколькими файлами.

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

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

Чините руки. Вам выше наглядно показали почему вы не правы. Либо у вас различается реализация, либо вы неправильно измеряете.

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

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

Ну чепуха же. В первом случае используются типичные батарейки и стандартная библиотека, во втором случае используются типичные батарейки и стандартная библиотека. Результат: ресурсоёмкость разнится на порядки и все недостатки на лицо.

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

102. Сообщение от Аноним (77), 11-Окт-25, 00:48 –2 +/–

>Ну и ну! Интерпретируемый скриптовый язык оказался медленее компилируемого. Да быть такого не может!
Вопрос не только в том, что он медленее, вопрос в том, насколько.
>Ты тогда ничего внятного не смог ответить на замечания (в частности, про Лисп 1965 года выпуска)
А что вы хотите услышать? Почему лисп появился раньше условного SML? Ну так причина ясна - Lisp реализовать гораздо проще чем SML. Если брать какой-то ещё более продвинутый язык, то его будет реализовать ещё сложнее. Для условного Rust вам потребуется и вывод типв по Хиндли-Милнеру, и вывод времени жизни для линейных типов, и мономорфизация и куча всего остального, чего в лиспе нет. На технологиях 1960-ых года выпуска не стоял вопрос о том, что оптимальнее, а стоял вопрос в том, что во-первых влезет в машину, а во-вторых можно реализовать за разумные сроки.
Вопрос неоптимальности? Ранее приведён пример со сравнием python и go, динамическая типизация всегда будет требовать больше памяти чем статическая. Если повезёт, то разница будет небольшой, но в случае с питоном очень сильно невезёт.
Вопрос с тем, что лисп устарел? Ну так посмотрите, много ли живых программ на лиспе сейчас?
Вопрос быстродействия? Уж если и выбирать между лиспом и питоном, то лисп гораздо лучше. В качестве примера возьмём https://benchmarksgame-team.pages.debian.net/benchmarksgame/... binary-trees. Различие между лучшим временем у си и лиспа - менее чем в два раза, лучший и худший результат принадлежат си. Если взять тот же тест но уже для питона, то различие будет более чем в тридцать раз https://benchmarksgame-team.pages.debian.net/benchmarksgame/.... При этом, это не один, особо неудачный бенчмарк, а общая тенденция. Да, существуют быстрые интерпретируемые языки, но питон явно не относится к их числу.
Питон в своё время преподносился как язык упрощающий разработку, однако сделан он крайне криво. Вначале он сделан динамичекски типизированным, сейчас к нему сверху пытаются прикрутить типизацию. Однако типизация эта проверяется сторонним инструментом и будет проигнорирована без малейших замечаний со стороны интерпретора.
Интерпетируемый язык, который не зависит от системных файлов? Получите зоопарк из pip, virtualenv и прочего. https://xkcd.com/1987/
Да даже в вопросе форматирования кода, вместо того, чтобы изобрести линтер, типа go fmt или ocamlformat, форматирующего в реальном времени, в питоне придумали дурацкий синтаксис, который до сих пор доставляет проблемы.
Если речь идёт о возможности лёгкого взаимодействия с нативными библиотеками, вроде numpy, то если заменить питон на условный лисп, луа или другой язык, то принципиально ничего не поменяется.
У питона нет такого места, которое можно было бы назвать его сильной стороной.
>Я прямо вижу, как ты при наваливании этой экспертизы сидишь и думаешь "господи, как же я хорош".
Я сомневаюсь, что вы не думаете "как же хорошо" про себя.
>Чтобы плюсиков получить от собратьев по экспертизе - и молча уйти в закат?
Доставайте свою экспертизу, будем сравнивать.

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

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

>>Пока что питон в десятки раз меньше го памяти потребляет в рантайме на ровно тех же задачах
> Размер нативного знакового числа в байтах, размер в байтах в питоне
Да ты не иначе как гений: сравнивать нативные числовые типы CPU с безлимитными числами Питона!
> Для сравнения, код на голанге
Ну давай, эксперт, сравним гошный math/big, который является аналогом Питоньего int:
package main
import (
    "fmt"
    "unsafe"
    "math/big"
)
func main() {
    var a big.Int
    fmt.Printf("%d\n", unsafe.Sizeof(a))
}
Выводит: 32
Ой, а что же это такое, эксперт? 32 байта против 28 в Питоне. Причем 32 - это размер полей самой структурки big.Int, без учета размера данных в динамическом массиве, который тем больше, чем больше цифр в числе.
> Пустой объект, с одним числовым полем занимает целых 48 байт.
> размер структуры в голанге равен суммарному размеру её членов и ни байтом больше.
Очередное гениальное сравнение: голый гошный struct на стеке - и Питоний class с его внутрянкой типа __dict__ и __weakref__, висящий в куче GC. Аплодирую стоя!
> Всё вышесказанное, будет очевидно любому, кто имеет хотя бы минимальные знания о программировании.
Из твоего вышесказанного очевидно, что ты некомпетентен в вопросах, о которых пытаешься умничать. Да еще и демагог (апеллирование к большинству прилагается).
> Вы слишком некомпетентны, чтобы рассуждать о таких сложных вещах.
Севший в лужу эксперт рассуждает о некомпетентности. Какая ирония, не правда ли?

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

104. Сообщение от Аноним (77), 11-Окт-25, 01:11 +/–

Телепаты в отпуске.
>когда вся задача скачать следующие чанки по ссылке.
Я надеюсь, вы меряете не сишные библиотеки, вызываемые питоном сравнивая их с голангом? Поскольку если ваша задча в том, чтобы передать пускай даже десяток строчек сишным библиотекам, то оверхед от питона будет крайне незаметным.
Попробуйте условый парсер комибнатор на питоне и голанге сравнить. У вас как раз и образуются множество мелких объектов. Или любой другой код, который данные обрабатывает.

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

105. Сообщение от Аноним (77), 11-Окт-25, 01:39 –2 +/–

>Да ты не иначе как гений: сравнивать нативные числовые типы CPU с безлимитными числами Питона!
А я просил безлимитные числа? Нет? Это гениальное решение - вначале из какой-нибудь сишной библиотеки придёт число, потом питон его превратит в безлимитное, а потом оно обратно превратится в число с фиксированной длиной, поскольку уходит уже к следующей сишной библиотеке. Случаи, когда требуются такие числа - крайне редки, а память потребляется всегда.
>Ой, а что же это такое, эксперт? 32 байта против 28 в Питоне.
Как и полагается питонисту, вы скромно умолчали, что 28 байт нужно для хранения двухбайтного числа. А потом, если вам потребуется сохранить хотя-бы четырёхбайтное число, то размер быстренько вырастет до 32 байт. Ну а к тому моменту, когда размер числа станет достаточно большим, для того, чтобы его уже действительно надо было хранить в таком формате, то и все 36 байт.
Кроме этого, в случае, если нам не нравится решение на компилируемом языке, как на том же go, мы можем без особого труда реализовать данный тип самостоятельно. А в питоне мы ничего самостоятельно реализовать не можем, и память всегда будет тратится, даже если она не нужна.
>Очередное гениальное сравнение: голый гошный struct на стеке - и Питоний class с его внутрянкой типа __dict__ и __weakref__, висящий в куче GC.
А теперь объясните, зачем мне нужен целый питонячий класс на каждом объекте. Чтобы что? Вот захочу я, например, построить concrete syntax tree. И будуте у меня на каждом токене висеть внутренности типа __dict__ и __weakref__. Для чего? Чтобы я не забыл что токен это токен? Ну так в нормальных языках для этого типизация есть. Вот задача с миллионом токенов - довольно обыденная, а вот задачу с миллионом уникальных классов - нет.
>висящий в куче GC
И что дальше? Это типо должно оправдать питон? Ну положите в голанге структуру в кучу, она у вас раздуется до размеров питона?
>апеллирование к большинству прилагается
Вы пытаетесь доказать свою компитетность в программировании познаниями по философии? Вы ещё похвастайтесь, что пишите без ошибок.

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

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

>> современная версия питона с кучей оптимизаций тормознее в семьдесят раз по сравнению с нативной версии с ручным управлением памятью.
> Вопрос не только в том, что он медленее, вопрос в том, насколько.
Ты на полном серьезе искренне недоумеваешь, что интерпретируемый язык в N раз медленнее нативного кода. Сори, но вопросов к тебе никаких быть уже не может.
> А что вы хотите услышать?
Откровенно говоря, я бы хотел тебя вообще не слышать, ибо ничего, кроме файспалма, твоя экспертиза не вызывает.
>> Ты тогда ничего внятного не смог ответить на замечания (в частности, про Лисп 1965 года выпуска)
Ты и тогда, и сейчас искренне недоумевал, зачем нужна скриптота (ибо она, цитата "динамически типизированная лапша, тормозит и жрет память". А потом оказалось, что динамически типизированные языки (Лисп) появились еще раньше, чем "компилируемые типобезопасные языки из 80-х", о которых ты вещал - и ты ушел в закат.
> Почему лисп появился раньше условного SML? Ну так причина ясна - Lisp реализовать гораздо проще
Нет, дружок: почему Лисп (1965) появился ПОЗЖЕ статически типизированных Фортрана (1957) и Алгола (1958). И при этом ВНЕЗАПНО был сложнее них для реализации, с его-то динамической типизацией, рекурсией и GC.
> 1960-ых года выпуска не стоял вопрос о том, что оптимальнее
Господи, я даже не знаю, как это комментировать. В эпоху, когда компы занимали целую комнату - "вопрос об оптимальности не стоял".
> стоял вопрос в том, что во-первых влезет в машину, а во-вторых можно реализовать за разумные сроки.
Да что ты! И потому "в разумные сроки" ребята специально для Лиспа проектировали Лисп-машины - чтобы "влезало"!
Извини, но дальше у меня уже нет сил комментировать твои бредни. Ты то ли неадекват с терминальной стадией Даннинга-Крюгера, то ли просто тролль.

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

107. Сообщение от Аноним (77), 11-Окт-25, 02:06 –1 +/–

>Ты на полном серьезе искренне недоумеваешь, что интерпретируемый язык в N раз медленнее нативного кода.
Нет, я недоумеваю, почему питон до сих пор не вытеснен условным лиспом, js-ом, lua и прочими быстрыми языками.
>о которых ты вещал - и ты ушел в закат.
В прошлой теме вы абсолютно ничего мне не ответили. https://www.opennet.dev/openforum/vsluhforumID3/138032.html#311 . Так что это вы ушли в закат, а не я.
>почему Лисп (1965) появился ПОЗЖЕ статически типизированных Фортрана (1957) и Алгола (1958)
А теперь сравните Алгол и SML.
>И при этом ВНЕЗАПНО был сложнее них для реализации, с его-то динамической типизацией, рекурсией и GC.
Вы сейчас удивитесь, если ещё не ушли в закат, но рекурсия и GC есть и в SML. А ещё там есть рекурсивные типы данных, проверяемые прямо в момент компиляции. А ещё там есть вывод типов. И первокласные модули. А так же алгебраические типы данных, кортежи и прочие весьма приятные вещи. И как не сложно догадаться, в лиспе этого нет.
>В эпоху, когда компы занимали целую комнату - "вопрос об оптимальности не стоял".
Ну давайте, реализуйте SML для тех времён.

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

108. Сообщение от Аноним (103), 11-Окт-25, 02:07 +/–

>>Да ты не иначе как гений: сравнивать нативные числовые типы CPU с безлимитными числами Питона!
> А я просил безлимитные числа? Нет?
Ты начал с ними сравнивать.
> Случаи, когда требуются такие числа - крайне редки, а память потребляется всегда.
Случай, когда В СКРИПТОВОМ языке нужно экономить на спичках, считая байтики - не просто редки, а равны нулю. А вот делать математические расчеты, не падая к верху лапками при достижении размера int на текущем CPU - это при расчетах нужно всегда.
>>Ой, а что же это такое, эксперт? 32 байта против 28 в Питоне.
> вы скромно умолчали, что 28 байт нужно для хранения двухбайтного числа. А потом, если вам потребуется сохранить хотя-бы четырёхбайтное число, то размер быстренько вырастет до 32 байт. Ну а к тому моменту, когда размер числа станет достаточно большим, для того, чтобы его уже действительно надо было хранить в таком формате, то и все 36 байт.
Я не просто умолчал, а прямым текстом написал, что при всех прочих равных (т.е. количестве цифер) гошный big.Int будет ВСЕГДА занимать на 4 байта больше, чем пионий Int. Или ты так и не понял, что в big.Int тоже используется динамическая память? Так я и об этом написал...
>> Очередное гениальное сравнение: голый гошный struct на стеке - и Питоний class с его внутрянкой типа __dict__ и __weakref__, висящий в куче GC.
> А теперь объясните, зачем мне нужен целый питонячий класс на каждом объекте.
Тебе - незачем. Серьезно. Про экономию байтиков в скриптоте я уже написал выше и не вижу смысла повторяться.
> Ну так в нормальных языках для этого типизация есть.
Персонаж опять записывает все динамически типизированные языки в "ненормальные".
>>висящий в куче GC
> Это типо должно оправдать питон? Ну положите в голанге структуру в кучу, она у вас раздуется до размеров питона?
Персонаж опять на полном серьезе сравнивает компилируемый и скриптовый языки. "Оправдать", блжадад...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105 Ответы: #112, #114, #117

109. Сообщение от Бес (??), 11-Окт-25, 02:09 +1 +/–

Классика же.Сам Гвидо советует примерно так и делать: переписывать проблемные места с Python на C.

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

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

> А теперь сравните Алгол и SML.
> Вы сейчас удивитесь, если ещё не ушли в закат, но рекурсия и GC есть и в SML. А ещё там есть рекурсивные типы данных...
Господи, да что ж ты такой тугой? При чем твой SML вообще?
Ты заявил, что Лисп появился раньше "компилируемых языков со статической типизацией" якобы потому, что его было легче реализовать. Но я тебе написал, что подобные языки уже были раньше, и Лисп был сложнее них в реализации (не говоря уж о его "динамической типизации, медленности и жору памяти").
Речь идет о твоем недоумевании по поводу того, почему интерпретируемые языки с динамической типизацией  и "лапшой, тормозами и потреблением кучи памяти" все еще существуют и почему их "в конце восьмидесятых" не вытеснили "простые типобезопасные статически типизируемые компилируемые языки". Теперь понятно, или из-за СДВГ ты не в состоянии сконцентрироваться на обсуждаемой теме?
И ответ на этот вопрос: да потому, что ты в силу некомпетентности, помноженной на терминальную стадию Даннинга-Крюгера - несешь откровенный бред и не понимаешь, что происходит. И, конечно же, как и все подобные персонажи, любые непонятные для себя явления ты объясняешь просто тем, что все вокруг дураки, а ты - умный и познал суть вещей.

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

111. Сообщение от Golangdev (?), 11-Окт-25, 03:19 +/–

> Pypy
> CPython
Госпаде, нафига их 2 ? Какой из них - правильный ?)
Почему бы не сделать один, нормальный, как Go, например, или Java...

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

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

>Ты начал с ними сравнивать.
Ну а как мне получить числа с фиксированной длиной в питоне? Никак? Через сложные костыли и сторонние библиотеки?
>Случай, когда В СКРИПТОВОМ языке нужно экономить на спичках, считая байтики - не просто редки, а равны нулю.
Ровно до тех пор, пока скриптовый язык не начинают использовать как язык общего назначения.
>А вот делать математические расчеты, не падая к верху лапками при достижении размера int на текущем CPU - это при расчетах нужно всегда.
Какие математические расчёты проводи django? А игра на PyGame? А утилита типа Mercurial? Наверное хеши файлов в безрамерных числах на питоне считает.
>Персонаж опять записывает все динамически типизированные языки в "ненормальные".
Я вам привёл предельно конкретную задачу, для которой питон плохо подходит. Вы мне ничего конкретного не привели. Математические расчёты это конечно хорошо, только вот для математических расчётов подключают библиотеки в нативном виде. Вы можете привести конкретный реальный пример, зачем для каждого объекта хранить его внутренее устройство?
>Персонаж опять на полном серьезе сравнивает компилируемый и скриптовый языки. "Оправдать", блжадад...
Хорошая причина тормозить: ну это просто язык интерпретируемый. Осталось только до авторов софта на питоне это донести, что это язык для расчётов, а не для программ.

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

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

>Ты заявил, что Лисп появился раньше "компилируемых языков со статической типизацией"
Вы пропустили одно важное слово "типобезопасный". Ни алгол, ти фортран типобезопасными языками не являются. Я не знаю, сколько раз вам нужно увидеть слово "типобезопасный", чтобы вы его заметили и ознакомились с тем, что это такое.
>да потому, что ты в силу некомпетентности, помноженной на терминальную стадию Даннинга-Крюгера
Желание обзываться идёт в комплекте с профессиональным навыком пропускать слова? Допустим, слов "типобезопасный" вам не ведомо. Выражение "рекурсивные типы данных" вас ничуть не смутило? А "алгебраические типы данных"? "Первокласные модули"?
>При чем твой SML вообще?
Вот действительно, при чём? Вы пропускаете половину объяснений, а потом размахиваете своим полным непониманием.
>и почему их "в конце восьмидесятых" не вытеснили "простые типобезопасные статически типизируемые компилируемые языки".
А вот здесь вы слово "типобезопасные" скопировали.
>Теперь понятно, или из-за СДВГ ты не в состоянии сконцентрироваться на обсуждаемой теме?
Так признавайтесь, вы его не видите, или сознательно игнорируете, чтобы казаться умнее?

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

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

>А вот делать математические расчеты, не падая к верху лапками при достижении размера int на текущем CPU - это при расчетах нужно всегда.
Кстати говоря, о математических расчётах.
0.1+0.2-0.1==0.2
False
sys.getsizeof(0.2)
24
Что это за за язык такой, что целые числа он хранит в безразмером формате, а дробные - нет? На что он тратит целых 24 байта, если после простейшего расчёта он уже теряет точность? Только не надо рассказывать про плавающую запятую, это ваша идея, что питон нужен для математических расчётов. Или питон только для целочисленных расчётов, а если нужны как миниму дроби, то их нужно изобретать самому?

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

115. Сообщение от Аноним (67), 11-Окт-25, 05:02 +1 +/–

Питон хорош для прототипирования, скриптов или в качестве клея для запуска чего-то, написанного на других языках. Если вы используете Питон в критичных частях - вы что-то делаете не так. Он прекрасен простотой и скоростью написания, и абсолютно отвратителен в плане производительности, безопасности и даже стабильности. Не надо брать в руки молоток и смотреть на всё вокруг как на гвозди.

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

116. Сообщение от enhance your python (-), 11-Окт-25, 05:02 +/–

Есть такая работа - питон ускорять. Можно, конечно, пописать под SBCL с компиляцией в натив двадцать лет назад как, а попробуй-ка ускорить питон. И асинками весь код обмажь. Вот то-то же.

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

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

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

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

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

На Opennet данный вопрос звучит очень неожиданно 🙂
Всё равно, что спросить:
>> Debian
>> SUSE
>> RHEL
>> Slackware
>...
>Госпаде, нафига их 100500 ? Какой из них - правильный ?)
>Почему бы не сделать один, нормальный, как Windows, например, или MacOS... 😜
Разные задачи, разные подходы, разная аудитория 😉🤷‍♂️

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

120. Сообщение от Имя (?), 11-Окт-25, 09:06 +/–

Если с файлом нужно работать много/долго, то этот код помещается в отдельный поток/процесс, а взаимодействие с ним из, к примеру, интерфейса организуется через очереди/сокеты. Мой вопрос был связан конкретно с ключевым слове async, и с тем, что оно под собой скрывает, а не с асинхронностью в целом

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

121. Сообщение от Имя (?), 11-Окт-25, 09:15 +/–

Я говорю конкретно об async, ключевом слове в языке python и о том, что оно под собой скрывает, а не об асинхронности в целом как явлении. В любом случае, для множества задач, где нет высоких требований, практического влияния GIL на ситуацию не оказывает. Зачастую не так уж и важно, псевдо-параллелизм или настоящий, если на глаз ничего друг друга не блокирует, если интерфейс и фоновые задачи выполняются, плавно взаимодействую друг с другом. А если важно, то возможно python не лучший выбор, хотя с учётом мощной экосистемы наверное это некий компромисс для тех, кто всё равно его выбирает, хотя нуждается в более производительном с точки зрения утилизации ресурсов компьютера инструменте.

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

122. Сообщение от Имя (?), 11-Окт-25, 09:40 +/–

Это интересно. Благодарю за объяснение. Python я врядли разлюблю, в основном за лаконичность синтаксиса, но, по-крайней мере, захотелось попробовать ocaml.

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

123. Сообщение от BrainFucker (ok), 11-Окт-25, 09:56 +/–

> Госпаде, нафига их 2 ? Какой из них - правильный ?) Почему бы не сделать один, нормальный, как Go, например, или Java...
Ну не два, больше, был ещё IronPython (вроде как мёртв), Jython (не помню жив ли).
А вот есть Cython (не CPython), он жив и используется. Вот его бы и надо было использовать в сравнении, тем более он вроде как популярнее PyPy.

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

124. Сообщение от Bottle (?), 11-Окт-25, 11:13 +/–

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

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

125. Сообщение от Bottle (?), 11-Окт-25, 11:21 +/–

Это здорово, но по сути это отдельный язык, примерно так же, как D несовместим с C++, а Zig с C.
То есть вещь хорошая, но если нужны либы, то тут уже будет проблема.

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

126. Сообщение от Прохожий (??), 11-Окт-25, 12:36 +/–

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

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

127. Сообщение от Прохожий (??), 11-Окт-25, 12:47 +/–

>Хорошо что он помер.
Увы, нет, не помер

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

128. Сообщение от Чтото знающий (?), 11-Окт-25, 12:55 +/–

>кому-то в голову приходит писать на питоне не просто скрипты на несколько десятков строк
Ну, мне приходится. На несколько десятков тысяч строк, правда. И оно работает. И достаточно быстро - пользователь не заметит разницы, если то же на C++ переписать. А памяти на наших серверах предостаточно. Плюс-минус сотня мегабайтов погоды не делает, от слова совсем.
Зато разработка космически быстрая, бизнесу именно это и надо в моём случае.
Что я делаю не так?

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

129. Сообщение от Чтото знающий (?), 11-Окт-25, 13:07 +/–

Справедливости ради, многообразие дистрибутивов Линукса в большинстве случаев вызвано не какой-то технической спецификой, а или тем, что кто-то хочет на рынок втиснуться, или just for fun. То есть, о целесообразности с точки зрения применимости мало кто думает.

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

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

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

Партнёры:

Хостинг:

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

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

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

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

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

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

5. Сообщение от Аноним (5), 10-Окт-25, 09:33	+4 +/–
Само по себе не имеет значения. Если асинхронный код в итоге выиграет, будет неплохо.
Ответить \| Правка \| Наверх \| 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	–4 +/–
Кому неплохо? Представь себе, в Python не все вeб-мakаки на хайлоаде, а в остальных местах async особо и ни нужон
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #5 Ответы: #11

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

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

14. Сообщение от Аноним (14), 10-Окт-25, 10:46	–3 +/–
Производительность программы не может не иметь значения. Это буквально время, оно самый дефицитный ресурс. То, что питонисты считают иначе, много о них говорит. Питон - это не язык создания программ, а клуб по интересам или секта.
Ответить \| Правка \| Наверх \| 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	–2 +/–
Миллиарды мух не могут ошибаться... То, что не могло бы появиться без таких проектов лучше бы и не появлялись.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #10 Ответы: #42, #47

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

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

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

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

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	+3 +/–
> Поддержка и баги это следствие малой пользовательской базы и малого количества разработчиков. > А вот минусы 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