The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Проект по интеграции поддержки многопоточности в Python и релиз PyPy 1.3

26.06.2010 10:36

В рамках проекта "newthreading" подготовлен прототип решения для добавления поддержки многопоточности в интерпретатор языка программирования Python, параллельное выполнение классов в котором ограничено из-за применения глобальной блокировки (GIL - Global Interpreter Lock). Начальная реализация технологии newthreading написана в виде модуля на языке Python и не обеспечивает заметного роста производительности, демонстрируя лишь принцип работы предложенной концепции.

API модуля "newthreading" включает реализацию функций стандартного модуля "threading", расширяя их дополнительными средствами для организации синхронизации между параллельно выполняющимися классами. Модулем поддерживаются понятия "атомарный объект" и "синхронизированный объект", реализуемые через классы AtomicObject и SynchronizedObject. Основная идея состоит в том, что создаваемые пользователями классы, если они являются потомками SynchronizedObject, автоматически устанавливают блокировку при входе в класс и снимают ее при выходе или при ситуации блокировки потока внутри класса. Соответственно при таком подходе полностью исключается ситуация одновременной активности двух потоков при выполнении одного класса. Дополнительно, внешние объекты могут передаваться (или приниматься) в SynchronizedObject-объекты только после их перевода в специальное состояние заморозки ("frozen").

Основным недостатком предложенного метода является нарушение совместимости с текущей реализацией Python при организации многопоточной работы. Разработчики отмечают, что частично проблема решается тем, что при выполнении однопоточных программ семантика Python полностью сохраняется, но при задействовании механизма многопоточности правила меняются и некоторые из динамических возможностей языка отключаются.

В заключение, можно отметить выход релиза проекта PyPy 1.3, в рамках которого разрабатывается реализации языка Python, написанная на языке Python. Несмотря на абсурдность подобной идеи на первый взгляд, благодаря задействованию JIT-компилятора, на лету транслирующего некоторые элементы в машинный код, минуя фазу интерпретации байткода в виртуальной машине, PyPy при выполнении некоторых операций в несколько раз обогняет по производительности классическую реализацию Python на языке Си. Ценой высокой производительности и использования JIT-компиляции является заметно более высокое потребление памяти.

В PyPy также поддерживается бесстековый (Stackless) режим работы, позволяющий добиться массового параллельного выполнения микро-нитей (micro-threads). Для выполнения кода к которому нет доверия реализован режим изолированного выполнения, отличающегося от sandbox в CPython полной поддержкой всех возможностей языка, без выделения unsafe-функций. Дополнительно на базе технологий PyPy созданы бэкенды для генерации в PyPy байткода для LLVM и виртуальных машин .NET/CLI и Java. Отдельно на базе PyPy ведется разработка реализаций на языке Python интерпретаторов Prolog, Smalltalk, JavaScript, Io и Scheme.

В новой версии PyPy добавлена тестовая возможность загрузки расширяющих функциональность модулей, написанных на языке Си для CPython. Другим важным улучшением PyPy 1.3 является проведение большой работы по оптимизации и стабилизации кода JIT-компилятора.

  1. Главная ссылка к новости (http://mail.python.org/piperma...)
Лицензия: CC-BY
Тип: К сведению
Ключевые слова: pythpn, thread
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (27) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, brzm (?), 11:54, 26/06/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Поправьте меня если я ошибаюсь, но когда эта фенечка будет реализована Python станет первым скриптовым языком в котором есть нормальная многопоточность без GIL, ага? Люто бешено плюсую.
     
     
  • 2.2, аноним (?), 12:13, 26/06/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А как же perl?
    Там эта многопоточность много-много лет уже!
     
     
  • 3.9, Имя123321 (?), 16:48, 26/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    осталось ещё {сборщик мусора} туда добавить :-) [впрочем в perl6 его таки добавили]

    # p.s.: {щётчик ссылок} это не {сборщик мусора}.

     
  • 3.26, hizel (ok), 22:07, 26/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    судя по shootout.alioth.debian.org с многопоточностью в perl-е не очень
     
     
  • 4.29, аноним (?), 10:09, 27/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ссылку на тест многопоточности на  shootout.alioth.debian.org
     
  • 2.3, Аноним (-), 12:33, 26/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    А чем конкретно вам так не угодил GIL?
     
     
  • 3.8, brzm (?), 16:46, 26/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Отсутствием возможность в одном процессе использовать имеющиеся 8+ голов. На С писать просто-напросто долго. При использовании fork (что на данный момент и делаю) необходимо взаимодествие через, например socketpair плюс не такая прозрачная логика.
     
     
  • 4.11, Имя123321 (?), 16:56, 26/06/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    по мне так -- использовать fork(..) напрямую -- не очень удобно...

    ...лучше модуль "multiprocessing" и ещё к нему + пару своих собственных костылей :-)

    (например очень полезен класс Pipes (MyPipes), но с добавлением к нему той функциональности что -- при закрытии Pipes в одном проссе -- он автоматически [передавая соответствующщее "сообщение"] закрывается и в другом процессе)

    (или ещё хорошобы добавить механизм, который обрабатывает сообщения от нескольких [вышеупомянутых] MyPipes -- при этом каждый экземпляр MyPipe способен склонировать себя для другого [нового] дружественного процесса, и также автоматически клон добавляется в обработку)

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

    (((неговоря уже о том что даже во всяких Java и .NET, в которых многонитевость реализованна без GIL -- при вызывании сборщика мусора -- блокируется работат ВСЕХ нитей текущщего процесса!!)))

     
     
  • 5.15, brzm (?), 17:10, 26/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    +1. Как только этот модуль начнет существовать в stable, его можно будет использовать :) А пока что fork() наше фсио.
     
     
  • 6.27, аноним (?), 00:24, 27/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Как только этот модуль начнет существовать в stable, его можно будет
    >использовать :)

    В каком stable? В Python 2.6.5 есть.

     
  • 2.22, анонимус (??), 18:13, 26/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Python станет первым скриптовым языком в котором есть нормальная многопоточность без GIL, ага?

    SBCL, не?

     

  • 1.4, bw (??), 13:49, 26/06/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    GIL это особенность именно Python, в Perl (если мне не изменяет склероз), проблема сохранения целостности данных при использовании решена иначе. GIL это было удачное решение в те ещё времена, когда про многоядерность никто и не помышлял, да и многопроцессорность было явлением может и не таким уж редким, но как-то не пересекающимся с Python (а в случае пересечения используйте процессы и будет вам счастье, потоки, это для десктопов, это не по взрослому :-), сейчас же она мешает лишь использовать (ИНТЕРПРЕТАТОРУ, а нативные расширения никто не отменял) одновременно несколько ядер, это проблема в вычислительных задачах (где действительно нужены ресурсы CPU), но представить широкое применение Python в ним мне довольно сложно :-). Почему ещё GIL это может быть плохо. Многие хомячки (кстати, они сейчас поголовно делают для себя открытие -- асинхронное/событийное программирование) используют потоки и для одновременной обработки задач ввода-вывода (сеть, веб клиент-серверы и пр.), где абсолютно во всём выигрывает именно асинхронное решение (опять же, нет тонны потоков, нет "выдуманных" проблем с GIL). Конечно можно использовать потоки и для ввода-вывода, только нужно отдавать себе отчёт в своих действиях и понимать, что в случаях падения производительности, вы сам себе злобный буратино.

    p.s. Извините за много букв.

    p.p.s. Я не говорю что GIL это хорошо и что проблема (если это для кого-то проблема) не достойна решения. Но как вы сами понимаете, лучшее враг хорошего. Может получиться так, что в 1 из 20 случаев будет 3х кратный прирост, а во всех остальных падение производительности на нцать процентов.

    ..bw

     
     
  • 2.5, kkk (??), 14:26, 26/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    GIL приводит к поразительно высокому contention даже в коде, который написан с использованием неблокирующего ввода-вывода. Об этом был забавный доклад с видео, выложенным в инете. Как только появляется несколько потоков, например, из-за используемых библиотек, так GIL сразу приводит к резкому падению производительности.
     
     
  • 3.14, Имя123321 (?), 17:06, 26/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >GIL приводит к поразительно высокому contention даже в коде, который написан с
    >использованием неблокирующего ввода-вывода. Об этом был забавный доклад с видео, выложенным
    >в инете. Как только появляется несколько потоков, например, из-за используемых библиотек,
    >так GIL сразу приводит к резкому падению производительности.

    Python работает удивительно стабильно.. никаких кратвовременных зависаний в работе.. всё плавно и ПРЕДСКАЗУЕМО.

    в Java и .NET (кроме кучи занятой памяти, о чём не будем говорить) -- постоянные предзависания! угадайте почему?

    про Perl и говорить не стоит, язык не того уровня.. ещёбы bash вспомнилибы...


     
     
  • 4.17, аноним (?), 17:46, 26/06/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Perl действительно не того уровня - на голову выше
     
     
  • 5.28, СуперАноним (?), 09:19, 27/06/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Perl действительно язык для тех, кто на голову ...
     
  • 4.32, Sugar (ok), 11:28, 30/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Почему питонисты такие ненавистники перла? Это что фанатизм, религия или просто свербит в одном месте от одного факта, что на перле тоже можно писать комфортно и удобно, и что правда он в чем-то может быть лучше питона.
    Нормальный язык, лично _мне_, для моих задач (написане административных скриптов, скриптов для домашненго использования), он подходит идеально. Кстати баш, недавно пришлось пиасать на нем скрипт более 100 строк кода, просто феерически неудобен, тут по-моему сравнение его с перлом просто немуместно.
     
     
  • 5.33, hizel (ok), 11:38, 30/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Кстати баш, недавно пришлось пиасать на
    >нем скрипт более 100 строк кода, просто феерически неудобен, тут по-моему
    >сравнение его с перлом просто немуместно.

    еще и не очень партатабельно, если писать то на чистом sh

    >лично _мне_, для моих задач (написане административных скриптов, скриптов для домашненго использования), он подходит идеально.

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

     
     
  • 6.34, Sugar (ok), 13:04, 30/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >еще и не очень партатабельно, если писать то на чистом sh

    Согласен, но на sh еще менее удобно, с удивлением обнаружил, то что на перле пишется легко и изящно, на шелле пришлось делать через глубокую задницу. Не знаю как народ осиливает огромные проекты на sh (etcnet, загрузочные скрипты BSD и т.д.)

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

    Зато у перла есть огромный cpan, где есть как и pure-perl модули, так и на с написанные.
    Ну устанвливать, не так уж это и сложно.
    Когда-нибудь доберусь до питона, как время будет, гляну эту хваленую стандартную библиотеку =)

     
  • 2.12, brzm (?), 17:03, 26/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Целиком и полностью согласен. Асинхронный подход это: экономия памяти, экономия на шедуле потоков/процессов, линейная логика, отсутствие дополнительных расходов на поддержании данных в консистентном состоянии.
    Но! Хочется решения, когда мы в той же самой системе можем, при соотетствующем походе (сабж, указание критических классов) таки использовать настоящую многопоточность. Задачи поедающие CPU действительно решаются выносом в отдельный процесс/модуль, который уже написан на С/etc, но наличие решения для Python позволит расширить класс задач, которые можно таким (c module) образом не допиливать.

    На данный момент (из самого распространённого) быстрее только Lua, а больше библиотека только у Perl (сделайте меня развидеть его скорость, особенно обработке строк, sic!), т.ч. Python шагом к использованию настоящей многопоточности может завоевать ещё over 9000 программистов.

     
     
  • 3.18, аноним (?), 17:47, 26/06/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > На данный момент (из самого распространённого) быстрее только Lua

    Perl тоже быстрее.
    И с многопоточностью никаких проблем

     
     
  • 4.20, brzm (?), 17:59, 26/06/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    да proof же!?
     
     
  • 5.23, аноним (?), 18:21, 26/06/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > На данный момент (из самого распространённого) быстрее только Lua

    Где пруф?!!!!!!!!!

     
     
  • 6.24, Аноним (-), 19:10, 26/06/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    http://shootout.alioth.debian.org
     
     
  • 7.25, аноним (?), 19:32, 26/06/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Этот пруф я знаю.
    Только там ничего нет про то, что якобы "перл на n-камней с трудом догоняет Питон на одном"
     
     
  • 8.31, аноним (?), 17:37, 28/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Правильно Там есть Питон на любой комбинации камней 32 64 bit с трэдами или... текст свёрнут, показать
     

  • 1.30, Аноним (-), 12:27, 27/06/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    многопоточном в одном процессе нужна лишь на винде, там создание нового процесса тормозная операция
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    MIRhosting
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру