Объясните мне, чем вам не угодил multiprocessing?

Лишняя память, это раз. Невозможность разделять адрессное пространство - это два.

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

Для такого объёма данных, пожалуй. Я не специалист в web. При решении чисто вычислительных задач одновременно грузить в память более 100Mb приходится ооочень редко. Как следствие, памяти действительно уходит больше, но это некритично.

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

А ты не улыбайся, а просто цифру назови.

А ты угадай с трех раз. И еще на досуге подумай, почему это не важно.

worker - это отдельный процесс в смысле процесса ОС?

Именно. Для веб-задач это стандартный паттерн.

Если нужно IPC между процессами то multiprocessing с очередями итп. Работает через shmem.

эти гринлеты - это какие-то костыли

Наоборот избавление от тех костылей что навязываются aio(всякие коллбэки итп).

сколько гринлетов можно исполнять параллельно на потоках ОС?

Ммм, gevent.fork() и вперёд :)

обгон может быть получен за счет другого принципа реализации

И так в каждой версии!

А теперь представь, что интерпретатор начал исполнение долгоиграющего запроса к базе, все остальные 1000 потоков тупо заблокированы

Nope. man select.

Про базу может был и не удачный пример, но что делать с файловым I/O? Я вот не припомню, чтобы там была польза от select. Переходить на AIO? Это уже весело может получиться.

> Адресное пространство разделять можно частично.

Что-то я слабо представляю, как в питоне это работает. Данные объекта еще можно разделить. А вот структуру? Счетчики поддерживать когюретно по всем потокам? Сомнительно это.

> И так в каждой версии!

Я вообще про json говорил. А то что каждая версия быстрее, говорит лишь об одном - классчиеский питон очень медленный.

Разработчики на Django слушают тебя с недоумением)))))

Что-то я слабо представляю, как в питоне это работает. Данные объекта еще можно разделить. А вот структуру? Счетчики поддерживать когюретно по всем потокам? Сомнительно это.

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

Про базу может был и не удачный пример, но что делать с файловым I/O?

Я неудачно выразился. При любом IO питон переключает на другие потоки.

> В руководстве написано, что можно разделять простые типы: массивы чисел и строки. Для этого их нужно соответствующим образом объявить.

Во, то есть разделение данных. В общем это все «костыль». Но часто это и не надо.

Этим пользовались 15 лет назад, когда не было эффективной поддержки ядром SMP систем, поскольку такое железо было экзотикой. Использование процессов для эмуляции потоков сейчас выглядить редким идиотизмом, особенно для линукса и особенно для задач, требующих высокой производительности.

> А теперь представь, что интерпретатор начал исполнение долгоиграющего запроса к базе, все остальные 1000 потоков тупо заблокированы, возникает вопрос о какой маштабируемости тут может идти речь?

При выполнении системных вызовов типа чтения-записи в файловый дескриптор GIL освобождается.

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

Во, то есть разделение данных. В общем это все «костыль». Но часто это и не надо.

Мне это особо не надо. Я действую достаточно просто: процесс создаётся, ещё выделяется функция на выполнение, туда передаётся очередь --- экземпляр класса Queue, из неё забираются нужные данные (часть данных общие для класса), расчёты производятся, результаты помещаются в очередь и возвращаются главному потоку. При времени выполнения такого потока в несколько секунд затраты на создание и обмен данными пренебрежимо малы.

вот это является узким местом

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

А где мне его выполнять? Если параметры следущего запроса зависят от этих вычислений? Но я хочу его выполнять параллельно, то есть запустил поток и забыл про него, когда данные становятся нужны - я их просто достаю из объекта.

И что он делает? То, о чём ты думаешь, возможно только если внутренний FIO сделан через AIO.

Я вообще про json говорил. А то что каждая версия быстрее, говорит лишь об одном - классчиеский питон очень медленный.

Ну так изменение алгоритма никак не связано с языком реализации в данном случае то. Т.е. тот же изменённый алгоритм на CPython будет так же быстрее.

В *большинстве* *веб* приложений узкое место — бд

Это если само приложение нифига толком не делает. БД как раз можно, зачастую, оптимизировать.

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

Расскажите это Брайту и Александреску. Они специально сделали потоки изолированными по пространству имён и велят в явном виде описывать, какие переменные общие.

> Ну так изменение алгоритма никак не связано с языком реализации в данном случае то. Т.е. тот же изменённый алгоритм на CPython будет так же быстрее.

CPythone медлененее PyPy. На нем реализация чего-то оказалась мделенее, чем аналогичные действия на С, но с другой релаизацией. А вот на PyPy оказалось быстрее.

То, о чём ты думаешь, возможно только если внутренний FIO сделан через AIO.

Shimon же дал верное пояснение. Перед началом блокирующего IO освобождается GIL. Так что AIO здесь не при делах.

А где мне его выполнять?

В случае с питоном, в отдельном процессе, очевидно.

Это если само приложение нифига толком не делает.

Таких приложений большинство. Тупые мордочки по доставанию данных из бд и вкорячиванию переменных в шаблоны. О том и речь.

>> Я указал, что multiprocessing к многопоточности отношения не имеет.

Это есть неверное суждение, либо вы используете специфичную терминологию.

Случай, что неправильную терминологию используешь ты, не рассматривается?

Multiprocessing повторяет функциональность threading почти полностью

Я не хуже тебя знаю, что такое multiprocessing. Он может сколько угодно повторять API модуля threading, но нити запускаются в едином адресном пространстве, а процессы - нет.

Поэтому я считаю, что вы совершенно напрасно вводите людей в заблуждение

А я считаю, что ты не освоил базовых понятий многозадачности и базовых навыков чтения.

>потоки изолированными по пространству имён

Не понял эту мысль. Все потоки в линуксе сделаны на базе pthreads, а там вроде нет пространства имен, или я чего то пропустил? И при чем тут Александреску?

>генерацию HTML из кода (т.е. не print «<BR>», а html->br()).

(response/xexpr '(html (head (title «My Blog»)) (body (h1 «Under construction»))))

Короче, Python — 1991, Perl — 1987. Вопросы?

Lisp - 1958, ну ты понял.

А как узнать, что данные готовы и передать указатель на объект содержащий результаты из одного процесса в другой, после смерти этого «отдельного» процесса?

Я не хуже тебя знаю, что такое multiprocessing.

Пока вы не подтвердили это суждение ни одним высказыванием.

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

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

А я считаю, что ты не освоил базовых понятий многозадачности

Это ваше мнение мне безразлично, потому что у меня программы работают нужным мне способом и распараллеливание происходит.

и базовых навыков чтения.

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

Привет Пёрл и Раби

Класс, скоро у Пистона будет JIT. Привет Пёрл и Раби.

> Lisp - 1958, ну ты понял

Ну то же LISP, а не «There's more than one way to screw it up»

А как узнать, что данные готовы и передать указатель на объект содержащий результаты из одного процесса в другой, после смерти этого «отдельного» процесса?

Для этого есть тысяча способов. Тот же multiprocessing предоставляет удобные абстракции.

Не понял эту мысль. Все потоки в линуксе сделаны на базе pthreads, а там вроде нет пространства имен, или я чего то пропустил? И при чем тут Александреску?

Я плохо выразился. При проектировании языка D по умолчанию они специально запретили обращение к переменным из разных потоков, если вы хотите использовать одну и ту же переменную в нескольких потоках, вы должны это декларировать явно. Хотя физическое разделение памяти не происходит, потоки работают в одном пространстве памяти, логическое разделение имеет место.

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

Зависит от многих условий. Для тебя - может быть, и несущественно.

Хамство может считаться признаком крутизны только в весьма специфических коллективах

Ты это начал.

я рад, что не работаю с вами в одном и том же.

А тебе это было бы полезно.

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

Утиные истории. Сам таким был, понимаю. На практике, отличия multiprocessing от threading надо досконально знать. От деталей там никак не абстрагироваться.

Мне страшно интересно, а какой смысл имеет указатель на объект в другом адресном пространстве другого процесса?

Мне страшно интересно, а какой смысл имеет указатель на объект в другом адресном пространстве другого процесса?

Дополнительного смысла, по сравнению с процессом родителем, не появляется.

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

Ну да, ну да. Особенно это видно по современным надежным программам....

классчиеский питон очень медленный

клинический тормоз - очень медленный

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

>вы должны это декларировать явно

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

Расскажите это Брайту и Александреску.

только после того как они допилят свою поделку, то есть - никогда

> Компилятор автоматически создаст примитив синхронизации и сделает доступ к переменной безопасным?

Ровно наоборот. Если переменная не помечена как shared, она считается локальной для нити, и компилятор генерирует соотвествующий код. Если она помечена как shared, она, внезапно, shared :) И компилятор генерирует другой код.

Lisp - 1958, ну ты понял

Ну то же LISP, а не «There's more than one way to screw it up»

то есть LISP - это «One way to screw it up»?

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

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

PyPy быстрее

Семафор или что, то подобное.

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

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

В простейшем случае это сериализация через пайп. Но multiprocessing умеет shmem.