Python 3.2.1

Ладно. Был неправ, исправлюсь: IronPython, но да, реализаций питона без GIL реально мало.

утвердили же

Видать, что то мешает werkzeug стать python3 совместимым.

ЕМНИМ, сейчас только в cherrypy и mod_wsgi есть экспериментальная поддержка.

Не тому это говоришь. Перечитай тред.

> Вы про UnladenSwallow? Я из гугловских пистонов знаю только его. Там вроде признали, что делать надо много и интерес гугла пропадает.

Я про pypy. http://pypy.org . UnladenSwallow — это попытка сделать из CPython скоростного монстра. А pypy — это успешная попытка сделать свой питон с Tracing JIT'ом (как в TraceMonkey).

давно уже.

В 3.2, ага.

> Ладно. Был неправ, исправлюсь: IronPython, но да, реализаций питона без GIL реально мало.

Потому что они не нужны. Были бы нужны (ценой замедления в 2 раза) — давно бы были.

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

Само по себе наличие или отсутствие GIL ничего не значит. Важна производительность в многопоточных программах. Если ее смогут подтянуть до приемлемого уровня (когда переводить некоторые типичные задачи на несколько потоков станет выгодно), уже будет не важно, есть там GIL или нет.

> > утвердили же

Видать, что то мешает werkzeug стать python3 совместимым.

http://lucumr.pocoo.org/2011/1/22/python-the-web-and-little-things/

В основном проблема та же — никто python 3 не пользуется, потому спешить некуда. А так, вроде потихоньку собираются таки сделать flask для python 3.

Не тому, сорри.

> В 3.2, ага.

20 февраля) Давненько.

> Само по себе наличие или отсутствие GIL ничего не значит. Важна производительность в многопоточных программах. Если ее смогут подтянуть до приемлемого уровня (когда переводить некоторые типичные задачи на несколько потоков станет выгодно), уже будет не важно, есть там GIL или нет.

Чего? Ты сам-то понял что сказал?

В основном проблема та же — никто python 3 не пользуется

Замкнутый круг, никто не пользуется, потому-что ничего и нет.

Хотя, я абсолютно не страдаю, даже наоборот, от необходимости держать py3k ветку supplement, один геморрой.

> Замкнутый круг, никто не пользуется, потому-что ничего и нет.

Просто python 2 настолько хорош, что python 3 не нужен пока что никому. Вон бедный Пиллигрим, жаловался, что от книги dive into python 3 только убытки получил :-)

На самом деле потихоньку все больше пакетов подпиливаются под 2to3. И как только достаточное количество будут «готовы» — будет некоторый рывок.

> Важна производительность в многопоточных программах.

Кому важна? Только не рассказывай, что ты писал производительные многопоточные программы. Мне, например, намного важней производительность однопоточной программы.

P.S. Задолбали уже обсуждать этот чертов GIL, кому нужна производительность, тот уже давно использует multiprocessing.

Ммм… А как с этим связаны модули расширений .so?

А как с этим связаны модули расширений .so?

Никак, автор новости наркоман.

Для сишных расширений появилась возможность шарить их между разными версиями интерпретатора.

Задолбали уже обсуждать этот чертов GIL

+++

Лучше бы уже телегу про отступы завели, гораздо более животрепещущая тема.

> Никак, автор новости наркоман.

Для сишных расширений появилась возможность шарить их между разными версиями интерпретатора.

Да нет же. Имеется в виду ABI version tagged .so files . Не наркоман никто)

> Ммм… А как с этим связаны модули расширений .so?

Ну вот собрал ты одно расширение для питона 2.6, а другое для 2.7. Так вот теперь они будут называться по-разному (с метками 26 и 27 соотв).

А ABI — это о том, что .so для 3.2.1 подойдёт и для 3.2.2 и т.д. (возможно и 3.3).

Или что ты имел в виду?

Не наркоман никто

ТС в одном предложении объединил pyc repositories с сошками.

Ну там две ссылки на PEP'ы и впринципе и то и другое решает одну и ту же проблему, только so сделали зависимыми от версии ABI, а pyc от интерпретатора и его версии. А проблема одна и та же решилась.

Django не нужна! Можно юзать Pylons.
WSGI не нужен - WebOb уже давно поддерживает python3.

Для себя я только PasteScript не нашёл для python3.

>А он-то тут при чем? В нем GIL прекрасно поживает.

Не помню, но кажется стэклесс как раз и делали для массовой паралельности. Как тогда они с GIL?

Вообще как там написал Java апологет? Он вроде говорил, что он сам не сможет написать надежную программу с потоками

>WSGI не нужен - WebOb уже давно поддерживает python3.

The primary object in WebOb is webob.Request, a wrapper around a WSGI environment.

Что там используется вместо WSGI?

Кому важна? Только не рассказывай, что ты писал производительные многопоточные программы. Мне, например, намного важней производительность однопоточной программы.

Да, писал, но не на питоне. И я уже упоминал тут, что задачи бывают разные. Некоторые необходимо решать в несколько потоков и хотелось бы, чтоб они были не медленнее, чем однопоточные. Хотя тут про мультипроцессинг какой-то говорят. Я еще не дошел до этой части питона, но подозреваю, что это простой запуск нескольких инстансов питона с организацией межпроцессного взаимодействия... Ничего по этому поводу не могу сказать. Вот дочитаю, осмыслю, тогда и мысли будут.

В стеклесс, иесли верить википедии, используются не обычные потоки, а какие-то загадочные микропотоки с ручным управлением этими микропотоками (в обход GIL?). Видимо фишка в этом.

Вообще ни на си, ни на питоне нельзя легко писать потокобезопасные приложения. Эти языки просто не приспособлены для этого.

Лучше бы уже телегу про отступы завели, гораздо более животрепещущая тема.

А чем вас отступы не устраивают? Меня лично от них коробило лишь первые два дня изучения языка, а потом привык. Не сказал бы, что жутко удобно, но и проблем серьезных не вижу. Это если ненормальных, которые табами пользуются при разметке кода, исключить из рассмотрения. Цель - повысить читаемость кода. Мне кажется, она достигнута.

> Не помню, но кажется стэклесс как раз и делали для массовой паралельности. Как тогда они с GIL?

Зато я помню. Его делали для зеленых потоков (greenlet потом выпилили в отдельную библиотеку вроде), сигналов (вот это крутая фича). Короче обычный себе concurrency, а никак не параллельные вычисления.

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

Это такая библиотека, полностью имитирующая библиотеку threading, только реализующая это всё через процессы, а не потоки.

python 2 и так хорош. Так что подождем.

полностью согласен, но ведь пишут гады о невероятной производительности и ускорении ;)))

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

GIL полностью не избавляет от ручной синхронизации.

> В стеклесс, иесли верить википедии, используются не обычные потоки, а какие-то загадочные микропотоки с ручным управлением этими микропотоками (в обход GIL?). Видимо фишка в этом.

Господи. Перестаньте нести ересь) GIL был есть и будет, а эти микропотоки — это обыкновенные зеленые потоки, где можно руками переключаться дальше. Только целый отдельный интерпретатор сделали чтоб еще можно было указать куда конкретно переключаться (на какой поток), просто указав имя функции, а еще поддержку сигналов/слотов (короче erlang такой себе).

> полностью согласен, но ведь пишут гады о невероятной производительности и ускорении ;)))


pypy быстрее, так что не нужен, не нужен))

Если это работает прозрачно для разработчика, то замечательно и пофиг на потоки. И на GIL тоже.

> GIL полностью не избавляет от ручной синхронизации.

кстати да, тоже думаю что меня смущало в этом посте

>GIL полностью не избавляет от ручной синхронизации.

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

В общем я про GIL узнал исключительно из воплей на форумах. В остальном ооооочень часто можно поднять производительность просто изменив алгоритмы. Я вот повышал в 10 раз изменяя три четыре строки

А чем вас отступы не устраивают?

Ограничения же. А душа свободного художника их не приемлет ^_^ И различать где блок закончился невероятно сложно. А некоторые вообще баги в модули вносят, отступив не то количество пробелов — форменный кошмар!

Отступы — наименьшее из уродств Python'а.

Отступы — наименьшее из уродств Python'а.

А мы вас уже заждались. Чай? Кофе? Специальная троллячья еда?

pypy быстрее, так что не нужен, не нужен))

пока у меня с pypy вся хренотень не взлетает, тонкие эффекты которые нет времени протыкать и понять ;( печалька

>Дополнительный оверхед на синхронизацию

Не понял. А сейчас в питоне синхронизация вообще не нужна? GIL не может передать управление другому потоку посреди критической секции?

> Не понял. А сейчас в питоне синхронизация вообще не нужна? GIL не может передать управление другому потоку посреди критической секции?

Кто сказал вообще не нужна? Дополнительная.

> Ограничения же. А душа свободного художника их не приемлет ^_^

Не всем еще свободным художникам, не оформляющим отступами код руки поотрывали? Жаль.

А сейчас в питоне синхронизация вообще не нужна?

Нужна конечно. Но ввиду того, что на потоках на питоне мало что пишется, кода с локами исчезающе мало.

>>Новая библиотека futures для работы с потоками и процессами в рамках конкурентного программирования (PEP 3148)

GIL GIL GIL

Если futures будет запускать вычисления в отдельном процессе, проблем с GIL'ом не будет

посреди критической секции?

Вообще, это серьезная проблема, GIL сильно убаюкивает, и проглядеть рейс довольно таки легко.

> У меня при переходе на 8 потоков производительность C программы упала в два раза. Все зависит от задачи. У меня было перемножение матриц размером 300мегабайт

Метод хоть блочный был? Уж очень похоже на затык по скорости доступа к памяти.

Это такая библиотека, полностью имитирующая библиотеку threading, только реализующая это всё через процессы, а не потоки.

Кроме того multiprocess предоставляет уже готовые реализации пулов, каналов очередей.

Пример из документации:

from multiprocessing import Pool

def f(x):
    return x*x

if __name__ == '__main__':
    pool = Pool(processes=4)              # start 4 worker processes

    result = pool.apply_async(f, (10,))    # evaluate "f(10)" asynchronously
    print result.get(timeout=1)           # prints "100" unless your computer is *very* slow

    print pool.map(f, range(10))          # prints "[0, 1, 4,..., 81]"

    it = pool.imap(f, range(10))
    print it.next()                       # prints "0"
    print it.next()                       # prints "1"
    print it.next(timeout=1)              # prints "4" unless your computer is *very* slow

    import time
    result = pool.apply_async(time.sleep, (10,))
    print result.get(timeout=1)           # raises TimeoutError

>Метод хоть блочный был? Уж очень похоже на затык по скорости доступа к памяти.

Именно. А точнее кеш потоки засирали. Это учебная фигня была. Когда народ писал как массив поинтеров на массивы у них потоки ускоряли. А я вектор делал

> 2) Используйте уже не потоки, а эффективное межпроцессорное взаимодействие.

Межпроцессное же