dmz>>может сделать код, написанный по умолчанию на С++ — ных потоках.
C>Из этого кода нельзя делать вызовы в интерпретатор. Даже банальные AddRef/Release на питоновских объектов работать не будет!!!

Не понял.

dmz>>часть времени проводит в цикле ожидания данных из базы — то не все ли равно, на каком языке он ожидает?
C>Не всё равно.

Убедительно.

Здравствуйте, dmz, Вы писали:

C>>Из этого кода нельзя делать вызовы в интерпретатор. Даже банальные AddRef/Release на питоновских объектов работать не будет!!!
dmz>Не понял.
Python использует не-threadsafe счётчик ссылок. Поэтому если ты будешь делать AddRef/Release на питоновских объектах без взятого GIL — получишь оооочень интересные эффекты.

dmz>>>часть времени проводит в цикле ожидания данных из базы — то не все ли равно, на каком языке он ожидает?
C>>Не всё равно.
dmz>Убедительно.
Ну да.

C>>>Из этого кода нельзя делать вызовы в интерпретатор. Даже банальные AddRef/Release на питоновских объектов работать не будет!!!
dmz>>Не понял.
C>Python использует не-threadsafe счётчик ссылок. Поэтому если ты будешь делать AddRef/Release на питоновских объектах без взятого GIL — получишь оооочень интересные эффекты.

Ээ, а что надо делать, что бы вырубить GIL ? И кто предлагает его не брать?

В общем-то, про GIL мне известно. Так же известно, что производительность с ним получается вполне удовлетворительная (собственно, я привел), а также никуда не девается возможность увеличения процессов/разнесения по нодам — у нас же веб. Более того, если ВДРУГ именно питон для какой-то задачи стал боттлнеком — почему не вынести эту задачу куда угодно в отдельный сервис — и работать с ним отдельно.

Конечно, в плане concurrency питон заранее сливает целой пачке языков; Но если для конкретной задачи это некритично — то что мешает им пользоваться — тем более, что скорость разработки действительно оч. высокая.

Здравствуйте, dmz, Вы писали:

C>>Python использует не-threadsafe счётчик ссылок. Поэтому если ты будешь делать AddRef/Release на питоновских объектах без взятого GIL — получишь оооочень интересные эффекты.
dmz>Ээ, а что надо делать, что бы вырубить GIL ?
А ничего. Он обязателен.

dmz>И кто предлагает его не брать?
А если брать — то вдруг пропадёт многопоточность.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, FR, Вы писали:

FR>>Угу только GUI питоные и субъективно и объективно работают шустрее явовских, понятно что за счет C++ библиотек.
C>Они работают за счёт использования нативных библиотек. Если использовать SWT в Java — то ты разницы не заметишь.

Приходилось одновременно пользоватся Еclipse, и недоделаным Boo, может и субъективно но у питоновскго отклик, был гораздо шустрее.

FR>>Ну и всякие расчетны программки c библиотеками типа NumPy тоже бывают шустрее.
C>Даже близко не быстрее.

Спорить не буду, но близко точно, там же практически 99% времени крутится оптимизированный сишный код.

FR>>А GIL сейчас модно обходить запуском новых процессов http://pypi.python.org/pypi/processing
C>Не всегда доступно.

Да ну где это недоступно?
В 2.6 подобный модуль уже стандартный http://docs.python.org/library/multiprocessing.html
Ну и плюс легкая реализация легких потоков через генераторы.

Здравствуйте, Cyberax, Вы писали:

C>>>Python использует не-threadsafe счётчик ссылок. Поэтому если ты будешь делать AddRef/Release на питоновских объектах без взятого GIL — получишь оооочень интересные эффекты.
dmz>>Ээ, а что надо делать, что бы вырубить GIL ?
C>А ничего. Он обязателен.

Не совсем http://www.stackless.com/

Здравствуйте, FR, Вы писали:

C>>А ничего. Он обязателен.
FR>Не совсем http://www.stackless.com/
Там тоже GIL

Здравствуйте, FR, Вы писали:

C>>Они работают за счёт использования нативных библиотек. Если использовать SWT в Java — то ты разницы не заметишь.
FR>Приходилось одновременно пользоватся Еclipse, и недоделаным Boo, может и субъективно но у питоновскго отклик, был гораздо шустрее.
Значит Eclipse больше делала в фоне. Так как разницы в отклике на простые операции взяться просто неоткуда.

FR>>>А GIL сейчас модно обходить запуском новых процессов http://pypi.python.org/pypi/processing
C>>Не всегда доступно.
FR>Да ну где это недоступно?
На Windows, например, оно будет ОЧЕНЬ тормозить. Так как создание процессов — весьма недёшево.

Опять же, не всё можно сделать через простой интерфейс в shared memory.

FR>В 2.6 подобный модуль уже стандартный http://docs.python.org/library/multiprocessing.html
FR>Ну и плюс легкая реализация легких потоков через генераторы.
Это не потоки, а сопроцедуры. Т.е. они не выполняются реально параллельно.

Здравствуйте, Cyberax, Вы писали:

C>Значит Eclipse больше делала в фоне. Так как разницы в отклике на простые операции взяться просто неоткуда.

Ну под С++ Eclipse почти ничего и не делает.

C>На Windows, например, оно будет ОЧЕНЬ тормозить. Так как создание процессов — весьма недёшево.

Там используется пул процессов.

C>Опять же, не всё можно сделать через простой интерфейс в shared memory.

Там ограничений мало.

C>Это не потоки, а сопроцедуры. Т.е. они не выполняются реально параллельно.

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

Здравствуйте, Cyberax, Вы писали:
C>Там тоже GIL

Мммм. Я конечно тормоз, но как же IronPython? Wiki говорит, что там нету GIL'а.