Python.GIL. Доколе?

фича... же

Лучше ты расскажи, чем именно тебе мешает GIL.

Парсеры, зараза, тормозят у меня. Вот прямо сейчас и тормозят. Тот самый BeautifulSoup. И ядер-то поболее одного (ажно восемь виртуальных ядер), а толку и нету.

Можно multiprocessing - так там тоже изврат. Да и не всякие данные можно запиклить опять же.

> Лучше ты расскажи, чем именно тебе мешает GIL.

Тёмная сторона Силы манит тебя, падаван.

Отвечать в стиле «А что тут плохого?» — это так в духе бздунов, лиспачей и прочего сомнительного сброда, но не Ъ-джедаев. Нет журналирования, множественных таблиц маршрутизации, драйверов WiFi? — Они не нужны. Отсутствует статическая типизация? — Она для быдлокодеров. Блокировка интерпретатора? — А что в ней плохого? Тёмная сторона Силы соблазняет тебя. Противься ей.

Если серьёзно — GIL делает программы на Python'е абсолютно не масштабируемыми в смысле SMP. Подробности здесь и здесь.

И если ты начнёшь доказывать, что SMP-масштабируемость не нужна, то, боюсь, одним джедаем на этом свете станет меньше. Не делай анонимусу грустно.

Были попытки избавиться. Но в итоге тормозило чуть ли в два раза больше. Поэтому воспринимай GIL как особенность языка, которая позволяет забыть о синхронизации и расслабиться.

SMP-масштабируемость не нужна

99% разработчикам на питоне она не нужна. Задачи просто не те.

parallel python?

Тем что мир лучше со ВСЕХ точек зрения без него

> Отвечать в стиле «А что тут плохого?» — это так в духе бздунов, лиспачей и прочего сомнительного сброда

Смотря с какой целью. Вдруг у человека вычислительная задача - тогда ему можно дать ссылку вроде http://www.scipy.org/Cookbook/Multithreading и спросить о результатах %)

А чем GIL плох «вообще», я и сам знаю.

без него все работает медленнее... не знаю уж что тут лучшего-то?

Кстати, вычислительные задачи меня тоже заставляли делать. Как раз на SciPy. Только тогда я не знал об этой ссылке и хотел сделать через multithreading. Не тут-то было, потому как объекты из SciPy отказывались по-человечески и запихиваться в тамошние map'ы. Потому у меня всё тоже с особым цинизмом тормозило. Я успевал немного погулять по коридорам своего заведения или попить чаю, пока машина что-то считала. Но я всё равно с грехом пополам посчитал и отложил горькие мысли об этом.

А теперь у меня есть много-много BeautifulSoup. Чует моё сердце, придётся мне юзать parallel-python.

Потому что ты трогаешь себя ночью.

1. Юзай lxml вместо BeautifulSoup. 2. Юзай multiprocessing вместо threading.

Не стоит благодарности. Твоя бабушка.

Обоснуй, интересно даже стало )

> Обоснуй, интересно даже стало )

Те, кто в теме, и так знают, а те, у кого праздное любопытство, строем идут в гугль.

Действительно интерестно как одно ядро стало быстрее многих. Короче понятно, не баг или кривой дизайн, без которого обошлись другие, а фича

>Действительно интерестно как одно ядро стало быстрее многих.

Меня забавляет слепая вера во всемогущий параллелизм и многоядерность =)
По идее, данный фокус должны показывать на первой лабе по курсу аля «распараллеливание вычислений», чтоб человек потом не удивлялся реальной жизни...

>Были попытки избавиться. Но в итоге тормозило чуть ли в два раза больше.

А как же Stackless?

А как же Stackless?

Я не слышал что там вычищен GIL. Поэтому не совсем понял при чем тут он.

>Я не слышал что там вычищен GIL

Ну, собственно, не раз слышал, что там с GIL проблем нет и он вполне масштабруется. EVE Online же, вроде, на Stackless, нет?

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

> Ну, собственно, не раз слышал, что там с GIL проблем нет и он вполне масштабруется.

Он масштабируется не из-за отсуствия GIL, а из-за маленьких стеков (похоже на Эрланг).

> Меня забавляет слепая вера во всемогущий параллелизм и многоядерность =)

Ну, ввели бы нам разработчики что-нибудь типа GIL.switch_on(False, если надо запиливать на многих потоках. Так нет, хрен-то.

он вполне масштабруется

Из за организации выполнения кода тасклетами. Причем (!) они всё равно выполняются в один поток. То есть утилизовать все ядра так просто не получится.

>Ну, ввели бы нам разработчики

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

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

Хотя можешь попытаться реализовать - опыт там сын ошибок трудных и все такое...

>Причем (!) они всё равно выполняются в один поток. То есть утилизовать все ядра так просто не получится.

Значит - запускать на одной машине N нод, где N = число ядер? ;)

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

За что вы так ненавидите Python?

А теперь у меня есть много-много BeautifulSoup. Чует моё сердце, придётся мне юзать parallel-python.

Объясни, что хочешь от CPython. Чтобы он тебе сам распараллелил в принципе однопоточный парсер?

>Чтобы он тебе сам распараллелил в принципе однопоточный парсер?

Зачем? Я и во много потоков работать мог бы.