0xd34df00d
15.07.2011 10:41 Azoth_primary
Питон все еще говно, или его интерпретатор уже хотя бы можно дергать из нескольких тредов сразу?
72 comments
recommend
bookmark
subscribeDo you really want to delete ?
- within threads
- within tags
- within users
сейчас набижит @uidtko и скажет что надо делать кучку процессов вместо кучки тредов
Посмотрим.
как будто между этими вариантами есть какая-то принципиальная разница.
да. у тредов общая память, что позволяет работать с объёмными данными из разных тредов без передачи их туда-сюда через ядро
писечку подергай чтоли
shmget(2)
хотя зачем, mmap(2), MAP_SHARED.
И все нахуй туда класть. Говнище. Кутишные объекты ж напрямую не поддерживают шмем, нужно сериализовать туда-сюда, но зачем? Есть же треды, а ограничения тупого языка не нужны :3
тоже вариант, вобщем-то, но менее удобно чем треды
СЛИШКОМ ДЕДФУТО
Ты как вообще скрещиваешь питон, плюсы и кути? И, главное, зачем?
Через PyQt + рантайм-магию в плюсах. Все выглядит так, будто я в плюсах в рантайме генерю объекты :3
Зачем — для поддержки скриптинга, обв.
тебе в скриптинге всенепременно обязательно нужен мультитрединг?..
Да, я страницы парсю в отдельном треде в рсс-читалке.
скриптами?
В том числе. Бывают тупые скрипты, которые просто CSS-селекторы отдают, и тогда я парсю из плюсокода, но все равно в отдельном треде, а могут быть умные, которые парсят все сами.
предвижу я тёмной стороны искушение в вопросе этом.
охуеть просто. особенно если положить в шмем объекты созданные в рамках какого-либо контекста. замечательно просто они будут обращаться к нему при необходимости.
Хочу расширить я зону охвата мозгов юных неокрепших личкрафтами.
Typical python-dev.
Ну и вообще $anything-obsessed-dev.
вопрос был о принципиальном различии параллелизма несколькими тредами и несколькими процессами. Я подчёркиваю, о принципиальном различии (коего нет).
я тебе про принципиальное различие между тредами и процессами и описываю. взаимосвязанные объекты теряют связь между собой если запихивать их в шмем.
растление малолетних личкрафтами, в составе группы лиц, по предварительному сговору? ты злодей.
тогда мапишь ещё немножко виртуальной памяти — и всё у тебя хорошо. Ещё раз повторю: принципиальной разницы нет.
В общем так.
1) GIL из питона убирать никто не собирается, повидимому. Это неизбежная необходимость.
2) На время блокирующего IO, тяжёлых FFI вызовов (numpy, всевозможный image processing) GIL отпускается. То есть, одновременно не могут выполнятся _питоновые байткоды_, но всё что бегает под ними — обычно может.
3) Левые треды эмбеддящего интерпретатор приложения, естественно, никоим образом не затрагивают GIL. Если тред не делает вызовов python api — для GIL этого треда нет.
хм, нет, вру. Unlaiden Shallow что-то там пытаются выпилить из 2.x ветки. Всё ещё work in progress.
R!
Да вообще все данные в один большой кусок шмема запихни, чо. Зато GIL.
1. ... вызванная криворукостью Гвидо и прочих.
2. А тут над ними.
3. А у меня меин-тред, к сожалению, делает. :(
Ну вот не надо о криворукости. Я вон тут уже вычитал, как в том же перле сделан «мультитрединг».
А никто не говорил про пёрл.
у меня есть сильная неуверенность, что синхронизацию можно было сделать как-то иначе, не затратив на два порядка больше человеко-часов, и одновременно не сделав производительность хуже.
%%в перловом «мультитрединге» нет shared memory, вообще. память приватная и копируется при создании треда%%
кстати, ты не начинал ещё думать в сторону выставления сервисов D-Bus? :3
оценку человекочасов предоставь тому кто их потратить. и прекрати тыкать перлом, ты в приличном обществе как-никак
У хаскелеёбов в этом плане хороший подход: париться и страдать должны разработчики компиляторов, а не пользователи. И это хорошо.
Да што ты мне свой перл тут тыкаешь, я его даже не осиливал.
а, простите.
Сейчас поищу, где в интерпретаторах как сделана синхронизация.
Начал, чо-то выставляется даже, но я слабо представляю, зачем, и чо дальше с этим делать.
Судя по /1 и тому, что Гелраен — рубиёб, поищи в рубях.
в интерпретаторе эрланга, например. нет?
эрланг не подходит, лол.
для чего не подходит?
Поцчему?
потому что зелёные треды же, ну.
Што.
хуя, оно вполне и на smp паралелится
ну, там свой планировщик же. В котором можно обеспечить любой желаемый уровень атомарности; в итоге синхронизация получается совсем нахаляву.
из живых интерпретаторов native threads умеет только jruby
Ну и что?
в рубях тоже GIL :cf:
ну и то, блеадь. Зделал в планировщике incref/decref атомарно — и уже синхронизировать подсчёт ссылок не нужно.
в jruby, емнип, нет. а reference implementation вообще не умеет порождать треды
Нет тредов — нет проблем.
да, ты прав.
> JVM-based equivalents of these languages (Jython and JRuby) are pure Java applications, so they don't have any limits on threading.
http://en.wikipedia.org/wiki/Global_Inte...
кстати вот, да.
ага, и scalability на N процессоров тоже нету, ага.
multiprocessing... /._.\
нет питона — нет проблем. зато есть треды, проверка типов на этапе компиляции, производительность и экономия ресурсов.
да, я так и выкручивался когда надо было, благо данных не сильно много надо было между ними гонять.
Это ты щас про плюсы сказал про проверку типов?
да. не знаю как дело обстоит в этих ваших кутях, а у меня скомпилировалось — значит работает. ... ну или сразу сегфолтится.
Ок-ок.
я бы назвал нативные треды самой коварной практикой в погромизме.
Новичкам при знакомстве с тредами обычно всё очень красиво и понятно — ну хуле, вот выполняется, и одновременно там выполняется. При этом строчки кода и даже простые выражения воспринимаются как атомарные операции. И только потом, когда написано уже дохуя, начинаются непонятные глюки и дедлоки. Отлавливать их — одно сплошное удовольствие; при этом ты один-на-один с кодом. Никаких автоматических средств. Только код, красиво разложенный по красивым тредам с красиво проглядывающим сквозь строчки тролфейсом.
Ряд нетривиальных подводных камней в синхронизации — плата за иллюзорно красивый мультитрединг. Асинхронный код полущ.
здесь новичков нет. здесь люди в уме дебажат программы на сотню потоков.
все ошибаются, все. Постоянно.
ок, если тебя это парит — бросай программирование. иди туда где ошибиться нельзя. например, в сапёры, больше одного раза не ошибёшься.
> производительность и экономия ресурсов
Если и экономия, то разве что вычислительных ресурсов. Человеческие ресурсы плюсы не экономят, совсем.
Да, столько неквалифицированной рабочей кодерской силы пропадает.
лучше пойду в профессиональные тролли, там хоть научат, как любую ошибку выдать за намеренные манипуляции окружающими.
Анус себе выдай, ПЕС.
а сколько КВАЛИФИЦИРОВАННОЙ рабочей кодерской силы КОМПИЛИРУЕТ ПЛЮСОКОД ПО ТРИ РАЗА В ДЕНЬ АРРРГХХХХ!!!
бугурт.
Мало. Они его чаще компилируют.
да, я знаю. И дольше. Намного дольше.
И рефакторят, и читают угловые скобки, и пишут эксплиситные копи-конструкторы. Блядь, блядь, блядь. Аргх.
ШТО