Увидел свет релиз проекта PyPy 7.2, в рамках которого развивается реализации языка Python, написанной на языке Python (используется статически типизированное подмножество RPython, Restricted Python). Выпуск подготовлен одновременно для веток PyPy2.7 и PyPy3.6, обеспечивающих поддержку синтаксиса Python 2.7 и Python 3.6. Выпуск доступен для Linux (x86, x86_64, PPC64, s390x, Aarch64, ARMv6 или ARMv7 с VFPv3), macOS (x86_64), OpenBSD, FreeBSD и Windows (x86)...Подробнее: https://www.opennet.me/opennews/art.shtml?num=51672
К сожалению, быстрее си всё равно не получается, а си ограничен всё теми же сетью и io.
Ответь - зачем ему быть быстрее си?
Жаба же шмогла (да, я в курсе, какое она тормозилово).
Твоя инфа (или твоя версия Java) устарела лет на 10.
Неужели теперь всё так плохо, что больше никогда не сможет? Ну хорошо, тогда у жабоскрипта все шансы быть быстрее. В 1/10 синтетических тестов, конечно. И в 1 поток.
Неужели в Си завезли JIT-компиляцию?
Ну хоть в чем-то Си быстрее. Хотя заказчику все равно на чем написано - главное быстро и работает. А зануды могут только с ехидкой поджидать в сторонке надеясь что python- скрипты однажды выполнятся не точно. Иногда они дожидаются, однако караван все равно идет...
И кстати, что благородные господа думают вот по этому поводу? https://instagram-engineering.com/dismissing-python-garbage-...
У джавистов это выглядит экстремальнее.
Шо питонодети не осилили написать норамальный GC.
Ничего нового. Wargaming точно так же сделала в танках (там вся логика в клиенте была на питоне) на несколько лет раньше. После завершения игровой сессии память освбождалась вся скопом.
Вроде, gc они только на сервере отключали.
А почему JIT не делают в основной ветке CPython? Пусть он был бы по умолчанию выключен, но зато была бы поддержка всех библиотек. Эти ребята молодцы конечно, но все же обеспечить поддержку абсолютно всей инфраструктуры CPython у них вряд ли получится.
Наверное по той же причине, по которой jython немного того. Вместе с ironpython. У stacklesspython наверно больше шансов на включение, но тот довольно специфический.
Потому что почти все попытки заканчивались на том, что это не очень-то и нужно. Нормальные люди просто не использую Python, там где его скорость действительно критична.
А с какой инфраструктурой у них проблемы?Все, что написано на чистом питоне, у них работает. Интерфейс с Си сделан свой -- да, тут могут быть нюансы. Была проблема с NumPy -- если я правильно понял, то там оказалось, что надо всю систему менять, так как тормозом стали переключения контекста питон-Си. Но сейчас, вроде бы, уже допилено.
Есть нюансы с разным поведением в некоторых ситуациях (нюасны реализации), они на офсайте описаны.
конечно это все хорошо, но скажите мне чем это отличается от заливки закиси озота в двигатель?)) он выигрывает в скорости, но также жрет ресурсы пачками. обычный питон не сказать чтоб был на диете, а это вообще жуть будет. не проще ли для высоконагруженных брать тот же с++, ну или кому для хипстоты - раст или го или же Д. я понимаю , что синтаксис и простота питона подкупают, но тогда надо пытаться собрать язык как питон , но компилируемый.
Cython уже обеспечивает эффективность питона на уровне равном си. На практике ограничение питона вовсе не в памяти, а, например, в gil с gc (мультипоток) и производительности питонового кода (где не cython и c).>не проще
не проще
>не проще ли для высоконагруженных брать тот же с++БЕРЁМ C++ ДЛЯ НАШЕГО СУПЕРХАЙОАД-СЕРВИСА, МЫ Ж НЕ ХИПСТЕРЫ
@
ПОЛГОДА СО СКРИПОМ ПИШЕМ СУПЕРХАЙЛОАД
@
ВСЁ ТОРМОЗИТ ИЗ-ЗА ТОГО, ЧТО СОБЫТИЙНЫЙ ДВИЖОК ИСПОЛЬЗУЕТ ОЧЕРЕДЬ С ПРИОРИТЕТОМ НА ПРОСТОМ СВЯЗНОМ СПИСКЕЭто я всё о наболевшем.
> не проще ли для высоконагруженных брать тот же с++Нет не проще, наоборот, намного сложнее.
Во-первых, чтобы переписать часть кода на с++ придётся сформировать модель из технических низкоуровневых объектов, которых в нём изначально нет. Проще говоря переизобрести велосипед. Да, есть вероятность, что это будет быстрее, но также есть вероятность, что у велосипеда будут квадратные колёса, костыли вместо педалей и руль вместо седушки.
Во-вторых, управление процессами. У высоконагнруженных приложений много коннектов. Если мы будем дёргать приложение на каждый коннект, то как мы будем управлять этими приложениями? Через CGI и ОС, специфические модули конкретного вебсервера? Нужно помнить, что для высоконагруженной задачи нужна еще прозрачная кластеризация с возможностью. Есть вероятность, что увеличение скорости исполнения конкретной задачи за счёт переписывания на с++ приведёт к увеличению накладных расходов по ряду косвенных показателей.
Опять же, всё это можно предусмотреть под конкретную высоконагруженную задачу и сделать на с++, но перед этим нужно ответить на 2 вопроса:
1) Почему бы просто не использовать java? Там и велосипедов изобретать не надо и сервера доставки работают совместно с модулями приложений
2) Почему бы просто не использовать IIS и .net? Возможность оптимизировать, замерить и отреагировать на поведение встроенного модуля - это основная причина, почему у IIS такая монструозная архитектура и размазанность по всей венде.> ну или кому для хипстоты - раст или го или же Д
Это следующий вопрос. Если высоконагруженная задача, например, не решается через готовые веб сервера, то почему бы не написать свой высоконагруженный сервер приложений, и эти "хипстерские" языки изначально помогают решить эту задачу, кстати, не забудем про erlang.
И вот я всё никак не дойду в цепочке рассуждений до С++ для высоконагруженной задачи, суровая реальность не позволяет мне даже помыслить об использовании инструмента, который не заточен под написание высоконагруженных приложений. ВысокоПРОИЗВОДИТЕЛЬНЫХ - спору нет, но высокоНАГРУЖЕННЫХ,.. работающих на кластерной/облачной инфраструктуре и держащих тьму соединений, и принимающие тонну данных... нет. С тем же успехом можно 1С Бухгалтерию переписать на С++ с её родного промптобейсика.
P.S. Ах да, еще nginx unit развивается для таких задач, но я с ним не знаком.
Поперхнулся чаем от 2-х вопросов.
Откуда столько хейта в адрес питона? Отличный выбор для ненагруженных проектов, где не требуется высокая производительность.
я вечно об этом твержу. но тут знаешь народ собрался экстремальный. им подавай абсолют во всем. если машину то суперкар, если язык программирования то равный си по скорости. и тому подобное. а когда сами пихают питон туда где ему отроду не положено быть - ругаются. все никак не могут понять, что для нормальной езды по делам суперкары не нужны, а нужны как раз машины среднего диапазона, чтоб надежно и с меньшими затратами. а если ты строго говоря машину С класса пытаешься использовать как раллийную, то уж извини это невозможно в силу конструкции. но собралась одна "горячая" студенческая "элита". увы.
Зачем нам тормозной си? Нам подавай любовно написанный ручками асм или хотя бы фортран (вроде об этом обычно мечтают, но ллвм есть ллвм). Давайте будем последовательны, ведь все хотят максимально надёжные и эффективные компоненты у авто. Или хотя бы качественные.
Сомневаюсь, что ты хоть какой код на си сможешь лучше оптимизировать на асм.
На асм всегда проще, на си очень многое зависит от особенностей и багов компилятора. Я конечно просто напихаю интринсиков где надо, и не осиливаю большие объёмы в асме (отладка и профилирование особенно утомительны), но асм получается в среднем быстрее и эффективнее, судя по тому что я видел. Что-то компилятор соптимизирует лучше конечно, но он довольно тупой.
На асме может и быстрее за счет того что не проверяешь пограничные условия, в том числе потому что лень столько писать. Но и в сегфолт свалится гораздо проще. Когда тебе не нужны шашечки, а надо просто ехать асм не нужен.
Студентом я задался целью сравнить си и асм и написал реализацию алгоритма брезенхейма рисовании линии на си и асме. Писалось напрямую в видеобуфер под досом. Писанина на си отняла минут 10-15.
На асме - пару часов, правда в основном из-за того, что фактически реализовывались разные варианты и сравнивалась их производительность. Иначе говоря, вариаций реализации на асме больше.
Мне удалось поднять производительность реализации на асме на 5% по сравнению с Си. Выйгрыш был за счет возможности использования циклических сдвигов в асме, которые отсутсвуют в си.
выЙгрыш
>циклических сдвигов в асме, которые отсутсвуют в си.э-э-э-м-м-м-м.... битовые операции в Си? не, не слышал
>>циклических сдвигов в асме, которые отсутсвуют в си.
> э-э-э-м-м-м-м.... битовые операции в Си? не, не слышалЭ-э-э-м-м-м-м… Вряд ли эмуляция битовыми операциями << | >>
будет быстрее нативного
ROR / ROL https://c9x.me/x86/html/file_module_x86_id_273.html
хм... согласен, обтекаю. Си в лучшем случае 5-7 асмовских команд сгенерит вместо одной.
> хм... согласен, обтекаю. Си в лучшем случае 5-7 асмовских команд сгенерит вместо одной.Ну … не все так плохо -- если использовать распространенный паттерн реализации, то более-менее современный (т.е. уже минимум лет 10 как ;) ) оптимизатор в gcc/clang вполне справится с этим:
% gcc -masm=intel -O2 -S -o /dev/stdout -xc - <<< "#include <stdint.h>;
uint32_t foo(uint32_t num, uint8_t i) { return ( (num << i) | num >> (32 - i)); }"
<snip>
foo:
.LFB0:
.cfi_startproc
mov eax, edi
mov ecx, esi
rol eax, cl
ret
но это (как впрочем еще целая куча мелочей) все же заслуга разработчиков этих компиляторов.
А что, чемпионат по неуместным сравнениям уже начался?Питон он как змея, а си он как буква
Да Вы, батенька, азов не знаете - питон он не как змея, он как комики https://ru.wikipedia.org/wiki/%D0%9C%D0%....
точка лишняя
Йумора вам в ленту: https://www.youtube.com/watch?v=0D7hFHfLEyk
Си - он как нота. Причём не си, а до.
> Откуда столько хейта в адрес питона?Потому что по факту это рядовой язык, который выезжает лишь за счет того, что стал выбором большинства. Осталось лишь прояснить, что такое "выбор большинства", но а) это будет оффтопиком, и б) меня тут же закидают говном (кто? - большинство, гы-гы).
Выбор большинства в эпоху СПО и пермиссивных лицензий - это значит, что за меня кто-то сделал часть моей работы. Поэтому неудивительно.
Вот только КАК он ее сделал.. ааа, пофиг, хоть как)) Хороший подход.
>Откуда столько хейта в адрес питона?На самом деле ровно от двух категорий людей:
1. От рукожопов, которые начитались таких же одаренностей о том, что Python учить не надо. Они его и не учат, считая что у них и так все получится. Вот у них и "получается", но обвиняют они не собственную "гениальность", а инструмент.
2. От пиарящих другой язык.
С появлением Трюфеля полезность pypy резко упала.
Я тут тоже проектик начал - pybash называется. Реализация Python на Bash.
Зацените:#!/bin/bash
echo pybash v. 0.0.1python $@
Баш там же у всех переменных тип стринг, не кошерно.
Напишите новость о миграции Project Trident с FreeBSD на Void Linux в 2020 году.
>в то время как cppyy для кода на C++.
>cppyy is based on ClingОни в курсе какой cling огромный, и что он тащит llvm, причём протухших версий, не используемых ни в одной актуальной версии дистров (и пропатчить на новые - это тонна работы, потому что в Церне форкнули когда-то давно шланг и на обновления до новой версии шланга и llvm забили)?
Хайп вокруг Питона связан с тем "ревностью", т.к. этот язык "подвинул" 95% других языков вниз. Скорость - последний оплот "выстоявших", и pypy/cython бьют именно по нему.Впрочем из-за pypy волноваться не стоит. Ведь тут http://packages.pypy.org/ - 1000 совместимых пакетов.
А вот тут
http://pypy.org/ - 200000 пакетов (в 200 раз больше).Сила Питона не в "большинстве", а именно в 200к пакетов на все случаи жизни (не одной сотни жизней). Ну и в списках, срезах, бесскобье тоже есть сила.
Вселенское притворство программистов - это ругать питон за медлительность. Ругать за это вправе только пользователи. А за то что на питоне быстро пишется - хвалить программисты вправе.
Большое число "пакетов" - это проклятье.
> Ведь тут http://packages.pypy.org/ - 1000 совместимых пакетов.Читаем на первой странице: "This page shows what happens when you use pip to install the 1000 most-downloaded package from pypi.python.org. This list is done automatically [...]"
В общем, иностранные товарищи хочут сказать, что это просто результат _автоматического_ тестирования 1000 самых популярных пакетов с pypi.org, а не то, что ты подумал.
> А вот тут http://pypy.org/ - 200000 пакетов (в 200 раз больше).
pypi.org только. Сколько там на самом деле совместимых с pypy пакетов - хз. Далеко не все тестируют совместимость и ставят соответствующий классификатор.
Какой смысл выпускать сейчас обновление когда в 3.8 добавили конструкцию := из гохи и надо бы её везде поддержать
Релиз PyPy 7.2, реализации Python, написанной на языке Python, для написания Python...
Питон, он как Electron, нафигачил и в mass production. Итог - миллионы пользователей тянут сотни мегабайт зависимостей и страдают от тормозов, из-за того, что разработчик решил сэкономить на разработке. От того и отношение к языку у многих такое.
Куда ему до JavaScript...
Действительно, падать ещё долго придётся до такого дна, на котором сейчас жс.
Разработчики JavaScript не путаются в назначении языка
> в то время как cppyy для кодаНеловко вышло...
phpphp 7.2