Global Interpretator Lock

 
0
 
Python
ava
GrayCardinal | 30.04.2011, 08:55
Добрый день !
Прочитал недавно про сабж. Жесть. Провел тесты на руби. Да, действительно, выполняется (одновременно) только один "поток". Пожалуйста, потестите Питон (трехтыщный) на ту же траблу. Не уверен что смогу сам написать (грамотно) тест.

Олег.
Kommentare (18)
ava
Void | 30.04.2011, 17:14 #
Цитата (GrayCardinal @ 30.4.2011, 09:55 findReferencedText)
Пожалуйста, потестите Питон (трехтыщный) на ту же траблу.

И тестить ничего не надо. В обозримом будущем GIL из Питона никуда не денется. В 3.2 его несколько оптимизировали, но все равно одновременно может исполняться только один поток (без кавычек, это реальные потоки ОС).
ava
GrayCardinal | 30.04.2011, 17:23 #
Void,
Ух. А я уже собрался на питон переходить smile
Благодарю за инфо. До последнего сомневался.
ava
Pfailed | 06.05.2011, 12:06 #
Ну тогда переходите на perl. Там нет этих самых GIL'ов
ava
MAKCim | 06.05.2011, 22:36 #
GrayCardinal,
можно юзать multiprocessing
ava
GrayCardinal | 07.05.2011, 08:16 #
MAKCim,
Это единственное, что сдерживает меня от Perl'а smile
ava
MAKCim | 07.05.2011, 13:35 #
Цитата (GrayCardinal @ 7.5.2011, 08:16 findReferencedText)
Это единственное, что сдерживает меня от Perl'а 

тогда сочувствую...серьезно
не видеть или не хотеть видеть преимуществ python'а глупо
ava
GrayCardinal | 07.05.2011, 13:56 #
MAKCim,
Ну не понимаю я его ! Не понимаю и всё. Так же как физику :(
ava
Daevaorn | 07.05.2011, 17:13 #
Цитата (GrayCardinal @ 7.5.2011, 14:56 findReferencedText)
Ну не понимаю я его ! Не понимаю и всё. Так же как физику :(

Слушайте, так это всё объясняет.
ava
bilbobagginz | 07.05.2011, 18:02 #
GrayCardinal,
давай смотреть правде в глаза: на перл ты не пересядешь (нет никакого резона на это - просто времяубийство)
а руби/питон - слишком с похожими целями, чтобы менять "то на то".
ava
GrayCardinal | 08.05.2011, 06:51 #
Я когда - то тащился от Perl'а :(
ava
Absinthe | 15.05.2011, 11:52 #
Цитата (MAKCim @ 6.5.2011, 22:36 findReferencedText)
multiprocessing

А как там с общими переменными работать?
Просто даже на обычных домашних компах уже по 4 ядра.
ava
GrayCardinal | 15.05.2011, 13:04 #
Absinthe,
Либо трубы (pipe) либо IPC.
ava
Daevaorn | 15.05.2011, 13:12 #
Цитата (Absinthe @ 15.5.2011, 12:52 findReferencedText)
А как там с общими переменными работать?

Для этого в multiprocessing есть свои примитивы -- http://docs.python.org/library/multiproces...tween-processes
ava
Skynin | 18.05.2011, 09:50 #
Цитата


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


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

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

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

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


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

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

Цитата


А если будет минимизирована работа с общими данными - то может оказаться что multiprocessing вполне подойдет.

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

Цитата


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

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

Цитата


Пока не будет предложен алгоритм не снижающий скорость выполнения однопоточной программы - GIL останется

А смысл однопоточных программ? Это значит что сети нафиг, интерфейсы нафиг...
ava
Skynin | 29.05.2011, 11:54 #
Цитата
А разве 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. Входящий в стандартную поставку.
ava
Absinthe | 29.05.2011, 14:25 #
Цитата


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

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

Цитата


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

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

Цитата


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

И удобно? Мое мнение - динамические языки неудобно использовать для подобных задач, среда не подскажет все ошибки и тестирование будет дольше по времени.
Конечно по сравнению с плюсами это будет быстрее, но почему бы не джава/дотнет?
ava
Skynin | 29.05.2011, 14:55 #
Цитата


Инструменты разработки на них(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 оказался замечательным инструментом. И наверное - лучшим, потому что самые популярные клиенты его используют.
Registrieren Sie sich oder melden Sie sich an, um schreiben zu können.
Unternehmen des Tages
Вы также можете добавить свою фирму в каталог IT-фирм, и публиковать статьи, новости, вакансии и другую информацию от имени фирмы.
Подробнее
Mitwirkende
advanced
Absenden