Добрый день !
Прочитал недавно про сабж. Жесть. Провел тесты на руби. Да, действительно, выполняется (одновременно) только один "поток". Пожалуйста, потестите Питон (трехтыщный) на ту же траблу. Не уверен что смогу сам написать (грамотно) тест.

Олег.

Это сообщение отредактировал(а) GrayCardinal - 30.4.2011, 08:01

И тестить ничего не надо. В обозримом будущем GIL из Питона никуда не денется. В 3.2 его несколько оптимизировали, но все равно одновременно может исполняться только один поток (без кавычек, это реальные потоки ОС).

Void, 
Ух. А я уже собрался на питон переходить 
Благодарю за инфо. До последнего сомневался.

Ну тогда переходите на perl. Там нет этих самых GIL'ов

GrayCardinal, 
можно юзать multiprocessing

MAKCim, 
Это единственное, что сдерживает меня от Perl'а 

тогда сочувствую...серьезно
не видеть или не хотеть видеть преимуществ python'а глупо

MAKCim, 
Ну не понимаю я его ! Не понимаю и всё. Так же как физику :(

Слушайте, так это всё объясняет.

GrayCardinal, 
давай смотреть правде в глаза: на перл ты не пересядешь (нет никакого резона на это - просто времяубийство)
а руби/питон - слишком с похожими целями, чтобы менять "то на то".


Это сообщение отредактировал(а) bilbobagginz - 7.5.2011, 18:03

Я когда - то тащился от Perl'а :(

Это сообщение отредактировал(а) GrayCardinal - 8.5.2011, 06:52

А как там с общими переменными работать?
Просто даже на обычных домашних компах уже по 4 ядра.

Absinthe, 
Либо трубы (pipe) либо IPC.

Это сообщение отредактировал(а) GrayCardinal - 15.5.2011, 13:05

Для этого в multiprocessing есть свои примитивы -- http://docs.python.org/library/multiproces...tween-processes

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

Задач где реальное распараллеливание даст эффект не так уж много. А если обильно "с общими переменными работать" - то эффект может быть и обратный, из-за затрат на синхронизацию. Аналог здесь как работа с сервером БД - много маленьких запросов кладут его напрочь, а объединение в несколько больших запросов - ускорить может на порядки. 
А если будет минимизирована работа с общими данными - то может оказаться что multiprocessing вполне подойдет.

В основном же требуется - организация асинхронности. GIL тут особо не мешает.

Хотя я новичек в питоне, пришел с Java где реально JVM параллелит (можно потому для серверных решений пользовать Jython, там нет GILа) но с твердостью Гвидо - "Пока не будет предложен алгоритм не снижающий скорость выполнения однопоточной программы - GIL останется" - согласен. Питон и так проигрывает в скорости ввиду динамической типизации. А существующие решения дают 60% от GILовского подхода (в Stackless Python тоже GIL, там ускорены асинхронные решения)

 А разве Python применяют в прикладном ПО?
Ну за исключением всяких убунт?

 Минимизирована. Но затраты на процесс же большие? Ну и писать с использованием спец. примитивов менее удобно.

 Для этого нужен другой подход к написанию алгоритмов. Не хочется менять :(

 А смысл однопоточных программ? Это значит что сети нафиг, интерфейсы нафиг...

Все больше и чаще - в заказном ПО.

Которого простой пользователь обычно не видит.

То же самое можно ответить и на:
А разве Java применяют в прикладном ПО?
А разве C# применяют в прикладном ПО?

Посмотрите на своем компьютере - много программ у вас на Java и C#?

Массовое прикладное ПО как писалось так и будет писаться на C/C++
Хотя... клиенты для Твиттера сплошь на Adobe AIR. Там тоже нет многопоточности, но так же решена проблема с блокирующим IO (см. дальше)

Например - OpenERP - это прикладное ПО?
Оно многопользовательское, имеет клиентские р. места и на PyGTK

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


Не нужно путать асинхронность с многопоточностью, вот мой посыл.

Проблема же "сетей" даже имеет отдельное название - блокирующий IO.

На примере решений на Java где многопоточность реальная:
Крайне НЕ рекомендуется для неблокирующего IO использовать модель: каждому сокету по отдельному потоку.

Интерфейсы, какие именно ввиду, GUI или WebUI? Если первое - то все равно реализуются средствами ОСи, и потому выносу логики GIL не помеха.

Конечно, реальная многопоточность востребована. Но она то для Pythonа имеется, просто не на уровне интерпретатора 

Скажем у С/С++ тоже нет многопоточности из коробки, на уровне языка (как у Java и С#) и что, нет многопоточных программ на С/С++?

P.S.
И не нужно забывать что реальная многопоточность возможна только на многоядерных процессорах.
А если это сегодняшний 2ух ядерный процессор, то второе ядро все равно частенько будет отбираться другими программами и сервисами самой ОСи.

То есть для любого прикладного ПО, то есть выполняемого на PC или его аналоге потребность не в многопоточности а в том чтобы:
IO и логика работы не блокировали UI.

Python вполне справляется, интерпретатор отслеживает блокирующие операции IO и отдает выполнение задержанным GIL потокам. Тоже вобщем-то у wxPython, PyGTK, PyQT.
Но если логика обработки уж очень тяжелая, и хочется чтобы хотя бы иногда она выполнялась на втором ядре - тогда да multiprocessing. Входящий в стандартную поставку.


Это сообщение отредактировал(а) Skynin - 29.5.2011, 12:20

 Инструменты разработки на них(PyCharm, VisualStudio)

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

 И удобно? Мое мнение - динамические языки неудобно использовать для подобных задач, среда не подскажет все ошибки и тестирование будет дольше по времени.
Конечно по сравнению с плюсами это будет быстрее, но почему бы не джава/дотнет?

Это ПО массового использования?


Вопрос - квалификации программиста и требований к эффективности.
Тысячи потоков - будут плохо работать и на хорошем сервере, потому то в фреймворках для Java JBoss Netty и Apache Mina применяются асинхронные решения, а не "каждому сокету по отдельному потоку"

По той же причине существует Stakless Python


Это мнение не совпадает с включением в крупное бизнес ПО скриптовых языков.
Да и с мнением разработчиков игрушек, в которых нередко сценарии написаны на Lua или Python.

И давайте конкретизироваться - подобные задачи это какие?

Я говорил - о бизнес-задачах (где клиентское ПО не занимается массивными вычислениями) и о бытовом ПО, типа клиентов для веб-сервисов, где тоже нет массивных вычислений.

Вы о каком прикладном ПО с массивными вычислениями говорите?
"Фотошопе", "Автокаде",..., ?


Потому что хрестоматийное - электронный магазин быстрее написать на PHP чем на Java. Не говоря о Ruby on Rails.
В наших краях - сколько писать склад на 1С и на джаве?

И только начиная либо с определенного масштаба приложения (когда уже нужны десятки программистов) либо с высокими требованиями к эффективности выполнения - джава/дотнет.

В заказном ПО как ни в каком другом важна - скорость разработки. Просто потому что независимо от ожидаемого функционала заказчик может потратить X денех. Он не будет платить месячную зарплату в Y, а за весь продукт.
Вот и считайте - пишете ПО полгода или месяц за X денех. В каком случае ваша прибыльность, как программиста будет выше?

Ухудшение качества - это тоже вопрос квалификации программистов.

"Мы можем написать:
1. Быстро,
2. Дешево, 
3. Качественно.
Выберите любые 2 но только 2 пункта"

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

Так вот ЯП с динамической типизацией обеспечивают пункты 1 и 2
3ий - за счет уровня программистов, и/или "тестирования на самом заказчике"

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

Потому в гуглах и яндексах внутренного софта полно на питоне. И GIL - не помеха.

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

P.S.
Я делю ПО комбинацией - коробочное/заказное, системное/прикладное
Итого 4ре вида

Спольски по другому, и мне тоже нравится, (мое деление разрешает пересечение):
Я считаю, что в программировании есть пять миров, иногда пересекающихся друг с другом, а в основном нет. Это:
Ширпотреб 
Внутреннее ПО 
Встроенное ПО 
Игры 
Одноразовое ПО
Пять миров

Так вот ЯП с динамической типизацией очевидно хороши для:
заказное - прикладное

Или
Внутреннее ПО, Одноразовое ПО

В остальных случаях - нужно анализировать дополнительные требования к задаче.
Как уже сказал, для 
коробочно - прикладного Ширпотреба в виде клиента к Твиттеру - Adobe AIR оказался замечательным инструментом. И наверное - лучшим, потому что самые популярные клиенты его используют.

Это сообщение отредактировал(а) Skynin - 29.5.2011, 15:07