The OpenNET Project / Index page

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

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

Разработчики проекта 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
Тип: К сведению
Ключевые слова: pypy, python, multicore, multithread, parallel
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Ajax/Линейный | Раскрыть все сообщения | 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 +/
    С таким же успехом, питона может и не быть на некоей платформе Например на всяк... весь текст скрыт [показать]
     
     
  • 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 [^] [ответить]     [к модератору]  
  • +/
    Питон не умеет нативно эффективно использовать более чем одно ядро в рамках од... весь текст скрыт [показать]
     
     
  • 3.17, Аноним (-), 14:33, 11/05/2012 [^] [ответить]     [к модератору]  
  • +/
    Позволяет использовать сколько угодно ядер http docs python org library multi... весь текст скрыт [показать]
     
     
  • 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 +/
    Да умеет питон треды Только по факту в конкретный промежуток времени работать м... весь текст скрыт [показать]
     
     
  • 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 [^] [ответить]    [к модератору]  
  • +/
    >Прямо времена Windows 3.0 вспоминаются... там тоже такая "многозадачность" была

    Вы сейчас продемонстрировали, что  не понимаете  разницу между задачей, процессом и потоком.

     
  • 2.12, spanasik (ok), 13:13, 11/05/2012 [^] [ответить]    [к модератору]  
  • +1 +/
    ты серьёзно считаешь, что питоном нельзя задействовать все ядра ?
     
     
  • 3.18, Нанобот (?), 14:36, 11/05/2012 [^] [ответить]     [к модератору]  
  • +1 +/
    та я вообще такого не говорил но, раз уж ты затронул эту тему, то сейчас задей... весь текст скрыт [показать]
     
     
  • 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 +/
    Я таки думаю, что в ваших замерах были либо многочисленные операции ввода вывода... весь текст скрыт [показать]
     
     
  • 3.48, szh (ok), 12:31, 12/05/2012 [^] [ответить]     [к модератору]  
  • +/
    python 2 6 5, perl 5 10 1, ubuntu 10 04 1 обсчет по большому графу - массивы с... весь текст скрыт [показать]
     
     
  • 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 [^] [ответить]     [к модератору]  
  • +/
    Это как Что за алгоритм Плохо что Рекурсии чего Вы путаетесь в показаниях,... весь текст скрыт [показать]
     
     
  • 5.54, szh (ok), 01:48, 13/05/2012 [^] [ответить]     [к модератору]  
  • +/
    создающий массивы и добавляющий в них данные Совсем медленно Хуже чем в 2 раза ... весь текст скрыт [показать]
     
     
  • 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:
    Заголовок:
    Текст:


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