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

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

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

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

Оглавление

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

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

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

Ну плюс-минус, но не на три порядка быстрее , Аноним (135), 15:19 , 11-Окт-25, (135)

После написания принципиальной части программы в Питоне, можно перейти, с неболь, Vamp (??), 17:50 , 11-Окт-25, (140)

А почему не начать изначально писать на нормальном языке Зачем эти вечные переп, Аноним (77), 17:56 , 11-Окт-25, (141) +1

Потому что, во-первых, больше ни на чём не умеют, а во-вторых, чтобы оправдать с, YetAnotherOnanym (ok), 20:29 , 11-Окт-25, (151) –1

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

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

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

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

Чтобы использовать питон только в подходящих для него областях применения, необх, YetAnotherOnanym (ok), 20:34 , 11-Окт-25, (153)

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

Правильно, пусть погроммист переписывает программу под новую версию питона, и ищ, Аноним (77), 17:57 , 11-Окт-25, (142) –1

Зачем бы ему В обозначено случае Упакует в контейнер со всем барахлом - и не , User (??), 18:15 , 11-Окт-25, (146)

Это же питон Ты видишь сколько тебе минусов накидали В питономире производител, YetAnotherOnanym (ok), 20:35 , 11-Окт-25, (154)

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

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

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

Ну меня очень радуют верные выводы сделанные в тестах того же 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) –5

Пока что питон в десятки раз меньше го памяти потребляет в рантайме на ровно тех, Аноним (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) –1

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

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

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

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

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

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

А ведь так хорошо, с таким умным видом начинал ветку 129318 CODE python2 7 , Аноним (136), 15:24 , 11-Окт-25, (136) +1

Отлично Значит с тем, что встроенные числа с плавающей запятой просто так жрут , Аноним (77), 18:05 , 11-Окт-25, (143) –1

Почему не пригоден Ты просил, цитата, дробные числа - и тебе показали, как ра, Аноним (152), 20:31 , 11-Окт-25, (152)

Вы так и не ответили, если числа, нужные для математических расчётов подключаютс, Аноним (77), 21:13 , 11-Окт-25, (156) –1

Он теряет точность потому что это бинарный, а не десятичный float 1 2 и 1 2 ч, Аноним (139), 17:05 , 11-Окт-25, (139) +1

Спасибо, но я это и без вас знаю Если это тип float, то почему он занимает 24 ба, Аноним (77), 18:08 , 11-Окт-25, (144) –2

Теперь знаешь, да А перед этим ты искренне недоумевал, где же безразмерные fl, Аноним (152), 20:09 , 11-Окт-25, (150)

Вам сюда https 0 30000000000000004 com , Кошкажена (?), 20:48 , 11-Окт-25, (155)

Кстати говоря Даже в динамически типизированном языке имеет смысл хранить метад, Аноним (77), 05:04 , 11-Окт-25, (117)

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

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

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

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

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

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

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

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

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

У вас за железо платит бизнес и ему решать, что дороже - оптимизация или железо , Аноним (77), 14:31 , 11-Окт-25, (133)

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

Питон хорош для прототипирования, скриптов или в качестве клея для запуска чего-, Аноним (67), 05:02 , 11-Окт-25, (115) +1
Все еще проще jit У нормальных людей не заваливают , Кошкажена (?), 14:31 , 11-Окт-25, (132)

Госпаде, нафига их 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)
Можно в поиске задать вопрос Он справится То есть, единственно верная реализа, Кошкажена (?), 14:26 , 11-Окт-25, (130)

в виде, пригодном для написания бизнес-приложения , Golangdev (?), 16:26 , 11-Окт-25, (138)

А какая разница То же самое, что есть сpython, а есть другие реализации , Кошкажена (?), 19:29 , 11-Окт-25, (149)

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

спасибо но нет Пробуют же numba, codonАга, а в sbcl ничего это нет И не до, Кошкажена (?), 14:29 , 11-Окт-25, (131)

Только вот это всё равно лучше, чем форматирование отступами Как минимум, можно, Аноним (77), 14:54 , 11-Окт-25, (134)

я бы сказал что очень спорно Доработать Он не развивает, Кошкажена (?), 15:34 , 11-Окт-25, (137)

Чем Нормально читается Хорошо работает переход к парной скобке в условном vim-, Аноним (77), 18:11 , 11-Окт-25, (145)

Ну нет же Без утилит по отслеживанию скобок они будут разбалансированы и надо б, Кошкажена (?), 19:26 , 11-Окт-25, (147)

Я писал на elisp, в emacs особых проблем не заметил Можно даже вообще без дораб, Аноним (77), 22:05 , 11-Окт-25, (157)

Ну так то да Но за пределами эмакса поддержка страдает Но так никто не форматир, Кошкажена (?), 23:36 , 11-Окт-25, (158)

Если они ускорили ведь правда , то почему распустили команду по ускорению пито, Кошкажена (?), 19:28 , 11-Окт-25, (148)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сообщение от Аноним (135), 11-Окт-25, 15:19

Ну плюс-минус, но не на три порядка быстрее.

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

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

Сообщение от Vamp (??), 11-Окт-25, 17:50

После написания принципиальной части программы в Питоне, можно перейти, с небольшими переделками, для компиляции в NIM (https://nim-lang.org/)

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

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

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

А почему не начать изначально писать на нормальном языке? Зачем эти вечные переписывания?

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

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

Сообщение от YetAnotherOnanym (ok), 11-Окт-25, 20:29

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сообщение от YetAnotherOnanym (ok), 11-Окт-25, 20:34

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>Время _программиста_ дефицитный ресурс.
Правильно, пусть погроммист переписывает программу под новую версию питона, и ищет ошибки типизации по логам. Экономия по питонски.

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

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

Сообщение от User (??), 11-Окт-25, 18:15

>>Время _программиста_ дефицитный ресурс.
> Правильно, пусть погроммист переписывает программу под новую версию питона, и ищет ошибки
> типизации по логам. Экономия по питонски.
Зачем бы ему? В обозначено случае? Упакует в контейнер со всем барахлом - и "не открывать до страшного суда", делов-то.

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

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

Сообщение от YetAnotherOnanym (ok), 11-Окт-25, 20:35

Это же питон! Ты видишь сколько тебе минусов накидали? В питономире производительность программы -это неприличное слово.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>Пока что питон в десятки раз меньше го памяти потребляет в рантайме на ровно тех же задачах
> Размер нативного знакового числа в байтах, размер в байтах в питоне
Да ты не иначе как гений: сравнивать нативные числовые типы 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. Аплодирую стоя!
> Всё вышесказанное, будет очевидно любому, кто имеет хотя бы минимальные знания о программировании.
Из твоего вышесказанного очевидно, что ты некомпетентен в вопросах, о которых пытаешься умничать. Да еще и демагог (апеллирование к большинству прилагается).
> Вы слишком некомпетентны, чтобы рассуждать о таких сложных вещах.
Севший в лужу эксперт рассуждает о некомпетентности. Какая ирония, не правда ли?

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

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

Сообщение от Аноним (77), 11-Окт-25, 01:39

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> Или питон только для целочисленных расчётов, а если нужны как миниму дроби, то их нужно изобретать самому?
А ведь так хорошо, с таким умным видом начинал ветку 🤦

% python2.7
Python 2.7.18 (default, Apr  3 2025, 08:32:01)
>>> from fractions import Fraction as f
>>> f(0.1)+f(0.2)-f(0.1) == f(0.2)
True

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

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

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

>from fractions import Fraction as f
Отлично. Значит с тем, что встроенные числа с плавающей запятой просто так жрут место, вы не спорите. А через сторонние библиотеки считать можно в любом языке. И отличительная черта питона здесь только в том, что он во-первых не пригоден с импортами по умолчанию для математических расчётов, а во-вторых жрёт память понапрасну.
>А ведь так хорошо, с таким умным видом начинал ветку
Если бы питон изначально бы проектировался под расчёты, как мне тут пытаются доказать, чтобы хоть как-то оправдать его аппетиты, то во-первых, всё бы работало из коробки, а во-вторых, это не был бы язык общего назначения, который суют везде где надо и где не надо.

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

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

Сообщение от Аноним (152), 11-Окт-25, 20:31

> отличительная черта питона здесь только в том, что он во-первых не пригоден с импортами по умолчанию для математических расчётов
Почему не пригоден? Ты просил, цитата, "дробные числа" - и тебе показали, как работать с этими самыми дробными числами.
Или Питон дожен тебе по умолчанию делать импорты для всех возможных рассчетов в математике, включая десятичный float, комплексные числа, матрицы, кватерионы и т.п.?
Ты явно не понимаешь, какую чушь сейчас несешь. Уже не знаешь, бедняга, к чему бы придраться.
> Если бы питон изначально бы проектировался под расчёты, как мне тут пытаются доказать
Покажи цитату, где в обсуждении выше кто-то утвержадет, будто Питон "проектировался под рассчеты".

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

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

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

>Ты просил, цитата, "дробные числа" - и тебе показали, как работать с этими самыми дробными числами.
Вы так и не ответили, если числа, нужные для математических расчётов подключаются через сторонний пакет, то почему тогда обычный Float занимает целых 24 байта?
>Покажи цитату, где в обсуждении выше кто-то утвержадет, будто Питон "проектировался под рассчеты".
Прокрутите немножко вверх
>Случай, когда В СКРИПТОВОМ языке нужно экономить на спичках, считая байтики - не просто редки, а равны нулю. А вот делать математические расчеты, не падая к верху лапками при достижении размера int на текущем CPU - это при расчетах нужно всегда.
Решение питона абсурдно: целочисленные значения в подавляющем большинстве нужны в размере для текущей архитектуры, в том числе и при использовании внутри языка, как для индексации массивов. Но нет, они зачем-то хранятся в безразмерном варианте. А вот с плавающей запятой почему-то решили сэкономить.
>Или Питон дожен тебе по умолчанию делать импорты для всех возможных рассчетов в математике, включая десятичный float, комплексные числа, матрицы, кватерионы и т.п.?
Язык непригодный не для чего. Для расчётов он слишком громоздкий, для скриптов - слишком тормозной.
>Уже не знаешь, бедняга, к чему бы придраться.
Я изначально писал, что язык во-первых тормозной, во-вторых потребляет лишнюю память. Вы мои слова никак не опровергли, но зато наглядно показали, насколько он плох для математических расчётов. Оборачивать каждую переменную можно хоть в расте, заодно и работать быстрее будет.

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

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

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

> если после простейшего расчёта он уже теряет точность?
Он "теряет точность" потому что это бинарный, а не десятичный float. 1.2 и 1.2 чисто физически невозможно точно сохранить в бинарном формате, вне зависимости от того, сколько у тебя памяти.
Ты хотя бы ВУЗ закончил бы, прежде чем тут экспертизу наваливать.
> Только не надо рассказывать про плавающую запятую
То есть ты юзаешь тип с названием float, но про плавающую запятую рассказывать тебе при этом не надо? Ясно, понятно...

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

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

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

>Он "теряет точность" потому что это бинарный, а не десятичный float.
Спасибо, но я это и без вас знаю.
>То есть ты юзаешь тип с названием float
Если это тип float, то почему он занимает 24 байта? Кому вообще могла придти в голову мысль в узкоспециализированном языке для расчётов использовать float?

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

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

Сообщение от Аноним (152), 11-Окт-25, 20:09

>>Он "теряет точность" потому что это бинарный, а не десятичный float.
> Спасибо, но я это и без вас знаю.
Теперь знаешь, да. А перед этим ты искренне недоумевал, где же "безразмерные" float и почему же теряется точность.
> Если это тип float, то почему он занимает 24 байта?
А сколько, по твоему, он должен занимать в интерпретируемом языке, где все является объектом с RTTI и методами?
Ах, да: ты же, гений, скриптоту с компилируемыми языками всерьез сравниваешь. Тебе уже выше разжевали, почему int на CPU и int в Питоне - это не совсем одно и то же. Казалось бы, адекватный человек мог бы провести аналогию и предположить, что float в Питоне - это то же как бы не совсем аналог голого float из IEEE 754. Но ты у нас особенный. Ты у нас Питон на чистую воду выводишь!
> в узкоспециализированном языке для расчётов
Ты опять какой-то бред несешь. С каких это пор Питон стал узкоспециализированным языком для рассчетов?
> Кому вообще могла придти в голову мысль [...] использовать float?
Эээ... А что нужно было использовать? Что, сейчас начешь срывать покровы с float? Ну давай, жги - позориться так позориться!

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

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

Сообщение от Кошкажена (?), 11-Окт-25, 20:48

>>А вот делать математические расчеты, не падая к верху лапками при достижении размера int на текущем CPU - это при расчетах нужно всегда.
> Кстати говоря, о математических расчётах.
> 0.1+0.2-0.1==0.2
> False
Вам сюда https://0.30000000000000004.com/

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

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

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

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

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

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

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

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

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

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

Сообщение от Аноним (77), 11-Окт-25, 00:48

>Ну и ну! Интерпретируемый скриптовый язык оказался медленее компилируемого. Да быть такого не может!
Вопрос не только в том, что он медленее, вопрос в том, насколько.
>Ты тогда ничего внятного не смог ответить на замечания (в частности, про Лисп 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ообщить модератору

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

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

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

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

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

Сообщение от Аноним (77), 11-Окт-25, 02:06

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сообщение от Бес (??), 11-Окт-25, 02:09

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сообщение от Аноним (67), 11-Окт-25, 05:02

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

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

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

Сообщение от Кошкажена (?), 11-Окт-25, 14:31

> Довольно жалко всё это. Больше всего меня расстраивает что они катастрофически усложняют и раздувают код ускорениями для частных случаев
Все еще проще jit.
> Даже наколеночный сайт на фласке - выставишь в сеть и его завалят AI боты.
У нормальных людей не заваливают.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сообщение от Кошкажена (?), 11-Окт-25, 14:26

> Госпаде, нафига их 2 ? Какой из них - правильный ?)
Можно в поиске задать вопрос. Он справится.
> Почему бы не сделать один, нормальный, как Go, например
То есть, единственно "верная" реализация от одной компании, диктующей путь развития - правильно? А еще же есть gccgo...

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

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

Сообщение от Golangdev (?), 11-Окт-25, 16:26

> есть gccgo
в виде, пригодном для написания бизнес-приложения ?

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

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

Сообщение от Кошкажена (?), 11-Окт-25, 19:29

> в виде, пригодном для написания бизнес-приложения ?
А какая разница? То же самое, что есть сpython, а есть другие реализации.

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

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

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

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

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

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

Сообщение от Кошкажена (?), 11-Окт-25, 14:29

> Можно, конечно, пописать под SBCL с компиляцией в натив двадцать лет назад как,
(спасибо (но (нет)))
> а попробуй-ка ускорить питон
Пробуют же numba, codon
> И асинками весь код обмажь.
Ага, а в sbcl ничего это нет. И не добавить, ибо не развивается.

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

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

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

>(спасибо (но (нет)))
Только вот это всё равно лучше, чем форматирование отступами. Как минимум, можно исходник привести в читаемое состояние, через автоформатирование, а не сидеть, выяснять, где с отступами проблема.
>Ага, а в sbcl ничего это нет. И не добавить, ибо не развивается.
Куда проще доработать уже быстрый язык, чем пытаться разогнать питон.

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

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

Сообщение от Кошкажена (?), 11-Окт-25, 15:34

>>(спасибо (но (нет)))
> Только вот это всё равно лучше, чем форматирование отступами. Как минимум, можно
> исходник привести в читаемое состояние
(я (бы)
   (сказал (что
           (очень) спорно)))
>>Ага, а в sbcl ничего это нет. И не добавить, ибо не развивается.
> Куда проще доработать уже быстрый язык, чем пытаться разогнать питон.
Доработать?) Он не развивается же, стандарт заморожен. Хочешь быстрый, возьми ocaml что ли, он хотя бы развивается.

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

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

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

>(я (бы)
>   (сказал (что
>           (очень) спорно)))
Чем? Нормально читается. Хорошо работает переход к парной скобке в условном vim-е. Можно безопасно копировать в разные места. Не страншо смешение пробелов и табуляций. Возможно автоматически форматировать код во время написания.
>Доработать?) Он не развивается же, стандарт заморожен.
Да хоть форкнуть.

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

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

Сообщение от Кошкажена (?), 11-Окт-25, 19:26

> Хорошо работает переход к парной скобке в условном vim-е. Можно безопасно копировать в разные места.
Ну нет же. Без утилит по отслеживанию скобок они будут разбалансированы и надо будет понять сколько добавить скобок (или убрать) в конце (а там будет что-то такое: ))))))))))
> Не страншо смешение пробелов и табуляций.
Решается настройкой редактора.
> Возможно автоматически форматировать код во время написания.
Тоже самое.
>>Доработать?) Он не развивается же, стандарт заморожен.
> Да хоть форкнуть.
И будет еще один форк. Как и куча заброшенных библиотек для cl.

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

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

Сообщение от Аноним (77), 11-Окт-25, 22:05

>Без утилит по отслеживанию скобок
Я писал на elisp, в emacs особых проблем не заметил. Можно даже вообще без доработок редактора писать. А вот для питона нужна поддержка со стороны редактора, иначе отступы будут постоянно вылазить.
>они будут разбалансированы
Ну так форматируйте в k&r стиле. Что-то вроде
(if (> 5 4)
    (message "5 is greater than 4!")
)
>Решается настройкой редактора.
Подстветка парных скобок есть в большинстве редакторов, и нужна не только для лиспа.

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

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

Сообщение от Кошкажена (?), 11-Окт-25, 23:36

>>Без утилит по отслеживанию скобок
> Я писал на elisp, в emacs особых проблем не заметил.
Ну так то да. Но за пределами эмакса поддержка страдает.
>>они будут разбалансированы
> Ну так форматируйте в k&r стиле. Что-то вроде
> (if (> 5 4)
>     (message "5 is greater than 4!")
> )
Но так никто не форматирует и не рекомендуется. А еще отступ в 2 пробела, что еще более скучивает код по мне.
>>Решается настройкой редактора.
> Подстветка парных скобок есть в большинстве редакторов, и нужна не только для
> лиспа.
Утверждение о том, что нужна подсветка скобок или выделение цветом блоков (как сделано на http://community.schemewiki.org/) для просмотра кода без наличия редактора, говорит о плохой читаемости. Вспомним просто Вирта с Паскалем или Обероном, в которых без подсветки читается ок, или Оберон от Гугл (у них до сих пор много примеров без подсветки и все читается отлично).

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

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

Сообщение от Кошкажена (?), 11-Окт-25, 19:28

Если они ускорили (ведь правда?), то почему распустили команду по ускорению питона в мс?

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

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

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

Партнёры:

Хостинг:

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

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

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


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


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


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


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


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


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


	140. "Оценка изменения производительности CPython за последние 5 л..."	+/–
	Сообщение от Vamp (??), 11-Окт-25, 17:50
	После написания принципиальной части программы в Питоне, можно перейти, с небольшими переделками, для компиляции в NIM (https://nim-lang.org/)
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


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


	151. "Оценка изменения производительности CPython за последние 5 л..."	–1 +/–
	Сообщение от YetAnotherOnanym (ok), 11-Окт-25, 20:29
	Потому что, во-первых, больше ни на чём не умеют, а во-вторых, чтобы оправдать свою неспособность выучить ещё один язык, придумали легенду о приоритете быстрой разработки над эффективностью кода.
	Ответить \| Правка \| Наверх \| Cообщить модератору

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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


	99. "Оценка изменения производительности CPython за последние 5 л..."	+/–
	Сообщение от Аноним (77), 10-Окт-25, 23:26
	>Мне даже интересно, а что это за такой use case, когда у тебя работа с файлом требует async? Вы предлагаете на время работы с файлом вешать программу целиком? Вот запустится работа с файлом, и сразу весь интерфейс программы заблокируется. Это уже не говоря про то, что программа может работать сразу с несколькими файлами.
	Ответить \| Правка \| Наверх \| Cообщить модератору


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