Гвидо ван Россум, создатель языка программирования Python, в своём докладе на конференции Python Language Summit рассказал о планах по оптимизации производительности CPython. К версии 3.11, которая ожидается в 2022 году, разработчики надеются добиться увеличения производительности в два раза. Проектом по оптимизации CPython занимается небольшая команда разработчиков из компании Microsoft, в которую недавно перешёл на работу Гвидо...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=55146
Они решили похоронить жс (единственного конкурента на сегодня)?
Вряд ли выйдет, JS немногим хуже Джавы по скорости
Жс (в частности нода) на мой взгляд всё же ограниченней питона. Питон про беспроблемную интеграцию с си и беспроблемное конвертирование диалекта питона в си (cython).
Ну, если искать в языке прослойку между си-функциями, то даА в ноду классы C++ отлично интегрируются, что несколько на уровень выше интеграции C
> А в ноду классы C++ отлично интегрируютсяДы вы батенька знаток в извращениях.
Почему извращения? https://github.com/nodejs/node-addon-api
Биндили SDK в Python и JavaScript особой разницы нет.
Разве производительность у Python действительно кошмарная.
На мой взгляд JavaScript конечно поприличнее и понятнее и без фанатизма напсиать все на JavaScript, что зачастую наблюдаемо у Python-истов.
> На мой взгляд JavaScript конечно поприличнее и понятнее и без фанатизма напсиать все на JavaScript, что зачастую наблюдаемо у Python-истов.Я не могу понять, это на русском написано или на джаваскрипте?
О как. Жабаскрипт вдруг стал понятнее питона. Странно, ещё вчера такого не было
ещё вчера не было ES6
Яблоки с кирпичами по прежнему можно складывать.
Пропаганда простоты - она такая. Кто кого перекричит, у того язык проще. Потом, правда, завалят синтаксическим мусором, но это потом.
Зачем все это, когда есть QML?
(#шутка)
Вообще, QML офигенная штука для всего декларативного, но для чего-то кроме интерфейса оптимизации ему явно не хватает
Так он и есть интерфейсный, а логику пишите плюсовую к нему
Чёж биг-датитсты так Питон и Эр любят.
Что смогли выучить, то и полюбили
Дюжина команд для использования numpy - это ещё не питон...
анука нукатипичный жабаскрипт:
1 - 1 = 0
1 + 1 = 11и так там везде))
Уже придумал оправдание 3 * "3", 3 * True и import sys; sys.getsizeof(3) == 28, не говоря про аллоцирование практически всего диапазона char на старте?
Беспроблемная интеграция в си - это lua или какая-нибудь scheme, но не это.
На самом деле это круто, всего лишь используя эти подсказки по типам по типам в рантайме на некоторых кейсах можно получить 100000 кратное ускорение. В жит я конечно не верю, это только лишние накладные раскходы. Как и в aot. Я тут на той неделе скомпилировал в nuitka и получил только замедление процентов 30 (по производительности примерно как питон без pgo и всяких no-plt).
Попробуй Numba, это LVM POWER
Сократил время с 35 часов до 1.5 секунд
*LLVM конечно же
Попробовал, поддерживает питон ещё хуже cython. Nuitka для сравнения всё прожевала прекрасно.>TypeError: class members are not yet supported
и
>numba.core.errors.UnsupportedError: Failed in object mode pipeline (step: analyzing bytecode)
>Use of unsupported opcode (FORMAT_VALUE) foundRIP хотя всё равно там ведь не numpy
Вместо запуска задачи теперь просто выводит "general error!"?
Оно эту функцию, как и Clang/Rust, просто так оптимизировало
Там длинный цикл, который для хороших языков - мгновение
> Попробуй Numba, это LVM POWER
> Сократил время с 35 часов до 1.5 секундCuda или что? Конечно есть кейсы где какие-то вычисления которые numba сможет распознать и оптимизировать, но в основном от выноса части горчей логики (даже без simd) в cython пользы куда больше.
Обычная оптимизация компилируемых языков
> Обычная оптимизация компилируемых языковВ 100000 раз? На отдельных задачах можно получить такое ускорение, однако на практике оно виртуальное. Хорошо, если получится 20-30% относительно питона отыграть. А жит приносит пользу только на повторениях, и то не после первой тысячи. Большинство задач завершается задолго до того как он только запустится, а ведь ему ещё разогреться надо.
На некоторых задачах числомолочения и правда прирост такой. Но вот даже из numpy он поддерживает только малую часть функций и вещи которые делаются в одну строку (например np.clip, np.max(axis=...) итд) приходится либо велосипедить, либо считать выйдя из @njit блока.
JS всегда будет легче оптимизировать для обычного кода. У него почти нет бинарных пакетов написанных на других языках. А в питоне их куча и каждый пакет юзает древнее C API, которое мешает добавить некоторые простые оптимизации с большим приростом по скорости. Например сборке мусора нельзя изменить, чтобы многопоточность без GIL была.
1) единственная оптимизация которую можно сделать при вызове функций это встраивание (inline) что имеет смысл очень не всегда
2) аллё, рантийм js написан на трудом языке
3) нет связи между реализацией api и архитектурой языка
Отлично, будет теперь не оооочень медленно, а оочень медленно
Быстрое исполнение - это non-pythonic и deprecatedА если чуть серьёзнее, то сильно подозреваю, что питон за скорость ругают те, кто на нём не пишет или ниасилил
Не осилил (зачеркнуто) захотел использовать везде си-биндинги вместо языка? И правда, как же я так :)
Да нормальный язык, просто ниша другая.
То-то же. Признание своей неправоты в сочетании с переписыванием с питона на си - это путь к совершенству
Или те кто пишут на других языках и сравнивают с производительностью одних и тех же задач.
Ага, и потоки все одним мьютексом синхронизированы. Просто опупеть. Говно язык если честно, что этот бейсик так любят? Нет в нём изюминки...
> Ага, и потоки все одним мьютексом синхронизированы. Просто опупеть. Говно язык если
> честно, что этот бейсик так любят? Нет в нём изюминки...В жс ведь тоже только 1 поток. И жс ещё популярнее. Наверно потому, что разрабатывать когда кто-то уже позаботился о синхронизации, намного проще и удобнее -- можно думать о задачах, а не о о том, как бы половчее написать, чтобы оно вообще хоть как-то работало. Изюминка питона как по мне в том, что весь написанный код будет сразу работать и делать именно то, что задумывалось. Наверно лучший язык для прототипирования любой сложности.
Лечение симптомов не поможет общей болезни.Хотя ускорение питона я могу только приветствовать. Ибо хочешь, не хочешь, а на нем крутится очень много кода и очень много машинных ресурсов потребляются в никуда. Теперь потребляться будет меньше.
Надеюсь.
Так питонисты же кричали кругом что нету никакой просадки посравнению с сями. И даже какие-то псевдотесты в сферическом вакууме делали.Куда это всё делось?
Такое уж было много много раз. Результат один. Вот такой вот. Но да, удачи, полезное дело.
А так оно было и есть. То-же сейчас и с растом. Фрактал там в дырень провалится.
> Так питонисты же кричали кругом что нету никакой просадки посравнению с сямипоказывай, где "кричали" (ссылки), трепло
Это смотря что писать.
(Это я как Сишник и СиПлюшПлюшник)
В большинстве приложений Python будет тормознее хотя бы в силу интерпретации. Но в некоторых проектах, сишный код будет в разы больше и жрать больше ресурсов и намного дольше выполняться.
Давай и про Раст заодно пруфы, трепло.
> Лечение симптомов не поможет общей болезни.Там нет болезни - разве что усложнение языка. Просто пихать его не надо во все дыры.
Где болезнь-то хоть?"Питон тормозит" - это просто мемасик. Не следует принимать его всерьёз
а что же тогда у меня происходит каждый раз, когда я запускаю сценарий ansible?
сценарий ансибл у тебя тормозит не из-за Питона вообще-то.
У вас в слове Terraform слишком много ошибок
Вы оба не осилили шелл.
Пипец блин да, ансибл - монструозное чудище.
Пользуемся, плюёмся, планируем слезать. Тормознющие треды, пожирающие в 32 рыла полностью 16 гиг памяти для простых, в общем-то задач - это трындец.
Что там сейчас реально работает? Puppet вдоль и поперёк проприетарный с потенциалом на полное закрытие, SaltStack сожран VMWare.
(или таки проще собственный автомейшн ныне накорябать?)
Ну https://github.com/hashicorp/terraform же... На правильной гошечке всё написано.
А можно было писать на шелле, но yaml-программисты разучились.
может хватит уже, может пора уже избавится от этого тестового г-на и перейти на нормальные объектные технологии, а не выуживать текстовыми редакторами и регулярками в выводе команд нужные данные, а?
Нормальные объектные технологии скрипт на awk раздувают как минимум в два раза, не говоря о том, что нормального ООП в природе не существует, а если и существует, то ворочается еле-еле.
CFEngine же всегда работал? Но он сложный, да.Ну и Chef же был? Или он тоже скатился?
Это надо постараться!
мигрирую Монго на Мускуль Питоном. 32 процесса, жрут 400Кб, в Монге >100Гб, время - 1.5 часа. У меня Питон другой системы или ЧЯДНТ?
> мигрирую Монго на Мускуль ПитономMySQL - здравый выбор, в остальном могу только посочувствовать.
Они ускоряют сифон. Питон так и останется тормозным.
Про PHP тоже так говорили.Не скажу, что PHP стал молнией, но конкурентов (Python, Ruby) таки взял и обошёл.
Ну чудес бы я не ждал: выиграют в производительности - скорее всего хорошо прирастут в потреблении памяти.
Удачи чел. Искренне.А к питонистам вопрос: Кто там кричал что у питона нет проседание по производительности по сравнения сями? А?
Или это были выходцы из армии фрактала?
> Кто там кричал что у питона нет проседание по производительности по сравнения сями?показывай, где "кричали" (ссылки), трепло
Всё просто: питон станет в 2 раза быстрее сей.
В облсати разработки или в области выполнения?Вообще лучше б они запилили WinRT и UWP в Python, а то Tkinter времен мамонтов очень стремно сегодня использовать.
ну с Питоном ты можешь использовать не то что GTK, QT, WxWidgets и еще кучу всего, но даже Дельфи - https://blogs.embarcadero.com/data-visualization-5-ways-to-b.../
Это понятно. А что с тем, что мне нужно WinRT, COM, .NET?
Все эти библиотеки живы только в Linux мире, а при портировании нужны именно виндовые сервисы.
И пока ее окончательно не похоронили с этим нужно считаться - сейчас только C# это может.
А, например, Qt чего портировать? Она и так под Винду есть. Софт, который из зависимостей пользует только Qt, тоже портировать не нужно, только пересобрать.
анон наверное подумал раз ты сравниваешь с Tkinter, то наверное тебе лишь бы ГУИ, пофик какой. Но если тебе принципиально UWP, тогда пиши на C#. Или IronPython, наверное.
Есил крутить Джангу, то наверное это довольно медленно, поэтому Фейсбук тут публикует какие-то примочки.
Я кручу ML и там вообще нет разницы, потому что 99.9% времени все крутится внутри видюхи, а если нет готовых решений и нужно подробить числа, то если используется numpy все оборочивается в JIT декоратор jax чтобы он типичные вызовы numpy в CUDA преобразовал, если numpy не используется, то оборачивается в JIT декоратор numba, чтобы он скомпилировал в LLVM байткод и все очень и очень быстро, практически не уступает по скорости чистому с/с++.
Машин лёрнинг на языках без типов и прочего статического анализа ведет к скайнету и прочему армагедону
Ты ж договоришься, устроят тебе машин поттеринг на тайпскрипте.
Типизация неявная.
Раньше заявлялось что питон это не про скорость. Т.е. его заранее писали не обращая существенного внимания на производительность. А теперь внезапно его пытаются продать за быстроту. Зачем делать из хлеба троллейбус ещё и с эмблемой мелкософта...
Низкая производительность - это основной недостаток питона. Она низкая не только в сравнении с луа и джаваскриптами всякими, но и с равнозначно сложным перлом.
Решили наконец что-то сделать с объективной проблемой языка.Продавать питон не надо. Его уже напродавали так, что деваться некуда от него.
Вообще-то луа не то чтобы быстрый даже не смотря на все свои особенности. Не надо путать с луажит который не очень то совместим и не очень то жив.
Язык Lua изначально сделан таким, чтобы его было удобно встраивать в систему. Т.е. фактически Lua это удобный способ делать вызовы библиотек.
Кстати, а давно питон медленнее перла, лол? Там есть конечно кое-где, но это скорее исключения.
Например, регекспы в некоторых случаях на питоне НАМНОГО медленнее. Подозреваю, что и строки вообще как таковыеПерл со строками вообще очень быстрый же, да и регекспы там воткнуты прямо в ядро, так что выполняются все мыслимые и немыслимые оптимизации
Мне надо было гонять большие текстовые файлы через регекспы. Регекспы совсем простые, но несколько последовательных строчек и на питоне оно, мягко говоря, не летало. Попробовал один в один тупо переписать на перле и стало в несколько раз быстрее (и во столько же раз нечитабельнее). Может, можно было бы и на питоне ускорить как-нибудь через анус, но нафик нада если скорость через вызов перловых скриптов меня уже устраивала, ничего не глючило, и код получился очень простой
Так я и говорю, в некоторых случаях, да. Не знаю насчёт намного, просто они там СОВСЕМ другие, и нельзя многие вещи делать так же эффективно. Могут быть оптимизированы другие аспекты, я не проверял. В питоне регулярочки оптимизированные сишные, быстрее просто не куда. Просто они другие. Профайлером регулярочек можно выяснить, что происходит -- иногда они делают совсем не то, что ты ожидаешь (и совсем не тем числом операций).
Они не другие. Они именно тормозные. Не за счёт библиотеки, а за счёт промежуточного слоя.
Ты гонишь. Давай тест-кейсы и как замерял.
Я использовал Perl для парсинга логов и прочей подобной фигни. Это _целевая_ задача для Perl'а в принципе, то для чего он создавался. И Python тут ему проигрывает по всем параметрам.
В то время пока питонщики мутили переход с 2.x на 3.x и пилили всякие фичи, Perl остановился в развитии фич и пилил оптимизацию. Оптимизацию работы с данными в первую очередь.
Я согласен, процессинг текста намного удобней в perl, не в последнюю очередь благодаря нормальным регуляркам. И даже в awk тоже. Но не всегда. Скажем, я не знаю аналога spacy для перла. Самую большую боль лично у меня вызывал ООП в перле. И, если перл это только парсинг логов, то питон это вообще всё что угодно -- очевидно, что выбирать.>В то время пока питонщики мутили переход с 2.x на 3.x
В это самое время перехода перл растерял последние проценты и питон взлетел до небес, ой.
И да, 3 питон объективно хорош. Пока перл оставался там где был, питон развивали и превращали в актуальный и современный ЯП, не теряя универсальности. Так что популярность вполне заслуженная.
С самого начала. Любая арифметика на Питоне медленнее, чем на Перле, примерно в 6 раз. На Си та же математика в ~90 раз быстрее Перла. Так было в 2001-м году, так же оставалось и в 2012-м.Джаваскрипт без JIT где-то между Перлом и Питоном.
Ну, типа, cython/pandas/numpy/numba в помощьНемножко (или сильно, это уж как посмотреть) костыли как бы, но ведь даже на сях есть вставки на асме, так пачиму на питоне нельзя тоже вставки
Я, конечно, вовсе не к тому, что тормоза - это гут. Сам не против был бы, кабы оно крутилось чуточку быстрее. Впрочем, в моих текущих штуковинах оно и так не сказать чтоб было плохо. Стартует только медленновато, а крутится - на скорость не пожалуюсь
а теперь тащи в студиу ссылки на объективные бенчи которые доказывают что Питон тормозит по сравнению с Перлом и Джаваскриптом
Это ты должен предоставить ссылки
Тебе надо - вот и займись.
То, что перл быстрее - факт.
Нет. Это ложь.
Читайте недавнее интервью автора Ruby (есть на Опеннете). Люди слишком много внимания обращают на чиселки из бенчмарков, поэтому есть смысл ускорить интерпретатор именно для них (а не из-за реальной потребности).
Пишешь вот ты какой-то процесс который потом будет крутиться на 5 миллионах серверов. Но ты решил использовать Python из-за чего процесс жрёт гораздо больше CPU и RAM чем требуется. А теперь просто попробуйте оценить в деньгах 0.1% одного ядра subtop-ового CPU и 100MB RAM умноженнык на 5 миллионов.Ну или другой вариант: вот пишешь ты фотохостинг на Python, а он внезапно оказывается популярным, и переписывать уже поздно. И потребляет это всё миллион subtop-овых серверов, когда вполне могло и 50к потреблять. Тоже попробуйте примерно в деньгах посчитать.
Ну вот кстати да. Когда проект уровня локалхоста с полутора пользователями - там бенчмарк особо не критичен.
Когда начинается масштабирование - очень быстро приплываешь в узкие места.
А всего-то надо посчитать, что дешевле: платить за хостинг или переписать софт. Как вариант, на другой ЯПНо виноват всё равно, конечно же, питон или там фреймворк. Просто ну не себя же объявлять виноватыми, что выбрали не тот инструмент
Питон очень экономен по отношению к памяти. По скорости - он типичный представитель своего семейства. Но по памяти - очень хорош, не сравнимо даже близко с Жабкой или Хаскелюшечкой
Для меня всегда було удивительно, чому все эти популярные веб приложения на триллиарды денег пишут на фигне для хуомпейджей и продающих одностраничков? А потом старателдьно превозмогают, всесто написания с нуля на нечто правильном.Неужели труд С-макаки НАСТОЛЬКО будет дороже, чем стоимость инфраструктуры? Ну не С так что там нынчно модно, но по-прежнему шустро? D/GO/whatever
Если сравнить рубю с лиспом, выиграет лисп, если ты не из дружной команды рубистов Днепропетровска.
Проблема питона не только в скорости. У него ещё и весьма громоздкий и плохо читаемый код получается. И, как следствие, довольно высокая стоимость сопровождения сколь-нибудь сложных проектов. Старые концепты никуда не спрячешь....
Фортран-программу можно написать на _любом_ языке.
на _любом_ языке есть комассивы и параллельные циклы?
Вот уж насчёт громоздкости и читаемости всё как раз с точностью до наоборотРазве что если под "громоздкостью" мсье понимает осмысленные и потому длинные названия идентификаторов. Ах, ну да, ещё ж в питоне не рекомендуется писать несколько операций в одной строчке
> Разве что если под "громоздкостью" мсье понимает осмысленные и потому длинные названия идентификаторов. Ах, ну да, ещё ж в питоне не рекомендуется писать несколько операций в одной строчкеДа как ни считай, эквивалентный код на питоне больше и по строками, и по операторам, чем у Ruby, Julia, Haskell и пр. более свежих языков. При этом ещё и по скорости проигрывает большинству современных языков.
Разница размера кода в килобайты реально может кому-то помешать в век терабайтных винтов и гигасов оперативки?На вкус и цвет фломастеры разные. Лично мне вот легче читать "раздутый" питонячий код, нежели "компактный" сишный/перловый/жабий/пхпшный/etc. Возможно, тут как раз есть какой-то персональный баланс лёгкости восприятия с учётом кол-ва мысли на строчку и килобайт текста
Но ведь, к примеру, обычный текст с абзацами и отступами при равном кол-ве знаков легче же читается, чем сплошным куском, хотя строк получается и больше
Ты просто привык. Испортил себе мозги, заточив их под объективно плохой питонячий синтаксис.
>Зачем делать из хлеба троллейбус ещё и с эмблемой мелкософта...Ну надо же ван Россуму что-то жрать на старости лет, ты думаешь, он просто так GIL не выпиливал? Это он себе, родимому, план на старость готовил по обеспечению себя работой.
Не верю. Никаких в 5 раз быстрее точно не будет. И в 2 тоже. Смотря как считать, конечно.
Реальный код будет ускорен на какие-нибудь проценты. Что конечно тоже очень хорошо.
Главное, что начали признавать проблему. Все время отмахивались, что нет разницы, сколько работает питон, типа это клей между сишным кодом. А тут зашевелились, смотри-ка.
JIT реально обычно на простые вычисления даёт прирост примерно в 5 раз
По аналогии с луа - для использования джита код нужно писать избегая плохо оптимизированных вещей. Так что для существующих кодов и большинства новых прирост производительности будет скромным.
Вы не поняли. Даже "i++" в JIT выполняется в разы быстрее.
Есть одна накладка. Чтобы i++ под JIT выполнялся в разы быстрее - его нужно из цикла несколько тысяч раз позвать. А так - да, JIT зовёт уже машинный код, без интерпретации.
Ну попробуйте, например, число факторизировать с JIT и без.
Они там numba изобретают? Так есть уже. А вот про изничтожение GIL опять ничего.
А как же numpy и numba? Они про уничтожение GIL как раз
> А как же numpy и numba? Они про уничтожение GIL как разCython про "уничтожение GIL", собственно в любом много-тредовом приложении стоит использовать сишные батарейки по максимуму (из-за освобождаемого гила они позволяют выжать куда больше). Субинтерпретаторы тоже про "уничтожение GIL", большая проблема на самом деле GC и субинтерпретаторы вроде бы позволяют её хоть как-то решить.
Ну убирание гила само по себе как таковое ничего хорошего не принесёт. Хренова куча кода поломается, а хренова куча программеров перестанет понимать, почему. Щаз можно более или менее спокойнёхонько юзать threads и, в общем, это достаточно приятная возможность. Скажем так, адекватная плата за отсутствие параллельного исполнения. Грамотно писать на тредах - отдельный вид искусства
Пришел на Питон недавно, и пока не могу понять, что такого _упрощает_ GIL: автор, подскажи, плиз!
Ведь Питон не дает гарантии атомарности выполнения операций: иными словами, даже a=b может быть разорвано посередине между 2мя тредами питона (прочитали b, переключились на другой тред, потом вернулись и присвоили a).
А в чем тогда плюсы, где простота? Все равно все через мьюьексы и кондишены делать, если у тебя многопоточность.
Отличные новости ^_^
Питон это наверное самый вредный из всех существующих языков. Раньше его чуть ли не обожествлял, а сейчас вижу в нем одни недостатки.
Насколько раньше? Времён 2, или 1? Мне он начал нравится в 3 примерно с тех пор как дататипы и тайпхинты перетащили в него, примерно в то же время async/await добавили. Стало намного лучше в целом, из-за сохранения поддержки 2 ветки он лет 10 стагнировал.
> Питон это наверное самый вредныйхех... куда бы мы делись без вашей оценки...
на самом деле -> питон - это крутой язык, написанный хорошим программистом для других хороших программистов. если что, то это я почти дословно цитирую фразу Гвидо из одной его лекции. питон покрывает колоссальное количество задач, используется от мелких кодиков и веба до прототипирования больших промышленных проектов корпоративного уровня. профи пишут на нём со скоростью мысли, перенося необходимые куски на нижние уровни (с++ и тп).
а вредными языками являются такие языки, как, например, си. почему я так считаю? си - великолепный! и прекрасный язык, но, зачастую, работают с ним __бездари__, не обладающие необходимой квалификацией и без должной теоретической подготовки, что часто на выходе приводит к катастрофам. таких горе-си кодеров я повидал за свою жизнь горы... пусть идут в яву... до си ещё нужно дорасти. от си, от асма нубов малоквалифицированных следует держать подальше - для них есть котлины, явы, го-ланги, расты.
> но, зачастую, работают с ним __бездари__, не обладающие необходимой квалификациейНу такие люди просто везде есть. Разгребал yблюдство на python год назад -- вот уж где талант был простые вещи решать сложно))
Доводилось видетьclass Struct
С переизобретением половины dict'а.
Только это не проблема языка.
> Только это не проблема языка.Так я о том же. Язык то прекрасен
До Си в принципе невозможно дорасти, даже самый опытный разработчик будет ошибаться. Вот только цена его ошибки - миллионы долларов. А чего ещё ждать от языка чуть выше уровнем, чем ассемблер?
А вот Раст хорош тем, что позволяет сосредоточиться на задаче, а не постоянно думать о памяти или UB, при этом имея тонну фишек, которых в C не будет никогда.
Офигенный язык, мой любимый с некоторых пор. По мне, самое главное достоинство - программы на нём можно писать гораздо более читабельные, чем на других ЯП-ах. Компактность не в ущерб, а на пользуНе в том, конечно, смысле, что нельзя написать криво, а в том, что есть возможность писать прямо
Похож в этом смысле на паскаль, но ещё более читабельный
>можно писать гораздо более читабельныеТы просто не видел мой код. Насколько я знаю, такой код (генераторы, включения, функциональщина) является идиоматически очень корректным для питона, а бонусом он ещё и примерно максимально быстрый -- т.е. не лапша из циклов и условных операторов, но вот читаемо это только для тех кто хорошо понимает питон (время действительно экономит, да). От паскаля это всё бесконечно далеко (ну или я плохо знаком с паскалем).
> Ты просто не видел мой кодКак-то претенциозно прозвучало
Я иногда задумываюсь о том, что нормальный эффективный питон может быть максимально нечитаемый с точки зрения людей не особо привыкших к нему. Flake8 и pylint указывают на ошибки форматирования, но читаемость они особо не повышают а скорее и понижают. Но, с другой стороны, других языков с такими приятными конструкциями и столь не перегруженным синтакисом я не знаю.
Можно сравнить с хаскелем.
Майн-функция из исходников пандока:
module Main where
import qualified Control.Exception as E
import Text.Pandoc.App (convertWithOpts, defaultOpts, options, parseOptions)
import Text.Pandoc.Error (handleError)main :: IO ()
main = E.catch (parseOptions options defaultOpts >>= convertWithOpts)
(handleError . Left)
Да не, претенциозно прозвучало, что твой код какой-то там особенно крутой.Topcoder, mazafaka, you know who I am.
I write code so sweet that you think it's jam.
(с) одна песня
Вообще, я имел в виду, что написанное мной бывает сложно прочитать даже мне, и не от хорошей жизни приходится писать менее очевидно. Т.е. нужно именно читать разбираясь что и где происходит -- пробежаться взглядом недостаточно.
>и столь не перегруженным синтакисомОперление началось с 3.5, = vs := доказывает, что перл они таки перегонят, потому что в timtowtdi была хотя бы крупица смысла, а здесь роспись в идио(ма)тизме.
Только := позволяет выкинуть десятки дополнительных операций и аккуратно локализовать присвоение, и ткакая запись даже повышает читаемость. Начиная с 3.8 (3.9, 3.10) принялись добавлять улучшения синтаксиса, которые давно надо было добавить (я больше про | чем про match).
Простой язык прост во всём, язык без мозгов в голове будет набирать синтаксический мусор.
= как expression был бы проще двух типов присваиваний.
Дело в том, что := (во всяком случае на данный момент) не является присваиванием в том смысле, в котором является присваиванием =. Ну они сначала ввели f-строки, и только потом взялись за присваивание… Я бы предпочёл, если бы присваивать можно было и в строках (сейчас присваивание в таких случаях приходится делать в format() что не очень хорошо выглядит). Бтв, питон никогда не был простым.
>Ну они сначала ввели f-строкиЕщё одно оперление. Мы кичились тем, что у нас ЧИТАЕМОСТЬ и НЕКАКУПЕРЛА, а потом украли ${} в строках.
>Дело в том, что := (во всяком случае на данный момент) не является присваиванием в том смысле, в котором является присваиванием =.Дело в том, что = как expression есть во всех вменяемых языках и только невменяемый клепатель GIL-ов решил, что оно кому-то там вредит. Потом понял свою ошибку, но только решил её не вменяемым способом (сменить в 3.0 смысл), а решил добавить горочку синтаксического мусора в и так убогий интерпретатор.
>Я бы предпочёл, если бы присваивать можно было и в строкахЯ думаю, ты готов для перла.
>Бтв, питон никогда не был простым.Берём и выкидываем the zen of python и прочую замануху для вайтишников, стучим Марку Лутцу по кумполу. Почему ещё не выкинули весь этот ворох айтишной пропаганды?
> других языков с такими приятными конструкциями и столь не перегруженным синтакисом я не знаюОх... Вот что я навспоминал только навскидку:
"Приятные" конструкции:* Тернарный оператор, непохожий на свои аналоги в других языках:
x = a if True else b
вместо обычного порядка типа
x = True ? a : b
или
x = if True then a else b* Оператор if не возвращает значение, в отличие от Ruby и Scala. Собственно, если бы возвращал - не пришлось бы городить вышеоупомянутый экзотический тернарный оператор.
* Вообще нету оператора switch, тем более возвращающего значение.
* Оператор while может иметь ветвь else. Ну, чтоб читающие код не расслаблялись, а пошевелили немного извилиной на предмет "что за фигня?"
* Упор в языке на list/dict comprehension. Для простых выражений - замечательная вещь, но когда нужна вложенность, лучше не использовать, ФП-подход в других языках выглядит гораздо читабельнее.
* Очень слабая поддержка ФП. Cлабые lambda, map, filter и reduce (и назван не fold). Отсутствуют flatMap, Option/Optional/Maybe, Either, pattern matching with deconstruction.
"Неперегруженный" синтаксис:* Регулярные выражения в стандартной библиотеке, а не в синтаксисе языка, как в Perl и Ruby. В результате надо писать re.search("\\d", s) вместо s =~ /\d/. А если надо сматчить сабгруппы - синтаксис становится ещё тяжелее, никаких тебе $1 после выражения. re.sub() по умолчанию работает как gsub() в других языках. re.gsub() вообще нету. Ну, надо же быть максимально непохожим на другие языки, чтобы программист всё время путался, переходя между языками.
* В куче мест нужно писать self. Особенно напрягает обязательность его как первого аргумента метода класса. Надо писать либо self, либо @staticmethod/@classmethod. Вот уж где "explicit is better than implicit", доведённый до маразма. Ни в одном языке такого нет. И не забудьте этот же self добавлять при вызове методов! Особенно "удобно" коллекцию свободных функций собирать в класс и добавлять "self." в начало их вызова, да ещё без проверки в compile time.
* После условий в if и while, после for, после описания класса или функции, перед переводом строки - надо ставить двоеточие в конце строки, перед телом цикла, функции или класса. Зачем??? Синтаксис языка и так зависит от whitespace и переводов строки! Убрали же необходимость точки с запятой в конце строк!
* Нету неявного return в конце функции, как, например в Ruby, Scala, Lisp, Haskell, etc. Соответственно надо писать
def sum(a, b):
return a + bвместо
def sum(a, b)
a + bили
def sum(a, b) = a + b
А если эта функция ещё и член класса - придётся добавить self/@staticmethod/@classmethod.
Так, ты перечислил достоинства питона. А минусы у него какие? По поводу ссылки на инстанс (я вижу что тебя это прям беспокоит), как по мне, это куда лучше и прозрачнее руби с его собачками -- есть явное разделение привязки к классу, к объекту, или к методу. Без accidental пересечений скопов. Остальное что-то совсем уж вкусовщина.
Нормальный такой ответ, главное - очень аргументированный
> Нормальный такой ответ, главное - очень аргументированныйЯ могу ответить детально по каждому пункту, но зачем? Я просто не согласен с твоей предвзятой позицией. Даже если мне что-то и не нравится в синтаксисе и возможностях питона, я понимаю и принимаю аргументацию, которой обосновывают те или иные решения. Не нравится -- берите любой другой язык.
> Даже если мне что-то и не нравится в синтаксисе и возможностях питона, я понимаю и принимаю аргументацию, которой обосновывают те или иные решения.Ну вот, это уже взвешенная позиция. А то такой уж поток восхвалений Питона от тебя шёл, как будто в Питоне и синтаксис идеальный, и никаких недостатков нету. Хоть ты этого прямо не говорил, но впечатление такое сложилось.
> Я просто не согласен с твоей предвзятой позицией.
Согласен, предвзято получилось. Спасибо что ты вывел разговор из "воронки троллинга".
>Отсутствуют flatMap, Option/Optional/Maybe, EitherУ вас там хаскель протёк, попишите на других языках.
Улыбнуло, спасибо :)
с некоторых пор я лично стал думать что функциональный стиль - чаще есть плохо, чем хорошо. Легко сделать нечитабельный mashcore. Хотя и работать часто будет быстрее.
функциональный стиль в питоне - просто маркетинг. В современных языках программирования - это хорошо.
ФП стиль в python -- это таки хорошо, когда применено к месту
ФП в python отлично сочетается с пайплайнами
Забавный парадокс: map, filter или reduce функции запросто могут быть методами классов (фабричными или обычными -- зависит от случая). Смешивать ООП и ФП тоже вкусно, только их надо уметь готовить
>функциональщинаNon-pythonic, на грани deprecated. Ты функциональщины настоящей не видел, в языке с куцыми лямбдами говорить про идио(ма)тизм.
Не выдумывай. Вот лямбды в питоне действительно использовать не стоит: они, во-первых, понижают читаемость, а во-вторых, тормозят. Мне нравится elixir, например, это никак не мешает мне отказываться от неэффективной лапши в питоне (хоть читаемость и страдает всё равно).
>они, во-первых, понижают читаемостьДа-да, понижают, особенно если у тебя в язык они в принципе не входят, потому что язык нестройный.
В лиспе с лямбдами всё сделано прекрасно.
>а во-вторых, тормозятВ питоне вообще всё тормозит.
ИЧСХ, ты сам полез доказывать, что функциональщину в питоне сделали для галочки.
Только один фюрер, да?
Не понял.
Других вариантов функциональщины быть не может?
Таких куцых - не может. Я писал не на одном ФП-языке и знаю, что говорю.
Как пример куцости можно те же лямбды привести (вот те самые, которыерядовые пистонисты не любят и хотят выпилить, но пока не подвернулся случай) и выпил из стандартного неймспейса fold в трёшке вместе с угробленным map "по-хаскелевски", при том, что map в хаскеле таков, потому что такой рантайм.
Про отсутствующую оптимизацию TCO и другие функциональные оптимизации/фичи уже можно не говорить.
Функциональщина, как теперь понимаю, это больше про стиль, чем про ЯП. В принципе-то, на любом языке можно писать функционально. Просто асилить как следует про чистые функции и функции с побочными эффектамиНу а чистая функциональщина как самоцель - это, безусловно, суперский повод писать абсолютно нечитаемый код, используя over9000 вложенных скобок. И заодно делать код, который тормозит хз почему и хз где сжирает всю память, потому что хз где и как разворачиваются ленивые вычисления
Кароч, всего должно быть в меру. В питоне мера покамест более или менее соблюдается
Ну я имел в виду, что питон и паскаль где-то рядом стоят по ограничениям, имеющим целью понятность кода. Вот на си-подобных гораздо легче написать невразумительную кашу, а тут всё-таки посложнее. Одно только отсутствие там и там ++/-- уже и то офигенный плюс к понятностиПисал на дельфях в своё время и раньше паскаль считал самым читабельным языком. Теперь питон - мой любимец в этом плане. Да и мысли как-то на нём легче выражаются. Раньше на эту тему любил перл, но, ска, на нём вообще хрен напишешь так, чтобы хотя бы самому потом прочитать. Но по лаконичности, конечно, он чуть ли не всех переплюнет
Наверное, можно сказать, что любовь к питону - это следствие проф деформации от паскаля) Но некоторых возможностей перла немножко не хватает. А вот про паскаль такого сказать не могу. Но большое спасибо ему за муштру. Да и объекты в паскале и питоне почти что одинаковые
На васик похож.Никакой возможности писать прямо нет. Есть возможность писать тупо. Без ФП, на одних стейтментах и с плохоньким ООП без раскидывания методов. Всё, что выходит за рамки такого подхода (васик-стайл), рано или поздно будет либо тормозить, либо non-pythonic.
Pythonic - это про читабельность кода. Способы писать так, чтобы потом можно было разобрать хотя бы что вообще написано, а в идеале ещё и понять, как оно работаетПод это заточены многие странные, казалось бы, ограничения и рекомендации
то что они планируют в 3.11 было сделано в php7, а 3.12/3.13 в php8
так что до уровня php им еще пахать и пахать ;)
Но лучше не надо
ну вот, определен идеал, на который можно ориентироваться - PHP
PHP ныне очень хорош как прикладной язык для обработки данных.
Да, системное программирование на нём невозможно, нет указателей и прямого доступа к памяти.
Да, нет API для гуя - предполагается browser-based UI.
Но всё остальное на месте.
PHP единственный нормальный язык из оставшихся, не считая крестов и сей который не пытается быть универсально бесплолезным
рождённый ползать - летать не может.
зато если рожденный ползать поймает хоть орла, хоть лошадь, он их переварит вместе с клювом и копытами
В отдельных случаях удается поймать (и переварить) даже жабу))
на ракете полетит
Иксперты опеннета хоронят питон, спешите видеть.
Зачем же? Просто ржут с убогих...
А что принципиально мешает сделать новый Python из Swift?
Apple.
Вроде же, как минимум, частично отпустили. И в ML где-то применяется
Ruby для 3 версии пообещали сделали трехкратный прирост в скорости по сравнению со второй веткой.
Python всего чуть
ну один тоже помнится обещал хайвеи от Лиссабона до Владивостока, станцию на Луне и обгон экономики Португалии. Просто один реалисты, другие - трепачи брехливые
Решили таки спастить pypy в мастер?
Pyston и Cinder тоже прикручивают JIT, но, видимо, делают это не так как надо...
Не за те деньги, слишком для диктатора маленькие. Пришлось целый МС нанимать.
Интересно, сколько ему надо заплатить, чтобы выпилил GIL? Хватит ли MS и гугли?
MS хватит, чтобы скупить всех опенсорсных бомжей, но зачем? Существование кривого linux, только усиливает позиции винды
Настолько усиливает, что Microsoft продули позиции на мобильном и серверном рынке.
Скажу честно - не верю. Но желаю удачи. Python слишком медленный. У него просадка по производительности в 30 раз от C/С++ кода. Это очень-очень-очень много.Наверное единственный язык, который приблизился к С из высокоуровневых - это Java. Но JS на пятки наступает.
А самый быстрый и интересный язык - Zig
> Python слишком медленный. У него просадка по производительности в 30 раз от C/С++ кода.Так это как раз значит, что есть куда оптимизировать!
>А самый быстрый и интересный язык - ZigБыстрый? Да.
Интересный? Нет.
Вы слишком рано похоронили Хаскель и прочие функциональные языки.
В некоторых ленивых алгоритмах Хаскель даже Си уделывает и легко соперничает в тяжеловесных абстракциях с C++. Всё-таки STG-машина довольно крутая вещь.
Но основная фишка функциональных языков: на ней проще писать правильные программы, которые не будут баговать и падать каждый день с ошибками. Это не значит, что тамс нельзя написать такую, это значит, что при прочих равных ты потратишь меньше сил на отладку и, значит, больше можешь улучшить производительность.
Ждём развития девятой ветки GHC, где должны добавить больше способов доказать поведение программы в рантайме.
Черт с ним, с Хаскелем, это уже старенький язык, где куча проблем с типами, а стандартный тип String -- это ужас с точки зрения производительности, так как односвязные списки тормозят.Вот koka
https://github.com/koka-lang/kokaИсследовательский язык, который на равных соперничает с си.
koka-lang лучше конечно/мимо Захарова, функционально-ориентированная Хаскелистка
Смотрю на скрин кода.
>effect yield<a>Угадайте, как я это прочитал.
Zig - это в первую очередь настоящая качественная альтернатива C. И замена C++ / Rust.Можно управлять памятью как в С - alignment, packing. Нет runtime вообще никакого. Нет привязки к libc. У них своя библиотека, с нуля написанная.
Нет "стандартных аллокаторов". Можно выбирать разные аллокаторы для разных функций.
Нет exception. Ошибки возвращаются из функции в виде Option (с обязательной проверкой).
Нет деструкторов.
Нельзя даже вызвать функцию без присваивания результата переменной.
Нет переполнения целых чисел. Помимо типов безопасность обеспечивают runtime проверки всего и вся.
Шаблонное программирование на этом же языке, как я понял. Что очень круто.
Compile time программирование.
Типы - это first class citizen (в compile time).
Есть Pattern matching.
Возможна вставка ассемблера.Нет variable name shadow (одна переменная перекрывает другую с таким же названием в scope выше) - ты всегда знаешь что эта переменная делает.
for loop, if, while, switch - являются выражениями и возвращают значение.
Поэтому это ещё вопрос что считать функциональным ЯП. У Zig есть много элементов ФП, без ущерба производительности
Haskell и тп. никак не замена. Для высокопроизводительного программирования нужно быть ближе к железу. Все эти ненужные абстракции текут (как в С++).
Real time не напишешь. Ядро не напишешь. Высокопроизводительные алгоритмы, с учётом кэша профессора не напишешь. И т.д..
Вот только без сообщества язык обречен, а ниша активно развивающегося языка, который заинтересовал в частности и корпорации, уже занята Растом.
Может, лет через 10 чего-то будет. Но велик шанс, что, подробно D, он так и не раскроет себя.
Хрустом сейчас занята ниша для хайпожоров. В своё время так же хайпили ruby, потом оно благополучно легло на рельсы и сдохнуло. После хруста будет ещё что-то, всерьёз эти поделки воспринимать трудно.
Нет. Если Руби - это непонятное нечто по скорости +- на уровне Питона (всё плохо), то Раст стал действительно интересным решением с хорошими фишками. После него C/C++ (мне, как C++ dev'у, да) всерьёз воспринимать трудно - один сплошной lefacy unsafe, пытающийся косить под modern (в случае с C++).
Возможно, после Раста что-то и будет в будущем, но вряд ли Zig.
>мне, как C++ dev'у, даИ когда это C++ dev-ы начали обожать язычки одной реализации с централизованным хранением лефтпадов?
Одна реализация -- это кайф после многобожества мира C++
4 основных компилятора! GCC, Clang, Apple Clang, MSVC, каждый в собственной мере и долго реализует актуальный стандарт.
Да это одна из причин любить Раст. Один компилятор -- счастье после такого разброда.Централизованное хранилище либ -- тоже хорошо: нет разброса, всё в одном месте. И то чего очень не хватает в C++: не выложил либу в реп = не выложил либу.
Помимо этого, одна из основных болей C++ -- это как раз работа с либами. Иронично, но в Расте проблемы со сборкой бывают в основном из-за биндингов либ C/C++, что о многом говорит :)
Руби + раст = рубираст.
Один раст - не рубираст.
У нас этот язык не запретят?
> Нет runtime вообще никакого.
> Нет переполнения целых чисел. Помимо типов безопасность обеспечивают runtime проверки всего и вся.Противоречие.
>> Нет runtime вообще никакого.
>> Нет переполнения целых чисел. Помимо типов безопасность обеспечивают runtime проверки всего и вся.
> Противоречие.Неа.
проверка в runtime (время исполнения), которой не нужен "runtime environment" (окружение/либа):
(псевдокод из пальца)
if(add_with_overflow_check(x,y,result)) { overflow error handling}
profit(42, result);
.
.
.
add eax, ebx
jno no_error
... error handling ...
no_error:
...
https://en.wikipedia.org/wiki/Status_register#Common_flags
> Но основная фишка функциональных языков: на ней проще писать правильные программы, которые не будут баговать и падать каждый день с ошибками.почему в Хаскель компиляторе и либах, да и в тулах такое большое количество ошибок? Даже RTS падает порой в кору. А ЛиквидХаскель - одна огромная ошибка. Что мешает в Хаскеле писать код с меньшим числом багов?
А Go насколько приблизился? Или он не особо высокоуровнем считается?
Я обычно пишу про что знаю))) О Go я практически ничего не знаю.Поэтому и пропустил его.
> Я обычно пишу про что знаю))) О Go я практически ничего не
> знаю.
> Поэтому и пропустил его.Достойная позиция, без сарказма, а что касается бенчмарков си против джава.
Лет 20 назад, в 2002, уже была новость про ханойские башни, квиксорт и что-то третье, что джава по цифрам практически (плюс минус) сравнялась с си, однако, вот поди ж ты.
Java не то что к C, к C++ и близко не приблизился, таких тормозов как в приложениях на Java нет пожалуй нигде... и не надо ляля про прогрев виртуальной машины и прочий бред, прогревай не прогревай а оно как тормозило так и тормозит
> Java не то что к C, к C++ и близко не приблизился,
> таких тормозов как в приложениях на Java нет пожалуй нигде... и
> не надо ляля про прогрев виртуальной машины и прочий бред, прогревай
> не прогревай а оно как тормозило так и тормозитВ реальном мире скидку за оверхед тоже не всегда удается получить.
И память жрёт как не в себя.
с GIL разобрались бы. Ява же шмогла.
Накроеться весь мир полным тазом. Там на GIL многое повешено.
Начиная от внешних библиотек. Заканчивая синхронизацией переменных.
Значит сразу надо предлагать распаралеливание а кроме глючного asncio ничего не предложить Python.
Выкинули б свои доморощенные bigint - с GMP было б быстрее не в 5 раз, а на порядки.
>достигнуть двукратного увеличения производительности в CPython 3.11Потребление памяти тоже удвоится?
Разумеется. Статку-то надо где-то хранить. За всё надо платит ьв этом мире. Как только речь заходит за деньги -- чудеса гарантированно заканчиваются.
"Просто докупите памяти."
На толстых микроконтроллерах избыток флеш и ОЗУ очень даже хорошо конвертируется в быстродействие.
А по теме.. Выбираете любые два параметра из трёх: несовместимость, жор памяти, быстродействие.
> Проектом [...] занимается [...] команда [...] из компании MicrosoftПропал калабуховский дом ©
Подскажите, для обычного юзера радость от этого всего будет? :) ну там emerge\portage бодрее забегают? (Хотя по сравнению с собссно компиляцией это наверное не так уж и долго...?)
Опыт внедрения JIT в PHP показывает, что вряд ли это будет "двукратный" прирост. Хотя с другой стороны в PHP всё опирается на сишные либы, а в пистоне принято велосипедить - может и да, будет посущественнее.
Python здорового человека уже есть: https://github.com/kuroko-lang/kuroko
Вместо того чтобы писать программы на простом, быстром и надёжном как швейцарские часы ANSI C, они пытаются ускорить язык для не умеющих за собой убирать и не понимающих как работает компютер
Сколько строк кода на Си вышло из под твоего пера?
Просто на проектах с тысячами строк кода рефакторинги большая боль.
А если еще учесть что в Си хреновенько с модулями и частичной пересборкой,
то задача становиться крайне сложной на ровном месте.
> язык для не умеющих за собой убирать"Умеющие убирать" до сих пор делают это ручками, как тетя Маша? Ну-ну...
Писатель бложиков на С выглядит тупее писателя драйверов на Питоне.
тык, CPython на чистом совершенстве и написан
Глядя на PEP-7 для этого совершенства, начинаешь сомневаться во вменяемости написавших и PEP-7, и это совершенство.
Написанное на идеальном, не обязательно должно быть идеальным.
Опечатался: начинаешь сомневаться во вменяемости тех, кто написал стайлгайд PEP-7 и тех, кто под этим стайлгайдом писал код.
Это у тебя окуляр сбился
> ANSI CСейчас что, 70е годы?
Jit это назад к истокам к java
CPython это - виртуальная машина.
Про D когда новости будут?
Когда напишешь, тогда и будут. Я б, кстати, тоже с удовольствием почитал быб.
байки из склепа?
из мавзолея
> добиться увеличения производительности в два раза
> поднять производительность в пять разНапоминает социалистические обязательства поднять надои в пять раз от одной коровы...
> добиться этого результата в выпуске Python 3.13... к 75-й годовщине Великой Октябрьской Социалистической Революции.
> Напоминает социалистические обязательстваТак ведь их - выполняли.
> ... к 75-й годовщине Великой Октябрьской Социалистической Революции.
А вы против Великой Октябрьской Социалистической Революции?
> Так ведь их - выполняли.Это не всегда хорошо, вообще-то. Умозрительный пример: швейная фабрика, один цех делает левые штанины, другой - правые, третий сшивает их вместе. План - 1000 штанов в месяц. Первый цех перевыполнил план и пошил дополнительно 100 левых штанин. Второму ткани не хватило, в результате фабрика пошила 900 штанов. Кто виноват? Начальник второго цеха (подвели передовиков из первого) и директор фабрики (не обеспечил, хотя фонды на ткань распределены заранее, но это никого не волнует). А реальный примеров было полно. Например, колхоз сдал государству N тонн овощей сверх плана. Места на овощебазе под них нет, всё сгниёт (ну, то есть, немножечко сгниёт, для акта, а остальное будет пущено налево). Но председателю колхоза плевать, он своё переходящее Красное Знамя за победу в соцсоревновании получил. Кст, можно вспомнить анекдот про укорочение грифеля в карандаше.
> А вы против Великой Октябрьской Социалистической Революции?Я против профанации в любой форме, в том числе в виде приурочивания чего-то там к 7 ноября. А к самой Великой Октябрьской Социалистической Революции у меня отношение сложное, но в детали я вдаваться не буду, чтобы не разжигать оффтопиковый флейм.
> Умозрительный пример: швейная фабрика, один цех делает левые штанины, другой - правые, третий сшивает их вместе. План - 1000 штанов в месяц. Первый цех перевыполнил план и пошил дополнительно 100 левых штанин. Второму ткани не хватило, в результате фабрика пошила 900 штанов. Кто виноват?Глупый пример. Плановики не учли данных соцобезательств, вот и все.
> Я против профанации в любой форме, в том числе в виде приурочивания чего-то там к 7 ноября.
А в чем тут профанация? Ты же не против поздравлений на ДР? А это стоит людям времени и ресурсов...
> разработчики надеются добиться увеличения производительности в два раза.Похоже на поздний социализм и, в частности, на планирование "от достигнутого". Понятно, что "надои молока", "выработка чугуна" и т.п. больше зависят от физически-обусловленных величин (размер коровы, скорость метаболизма, объём доменной печи, энергоёмкость окислительно-восстановительных реакций и т.п.), чем от воли оператора.
Планирование "от достигнутого" привело к непрерывному снижению качества продукции в масштабах страны: молоко, сметану разбавляли, высоту потолков, толщину стен и перекрытий в жилых домах уменьшали и т.д.
Планирование от достигнутого во многом способствовало развалу СССР.
> Умозрительный пример: швейная фабрика, один цех делает левые штанины, другой - правые, третий сшивает их вместе.
"Умозрительный пример" так же далёк от реального производства, основанного на планировании ТЭП, как производительность "интерпретатора байт-кода" (CPython) далека от производительности ЦПУ, выполняющего нативный код "интерпретатора байт-кода".
> Я против профанации в любой форме < ... >
Игнор базовых понятий ("технологическая операция", "технологический участок", "технологическая линия" и т.д) приводит к несчастью. Ибо ( "Игнор базовых понятий" == "Профанация" ). Последнее - введение в заблуждение через искажение реальности.
Реальность жестока к тем, кто её искажает.imho
> Похоже на поздний социализм и, в частности, на планирование "от достигнутого".Хуже. Похоже на модно-молодежные сказки про поздний социализм.
> Планирование "от достигнутого" привело к непрерывному снижению качества продукции в масштабах
> страны: молоко, сметану разбавляли, высоту потолков, толщину стен и перекрытий в
> жилых домах уменьшали и т.д.Не, это больше про рентабельность, хозрасчет и проч. ростки прекрасного капиталистического завтра, которые запилил Хрущев и ко.
У меня ощущения что в питоне все можно ускорить в 100тни раз.
Тот же цикл от 0 до 10_000 выполняется 0.042 секунде на моем компе,
а на ассебмлере он может выполняться в 15_000 раз быстрее.
Чтобы все ускорить, нужно убрать из питона собственно питон.
Взять тот же луа. Язык простой как палка, джит прикручивается легко - всё летает.
Или жс. Язык опять же простой - с оптимизациями всё летает.
Но не таков наш питон. Или руби - там напихано еще больше и они еще медленнее.
Но с другой стороны, есть пример перла - язык вроде сложный, но все равно быстрее питона - потому что в процессе разработки перла о производительности думали всегда.Выкинуть половину и оставшееся ускорить - уже есть руру и куча подобных проектов.
> Или жс. Язык опять же простой - с оптимизациями всё летает.
> ...
> Выкинуть половину и оставшееся ускорить - уже есть руру и куча подобных
> проектов.Давай ссылку с бенчами на "летающую", оптимизованную реализацию не за сотню миллионов (гугл с мозиллой), оналитек хренов.
нутк пиши на ассемблере, что ты мучаешься
Это что ж за комп такой? 386-й, небось? Тогда, наверное, пришла пора поапгрейдитьсяНу или, как вариант, учиться на питоне крутить правильные циклы. А правильно их крутят через range() и локальные переменные. Или через подчёркивание (for _ in range), если нужно только кол-во циклов, так будет на 0,5 мс быстрее
# === шибко сикретный код, после прочтения съесть ===
from time import timedef aa():
t0 = time()
for i in range(1_000_000):
pass
t1 = time()
print(t1 - t0)
aa()
# === канец сикретного кода, теперь съеш меняРезультат: 0.015542268753051758
Скорость не поражает воображение, но всё же в 300 раз быстрее
Почему Гуглу с JS удалось сделать, а Гвидо до сих пор никак?
> Почему Гуглу с JS удалось сделать, а Гвидо до сих пор никак?Наверное, потому что гугл вкачал в браузерный движок не одну сотню миллионов?
Ну бабки у МС есть...
> Ну бабки у МС есть...Но бабки МС и Гвидо существовали до этого в разных "плоскостях".
И какой-то сильной мотивации улучшать реализацию питона у МС, в отличие от гугла-мозиллы, не было (да вроде бы особо и нет - по крайней мере, сравнимым с гугловским "мы вырвемся в топ браузеров! А еще сможем переложить рендеринг страниц наших сервисов на клиента и экономить на железе-электричестве!").
Че-то как-то стремно - ребята им майкрософт приложат ручки, и ...
Патчи из Миннесоты роднее?
> Патчи из Миннесоты роднее?Миннесота пришла на чужую вечеринку и попыталась плюнуть в бочку с общим бухлом. А Микрософт у себя дома. Это его бухло и он может даже [censored] туда. А вы, хотите -- пейте, не хотите -- нет.
Основное отличие linux от windows, это то что в винде бэкдоры фирменные мягкие, а линуксе от хрен пойми кого, вплоть до хацкеров
Если приложат ручки так же, как к R или C#, то мы все от этого только выиграем
>Проектом по оптимизации CPython занимается небольшая команда разработчиков из компании MicrosoftПитонокапец
Скрестят с Поршелем.
Поршель с питона и делали. Мерж сделать только.
надо было на rust переписать, вот тогда производительность повысится
https://pybenchmarks.org/u64q/rustpython.php
Компания Google не смогла, сдалась. В этот раз всё будет иначе?
> Компания Google не смогла, сдалась.Да-да, всей компанией пытались, миллиарды триллионов тратили (а не просто пару месяцев тройку разработчиков спонсировал, благополучно после этого забив на результат).
она разве пыталась? есть же go у них
>Проектом по оптимизации CPython занимается небольшая команда разработчиков из компании Microsoft, в которую недавно перешёл на работу Гвидо.Срочно! Скажите Гвидону, что с Майкрософт связываться нельзя. Это проклятая компания!
А что там с Мигелем Де Иказа? Он, помнится, тоже связался.
Мигелюшка достиг своей цели, здела таки дотнет кроссплатформенным, а чего добился ты?
Так сделал, что до сих пор программы на втором-четвертом старом дотнете не запускаются. Не говоря про дыру в виде C++/CLI.
Различай стандартную либу дотнета и фреймворки винды, которые в дотнет ну никак не входят
Для сравнения, это если бы ты требовал чтобы в рантайм C++ по дефолту входил Qt
> Скажите Гвидону, что с Майкрософт связываться нельзя.А заодно, и всем гитхаберам скажите
Одно к другому липнет, ты что, не заметил? Он-то не из наших ну ни разу.
Кратко о JIT, тормозить и жрать памяти станет еще больше... занавес
> Проектом по оптимизации CPython занимается небольшая команда
> разработчиков из компании Microsoft, в которую недавно перешёл
> на работу Гвидо.Все ясно -- стандарта на python не будет никогда. Постоянно что-то будет глючить, ломаться, что-то вообще откажется работать через три-пять лет, а Опоссум будет тешить ч.с.в., форматируя код под виртуальную перфокарту вместо использования блочных скобок.
Только успели отвыкнуть от записи кода на бланках с фиксированными отступами для компонент кода, как появилось чмо, пытающееся реанимировать тупой маразм.
Ну так хотел серьезный язык - пиши на лиспе. Это очередной пых без стандарта, написанный кучкой обезьянок. Протопых, гвидопых, джапопых - одного поля ягоды, которые сгниют рано или поздно, а сбоку к ним примостился нодыжс, который хоть и гниет на полную, но пока андед.
>Опоссум будет тешить ч.с.в.Да тут не в отступах и значащем whitespace-е проблема, хотя и в нём есть проём для пары фич, тут дело в системном мышлении, которого у макак не было никогда.
> Гвидо .. рассказал о планахДед хорохорится, разводит Мелкософт на пенсию
- расслабьтесь, кина не будет (по кр. мере хорошего кина).
Аа-аа, а я уже попкорном запасся.
Ну супер - производительность это последняя и единственная из проблем питона. Пофиксят и другие языки перестанут быть нужны.
а ещё поднять бы выразительность хотя бы до уровня Ruby, упростить и выбросить синтаксический хлам, которым он оброс за последние лет 10.... Да и вообще, придумать бы ему область применения в современном мире, отличную от студенческих поделок....
Эх школьник... C++ никуда с сями не то что не уйдет, даже не планирует
> При реализации проекта разработчики намерены придерживаться ряда ограничений, таких как сохранение полной совместимости на уровне ABI и кода, а также недопустимость повышения производительности за счёт замедления в пограничных случаях.Какие же Microsoft всё таки молодцы...
Выкинуть и запретить говнище с тысячей звыисимостей в аппликухе.Версия 2,версия 3 - этот пакет брошен.,берите новый,и иак весь стек
До assembler ему как до луны
Assembler is perl
> К версии 3.11, которая ожидается в 2022 году, разработчики надеются добиться увеличения производительности в два раза.Можно не ждать год, а просто попринимать все патчи по оптимизации, которые много лет присылали в рассылках питона.
Помнится, там выигрыш раза в два был если просто заменить встроенные list/dict/set на полностью совместимые blist/bdict/bset. Но их зарубили, потому что "слишком сложно" и "скорость сортировки не доказана".
Замена встроенной библиотеки `re` на что-то другое, тоже полностью совместимое, тоже давало дикое ускорение. Но отказались, х.з. почему.
И таких вот зарубленных drop in replacement оптимизаций была целая куча.
Сейчас бы в 2k21 году использовать язык без статической типизации, добровольно перенося все ошибки в runtime. Да ещё при этом считать каждый пробельчик. Если растоманов ещё хоть как то можно понять, то питонисты - это уже клиника.
>это уже клиника.Клиника - это когда постоянно несешь бред в интернете, ничего по теме не зная. А динамическая типизации в малых программах гораздо удобнее статической.
2k21-> 200021да, к 200х тысячному году думаю точно успеют:)
Неужели?! Не прошло и... а нет, уже прошло
Python? Jit?)))Да...с таким успехом явно джаву догонят:))))!!
> Jit?)))А pypy че?
> Проектом по оптимизации CPython занимается небольшая команда разработчиков из компании Microsoft
> В Python 3.12 появится простой JIT-компилятор, применяемый для небольшой части специализированного кода.
> В Python 3.13 будут добавлены новые возможности генерации машинного кода во время выполнения и расширено применение JIT-компилятора.Микрософт портит питон!!! JIT надо удалять отовсюду!
Мне уже много лет приходится патчить питон чтобы он мог запустится и работать на моей платформе. И что делают эти патчи? Удаляют код добавленый Микрософт, который требует выделения памяти в режиме WX одновременно!!!
Если эти патчи не понижают эффективность, зашлёшь их в генту?
"Он улетел... Но он обещал вернуться. Милый. Милый"...