Состоялся (http://morepypy.blogspot.ru/2016/03/pypy-50-released.html) релиз PyPy 5.0 (http://pypy.org/), реализации языка Python, написанной на языке Python (используется статически типизированное подмножество RPython (http://doc.pypy.org/en/latest/coding-guide.html#id1), Restricted Python). Новый выпуск примечателен значительным увеличением (http://speed.pypy.org/) производительности, он в среднем на 1% быстрее прошлой версии PyPy и в 9.2 раз быстрее классического CPython 2.7. Выпуск доступен для x86-систем Linux 32/64, OpenBSD, FreeBSD, OS X 64 и Windows 32, а также для систем на базе архитектуры ARM (ARMv6 или ARMv7 с VFPv3) и PowerPC (ppc64).
Благодаря задействованию JIT-компилятора, на лету транслирующего некоторые элементы в машинный код, PyPy при выполнении некоторых операций в несколько раз обгоняет по производительности классическую реализацию Python на языке Си (CPython). Ценой высокой производительности и использования JIT-компиляции является более высокое потребление памяти - общее потребление памяти в сложных и длительно работающих процессах (например, при трансляции PyPy силами самого PyPy) превышает потребление CPython в полтора-два раза.
Новшества (http://doc.pypy.org/en/latest/release-5.0.0.html), добавленные в PyPy 5.0:- Продолжена работа по оптимизации использования метаданных в JIT-компиляторе. Разогрев JIT (warmup) теперь выполнятся на 30% быстрее, потребляя на 30% меньше памяти;
- Обновлён C-API (cpyext). Новый cpyext отличается значительным увеличением производительности и упрощением взаимодействия между объектами на языке Си и объектами на уровне интерпретатора PyPy. Реализован (http://morepypy.blogspot.com/2016/02/c-api-support-update.html) более стабильный метод создания объектов PyObjects в cpyext. В результате, новый cpyext позволил добиться успешного прохождения всех тестов (https://bitbucket.org/pypy/compatibility/wiki/lxml) библиотекой lxml, собранной со всеми компонентами cython;- Система профилирования vmprof (http://vmprof.readthedocs.org/) адаптирована для работы на различных платформах. Кроме Linux,
vmprof теперь может применяться в OS X и Windows, поддерживается работа как с PyPy, так и с CPython.
- До версии 1.5ю2 обновлён модуль CFFI (https://cffi.readthedocs.org/en/latest/) (C Foreign Function Interface) с реализацией интерфейса для вызова функций, написанных на языке Си, который может выступать в качестве более простой альтернативы модулю ctypes (http://python.net/crew/theller/ctypes/). В новой версии появилась возможность встраивания PyPy или CPython в программы на языке Си;- По аналогии с CPython по умолчанию в операциях с файловой системой теперь используется кодировка ASCII;
- Для создания тестов задействована библиотека hypothesis (http://hypothesis.readthedocs.org/);
- Расширены возможности интегрированной математической библиотеки Numpy, в которой добавлена возможность индексированной фильтрации двоичных массивов ndarray и частично реализована поддержка функции partition();- Проведены многочисленные оптимизации: ускорены операции соединения строк, оптимизирован поиск глобальных переменных, в 15 раз ускорены операции распаковки чисел с типами float и double, на 50% ускорена распаковка целочисленных типов, оптимизирован поиск в mapdic, значительно увеличена производительность re.sub().
Основные особенности PyPy:
- Поддержка бесстекового (Stackless) режима работы, позволяющего использовать модель actor (erlang-подобное программирование с массой микропотоков и отсыланием сигналов друг другу);
- Реализация режима изолированного выполнения кода, к которому нет доверия. От sandbox в CPython данный режим отличается полной поддержкой всех возможностей языка без выделения unsafe-функций.- Автоматическая генерация и полная прозрачность встроенного JIT-компилятора;
- PyPy успешно проходит стандартный тестовый пакет Python и поддерживает (http://pypy.org/compat.html) большинство из стандартных Python-модулей и фреймворков, таких как ctypes, django (с sqlite), twisted (без поддержки ssl), pylons, pyglet. PyPy может быть использован для бесшовной замены CPython 2.7;
- Поддержка работы на архитектурах x86 (IA-32) , x86_64 и ARM. Ведется работа по адаптации для архитектуры PowerPC (PPC64), но она ещё не завершена;
- На базе технологий PyPy созданы бэкенды для генерации в PyPy байткода для LLVM и виртуальных машин .NET/CLI и Java.
- На базе PyPy ведется разработка реализаций на языке Python интерпретаторов Prolog, Smalltalk, Ruby, JavaScript, Io и Scheme.
- Версия PyPy с поддержкой Python 3 развивается в рамках проекта Py3k (https://www.opennet.dev/opennews/art.shtml?num=40050);
- Вариант PyPy с поддержкой распараллеливания на многоядерных системах развивается в рамках проекта PyPy-STM (https://www.opennet.dev/opennews/art.shtml?num=40150) (PyPy Software Transactional Memory).
URL: http://morepypy.blogspot.ru/2016/03/pypy-50-released.html
Новость: http://www.opennet.dev/opennews/art.shtml?num=44025
Реализации Python, написанной на Python и питоном погоняя :D
Все это хорошо, но вот бы если занялись лишением недостатков реализации самого CPython, это было б значительно лучше.
Просто питон работает быстрее, если написан на питоне.
Ложь, если PyPy и быстрее хоть где-то чем CPython то только за счёт использования JIT, который в CPython не используют, если бы использовали не было бы такого.
Если бы у бабушки был .у., она была бы дедушкой.
и как истинный питон не совместим с другими питонами.
> и как истинный питон не совместим с другими питонами.Как истинный аноним – высказал свое мнение, не утруждая себя знанием предмета или аргументацией!
> PyPy успешно проходит стандартный тестовый пакет Python и поддерживает
>(http://pypy.org/compat.html) большинство из стандартных Python-модулей и фреймворков, таких
> как ctypes, django (с sqlite), twisted (без поддержки ssl), pylons, pyglet. PyPy может быть использован
> для бесшовной замены CPython 2.7;
> Реализации Python, написанной на Python и питоном погоняя :DЧитать не только заголовок новости не пробовали? Счастливчик – "сколько вам открытий чудных ..."
Первое предложение:
> Состоялся релиз PyPy 5.0, реализации языка Python, написанной на языке Python (используется
> статически типизированное подмножество RPython, Restricted Python).
Может хоть с ним portage перестанет тормозить.
Ты, наверно, очень невнимательный гентушник, раз не заметил что тормозит portage жесткий диск.
Почему же тогда на точно таком же жёстком диске не тормозит apt из Debian, который написан на C?
Потому что разное устройство пакетной базы, не?
Переход с HDD на SSD не дает ощутимого прироста. В portage тормозит далеко не только io.
Дает. Повторный запуск emerge всегда в разы быстрее, пока кэш ФС в RAM. Если, конечно, у тебя RAM не 512 мб.
>> Переход с HDD на SSD не дает ощутимого прироста.
> Дает. Повторный запуск emerge всегда в разы быстрее, пока кэш ФС в
> RAM. Если, конечно, у тебя RAM не 512 мб.Я так понимаю, тут или особенный, уличный кэш для SSD или же при использовании HDD кэш насильно сбрасывают (типа "если у нас хдд, значит мы ХОТИМ читать/писать медленно! Не мешайте своим кэшем!")?
Как я уже сказал, зависит от размера кэша ФС в памяти. Если памяти мало, то сбрасывается. В том числе во время компиляции тяжелого софта. Лично мне с моими 3 Гб ее всегда хватало если запросить дерево зависимостей при обновлении софта, Ctrl+C, снова повторить вывод дерева зависимостей.
I/O с кэшем в памяти - тоже I/O. И тоже есть накладные расходы на открытие/закрытие файловых дескрипторов. Особенно если это десятки тысяч файлов.
При использовании питона накладные расходы увеличиваются еще и благодаря питону. Это даже до редхата с DNF дошло, не прошло и 20 лет.
Подсказка двоешникам:
Весь "I/O и окрытие/закрытие файловых дескрипторов" в питоне делается где то глубоко с кишках Си-шных либриотек, с их нативной скоростью.
Навеки Ваш,
Кэп.
Попробуй paludis
Не перестаёт, если интересуют экспериментальные данные ))
Как верно заметили - узкое место hdd. C PyPy диск пригружается эффективней и всё на этом.
> Ценой высокой производительности и использования JIT-компиляции является более высокое потребление памяти - общее потребление памяти в сложных и длительно работающих процессах (например, при трансляции PyPy силами самого PyPy) превышает потребление CPython в полтора-два раза.нужно больше памяти
Важнейший вопрос: выполняется ли pypy на pypy? (pypypypy)
И сколько уровней вложенности потянет
Если не умеет в многоядерность, то не потянет. Если умеет - 32-ядерного сервачка вполне себе хватит на 2-3 уровня вложений!
>Благодаря задействованию JIT-компилятора, на лету транслирующего некоторые элементы в машинный код, PyPy при выполнении некоторых операций в несколько раз обгоняет по производительности классическую реализацию Python на языке Си (CPython).Что-то мне подсказывает что если добавить в классическую реализацию Python на языке Си (CPython) JIT-компилятор, на лету транслирующий некоторые элементы в машинный код то CPython будет быстрее в несколько раз и в несколько раз меньше потреблять память чем PyPy (ибо написан на C у которого по этим параметрам огромное превосходство над Python, на котором написан PyPy).
> Что-то мне подсказывает что если добавить в классическую реализацию Python на языке Си (CPython) JIT-компилятор, на лету транслирующий некоторые элементы в машинный код то CPython будет быстрее в несколько раз и в несколько раз меньше потреблять память чем PyPy (ибо написан на C у которого по этим параметрам огромное превосходство над Python, на котором написан PyPy).Верно мыслите. Но будет ещё быстрее, если алгоритм будет проработан и несколько раз переписан с нуля на Python, и уже когда переделывать будет нечего, реализован с низкоуровневом языке.
Над этим уже работают
https://github.com/dropbox/pyston
http://www.opennet.dev/opennews/art.shtml?num=39494
Быстрее это вряд ли. Скорость и так сишная в некоторых случая. Куда быстрее?
>Скорость и так сишная в некоторых случая.Сишная говорите в некоторых случаях? Что же, охотно верю при условии что число этих случаев стремится к нулю или вообще отрицательно.
Вот некоторый случай: На LORе как-то выкладывали пример с вычислением синуса в цикле.
from math import sindef test():
sum = 0.0
for i in range(100000000):
sum += sin(i)
return sumprint(test())
Вроде так. Под PyPy скорость одинаковая по сравнению с аналогом на Си.
Ваш пример:
time python ./test.py
0.782010319461real 0m13.458s
user 0m12.687s
sys 0m0.755sАналог на C test.c:
#include <stdio.h>
#include <math.h>void main()
{
int i;
double sum = 0.0;
for( i = 0; i < 100000000; ++i )
sum += sin(i);
printf("%.12f\n", sum);
}
gcc test.c -lm
time ./a.out:
0.782010319461real 0m3.262s
user 0m3.254s
sys 0m0.004s
Итого: код на С работает в 4 раза быстрее кода на Python.
Вы читать умеете? Под PyPy, а не под стандартным интерпретатором.
Нужно так
$ time PyPy ./test.py
С PyPy действительно на одном уровне с C:
time pypy ./test.py
0.782010319461real 0m3.475s
user 0m3.464s
sys 0m0.011sно вот только объяснение этому такое:
https://ru.wikipedia.org/wiki/PyPy
>PyPy состоит из стандартного интерпретатора и транслятора. Интерпретатор полностью реализует язык Python. Сам интерпретатор написан на ограниченном подмножестве этого же языка, называемом RPython (Restricted Python). В отличие от стандартного Python, RPython является статически типизированным для более эффективной компиляции
>C — трансляция кода RPython в C и запуск как родной программы; это стандартный режим работы;Кроме того если в приведённый выше код на C добавить одну строку из openmp:
#include <stdio.h>
#include <math.h>void main()
{
int i;
double sum = 0.0;
#pragma omp parallel for reduction(+:sum)
for( i = 0; i < 100000000; ++i )
sum += sin(i);
printf("%.12f\n", sum);
}
То результаты C кардинально меняются:
gcc test.c -fopenmp -lm
time ./a.out
0.782010319461real 0m0.545s
user 0m4.207s
sys 0m0.000s
Добавим нолик к диапазону:
Python2: отказывается исполнять такой код
time python test.py
Traceback (most recent call last):
File "test.py", line 9, in <module>
print(test())
File "test.py", line 5, in test
for i in range(1000000000):
MemoryError
Python3:
$ time python3 test.py
-0.12454896270324128real 2m37.319s
user 2m37.137s
sys 0m0.015s
PyPy:
time pypy test.py
-0.124548962703real 0m40.081s
user 0m40.035s
sys 0m0.008s
код на C без openmp:
time ./a.out
-0.124548962703real 0m38.697s
user 0m38.659s
sys 0m0.000s
код на C c openmp:
gcc test.c -fopenmp -lm
time ./a.out
-0.124548962703real 0m6.378s
user 0m48.648s
sys 0m0.000s
В новости под которой мы сейчас пишем последняя строка как бы заранее отвечает на ваше добавление openmp.
И к чему этот "срыв покровов", я не понимаю? Хотите сказать что автор коммента, на который отвечал я выше, прав и при указанных им изменениях программы будут в разы быстрее чем под PyPy, то есть в разы быстрее чем написанные на Си?
> В новости под которой мы сейчас пишем последняя строка как бы заранее
> отвечает на ваше добавление openmp.Так он даже без openmp продул. Это человек еще флаги оптимизации не показал. А то с правильными флагами код можно разогнать в пару раз без проблем. Ну вон LZ4 собирают с -O3 по дефолту, ядрено получается. Попробуй кодом на питоне распаковать что-нибудь со скоростью 2 гига в секунду - узнаешь много нового на тему "не тормозит".
А дефолтный питон почему-то вообще лажанулся. Это вообще нормально - валиться от инкремента счетчика? Если кручение счетчика вызывает ошибку, ошибка не в памяти а в ДНК того кто это придумал.
>А то с правильными флагами код можно разогнать в пару
> раз без проблем.Ну-ка ну-ка ... "разгон в пару раз" того кода, c помощью флагов – в студию!
Хотя да, куда там непонятному "-Ofast" до "-O3" o_O> А дефолтный питон почему-то вообще лажанулся. Это вообще нормально - валиться от
> инкремента счетчика? Если кручение счетчика вызывает ошибку, ошибка не в памяти
> а в ДНК того кто это придумал.А вот мне кажется, что один конкретный Аноним опять лажанулся – непонятно где в питоно-коде простой инкремент счетчика увидел. Хотя любой школьник в курсе, что "range" возвращает список с 0..n – но то школьник, куда ему до Анонима.
> Ну-ка ну-ка ... "разгон в пару раз" того кода, c помощью
> флагов – в студию!
> Хотя да, куда там непонятному "-Ofast" до "-O3" o_OН-да. Классическое "А вдоль лyж анонимы на дивaнах сидят! И тишина!"
Вообще-то mfpmath=387 + ffast-math спасут таки "болеющих за правое дело cи!".
# gcc49 -Ofast -fopenmp test.c -lm -o sine
# time ./sine
0.782010319460
./sine 35,38s user 0,00s system 389% cpu 9,095 total
# gcc49 -Ofast -fopenmp test.c -mfpmath=387+sse -o sine
# time ./sine
0.782010319460
./sine 5,63s user 0,02s system 390% cpu 1,447 total
Но да, как в темах о <любой не-си-компилятор/ЯП> орать про то, что "си рулит, а все остальное отстoй для неoсиляторов!", так чуть ли не каждый второй анон – матeрый сишник, а каждый четвертый – вообще в hex-редакторе код пишет.
Правда, как только дело доходит до конкретики … "И тишина!"
Трое суток флаги гуглил. Сразу видно эксперта. У pypy кстати тоже флаги есть. Короче гугли ещё трое суток и покажи результаты питона с флагами и мультипоточностью.
> Трое суток флаги гуглил. Сразу видно эксперта.Да-да, Анонимному Эксперту ведь кто-то активно мешал "смешать питонщиков с грязью", когда была возможность!
Только и хватало на пару очередных глупостей^W мудростей, да обязательного проставления минусиков с плюсиками.
А не то Аноним бы ого-го! Всем бы показал! =)Ну, типа заделал бы больше таких вот перлов, да еще и в разных вариациях:
> и как истинный питон не совместим с другими питонами.
> 4) Не совместимо с существующим кодом на питоне, в лучших традициях.И правда – с чегой-то простым анонимам делать различие между языком и расширениями для конкретного интерпретатора? Аноним видит знакомое слово и сразу начинает газовую атаку!
А то, что даже в самой новости говорится о
> PyPy успешно проходит стандартный тестовый пакет Python ... может быть использован для бесшовной замены CPython 2.7;Ну дык аноним у нас Отвечатель, а не Читатель!
А еще аноним у нас "знаток" питона (ну или си):
у него питоновское
> for i in range(100000000)которое https://docs.python.org/2/library/functions.html#range
> This is a versatile function to create lists containing arithmetic progressions.то же самое, что и сишное
> for( i = 0; i < 100000000; ++i )Оказывается, "for i in range" (т.е. "for element in list((0,1,2, ..., n))") – это такое "кручение счетчика"
> Если кручение счетчика вызывает ошибкуНу да, списки, счетчики, флаги компилятора или улчшение алгоритмов – невместо Эксперту в таких мелочах разбираться! Он лучше про "вложенность" и "питон на питоне на питоне" пропетросянит! Ведь читать даже первое предложение, в котором уточняется про "статически типизированное подмножество RPython " – это ведь не для Отвечателя!
В общем:
Пишите обязательно еще – побольше Экспертной Мудрости, а то еще не все лужи газифицированны!
И не забудте: +2 себе, -2 врагам! Так и только так ваша очередная глупость станет сразу мудрым высказыванием!1 =)
> И не забудте: +2 себе, -2 врагам! Так и только так ваша
> очередная глупость станет сразу мудрым высказыванием!1 =)Шо у вас такая болезнь про хаброшколие? У них это рефлекс, их как собак Павлова специально обучили, вместо слюны - минусики.
> Шо у вас такая болезнь про хаброшколие? У них это рефлекс,
> их как собак Павлова специально обучили, вместо слюны - минусики.Та не, просто прикольно - ничего, ничего, потом отвечает "типа аноним, типа один из многих!" - и раз, весь "свежачок" оказывается проплюсо-минусовываным. Типа "во, гляди - я прав!". Совсем беспалевно, особенно когда "двоить" )
Какой-то бессвязный бред. Попробую вам помочь разобраться.
До того как другой Аноним не написал что range это функция возвращающая список вы молчали об этом в тряпочку, а потом внезапно стали повторять как попугай это в каждом посте.
До того как кто-то не использовал в этой теме многопоточность вы не использовали её. А потом стали использовать, хотя сравнивать скорость работы кода в один поток с работой другого в четыре(или сколько там?), как-то не корректно да и просто глупо так как это сравнение уже было сделанно выше до вас.
Ещё вы воспринимаете разных людей пишущих анонимно как одного человека игнорируя контекст. Так же вы в одном из комментов приписываете мне авторство кода, когда я чётко сказал что скопировал его с LORа.
Резюмирую. Вместо того чтобы выдавать себя за программиста, или человека разбирающегося, изматывать себя спорами займитесь реальным изучением этой унылой вещи, раз вам так хочется чтобы люди считали вас программистом. Хотя бы будете при деле.
> До того как другой Аноним не написал что range это функция возвращающая
> список вы молчали об этом в тряпочку, а потом внезапно стали
> повторять как попугайДа-да, только Вы, Истинный Аноним, ведаете "ху из ху". А про то, что можно, как бы, и с иобильника написать - не, не слышали!
> До того как кто-то не использовал в этой теме многопоточность вы не
> использовали её. А потом стали использовать, хотя сравнивать скорость работы кодаДа да! Это не Анонимный Эксперт решил использовать многопоточность, чтобы "доказать, что петон отстoй!"
> Ещё вы воспринимаете разных людей пишущих анонимно как одного человека игнорируя контекст.
Да-да, писать из под анонима так удобно - типа, сел в лyжу - "это не я! Это другой аноним!"
> когда я чётко сказал что скопировал его с LORа.
Т.е. не разобравшись, но утверждая, что это мол, то же самое и вообще, "честное сравнение"? Понятно.
> Резюмирую. Вместо того чтобы выдавать себя за программиста, или человека разбирающегося,А по теме что-то будет? Ну, вместо вангования кто в чем не разбирается?
Опять какой-то не адекват. По теме - вам лечится надо, или хотя бы следить за собой весной и осенью, раз уж вы не в состоянии прочитать одну ветку и разобраться, прежде чем стучать по клаве генерируя бред. Всё.
> Опять какой-то не адекват. По теме - вам лечится надо, или хотя
> бы следить за собой весной и осенью,Да не расстраиваетесь вы так! Переход на личности и "тонкие" намеки вместо аргументов -- тоже вполне достойный Анона ответ! Вы победили и всем показали!
> Ну-ка ну-ка ... "разгон в пару раз" того кода, c помощью флагов – в студию!Легко. Собери LZ4 с -O0 и -O3, поудивляйся разнице.
> Хотя да, куда там непонятному "-Ofast" до "-O3" o_O
Это про цирк где питонист подсунул питону предварительно вычисленное выражение? Там мухлеж на уровне алгоритма. Извольте-ка сравнивать одинаковые алгоритмы. И если уж производительность питона - без вызова сишных библиотек.
> А вот мне кажется, что один конкретный Аноним опять лажанулся – непонятно
> где в питоно-коде простой инкремент счетчика увидел.В цикле, вестимо. Ну хорошо, уломал, там еще синус и суммирование. Не вижу чего из этого может много памяти потребить.
> курсе, что "range" возвращает список с 0..n – но то школьник, куда ему до Анонима.
Так и запишем - питонисты пишут код настолько ж...й, что даже цикл написать нормально уже не могут.
>> Ну-ка ну-ка ... "разгон в пару раз" того кода, c помощью флагов – в студию!
> Легко. Собери LZ4 с -O0 и -O3, поудивляйся разнице.Вы, наверное, автор LZ4, раз его каждый раз в пример ставите? А автограф можно?
Или просто невнимателно читали – там вроде бы речь про код из #35 или #43.
> Это про цирк где питонист подсунул питону предварительно вычисленное выражение?Какое предварительно вычисленное выражение?
Внимательнее нужно быть, внимательнее:
> def compute(val):
> return 0.5 * cos(0.5)/sin(0.5) - cos(( val + 0.5))/(2*sin(0.5))Если добавить "import sys" и заменить
return compute(100000000-1)
хотя бы на
return compute(long(sys.argv[1])-1)
то можно считать что угодно.
> Там мухлеж на уровне алгоритма. Извольте-ка сравнивать одинаковые алгоритмы.Ну … Там один аноним скопировал что-то с лора. Если я не ошибаюсь:
> пример с вычислением синуса в цикле.Другой (или тот же) аноним написал эдакий "аналог" на сях. Который, правда, не совсем аналог – потому как он, автор, почему-то решил не создавать и инициализировать список, только ради того, чтобы потом брать из него нужные значения. Оно и понятно – как-то это удаление гланд автогеном через так называемый "первичный рот" напоминает. Но тем не менее, ни код на питоне не исправил, ни свой код соответственно не переписал, а занялся добавлением многопоточности.
То есть, уже изначально сравнивались, как любят выражаться некоторые товарищи, "теплое с мягким". При этом, нигде даже особо не оговаривалось, что вычислять нужно именно в цикле. Да и несколько странно требовать соблюдения правил, которые нарушаешь сам.
> В цикле, вестимо. Ну хорошо, уломал, там еще синус и суммирование. Не
> вижу чего из этого может много памяти потребить.Вы не правы, тут не используют простой счетчик, а делают список с помощью "range(a,b)".
Зачем и почему – надобно спросить того, кто это написал. А то вдруг программирование у него такое маленькое хобби, а в действительности он ЛОР-доктор с очень интересной методикой удаления миндалин …> Так и запишем - питонисты пишут код настолько ж...й, что даже цикл
> написать нормально уже не могут.Вы правы. Хотя странно, что Вы ожидали чего-то другого от анонимов опеннета.
Разница в рамках погрешности, а если добавить к этому холодный старт PyPy то уже не понятно кто кому продул. У меня то один то другой в рамках 3.500-4.100 колеблются. Ниже дан пример с флагом на скорость. Что-то особого роста не наблюдается.
А точно с распаковкой будут проблемы если использовать питон в pypy? Там же стандартные алгоритмы. Но если всё же будут то где гарантии что дело исключительно в том что pypy написан на питоне?
Я то, блин утверждаю что в некоторых случаях код на питоне исполняемый в pypy сравним с кодом написанным на си(попытки хитрить используя openmp, флаги оптимизации в сишной реализации это только подтверждают). И поэтому СPython никак не будет в разы быстрее. Я не утверждаю что питон прекрасен и быстр, а при использовании обсуждаемой реализации вообще конкурент Си. Нет блин.
> Я то, блин утверждаю что в некоторых случаях код на питоне исполняемый
> в pypy сравним с кодом написанным на си(попытки хитрить используя openmp,
> флаги оптимизации в сишной реализации это только подтверждают).А почему хитрить то? Вон image magic "хитрит" в дефолтной сборке в почти всех дистров уже лет пять наверное.
> И поэтому СPython никак не будет в разы быстрее.
Было бы странно если бы интерпретатор был быстрее jit. Какие к тому предпосылки? Но jit память жрет как... как JS в браузере. Тут вон орлы memory error огребли в простейшем цикле. Хренасе.
> Нет блин.
Зато это делают другие.
> но вот только объяснение этому такое:
> https://ru.wikipedia.org/wiki/PyPyКакое? Сам скрипт не транслируется в Си, а то что JIT "как бы на Си", особо не влияет на результат, только на работу непосредственно самого джита (т.е генерирование нативного кода)
ЗЫ:> Кроме того если в приведённый выше код на C добавить одну строку
> из openmp:
>
> #include <stdio.h>
> #include <math.h>...
>
> То результаты C кардинально меняются:
> gcc test.c -fopenmp -lm
> time ./a.out
> 0.782010319461
> real 0m0.545s
> user 0m4.207s
> sys 0m0.000sНу, а если бабушке пришить^W^W к питонокоду добавить две строчки, переписать одну и убрать три:
from math import sin, cos
def compute(val):
return 0.5 * cos(0.5)/sin(0.5) - cos((val + 0.5))/(2*sin(0.5))
def test():
return compute(100000000-1)print(test())
То результаты действительно меняются )
# time pypy test2.py
0.782010319461
pypy test2.py 0,06s user 0,04s system 99% cpu 0,102 total
# gcc49 -Ofast -lm -fopenmp test.c
# time ./a.out
0.782010319460
./a.out 35,24s user 0,00s system 391% cpu 8,993 total> Добавим нолик к диапазону:
> Python2: отказывается исполнять такой кодxrange в помощь
https://docs.python.org/2/library/functions.html#xrange
>[оверквотинг удален]
> real 0m38.697s
> user 0m38.659s
> sys 0m0.000s
> код на C c openmp:
> gcc test.c -fopenmp -lm
> time ./a.out
> -0.124548962703
> real 0m6.378s
> user 0m48.648s
> sys 0m0.000s
Чей-то у вас компутер допотопный o_OТот самый код на питоне:
# time python test2.py
-0.124548962702
python test2.py 0,02s user 0,02s system 97% cpu 0,042 total
Заменить цикл единственным вычислением - такой же примитивный и пошлый троллинг можно встретить разве что от гражданина под ником myhand.
> Заменить цикл единственным вычислением - такой же примитивный и пошлый троллинг можно
> встретить разве что от гражданина под ником myhand.Так при честном сравнении питон продувает, приходится жульничать. А если еще и потребление памяти сравнить - любители питона почувствуют себя ужами на сковородке.
> Так при честном сравнении питон продувает, приходится жульничать.А где Уважаемый Эксперт "честное сравнение" увидел?
В Си-коде аноним использует простой цикл со счетчиком – а в питоне, ничтоже сумняшеся, вместо простого цикла берет полноценный список на 10000000 циферок ... "а че, все честно!" (с). Да еще и удивляется – как это, список с 100500 циферками не хочет в памяти помещаться, да еще и память жрет!? Вот ведь фейл!Ну я и подумал, что можно конечно поступить как Анонимный Эксперт и всецело положиться на оптимизацию компилятора гцц (благо там целая уйма человекочасов, да и люди отнюдь не глупые делают), при этом важно надувать щеки, как будто самолично его (гцц) писал, а не просто запускал – и вещать про "тормознутость".
А можно задействовать то, во что частенько только едят. И результат – на лицо.
Потому как парни из гцц – отнюдь не провидцы, да и либастрал так и не встроили, а значит заоптимизировать *реноватый алгоритм все же не в состоянии.Ну а анониму остается только вещать про "неправильность" и "нечестность" – сам-то он не догадался, привык уже к тому что парни из гцц за него основную работу делают, а тут на тебе – громко и с выражением повторять "бидон тормозит!" не помогает!
> В Си-коде аноним использует простой цикл со счетчиком – а в питоне,
> ничтоже сумняшеся, вместо простого цикла берет полноценный список на 10000000 циферок
> ... "а че, все честно!" (с).Судя по тому как yum/dnf/portages работают - реалистичная аппроксимация.
> да и люди отнюдь не глупые делают), при этом важно надувать
> щеки, как будто самолично его (гцц) писал, а не просто запускал
> – и вещать про "тормознутость".Надувание щек обычно имеет смысл если ты умеешь этой самой оптимизации не мешать. А иногда приходится активно помогать. В случае jit это будет не сложно, а очень сложно.
> А можно задействовать то, во что частенько только едят. И результат – на лицо.
Так питон считается low entry barrier. Как видим не зря.
> так и не встроили, а значит заоптимизировать *реноватый алгоритм все же не в состоянии.
Иногда в состоянии. Контрпример:
for (...i < 100500...)
{
a = 5;
}легко превратится в нечто вида:
mov r7, #5 // a = 5;Т.е. сразу результат, без циклов вообще. И такого в gcc - есть. Если a нигде не используется - кода вообще не будет. А поскольку это compile time а не run time, реальное время не жмет и можно позволить себе довольно солидный анализ. Что и происходит. В случае с jit - ты не обрадуешься если все так встрянет для более качественной кодогенерации.
> за него основную работу делают, а тут на тебе – громко
> и с выражением повторять "бидон тормозит!" не помогает!Они ее довольно хорошо делают, тут он прав.
> Судя по тому как yum/dnf/portages работают - реалистичная аппроксимация.Не знаю, так как не использую. А причем здесь вообще эта отсылка?
Я так понимаю, что все порывы переписать все это на си категорически отвергались и запрещались под страхом пожизненного лишения интернета?
>> А можно задействовать то, во что частенько только едят. И результат – на лицо.
> Так питон считается low entry barrier. Как видим не зря.Гм, почему-то представители "не-low-entry" ЯП в этой теме тоже особо не блистали. Нашли где-то какой-то, мягко говоря, странный пример. Кинулись писать что-то довольно отдаленно похожее, подзабыв про то, что неплохо сначала подобрать более оптимальный алгоритм.
>> так и не встроили, а значит заоптимизировать *реноватый алгоритм все же не в состоянии.
> Иногда в состоянии. Контрпример:
> for (...i < 100500...)
> {
> a = 5;
> }...
> Т.е. сразу результат, без циклов вообще. И такого в gcc - есть.
> Если a нигде не используется - кода вообще не будет.Я так понимаю, что имелись в виду не настолько тривиальные примеры. Что косвенно подтверждается результатами в этой теме. Да и DCE в этом примере все же далеко не оптимизация не очень тривиального алгоритма.
>> за него основную работу делают, а тут на тебе – громко
> Они ее довольно хорошо делают, тут он прав.Тем не менее, результат – отличный пример этой самой привычки или даже, к сожалению, довольно распространенного заблуждения "главное, написать на си, а там оно уж как нибудь само …"
> Чей-то у вас компутер допотопный o_OТеперь понятно почему питон не тормозит. Надо оказывается сервер 32-ядерный брать, с 128 гиг оперативки.
> Теперь понятно почему питон не тормозит. Надо оказывается сервер 32-ядерный брать, с
> 128 гиг оперативки.Ну да, если не осилил подумать головой – "throw hardware at it!"
>> Под PyPy скорость одинаковая по сравнению с аналогом на Си.
> Ваш пример:
> time python ./test.py
> 0.782010319461
> Итого: код на С работает в 4 раза быстрее кода на Python.Неа.
# gcc49 test.c -lm
# time ./a.out
0.782010319460
./a.out 23,89s user 0,02s system 99% cpu 23,923 total
# gcc49 test.c -lm -Ofast
# time ./a.out
0.782010319460
./a.out 23,60s user 0,00s system 99% cpu 23,603 total
# time pypy test.py
0.78201031946
pypy test.py 24,89s user 0,06s system 99% cpu 24,956 total
# pypy --version
Python 2.7.10 [PyPy 4.0.1
Python != CPython != PyPy
Из вашего же комментария ниже:>Ага, главное вставить про Си ... ведь знать, что PyPy написано RPython
>который транслируется в СиОтсюда и скорость одинаковая, вот только этот пример лишь маленький частный случай, что-то никто не торопится заменять стандартные интерпретаторы.
> Отсюда и скорость одинаковая, вот только этот пример лишь маленький частный случай,Скорость чего? Генерирования нативного кода или скорость выполнения этого самого кода? Вы уж определитесь.
Сам JIT, который в основном (в этом конкретном случае) и влияет на "скорость выполнения" скрипта , внезапно, генерирует отнюдь не Си.
Так каким же образом одинаковый машинный код, генерированный "JIT-ом на Си" будет быстрее того же машинного кода "JITa-который на Р-питоне"?КО:
Когда затевался сам PyPY, тот же LLVM был еще в зачаточном состоянии.
Т.е. – можно было пилить очередной велосипедo-компилятор с квадратными колесами или не выделываться и пользоваться гцц. Кстати, там, в ПайПае еще и другие бэкэнды были – JVM, IL но за отсутствием интереса рекратили поддержку.Кстати, сами разработчики отнюдь не собираются "нагнать и перегнать Си", как тут частенько интерпретируют в новостях о PyPy – потому как они прекрасно понимают, почему это невозможно (и дело отнюдь не в (не)использовании Си – тех же "py2C(++)" переводчиков вагон и маленькая тележка:
https://wiki.python.org/moin/PythonImplementations#Compilers ).
JIT
1) Требует дополнительного времени на генерацию кода.
2) В памяти будет висеть немаленький кодогенератор.
3) Под служебные структуры, описывающие внутреннее состояние, что заоптимизировано и сам код - скушается море памяти.В случае нормальных компиляторов - это случается в compile time, реальное время там не жмет и это вообще не проблема того кто программу выполняет. В случае если это в run time, все оказывается свалено в одну кучу. В лучшем случае получается что-то типа явы.
Бонусом,
4) Не совместимо с существующим кодом на питоне, в лучших традициях.
> Бонусом,
> 4) Не совместимо с существующим кодом на питоне, в лучших традициях.Новость не читай, сразу в лужу отвечай?
Пруф или GTFO.
> Что-то мне подсказывает что если добавить в классическую реализацию Python на языке СиАга, главное вставить про Си ... ведь знать, что PyPy написано RPython
http://rpython.readthedocs.org/en/latest/faq.html#what-is-th...> RPython is a restricted subset of the Python language.
> RPython program restrictions mostly limit the ability to mix types in arbitrary ways.
> RPython does not allow the binding of two different types in the same variable.
> In this respect (and in some others) it feels a bit like Java.
> Other features not allowed in RPython are the use of special methods (__xxx__) except __init__ and __del__, and the use of reflection capabilities (e.g.который транслируется в Си
http://rpython.readthedocs.org/en/latest/translation.html#th...
совсем не обязательно!
> Что-то мне подсказываетПытались уже не раз, вон:
https://en.wikipedia.org/wiki/Unladen_Swallow
даже при спонсировании гугла – не вышло.
Видимо, нужно было писать на Си, а не на С++.
Вот только писать сложную алгоритмику на сях - удовольствие ниже среднего, а отлаживать - тем более.
за erlang-подобия - зачетно ! захотелось попробовать ...
Хочу реализацию JavaScript на JavaScript - JaJa!
https://github.com/jterrace/js.js/
> Разогрев JIT (warmup) теперь выполнятся на 30% быстрее, потребляя на 30% меньше памяти;А долго надо разогревать?)
Пока не встанет
> А долго надо разогревать?)Пару минут, если он теплый и ламповый.
numpy для py3k до сих пор не работает?
Тебя нае^манули :) https://pypi.python.org/pypi/numpy
А на PyPy можно запускать ещё один PyPy?
> А на PyPy можно запускать ещё один PyPy?Каким образом?
PyPy написан на RPython, а интерпретирует обычный Python - это разные языки.
Обьясните мне глупому что такое JIT и в чем отличие от текущего Python Comile (.pyc и .pyo)? Если заменить все .py файлы на .pyc, то это можно назвать JIT интерпритатором CPython?
> Обьясните мне глупому что такое JIT и в чем отличие от текущего
> Python Comile (.pyc и .pyo)? Если заменить все .py файлы на
> .pyc, то это можно назвать JIT интерпритатором CPython?Для этого надо понять разницу между машинным кодом и какими-то там опкодами чего-то виртуального в pyc файлах. В pyc файлах не надо парсить синтаксис, но это не машинный код и поэтому все-равно производится интерпретация. Ну да, не слов а опкодов. Скорость все-равно плохая. Потому что быстрее всего - выполнить машинный код в процессоре аппаратно.