Комментарии 35
Я помню на хабре несколько лет назад был пост, где разработчик переработал систему запуска питона, значительно ёё ускорив, и создал соответствующий пул-реквест.
Но объем кода был достаточно большой, и не нашлось желающих его проверить. По итогу разработчик обратился напрямую к Гвидо, который отшил его, сказав, что если не нашлось ведущих контрибьютеров питона, которые хотят проверить код данного ускорения, то наверное это ускорение никому не надо.
Теперь мы видим, что ситуация меняется, что не может не радовать.
Самое главное это финансирование Microsoft, которое позволило работать на постоянно основе над проектом.
Общая цель — это ускорение CPython в 5 раз в ближайшие 4 года! Планируется это сделать в 4 отдельных этапа, каждый из которых увеличивает скорость CPython на 50 процентов.
Предыдущая попытка 13 лет тому назад ускорить cpython в 5 раз закончилась почти ни чем https://peps.python.org/pep-3146/ . Вопреки стараниям команды Unladen Swallow из Google, Гвидо решил не усложнять реализацию разными jit'ами (а может просто побоялся потерять контроль?) В прочем, идеи не пропали даром и у нас (них) теперь есть быстрый JavaScript.
Надеюсь, что у Microsoft в этот раз все получится и прирост производительности окажется достойным не только под Windows,)
Ровно 15 грубых ошибок отправлены в личку. Автор, может не надо так?
Спасибо за бдительность, пропущенные буквы, лишние пробелы и запятые поправлены, не заметил данные опечатки при финальном прочтении материала.
Там большая часть - несогласованные падежи и -ться/-тся. Стыдно должно быть!
В паре мест не заметил, в следующий раз буду повнимательней на этот счет и буду проверять лучше, текст не маленький, а проверяющего нет, в остальных таких же местах всё было верно и корректно(например, -ться/-тся было в двух местах из всего текста написано не верно, а не повально). Как-никак это техническая тема, а не сочинение по русскому языку, давайте комментарии оставлять лучше по существу и по теме, а остальное лучше в личку, чтобы не захламлять ненужными комментариями пост. Спасибо!
Как-никак это техническая тема, а не сочинение по русскому языку,
Но в русском языке есть правила, которые должны выполняться, коль скоро Вы его используете. И они ничем не хуже, чем правила языков программирования, которые Вы описываете или, может быть, даже используете. Более того, могу открыть Вам совсем маленький "секрет": есть программы, которые могут проверять Ваш текст на "русском" языке. Более того, большую часть ошибок из Вашей статьи они бы "выделили"! Аминь!
Даже многие писатели пользуются и пользовались услугами по вычитке и корректировке текстов, т.к. допускали ошибки. Спасибо за секрет, но увы, не все опечатки они видят, например, вместо предлога "с", был написан случайно предлог "в" или опечатка в окончание слова, но слово читается и так и так верно(пропущена одна буква). Такого рода ошибки они не замечают, как и запятые в сложны местах или оборотах, а часть текста я дописал прямо здесь, в редакторе, не предполагая, что пропущенная запятая или тире вызовет столько комментов, для меня всегда важнее была смысловая часть)
Ну, блин, до писателя Вам, как до Китая... Ну и кто мешает воспользоваться услугами "по вычитке и корректировке тестов "? Религия не позволяет? А ещё Вам не грех узнать, что программы могут проверять не только орфографию (тот же MS Word), но и грамматику (синтаксис - это чтоб понятнее было), и они смогли бы разобраться со всеми Вашими предлогами, тем более, что Ваши предложения попроще, чем у Льва Толстого.
Когда видишь не отдельные опечатки, а текст с ошибками практически в каждом абзаце (слава богу, что не в каждом предложении), то уж точно трудно сосредоточиться на "смысловой" части! Более того, возникает вопрос: "Если автор так относится к правилам русского языка, может ли он рассказать что либо ценное о языке программирования, который описывает? Может быть его познания в этой области соответствующие?.."
Правда, вынужден признать, что Вы поступили "хитро", вставив куски на англицком в статью на русском. Обычно правилом хорошего тона бывает перевод того, что приведено на языке, отличном от языка статьи (не обязательно дословный и литературный).
Я понимаю, что для большинства читателей Хабра не составляет труда читать оригинальный текст (я не исключение), но это всего лишь "правило хорошего тона", так же, как и письмо без ошибок!.
Честно говоря, не понимаю, почему можно так неуважительно относиться к будущим читателям Вашего опуса и не удосужиться элементарно проверить хотя бы с помощью какого-нибудь "спел-чекера"?
Обычно авторы на замечания об ошибках (желательно, конечно, не в комментариях - тут я готов с Вами полностью согласиться) благодарят и "молча" исправляют! Дискутировать на эту тему, высказывать своё "фи..", оправдываясь смысловой частью, как-то не комильфо!
Почему человек, не являющийся профессиональным писателем должен это делать?
Что делать? Проверить каким-нибудь спел-чекером свою писанину? Если Вы "не въехали" в мой комментарий, попробуйте перечитать его ещё раз или попросите кого-нибудь более "внимательного" растолковать Вам его смысл...
Если прям топите за грамматику, предложите в личку свои услуги по вычитке на бесплатной основе.
Именно это я и сделал до своих комментариев. Отправил автору кучу исправлений, которые были уже дополнением к тому, что отправил https://habr.com/ru/post/662087/comments/#comment_24284301 до меня. Мы ни разу не пересеклись, как это ни странно!!! А то, что он до меня начал с автором опуса обсуждать эту тему в комментариях, так все вопросы не ко мне...
Просто сегодня какой-то день неправильный: читаю третью статью на Хабре, а там в почти в каждом абзаце ошибки во всех трех, глаз режет...
Такие как Вы отбивают желание писать какие-либо статьи на Хабре.
А сколько статей Вы уже тут написали? Может просто, Вам не о чем сказать? И надо не "желать", а писать, если есть, что сказать...
Лучше бы дельные комментарии давали по сути написанного.
Так по сути там и комментировать-то нечего. Всё на англицком дословно (и без ошибок) сформулировано. Автор пытается "пересказать" то, что написали до него. Только вот сейчас пересмотрел заново и не нашел ссылок на источник/источники, откуда эти цитаты!
только вот сейчас пересмотрел заново и не нашел ссылок на источник/источники, откуда эти цитаты!
Видимо, вы даже прочесть нормально не удосужились, первая ссылка в источниках... Это не гайд, а новость основная на том что будет, естественно я пользуюсь оригиналом, дабы не искажать смысл, а в тех местах где нужно и что нужно я перевёл и написал своими словами, как посчитал нужным. Я уже получил много благодарностей в личку о том, что статья очень хорошо написана, причём от популярных людей в сообществе. Все поняли, что вы самый умный, давайте, пожалуй, на этом закончим. Спасибо.
Видимо вы даже прочесть нормально не удосужились, первая ссылка в источниках...
Точно, Вы правы, до ссылок я уже не дошел, хотя видел их, поторопился с утверждением, но я искал ссылки сразу в районе цитат. Мне что нужно "перерыть" все источники. чтоб разобраться, что откуда? Видимо устал формировать "репорты об ошибках" к тому времени...
Все поняли, что вы самый умный,
Господи, как примитивно... Ещё мне не хватало, чтоб с Вами чем-то меряться.
>как это не странно
как это ни странно. извините
согласен, спасибо. Кстати, на комментариях отчеты об ошибках не работают!! А очень жаль. А то, что ошибки бывают практически всегда, надеюсь, что с этим тезисом спорить никто не будет. Вопрос в том, сколько их...
Ну я скорее к тому, что в целом ошибки совершают все, некоторые физически не способны вычитать даже простой текст - это такая особенность работы мозга. Да читать это бывает тяжело, глаз цепляется, но вы, блин, тут развели в комментах что-то странное. Заметил ошибку - отправил в личку. Заодно предложил помощь в вычитке в будущем. Ну, ей богу, настрочили текста больше чем в оригинальной заметке.
Ну, блин, до писателя Вам, как до Китая… Ну и кто мешает воспользоваться услугами "по вычитке и корректировке тестов "? Религия не позволяет?
А что вам не позволяет писать свои претензии (которым имхо тут не место в таком количестве) хотя бы уважительно?
Я за грамотное написание. Позволю себе отметить несколько фактов.
1. Вы пишите об ошибках автора, которые он уже признал.
2. Вы сами совершаете ошибки. Например, во втором абзаце вы пишите "что либо" без дефиса.
3. Пост очень большой, но не по теме и публичный.
Лично я (читатель) делаю вывод, что этот пост написан, чтобы самоутвердиться. Пишите в личку!
Автор, извините, что не по теме поста.
Python существенно отличается от других языков программирования меньшими проблемами при смене версий. Если у разработчиков python получится сохранять обратную совместимость и дальше, то любые улучшения производительности будут большим плюсом.
Python существенно отличается от других языков программирования меньшими проблемами при смене версий.
В Расте их вообще почти нет.
Нельзя ни как сохранить полную обратную совместимость, если вносится что-то действительно значимое. Если остается полная совместимость, значит либо:
1. Остается куча легаси или деприкейтед (подобное мы можем наблюдать в Windows)
2. Нет значительных изменений
3. Код настолько идеальный, что его дальше некуда улучшать (смешно)
На данный момент заявляется полная обратная совместимость, конечно поживём-увидим, но я считаю, что им это удастся сделать, ибо под обратной совместимостью понимается две вещи: 1) запуск старого python кода, который работал на версиях 3.10, 3.9 и т.д. 2) совместимость с C API, которое используется, например, в numpy. Первая задача достаточно просто решается, и с ней проблем, я думаю, не будет, за исключением определённых вещей, которые будут удалены, т.к. устареют в этой версии, но если вы не используете депрекейтед код, то проблем не будет. А вот второе, это, конечно, задача по сложнее с точки зрения сохранения обратной совместимости, возможно, будет переходный этап, возможно, вообще не затронут конечные интерфейсы, объекты и в целом API, но одно ясно точно, это не будет такой же переход как с 2 на 3, а будет постепенное развитие, а не революция, Гвидо сильно против любой поломки совместимости. Главная цель - это ускорить так, чтобы ничего переписывать конечным пользователем не нужно было. Поэтому сейчас основная работа сосредоточена в ядре, то до чего руки обычных пользователей не дотягиваются или работа идет исключительно через обёртки.
Как ни странно, но в рамкакх ветки 2 и ветки 3 в основном это до сих пор удавалось. Так что к обратной совместимости пользователи привыкли. Разработчики фиксят обычно те немногочисленные ошибки, которые крайне редко, но таки появляются.
Пфф, расскажи это тем, кто с Python 2 переходил на Python 3.
С ходу даже и не вспомнить, кто ещё косячил с обратной совместимостью, настолько же сильно, как Python.
Я вообще-то переходил с 2 на 3. Какой смысл вкладывается в слово "косячил". Процесс будущих изменений в новых версиях скурпулёзно документируется и обсуждается заблаговременно и публично. История изменений языка всегда является частью системной документации. Кстати ветка 2 до сих пор поддерживается. Разработчики python продолжают следовать тем правилам, которые завёл Гвидо Ван Россум. Это как раз светлая часть языка.
Прочитав заголовок, подумал, что ускорили работу Python в Windows 3.11. Ан нет, придется и дальше страдать.
Попробовал на 3.11 (в сравненини с 3.10) код из "Sexy primes, «медленный питон» ...". Как чистая "числодробилка" оно всё ещё не очень комильфо...
где-то даже чуть медленнее ...
-$ python3.10 sexy-primes-test.py 30K org 5
+$ python3.11 sexy-primes-test.py 30K org 5
- org === 4.07481 s === 4074.81 mils | 951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]
+ org === 5.29273 s === 5292.73 mils | 951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]
- mod1 === 3.96475 s === 3964.75 mils | 951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]
+ mod1 === 4.87965 s === 4879.65 mils | 951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]
- mod2 === 2.22087 s === 2220.87 mils | 951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]
+ mod2 === 2.48653 s === 2486.53 mils | 951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]
- org2 === 1.70525 s === 1705.25 mils | 951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]
+ org2 === 2.34608 s === 2346.08 mils | 951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]
- max === 0.02840 s === 28.40 mils | 951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]
+ max === 0.03147 s === 31.47 mils | 951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]
- orgm === 0.03075 s === 30.75 mils | 951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]
+ orgm === 0.04177 s === 41.77 mils | 951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]
-gesiv === 0.01476 s === 14.76 mils | 951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]
+gesiv === 0.01606 s === 16.06 mils | 951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]
-gesim === 0.00567 s === 5.67 mils | 951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]
+gesim === 0.00565 s === 5.65 mils | 951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]
-siev1 === 0.00160 s === 1.60 mils | 951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]
+siev1 === 0.00194 s === 1.94 mils | 951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]
-siev2 === 0.00156 s === 1.56 mils | 951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]
+siev2 === 0.00201 s === 2.01 mils | 951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]
-osie1 === 0.00229 s === 2.29 mils | 951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]
+osie1 === 0.00283 s === 2.83 mils | 951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]
-osie2 === 0.00212 s === 2.12 mils | 951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]
+osie2 === 0.00237 s === 2.37 mils | 951 sp: [5, 11], [7, 13], ... [29921, 29927], [29983, 29989]где-то действительно чуть быстрее ...
-$ python3.10 sexy-primes-test.py 1M max 5
+$ python3.11 sexy-primes-test.py 1M max 5
- max === 4.84150 s === 4841.50 mils | 16386 sp: [5, 11], [7, 13], ... [999763, 999769], [999953, 999959]
+ max === 4.00079 s === 4000.79 mils | 16386 sp: [5, 11], [7, 13], ... [999763, 999769], [999953, 999959]
- orgm === 3.93674 s === 3936.74 mils | 16386 sp: [5, 11], [7, 13], ... [999763, 999769], [999953, 999959]
+ orgm === 3.53014 s === 3530.14 mils | 16386 sp: [5, 11], [7, 13], ... [999763, 999769], [999953, 999959]
-gesiv === 0.59956 s === 599.56 mils | 16386 sp: [5, 11], [7, 13], ... [999763, 999769], [999953, 999959]
+gesiv === 0.61838 s === 618.38 mils | 16386 sp: [5, 11], [7, 13], ... [999763, 999769], [999953, 999959]
-gesim === 0.22313 s === 223.13 mils | 16386 sp: [5, 11], [7, 13], ... [999763, 999769], [999953, 999959]
+gesim === 0.21676 s === 216.76 mils | 16386 sp: [5, 11], [7, 13], ... [999763, 999769], [999953, 999959]
-siev1 === 0.06775 s === 67.75 mils | 16386 sp: [5, 11], [7, 13], ... [999763, 999769], [999953, 999959]
+siev1 === 0.06535 s === 65.35 mils | 16386 sp: [5, 11], [7, 13], ... [999763, 999769], [999953, 999959]
-siev2 === 0.06941 s === 69.41 mils | 16386 sp: [5, 11], [7, 13], ... [999763, 999769], [999953, 999959]
+siev2 === 0.06778 s === 67.78 mils | 16386 sp: [5, 11], [7, 13], ... [999763, 999769], [999953, 999959]
-osie1 === 0.10289 s === 102.89 mils | 16386 sp: [5, 11], [7, 13], ... [999763, 999769], [999953, 999959]
+osie1 === 0.10788 s === 107.88 mils | 16386 sp: [5, 11], [7, 13], ... [999763, 999769], [999953, 999959]
-osie2 === 0.08179 s === 81.79 mils | 16386 sp: [5, 11], [7, 13], ... [999763, 999769], [999953, 999959]
+osie2 === 0.08253 s === 82.53 mils | 16386 sp: [5, 11], [7, 13], ... [999763, 999769], [999953, 999959]Тесты делал на i7-4790 @ 3.60GHz, обе версии собирались локально с оптимизацией (configure --enable-optimizations, -mtune=native, -O3 и т.д.).
Хотя судя по всему что-то в этом PEP 659 "кэшировании" (ака specializing adaptive interpreter) всё-таки есть, надо будет потискать в бою.
Автор, переводили гугл-транслейтом? Стилистический кошмар какой-то. Сделали бы хотя бы минимальный рерайт: "А в большей части пользовательского кода, объекты фрейма, при вызове функций, теперь не создаются вовсе" -> "Теперь в большей части пользовательского кода объекты фрейма при вызове функций не создаются вовсе"
Ускорение производительности Python в 3.11