LINUX.ORG.RU
Новости — Open Source  

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)

 ← 1 2 3 4 5 6 7 8 →
Ответ на: комментарий от tailgunner

> Это не многозадачность.

«кто скажет, что это девочка, пусть первый бросит в меня камень» . greenlets - это классическая кооперативная многозадачность.

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

>> он не гарантирует очистку памяти

В смысле?

Они где-то писали, что они стараются очистить все объекты, но не обещают, что смогут очистить все.

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

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

Еще раз раскажите это FriendFeed И кстати ребята Java знают точно лучше вас!

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

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

Я могу ошибаться, но у Эрланка вообще понятия потоков нет. Все работает само.

А графика? Да вы что? У C есть биндинги к GTK? Нет? Ааааааа GTK на нем написан? Мне вообще такой толстый тролль давно не попадался. Теперь у нас вызовы C библиотек стали тормозить. Стек мешает?

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

Чорт, точно. Если есть метод __del__ то оно дуба даёт и требует ручного удаления ссылок. Ну, это не сильно большая проблема, решается в пару строк :)

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

> Я могу ошибаться, но у Эрланка вообще понятия потоков нет. Все работает само.

У эрланга есть внутренние процессы. Причем это именно процессы, у них свое «адресное пространство», они ни содержат разделяемых объектов. Умные люди в ерикссон понимали еще 20 лет назад, что разделяемые объекты - лишний гемор, необходимость синхронизации и трудноуловимые ошибки.

А процессы там внутренние, потому что операционки с таким числом процессов не справляются. Как то для интереса запускал 2 миллиона процессов. Съело 2 гига памяти, но работало. Запустите как 2 миллиона потоков в жабе или питоне.

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

gc.collect() вызывали?

Если да то вот это поможет:

def liquidator():
    gc.collect()
    print(gc.garbage)
    for sucker in gc.garbage:
        sucker.__dict__.clear()
    del gc.garbage[:]

Правда, это весь код поломает... Интересно, а как в яве решена эта проблема?

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

>У эрланга есть внутренние процессы. Причем это именно процессы, у них свое «адресное пространство», они ни содержат разделяемых объектов. Умные люди в ерикссон понимали еще 20 лет назад, что разделяемые объекты - лишний гемор, необходимость синхронизации и трудноуловимые ошибки.

Дай я тебя в лоб поцелую. Вот примерно так я и считаю.

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

>Правда, это весь код поломает... Интересно, а как в яве решена эта проблема?

Никак. У них сабстринг не возвращает новый стринг. Он хранит ссылку на исходник и в итоге если ты с гиговой строки выбрал три смвола и всю дорогу их хранишь - гигова строка сидит в памяти ибо ссылка на нее жива.

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

Короче, косяк в том что если есть циклические ссылки у объектов с __del__ то непонятно в каком порядке их вызывать(я так понимаю это фундаментальное ограничение reference count).

Этот код тупо убивает инстанс(убирает рефы на все локальные переменные) со всеми его циклическими ссылками.

Собстно, в этом вся и проблема, после этого __del__ вызывать бессмысленно т.к. и так уже всё подтёрто самым поганым образом.

Как это в яве обошли я с ходу не понял. Там какие-то финалайзеры вызываются. Но, походу, из-за явовского tracing-коллектора компилер лучше понимает порядок вызова деструкторов, вот и всё.

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

> Короче, косяк в том что если есть циклические ссылки

По идее у них есть какая-то эвристика. Вот из-за нее может и не удаляться даже нормальный объект.

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

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

Вспомнил, я в простом проекте на 200 строк посадил очень хитрую петлю которую я искал оочень долго. Да, ты прав, gc в питоне не очень :(

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

Циклические ссылки в большинстве случаев указывают на кривость архитектуры.

И снова спасибо erlang'у, что не дает мне отстрелить себе ногу)

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

По идее у них есть какая-то эвристика

Нету :). На сколько помню, оно просто строит граф и смотрит не образовалось ли изолированных островков. Могу ошибаться, года два назад доки читал. Где-то в тутториале было что надо делать. С ходу нахожу только вот это: http://docs.python.org/py3k/c-api/gcsupport.html

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

Циклические ссылки в большинстве случаев указывают на кривость архитектуры.

это так кажется. На самом деле посадить нехрен делать.

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

>Нету :). На сколько помню, оно просто строит граф и смотрит не образовалось ли изолированных островков.

Есть! Я еще в 1.5 читал как они борются. Там не Эвристика, а типа подсчет обхода элемента графа. как только пошли по второму кругу значит цикл. Удаляет, проверено

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

Абсолютно не понял смысла фразы

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

Потом кто сказал что так делать нельзя? Если есть цикл это не значит автоматом что программа жутко запутанная.

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

>ну я об этом же написал :).

Ну это не эвристика. Эвристика это на основе нечеткой логики или нейронных сетей. Или на основе статистики. Короче Эвристику сам пейсатель ХЗ предскажет в общем случае. Ненавижу. Но бывает полезно.

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

Потоки в питоне есть но они не используют преимущества многоядерных процессоров, спасибо GIL.
Начинал нормально изучать программирование как раз с Perl (не считая шела) , позже параллельно начал изучать Python. Когда дошел до нужного уровня все проекты делал на Python так как это было легче и понятнее, также из-за того что уже как года 3-4 падает спрос на Perl разработчиков. Да и изначально Perl был предназначен для обработки текста . В общем по своему опыту не советую на Perl ничего делать, 6ю версию уже 11 лет пишут :)

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

У Эрланга внутренее устройство и сложнее и проще. Там с циклическими ссылками проще. Там не так с объектами. Функции, данные. Очень лаконично и бесит ООП маниаков. Но у него свои проблемы.

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

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

Они появляются оттого, что люди не знают, как сделать по-другому.

Потом кто сказал что так делать нельзя? Если есть цикл это не значит автоматом что программа жутко запутанная.

Циклические ссылки подразумевают большую связность. То есть не один кусок кода должен знать о другом, а они оба должны быть завязаны друг на друга. Это возможно, когда объекты находятся на одном уровне абстракции, например узлы графа (и то, граф можно кучей способов описать). Но это плохо, когда объекты нижнего уровня абстракции знает о более верхних. У объектов должна быть как можно более узкая зона ответственности и они не должны знать того, чего им знать не положено.

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

Я начинал с Pascal потом был Perl (три года или 4) потом долго выбирал Руби или Пайтон. Еще TCL юзал. GIL есть, но я еще ни разу не попадал в ситуацию чтоб ох ох. Выделл в процессы и т.п. Удобный лаконичный язык. Могу еще про эрланг позавидовать и про окамл. А так всё есть. Идиоты отсеиваются, обидно что народ не много, одному писать чтолибо тяжко.

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

Они появляются оттого, что люди не знают, как сделать по-другому.

они появляются от того что так удобно.

Это возможно, когда объекты находятся на одном уровне абстракции

мой случай.

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

Очень лаконично и бесит ООП маниаков

Упс, тогда мне не подходит :). Вообще, честно скажу, года четыре назад пробовал, мне показалось очень гиковской вещью и неудобной на моих задачах.

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

Ну это не эвристика

я прямо так и сказал, написал что нету там эвристики :)

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

> В общем, для питона, похоже, самый лучший способ избежать проблем это не создавать циклические ссылки.

Более очевидный способ - не писать свой __del__.

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

> они появляются от того что так удобно.

Копипаст тоже удобнее и проще выделения общего функционала.

мой случай.

А можно пример?

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

> Более очевидный способ - не писать свой __del__.

Ну __del__ не просто же так придумали.

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

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

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

Что отстрелить позвольте? __del__ написали чтоб тот кто написал объект подумал и наиболее эффективным способом освободил все, что он захватил. В 80% он не нужен, но в 30% он помогает. Гап в 10%

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

Что отстрелить позвольте?

не позволю :)

__del__ написали чтоб тот кто написал объект подумал и наиболее эффективным способом освободил все, что он захватил.

ОМГ, эффективные деструкторы ценой утечек памяти? nowai, пусть лучше будут неэффективными

shty ★★★★★
()

>до 20 раз быстрее

когда я вижу такое, я точно уверен, что впереди прирост еще в двести раз.

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

>ОМГ, эффективные деструкторы ценой утечек памяти? nowai, пусть лучше будут неэффективными

Тут человеческий фактор. Дай дураку стеклянный х....

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

>когда я вижу такое, я точно уверен, что впереди прирост еще в двести раз.

И это правда.

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

> Он там не сломается? Хотя не дожен, а идея мне опнравилась. С какой стати сломаться должен? multiprocessing-Ом это еще и в красивую обертку за вернуть можно. Одна только проблема, если там результат вычислений еще на 1Тб, то обратно собрать его будет проблемно.

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

ОМГ, эффективные деструкторы ценой утечек памяти?

Не подмешивай проблемы конкретной реализации. Тут не от деструкторов надо избавляться, а от проблемы.

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

А можно пример?

Да легко. В дочернем классе делал self.func_old = self.func_new или типа того чтобы подменить коллбэк (долбаный aio, тогда ещё не придумали gevent). Этого хватило. Да, говнокод(давно дело было), тока попробуй определи где сдесь цикл создаётся.

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

>ОМГ, эффективные деструкторы ценой утечек памяти? nowai, пусть лучше будут неэффективными

Тут человеческий фактор. Дай дураку стеклянный х....

...а второй потеряет :)

я собственно про что и говорю, либо тут уже надо использовать стандартный функционал и не плакать, либо твёрдо знать что ты делаешь и тогда не плакать уже по другой причине

но обвинять GC в том что он не исполняет чьи то эротические фантазии и на этом мощном базисе делать заключения о годности/негодности - это через чур

да, имеет свои ограничения, да довольно простенькие алгоритмы, но плохой?..

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

Тут не от деструкторов надо избавляться, а от проблемы.

а в чём проблема - в руках, или в голове?

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

> Стать стандартным Питоном во всех дистрах :)

А срок на который намечен cpython-капец?

Не так давно пробовал fuzzy-search (нечеткий поиск, разница строк: levenstein) сравнить. Использовались списки (точнее, насколько понимаю, аdjustabje arrays). На порядок медленней.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2 3 4 5 6 7 8 →
Open Source