The OpenNET Project / Index page

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

Представлен pypy-stm, интерпретатор Python с поддержкой распараллеливания на многоядерных системах

11.05.2012 11:34

Разработчики проекта PyPy представили проект pypy-stm (PyPy Software Transactional Memory), в рамках которого проведена работа по избавлению от глобальной блокировки интерпретатора, мешающей обеспечению параллельного выполнения нескольких нитей кода на языке Python. В настоящее время представлена надстройка над PyPy c рабочей реализацией интерпретатора Python 2.7, поддерживающая одновременное исполнение нитей существующих многопоточных приложений на разных ядрах CPU. Кроме STM-надстройки над PyPy дополнительно ведётся работа по реализации поддержки STM для экспериментальной ветки СPython 3.3.

От проблем с глобальной блокировкой до настоящего времени был избавлен только проект Jython, который использовал для обеспечения параллельного выполнения особенности виртуальной машины JVM вкупе с привязкой локов к изменяемым встроенным типам. В PyPy, CPython и IronPython, глобальная блокировка присутствует, что существенно ограничивает производительность данных реализаций языка Python. Для решения указанной проблемы участники проекта PyPy решили перейти от традиционных блокировок к программной транзакционной памяти, в качестве механизма для обеспечения параллелизма. Данный механизм по своей сути напоминает методы изоляции изменений, используемые в СУБД для обеспечения целостности транзакций. Для желающих принять участие в тестировании проекта подготовлено подробное описание используемых в pypy-stm методов управления параллелизмом.

В настоящее время подготовлена сборка для 32-разрядных Linux-систем (можно собрать и для x86-64). Отмечается, что разработка пока представляет собой демонстрационный прототип, который ещё не подвергался оптимизации и поэтому работает очень медленно. Pypy-stm отстаёт по производительности от PyPy в 2-5 раз, так как PyPy в режиме STM пока не совместим с реализацией JIT-компилятора и не поддерживает многие оптимизации. В настоящее время pypy-stm полностью совместим с содержащей глобальную блокировку версией PyPy, т.е. может быть использован для выполнения многопоточных приложений в качестве прозрачной замены PyPy. Дополнительно, в стандартный модуль thread добавлен низкоуровневый API "thread.atomic", позволяющий более тонко управлять выполнением многопоточных приложений на разных ядрах CPU. Со временем на базе данного низкоуровневого API планируется разработать высокоуровневый программный интерфейс, который можно будет использовать для распараллеливания изначально не многопоточных программ.

  1. Главная ссылка к новости (http://morepypy.blogspot.com/2...)
  2. OpenNews: Релиз PyPy 1.8, реализации Python, написанной на языке Python
  3. OpenNews: Проект PyPy представил визуализатор процесса JIT-компиляции и обрисовал ситуацию, когда PyPy быстрее языка Си
  4. OpenNews: Релиз Python-компилятора Shed Skin 0.8
  5. OpenNews: Релиз языка программирования Python 3.2
  6. OpenNews: Релиз Cython 0.15, варианта языка Python, поддерживающего плотную интеграцию с Си
Лицензия: CC-BY
Тип: К сведению
Короткая ссылка: https://opennet.ru/33817-pypy
Ключевые слова: pypy, python, multicore, multithread, parallel
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (45) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.5, ZeroOne (ok), 12:48, 11/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интересная идея. Что ж, удачи им.
    А реализацию многопоточности через С/С++ расширения либо через грядущую версию С с поддержкой этой самой многопоточности ещё не пробовали делать или же что-то пробовали, да получилось не очень? Кто-то знает? Если есть ссылки, буду рад.
     
     
  • 2.10, жопка3 (?), 13:06, 11/05/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А расскажите, пожалуйста, подробней про грядущую версию С с поддержкой многопоточности?
     
     
  • 3.15, Аноним (-), 13:48, 11/05/2012 [^] [^^] [^^^] [ответить]  
  • –8 +/
    Внезапно, многопоточность в Си поддерживается уже как минимум с 1995 года, если не раньше. Два слова: POSIX threads. Подробней: cc -lpthread my_multithreaded_program.c -o my_multithreaded_program
     
     
  • 4.16, Аноним (-), 14:23, 11/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >Внезапно, многопоточность в Си поддерживается уже как минимум с 1995 года

    Бывает что ирония и сарказм не улавливается, но не настолько.

     
  • 4.20, Аноним (-), 15:07, 11/05/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >POSIX threads
    >многопоточность в Си

    pthread не являются частью стандарта С.

     
     
  • 5.25, Аноним (-), 16:13, 11/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > pthread не являются частью стандарта С.

    Ага, и еще 100500 либ не являются. Это не мешает ими пользоваться.

     
     
  • 6.36, Аноним239 (?), 22:32, 11/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Еще как мешает.
    Что делать на платформах под которые есть компилятор С но нет pthread?

     
     
  • 7.42, Аноним (-), 09:14, 12/05/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Что делать на платформах под которые есть компилятор С но нет pthread?

    С таким же успехом, питона может и не быть на некоей платформе. Например на всякой эмбеддовке он не в почете за жрач ресурсов. И?

     
     
  • 8.49, Аноним (-), 14:40, 12/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    И читать стоит то на что вы отвечаете Иначе так и будете попадать впросак ... текст свёрнут, показать
     
  • 4.58, Vasily Pupkin (?), 09:40, 13/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    О как. А шо там как там с posix threads в MSVC собирать?
     
  • 3.21, Аноним (-), 15:09, 11/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > А расскажите, пожалуйста, подробней про грядущую версию С с поддержкой многопоточности?

    google c11 threads.h

     
  • 3.30, ZeroOne (ok), 17:05, 11/05/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Сам ещё об этом ничего не знаю. Знаю, что с выходом C11 активировалось обсуждение развития и в стандарте С. Тогда я про грядущую многопоточность и узнал.
     

  • 1.6, Нанобот (?), 12:48, 11/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    что, не хватает питону одного ядра процессора, да?
     
     
  • 2.8, Аноним (-), 13:02, 11/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Теперь будет тормозить на всех ядрах одновременно!
     
  • 2.9, Аноним (-), 13:04, 11/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Питон не умеет (нативно/эффективно) использовать более чем одно ядро в рамках одного процесса из-за родового проклятия (GIL). Треды есть, но они не решают этой проблемы. PyPy не первый кто заявляет о решении проблемы GIL, но похоже наиболее перспективный.
     
     
  • 3.17, Аноним (-), 14:33, 11/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Питон не умеет (нативно/эффективно) использовать более чем одно ядро в рамках одного
    > процесса из-за родового проклятия (GIL).

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

    > этой проблемы. PyPy не первый кто заявляет о решении проблемы GIL,
    > но похоже наиболее перспективный.

    Какой же он первый Jython, IronPython умеют это с рождения.


     
     
  • 4.19, Аноним (-), 14:58, 11/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    аноним не читатель, аноним писатель?

    1) multiprocessing запускает отдельный _процесс_
    2) PyPy _не_ первый

     
     
  • 5.27, Аноним (-), 16:16, 11/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > 1) multiprocessing запускает отдельный _процесс_

    А чо, треды оно не того? Бла, даже жабаскрипт уже умеет фоновые воркеры :)


     
     
  • 6.31, Аноним (-), 18:49, 11/05/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да умеет питон треды! Только по факту в конкретный промежуток времени работать может только один тред. Типа ухватил GIL и работает, а другие должны ждать. Другими словами в каждый конкретный момент времени занято может быть только ядро, сколько бы ни было тредов и ядер. Вопрос решается или форканьем или либами заточенными под мультипроцессорность.
     
     
  • 7.33, Аноним (-), 19:41, 11/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >Только по факту в конкретный промежуток времени работать может только один тред.

    Немаловажное замечание: в рамках одного процесса, а процессов может быть много.

     
     
  • 8.34, Аноним (-), 20:14, 11/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Конечно, может Но в питоне синхронизация тредов и процессов вещи очень сильно р... текст свёрнут, показать
     
     
  • 9.47, Аноним (-), 11:27, 12/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Треды синхронизируют механизм GIL, а процессы руками ... текст свёрнут, показать
     
  • 7.43, Аноним (-), 10:39, 12/05/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Да умеет питон треды! Только по факту в конкретный промежуток времени работать
    > может только один тред.

    Прямо времена Windows 3.0 вспоминаются... там тоже такая "многозадачность" была. Кто ухватил время проца, тот и в дамках. Пока не отдаст - остальные курят бамбук. Правда вот почему-то на такую схему были нарекания :)

     
     
  • 8.45, Аноним (-), 11:17, 12/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Вы сейчас продемонстрировали, что не понимаете разницу между задачей, процессо... текст свёрнут, показать
     
  • 2.12, spanasik (ok), 13:13, 11/05/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ты серьёзно считаешь, что питоном нельзя задействовать все ядра ?
     
     
  • 3.18, Нанобот (?), 14:36, 11/05/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    та я вообще такого не говорил.
    но, раз уж ты затронул эту тему, то: сейчас задействовать все ядра достаточно сложно, нужно всякие там fork() использовать и т.п.
    а вот в будущих версиях пи-пи (PyPy) для задействования всех ядер достаточно будет вызвать print 'hello, world'. ура великому языку питону!
     
     
  • 4.32, anonymous (??), 18:58, 11/05/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    http://docs.python.org/library/multiprocessing.html не надо явно никакой форк вызывать. Но если хочется руками - всегда можно.
     
  • 3.22, Аноним (-), 15:12, 11/05/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > ты серьёзно считаешь, что питоном нельзя задействовать все ядра ?

    Смотря какой длины питоном. Достаточно длинным питоном, да с размаху можно так ... по ядрам то... Мало не покажется!


     

  • 1.39, Мяут (ok), 01:06, 12/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А есть шанс, что PyPy станет мейнстримовым, как когда-то hotspot стал основной Java VM?
     
  • 1.40, szh (ok), 01:07, 12/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Они бы лучше python ускорили сам по себе, без распараллеливания. Он в 2 раза медленнее перл по моим замерам, хоть и меньше RAM ест.

    Многие задачи все равно не распаралелить толком по ядрам, или это слишком геморно-дорого.

     
     
  • 2.46, Аноним (-), 11:24, 12/05/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Они бы лучше python ускорили сам по себе, без распараллеливания. Он в
    > 2 раза медленнее перл по моим замерам, хоть и меньше RAM
    > ест.

    Я таки думаю, что в ваших замерах были либо многочисленные операции ввода/вывода и python был версии меньше 2.5, либо регулярки сравнивали.

    > Многие задачи все равно не распаралелить толком по ядрам, или это слишком
    > геморно-дорого.

    И всё-таки большинство задач можно распараллелить.

     
     
  • 3.48, szh (ok), 12:31, 12/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    python 2.6.5, perl 5.10.1, ubuntu 10.04

    1) обсчет по большому графу -  массивы/словари(хэши)
    2) регуляные выражения - совсем плохо

    3) при рекурсии в 50000 python падал. Perl выдавал лишь warning. Pypy упал еще быстрее.

    только как числодробилка python опередил perl.

     
     
  • 4.50, Аноним (-), 14:48, 12/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    О боже.
    - Вась, а топор оказывается быстрее лома.
    - А как ты проверял?
    - Красил стены. За два часа ломом смог покрасить пол метра, а топором - полтора!
    Но дальше больше - потолок побелить ломом не получается вообще, а топором можно, только подкидывать приходится постоянно.
    - Спасибо, что сказал! Теперь только топор. Не знаешь, какой лучший способ ловить рыбу топором?

     
     
  • 5.51, szh (ok), 17:30, 12/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    perl и python это два топора у которых одно и то же предназначение, рубить одни и те же дрова.
     
  • 4.52, Аноним (-), 23:25, 12/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >python 2.6.5, perl 5.10.1, ubuntu 10.04
    >1) обсчет по большому графу -  массивы/словари(хэши)

    Это как? Что за алгоритм?

    >2) регуляные выражения - совсем плохо

    Плохо что?

    >3) при рекурсии в 50000 python падал. Perl выдавал лишь warning. Pypy упал еще быстрее.

    Рекурсии чего?

    >только как числодробилка python опередил perl.

    Вы путаетесь в показаниях, пару постов вы писали противоположное.

     
     
  • 5.54, szh (ok), 01:48, 13/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >>1) обсчет по большому графу -  массивы/словари(хэши)
    > Это как? Что за алгоритм?

    создающий массивы и добавляющий в них данные


    >>2) регуляные выражения - совсем плохо
    > Плохо что?

    Совсем медленно. Хуже чем в 2 раза медленнее чем perl. И помимо этого неудобный синтаксис, слишком много лишних действий по сравнению с perl. вот смотрите http://snowplow.org/martin/rebench/

    >> 3) при рекурсии в 50000 python падал. Perl выдавал лишь warning. Pypy упал еще быстрее.
    > Рекурсии чего?

    Функция вызывает сама себя. Не забудьте sys.setrecursionlimit(10000000) в python, а то он из коробки много отказывается поддержать.

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

    Вы думаете если я утверждаю что python тормоз, то я не признаю что он в чем-то быстрей, если он там действительно быстрей ?

     
     
  • 6.60, Аноним (-), 08:22, 14/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Как это относится к графам Я понимаю например нахождение оптимального пути в гр... большой текст свёрнут, показать
     

  • 1.41, evgeny_t (ok), 02:06, 12/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    мда транзакции вместо локов ) что то новое, чторошо что они не пишут ядро linux )
     
     
  • 2.44, Аноним (-), 10:42, 12/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    А вы уверены, что транзакции это хуже локов с архитектурной точки зрения и точки зрения быстродействия?
     
     
  • 3.53, Аноним (-), 23:27, 12/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > А вы уверены, что транзакции это хуже локов с архитектурной точки зрения
    > и точки зрения быстродействия?

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

     
     
  • 4.59, etw (ok), 11:43, 13/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    STM зачастую медленнее хорошо написанных явных блокировок, особенно, при небольшом числе процессоров/ядер, т.к. при работе с общей памятью накладные расходы на ведение лога и коммиты никуда не исчезают
     
  • 3.55, evgeny_t (ok), 07:54, 13/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    транзакции не панацея, и имеют свои проблемы
    дедлоки, конфликты при оптимистических транзакциях.

    нет не уверен, но как показывает практика (java с#) нормальное решение это локи.
    но возможно 0.0001% они откроют новую веху в построении паралельных програм )


     
     
  • 4.56, evgeny_t (ok), 07:56, 13/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    включая бесконечное зацикливание которе ещё никто не разрешил )
     
     
  • 5.57, evgeny_t (ok), 08:04, 13/05/2012 [^] [^^] [^^^] [ответить]  
  • +/
    да же с++ есть локи )
    то есть нормально когда у тебя есть локи, а потом можно и всё остальное придумывать.

    Походу питону ещё долго жить с глобальной блокировкой. )

     

  • 1.61, Аноним (-), 09:10, 14/05/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А чем "это" лучше Clojure?
     

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



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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