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

Олег.

Это сообщение отредактировал(а) 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, там ускорены асинхронные решения)