LINUX.ORG.RU

PyPy 1.7

 , ,


0

1

Вышла очередная версия PyPy — интерпретатора языка программирования Python, который написан на Python и может компилировать сам себя. Основным изменением этого выпуска является значительный прирост производительности. В среднем на тестовом пакете, прирост производительности PyPy 1.7 составляет около 30%, по сравнению с PyPy 1.6 и до 20 раз быстрее на некоторых тестах.

Основные изменения:

  • исправление ошибок, совместимость исправлений с CPython;
  • исправления в Windows-версии;
  • в PyPy 1.7 по умолчанию включен stackless;
  • NumPy был переименован в numpypy;
  • JSON encoder заменен на новый, написанный на чистом Python, превосходящий по скорости CPython с расширениями на С в 2 раза;
  • уменьшено потребление памяти некоторыми RPython модулями.

Ссылка для загрузки.

>>> Подробности

★★★★★

Проверено: maxcom ()
Последнее исправление: adriano32 (всего исправлений: 1)
Ответ на: комментарий от anonymous

> Очень уклончивый ответ, я примерно представляю как передать объект из одного процесса в другой. Это сериализация?

Shared Memory и передавать ничего не надо.

EvilBlueBeaver
()
Ответ на: комментарий от namezys

> то её достаточно для решения широкого класса задач, только писать надо уметь

PyPy быстрее

представим на секунду, что это суждение верно для всего возможного множества платформ и задачи (хотя это бы надо доказать ещё, что само по себе задача нетривиальная), теперь зажмуримся и постараемся ответить на простые вопросы:
1. что из этого следует?
2. как это опровергает мой тезис?

shty ★★★★★
()

Мне вот просто чисто из любопытства. Те кто ругают GIL они какую альтернативу предлагают? И почему за столько лет никто не сделал свою версию интерпретатора с этой альтернативой? Видимо, те кто могут сделать альтернативу не в ужасе от GIL - не?

demmsnt
()
Ответ на: комментарий от namezys

> Вот мы пишем сервер, который грузит в память около 3 Гб данных. Так на все 24 ядра на машиен сколько надо памяти?

А в чем проблема? 64-бит система и грузите всё в разделяемую память.

tailgunner ★★★★★
()
Ответ на: комментарий от EvilBlueBeaver

>Shared Memory и передавать ничего не надо.

И получишь, что 1 процесс увеличивает счетчик, а другой его читает. А в внутренних структурах Python дофига всяких счетчиков именно оттуда у GIL уши и ростут.

demmsnt
()
Ответ на: комментарий от demmsnt

> И почему за столько лет никто не сделал свою версию интерпретатора с этой альтернативой? Видимо, те кто могут сделать альтернативу не в ужасе от GIL - не?

Python без GIL сделали минимум 1 раз. Но эта версия была в 1.5 раз медленнее на однопроцессорной машине.

tailgunner ★★★★★
()
Ответ на: комментарий от namezys

Вот мы пишем сервер, который грузит в память около 3 Гб данных. Так на все 24 ядра на машиен сколько надо памяти?

если у вас работают макаки с калькуляторами заместо программистов - 3*23 Гб, для более подробного ответа надо хотя бы чуть-чуть подробностей раскрыть

shty ★★★★★
()
Ответ на: комментарий от true_admin

> Тут стандартный пистон без стероидов не подходит. Правда, вменяемых стероидов я не знаю.

Да ладно. Отлично живет. Грузит данных в начале, потом живет вечно. А ищет он там быстро, обрабатывает около 15000 запросов в секунда, а на ПиПи около 22000

namezys ★★★★
()
Ответ на: комментарий от shty

Ну это я так сказал. Вообще у нас 2 таких сервера на разных машинах запущен - их производительность покрывает наши требования сейчас где-то в 10 раз. Потом может еще один запустим.

namezys ★★★★
()
Ответ на: комментарий от Vudod

Для программиста на Питоне это не существенно.

За всех отучайся говорить. Как только у тебя появится необходимость расшарить структуру, где есть сишный хэндл, то твой multiprocessing очень быстро отправится на свалку.

Vovka-Korovka ★★★★★
()
Ответ на: комментарий от tailgunner

> А в чем проблема? 64-бит система и грузите всё в разделяемую память.

И что, каждый сервер грузит свои данные из базы и заполняет свои струкутуры. Правда они для каждого идентичные в результате.

namezys ★★★★
()
Ответ на: комментарий от namezys

> каждый сервер грузит свои данные из базы и заполняет свои струкутуры. Правда они для каждого идентичные в результате.

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

tailgunner ★★★★★
()
Ответ на: комментарий от baverman

Круто, каждая итерация: 150 мег из процесса копируем в ядро, а из ядра в другой процесс. А синхронизация процессов надо полагать через сигналы?

anonymous
()
Ответ на: комментарий от namezys

А ищет он там быстро, обрабатывает около 15000 запросов в секунда, а на ПиПи около 22000

поставили «пипи» и сразу количество запросов увеличилось - по 20р запрос, тоже бизнес, чо :)

не пойму как любая, даже самая инопланетянская продвинутая технология может увеличить число запрсов, которые генерят «пользователи», разве что mind control

shty ★★★★★
()
Ответ на: комментарий от shty

Я этого не говорил. У нас запросов сейчас на порядок меньше. Но возможности больше стали

namezys ★★★★
()
Ответ на: комментарий от namezys

Вообще у нас 2 таких сервера на разных машинах запущен - их производительность покрывает наши требования сейчас где-то в 10 раз. Потом может еще один запустим.[/quote[

а для каждого сервака прям все данные нужны, или всё же можно поставить прокси?

shty ★★★★★
()
Ответ на: комментарий от namezys

Следует, что его не зря пилят.

а что, кто-то с этим спорит?

shty ★★★★★
()
Ответ на: комментарий от anonymous

150 мег

О да, блжад, почему как только речь заходи о питоне, всем сразу хочется ворочать гигабаты данных и нативной скорости. Это ж такие рядовые задачи!

baverman ★★★
()
Ответ на: комментарий от demmsnt

>Те кто ругают GIL они какую альтернативу предлагают? И почему за столько лет никто не сделал свою версию интерпретатора с этой альтернативой?

Надо делать гибрид интепретатора с компилятором, как в лиспе. Хочешь native threads - будь любезен скомпилять. Лисп, единственный из динамических языков, где потоки работают нормально.

anonymous
()
Ответ на: комментарий от anonymous

>ядро линуса все из себя многопоточно и вполне надежно. 30 млн. строк, если не врут :)))

Ага. И оно вызывает видимо кучу не C софта. Python как раз в случае вызова внешних штук (а это и syscall) и делает GIL. А еще раз в какое, то время для чего уже не помню.

demmsnt
()
Ответ на: комментарий от demmsnt

> Python как раз в случае вызова внешних штук (а это и syscall) и делает GIL.

В случае вызова «внешних штук» он его как раз освобождает.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>Python без GIL сделали минимум 1 раз. Но эта версия была в 1.5 раз медленнее на однопроцессорной машине.

Да было, но ведь дальше решили не делать? Вот я и говорю кричащим про GIL всё в ваших руках. По мне лучше спроектировать систему так, чтоб вообще минимизировать всякие параллельные штуки ибо там не всегда мозг правильно работает. А то, что нужно для скорости и т.п. делать отдельными задачами и синхронизировать с помощью какихнибудь MQ

demmsnt
()
Ответ на: комментарий от shty

> а для каждого сервака прям все данные нужны, или всё же можно поставить прокси?

У нас 2 nginx, они на каждый из серверов раскидывают запросы. Можно и один оставить, но это ненадежно.

namezys ★★★★
()
Ответ на: комментарий от anonymous

>А что смущает. 100 запросов по 1.5 мега каждый, не бог весть какая нагрузка, PHP справляется.

Блин это не обрабатывается целеком! Сделай пул и обрабатывай кусочками по полтора мегабайта. Кстати что там у вас? Картинки?

demmsnt
()
Ответ на: комментарий от tailgunner

> А какой именно чистоты тебе не хватает в os.fork?

Он там не сломается? Хотя не дожен, а идея мне опнравилась.

namezys ★★★★
()
Ответ на: комментарий от demmsnt

>Вот я и говорю кричащим про GIL всё в ваших руках.

Да нет, если мне не нравится GIL, я просто возьму другой язык. Так что это в интересах разработчиках питона что-то сделать с GIL'ом. Ваша гнилая отмаза «критикуя - предлагай» тут вообще не работает.

anonymous
()
Ответ на: комментарий от anonymous

100 запросов по 1.5 мега каждый

Это фигня. На питоне я на своем телефоне это обслужу.

baverman ★★★
()
Ответ на: комментарий от demmsnt

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

anonymous
()
Ответ на: комментарий от anonymous

Да нет, если мне не нравится GIL, я просто возьму другой язык. Так что это в интересах разработчиках питона что-то сделать с GIL'ом

О да, разработчики питона просто кровно заинтересованы тобой. Как же, как же, они не перенесут потерю такого драгоценного анона.

baverman ★★★
()
Ответ на: комментарий от namezys

>> А какой именно чистоты тебе не хватает в os.fork?

Он там не сломается?

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

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

А ничего, что потоки дают минимальный оверхед именно при синхронизации,

А event-loop'ы дают оверхед еще меньше.

baverman ★★★
()
Ответ на: комментарий от anonymous

>Да нет, если мне не нравится GIL, я просто возьму другой язык.

Тут некоторым вообще отступы ненравятся. Когда кроме GIL делать нечего будет вероятно возьмутся за GIL. А пока это примерно такая, же проблема как у меня дома не свежий чай в заварном чайнике. Надо будет заварю свежий.

demmsnt
()
Ответ на: комментарий от anonymous

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

Это вы про сферического коня. По факту там оверхед будет в разы меньше чем отверхед от скажем передачи от nginix к бэкэнду.

demmsnt
()
Ответ на: комментарий от anonymous

Ваша гнилая отмаза «критикуя - предлагай» с лисподрочерами вообще не работает.

да, и особенно ярко это видно по общему состоянию с развитием Lisp

shty ★★★★★
()
Ответ на: комментарий от demmsnt

>А пока это примерно такая, же проблема как у меня дома не свежий чай в заварном чайнике

Питон тормоз, и годится для таких задач, где производительность не играет роли, это же очевидно.

anonymous
()
Ответ на: комментарий от namezys

> а для каждого сервака прям все данные нужны, или всё же можно поставить прокси?

У нас 2 nginx, они на каждый из серверов раскидывают запросы.

ну nginx стоит у вас на frontend как я понимаю, речь несколько о другом, так ли нужно прям 3Гб на сервер грузить? как правило можно работать с фрагментами информации, то есть почему бы не запилить map-reduce какой-нибудь в backend и обрабатывать запросы параллельно?

shty ★★★★★
()
Ответ на: комментарий от anonymous

Питон тормоз, и годится для таких задач, где производительность не играет роли, это же очевидно.

Кто-то утверждал обратное?

baverman ★★★
()
Ответ на: комментарий от anonymous

Голосам в своей голове и отвечай про себя, а не в форум.

тебе можно, почему мне нельзя?

shty ★★★★★
()
Ответ на: комментарий от shty

Просто в этом нет необходимости. А если разделять данные по серверам, то надо будет делать прокладку, которая будет распределять запросы в зависимости от их содержания.

А налогично нет необходимости пока в форканье.

namezys ★★★★
()
Ответ на: комментарий от demmsnt

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

А графика? Питон хорош для графики, со своими биндингом к Qt и gtk+, или там тоже тормозит?

anonymous
()
Ответ на: комментарий от anonymous

> Питон тормоз, и годится для таких задач, где производительность не играет роли, это же очевидно.

Ну highload это к чему тогда относится?

namezys ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.