The OpenNET Project / Index page

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

Первый выпуск PyPy-STM, интерпретатора Python с поддержкой многоядерных систем

07.07.2014 10:47

После трёх лет разработки представлен первый официальный выпуск проекта PyPy-STM (PyPy Software Transactional Memory), в рамках которого развивается реализация языка Python, способная распараллеливать выполнение разных потоков одного многопоточного приложения на нескольких ядрах CPU. Разработка PyPy-STM направлена на устранение одной из основных проблем СPython - наличие глобальной блокировки интерпретатора (GIL, global interpreter lock), не позволяющей обеспечить параллельное выполнение нескольких нитей кода на языке Python.

PyPy-STM основывается на кодовой базе PyPy, высокопроизводительной реализации языка Python, написанной на языке Python (используется статически типизированное подмножество RPython, Restricted Python). Высокий уровень производительности достигается благодаря задействованию JIT-компилятора, на лету транслирующего некоторые элементы в машинный код. PyPy-STM полностью совместим с содержащей глобальную блокировку версией PyPy, т.е. может быть использован для выполнения обычных многопоточных приложений на языке Python, выступая в качестве прозрачной замены PyPy. Дополнительно, в стандартный модуль thread добавлен низкоуровневый API "thread.atomic", позволяющий более тонко управлять выполнением многопоточных приложений на разных ядрах CPU.

Для решения проблемы с распараллеливанием на многоядерных системах в PyPy-STM осуществлён переход от традиционных блокировок к программной транзакционной памяти, в качестве механизма для обеспечения параллелизма. Данный механизм по своей сути напоминает методы изоляции изменений, используемые в СУБД для обеспечения целостности транзакций. По производительности выполнения программ PyPy-STM приблизился к уровню PyPy, в основном благодаря задействованию единого JIT-компилятора и устранению узких мест в сборщике мусора (первые сборки PyPy-STM отставали по производительности от PyPy в 2-5 раз).

При выполнении однопоточных программ наблюдается заметное отставание от PyPy на 20% - 300%, но уже при запуске многопоточной программы на двух ядрах CPU PyPy-STM начинает опережать PyPy, при увеличении числа вовлечённых в выполнение ядер CPU разрыв увеличивается. Например, тест mandelbrot выполняется в PyPy за 22.9 сек, в PyPy-STM на одном CPU за 27.5 сек, на двух - за 14.4 сек, на трёх за 10.3 сек, на четырёх за 8.71 сек. В тесте multithread-richards наблюдается отставание от PyPy независимо от числа ядер CPU, в тесте btree производительность держится примерно на одном уровне. Поддержка распараллеливания проверена для базового Python-кода, должный уровень производительности и распараллеливания не гарантируется при использовании сторонних многопоточных библиотек или при прямых манипуляциях памятью через array.array или массивы numpy.

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

PyPy-STM пока поддерживает работу только на 64-разрядных платформах под управлением Linux, для сборки требуется модифицированная версия clang/llvm. Готовые для установки пакеты сформированы для выпусков Ubuntu с 12.04 по 14.04. В настоящее время стартовал сбор средств для второй фазы развития PyPy-STM, в рамках которой планируется решить остающиеся проблемы, провести оптимизации для различных внешних библиотек, обеспечить возможность распараллеливания различных фаз выполнения однопоточных программ, создать фреймворк для написания эффективных многопоточных приложений.

  1. Главная ссылка к новости (http://morepypy.blogspot.ru/20...)
  2. OpenNews: Первый стабильный выпуск PyPy3 с поддержкой Python 3
  3. OpenNews: Выпуск PyPy 2.3, реализации Python, написанной на языке Python
  4. OpenNews: Представлен pypy-stm, интерпретатор Python с поддержкой распараллеливания на многоядерных системах
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/40150-pypy-stm
Ключевые слова: pypy-stm, python
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (53) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, свин (?), 11:45, 07/07/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    шёл 2014 год...
     
     
  • 2.2, bav (ok), 11:52, 07/07/2014 [^] [^^] [^^^] [ответить]  
  • +9 +/
    … а GIL до сих пор мешает кому угодно, только не питонистам.
     
     
  • 3.3, via (??), 13:17, 07/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    + кто докажет, что это pypy-stm не глючит.
     
     
  • 4.29, AlexAT (ok), 21:18, 07/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    юнит-тесты?
     
     
  • 5.30, Аноним (-), 22:46, 07/07/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Юнит-тесты доказывают лишь невменяемость некоторых программистов, ибо отнимают кучу времени и сил, препятствуют дальнейшей разработки и рефакторингу кодовой базы, при том что обеспечивают надёжность лишь в типовых ситуациях.
     
     
  • 6.40, МММ (??), 07:38, 08/07/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Юнит-тесты доказывают лишь невменяемость некоторых программистов, ибо отнимают кучу времени
    > и сил, препятствуют дальнейшей разработки и рефакторингу кодовой базы, при том
    > что обеспечивают надёжность лишь в типовых ситуациях.

    И как ты будешь рефакторинг делать без тестов?  Тесты это такая штука, которая позволяет формализовать требования к задаче еще до написания кода и это серьезно экономит время, тесты пишутся легко, во время написания тестов программист думает о том как решить задачу которую описывает тест,
    тесты позволяют использовать нормальный DevOps с CI, автоматическим тестированием и деплоем и позволяют по несколько раз в день выкатывать новые версии продукта, тесты позволяют спокойно спать ночью, а не фиксить "внезапно"  возникшие проблемы на продакшине.

     
  • 3.8, Аноним (-), 14:54, 07/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Например, для web-разработки GIL не является узким местом, так как проблема решается запуском нескольких экземпляров обработчиков запросов.
     
     
  • 4.13, Аноним (-), 18:07, 07/07/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    У веб разработчиков узким обычно вообще является другое место.
     
  • 4.20, Филипп Филиппович (ok), 19:54, 07/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Если под веб-разработкой понимать сайтописательство, то несомненно. Там всё решается специфичной средой выполнения. Если же говорить о сетевом коде вообще (Twisted, gevent и т.п.), то картина меняется. Там GIL и использование разных изобретений вместо простых потоков очень мешает.
     
     
  • 5.23, МММ (??), 20:42, 07/07/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Если под веб-разработкой понимать сайтописательство, то несомненно. Там всё решается специфичной
    > средой выполнения. Если же говорить о сетевом коде вообще (Twisted, gevent
    > и т.п.), то картина меняется. Там GIL и использование разных изобретений
    > вместо простых потоков очень мешает.

    И каким местом в асинхронных фреймворках мешает GIL.

     
     
  • 6.33, Филипп Филиппович (ok), 23:42, 07/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Вот именно тем и мешает, что вместо нормальных потоков городится чёрт знает что, работающее в итоге в одном. Что в Twisted, что гринлеты в gevent параллелятся очень специфическим образом. Иногда это нормально. Иногда это большая головная боль, и нужна возможность использовать нормальные потоки ОС, способные эффективно выполняться на разных ядрах и параллелиться без явного использования логики сопрограмм или патчей к половине стандартной библиотеки.

    Нормальный архитектурный паттерн полноценного асинхронного фреймворка с реакторами всегда предполагает потоки. Достаточно вспомнить boost::asio. Реактор -- самое базовое понятие, но именно из-за GIL в асинхронных фреймворках реактор реализован не так, как обычно, а через одно место. Да, красиво, да, остроумно, но всё равно криво.

     
     
  • 7.37, МММ (??), 07:12, 08/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >Вот именно тем и мешает, что вместо нормальных потоков городится чёрт знает что, работающее в итоге в одном. Что в Twisted, что гринлеты в gevent параллелятся очень специфическим образом. Иногда это нормально. Иногда это большая головная боль, и нужна возможность использовать нормальные потоки ОС, способные эффективно выполняться на разных ядрах и параллелиться без явного использования логики сопрограмм или патчей к половине стандартной библиотеки.

    В асинхронных фреймворках ничего не параллелится, на то они и асинхронные. Весь смысл существования асинхронной парадигмы в передаче управления другой задаче(функции), если выполняемая задача(функция) попала под блокировку, никаких потоков для этого не нужно, процесс имеет один поток.

     
     
  • 8.41, Филипп Филиппович (ok), 14:16, 08/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Боже мой, идите и прочтите хоть что-нибудь Хотя бы вот это для начала http e... текст свёрнут, показать
     
     
  • 9.43, rob pike (?), 17:52, 08/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Это что вы вот сейчас имели в виду Какие-то конкретные общеизвестные проблемы в... текст свёрнут, показать
     
     
  • 10.47, МММ (??), 18:25, 08/07/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Он просто бредит ... текст свёрнут, показать
     
  • 9.46, МММ (??), 18:25, 08/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Во-во прочти-ка сам Какие блин отличия, внутри все те же, внезапно libev libe... текст свёрнут, показать
     
     
  • 10.49, Мимо проходил (?), 19:48, 08/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Имеется в виду распределение асинхронных обработчиков не на 1 реактор, а сразу н... текст свёрнут, показать
     
     
  • 11.55, MM M (?), 20:06, 13/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Gevent так и работает from gevent pool import Pool , в чём проблема с потоками ... текст свёрнут, показать
     
  • 5.27, bav (ok), 20:59, 07/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Там GIL и использование разных изобретений вместо простых потоков очень мешает.

    Внезапно, GIL сделан как раз с целью обеспечить работу простых потоков.

     
     
  • 6.34, Филипп Филиппович (ok), 23:45, 07/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> Там GIL и использование разных изобретений вместо простых потоков очень мешает.
    > Внезапно, GIL сделан как раз с целью обеспечить работу простых потоков.

    Бездну понимания прозреваю в словах ваших я. Это один из существующих способов. Очень простой. Довольно эффективный на одноядерных машинах. Но сейчас уже совершенно устаревший именно из-за направления развития современных процессоров в последние 10 лет.


     
     
  • 7.38, МММ (??), 07:16, 08/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >>> Там GIL и использование разных изобретений вместо простых потоков очень мешает.
    >> Внезапно, GIL сделан как раз с целью обеспечить работу простых потоков.
    > Бездну понимания прозреваю в словах ваших я. Это один из существующих способов.
    > Очень простой. Довольно эффективный на одноядерных машинах. Но сейчас уже совершенно
    > устаревший именно из-за направления развития современных процессоров в последние 10 лет.

    А других для интерпретируемых языков методов нет, точнее есть форк интерпретатора, но он менее эффективный. А для многопроцессорных систем логичнее использовать процессы.

     
     
  • 8.42, Филипп Филиппович (ok), 14:41, 08/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Интересный штамп Интерпретируемый язык А что это такое Непрерывный парсин... текст свёрнут, показать
     
     
  • 9.44, rob pike (?), 17:57, 08/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Не только в PyPy его ищут https speakerdeck com trent pyparallel-how-we-remov... текст свёрнут, показать
     
  • 9.45, МММ (??), 18:19, 08/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Программа написанная на интерпретируемом языке не может выполняться отдельно без... текст свёрнут, показать
     
  • 9.48, МММ (??), 18:37, 08/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Отличие в байт-коде, и методах его трансляции Они совсем разные Байт-код питон... текст свёрнут, показать
     
     
  • 10.56, Филипп Филиппович (ok), 20:02, 27/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    А различие -- да, именно в неэффективной и устаревшей на сегодня ВМ и устаревшем... текст свёрнут, показать
     
  • 2.12, Аноним (-), 18:04, 07/07/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >  шёл 2014 год...

    А питонисты зарубались с рубистами из соседней новости: кто больше версий не совместимого с самим собой шита выкатить сумеет?! Рубисты накручивали версию, питонисты задолбавшись крутить версию, выпускали несовместимые между собой недопилки.

     
  • 2.28, МММ (??), 20:59, 07/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > шёл 2014 год...

    Да всё банально. Потоки используют для экономии памяти и времени на создание процесса. При этом получают проблемы с единой областью памяти, т.е. данные могут теряться вследсвии перезаписи в одно и тоже место  памяти разными потоками и в тоже время получают плюсы за счет простоты передачи данных между потоками -- так как память общая и данные общие. То есть многопоточное программирование это довольно трудная задача, в скриптовых/интерпретированных языках не решаемая в принципе. По этому или GIL как в python/ruby или форк интерпретатора как в lua/perl и т.п., во-втором случае выигрыша по сравнению с фоком процесса никакого а трахаться с памятью всё равно придется. Так что  GIL был есть и  всегда будет.

     
     
  • 3.31, Аноним (-), 22:49, 07/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Тем более что в современном мире параллельность означает наличие многих машин, а не четырёхядерного процика, упирающегося в частоту оперативы.
     
     
  • 4.35, rob pike (?), 01:21, 08/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Это вам в Cloud Haskell.
     
     
  • 5.39, МММ (??), 07:18, 08/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Это вам в Cloud Haskell.

    Зачем, есть Disco. http://discoproject.org

     
  • 3.50, Аноним (-), 21:08, 08/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    В нормальных операционных системах время создания процесса такое же как и потока.
     

  • 1.5, anonim66666 (?), 13:55, 07/07/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    если нужно что то быстро обсчитать(очень тяжелое), то проще и быстрее заиспользовать pyopencl. он в разы(на порядки, если на gpu) быстрее, чем на многопоточном python.
     
     
  • 2.15, Аноним (-), 18:09, 07/07/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > pyopencl.

    Учитывая что в opencl пишут на специфичном подвиде C, питон там вообще лишний элемент пейзажа.

     
     
  • 3.22, МММ (??), 20:39, 07/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> pyopencl.
    > Учитывая что в opencl пишут на специфичном подвиде C, питон там вообще
    > лишний элемент пейзажа.

    А в pyopencl пишут таки на обычном питоне.

     
  • 2.18, Антоним (?), 19:50, 07/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Не каждую задачу можно ускорить, запустив на GPU. К тому же требует модификации кода.
     

  • 1.6, anonim66666 (?), 14:00, 07/07/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    считаем Mandelbrot Set на gpu за 41ms, а не за 9 сек и даже не за 23 ...
    http://www.bealto.com/mp-mandelbrot_benchmarks.html
     
     
  • 2.16, Аноним (-), 18:11, 07/07/2014 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > считаем Mandelbrot Set на gpu за 41ms, а не за 9 сек
    > и даже не за 23 ...

    Только GPU вообще питон выполнять не умеет, а opencl к питону весьма слабо относится. В порядке извращения конечно можно и из питона дергать, но писать на 2 кардинально разных ЯП - не то чтобы сильно удобно.


     
     
  • 3.21, МММ (??), 20:37, 07/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >Только GPU вообще питон выполнять не умеет

    С какого перепугу? Theano http://deeplearning.net/software/theano/

     

  • 1.9, Аноним (-), 15:46, 07/07/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > При выполнении однопоточных программ наблюдается заметное отставание от PyPy на 20% - 300%

    не нужно.

     
  • 1.10, Аноним (-), 15:50, 07/07/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Для решения проблемы с распараллеливанием на многоядержных системах в PyPy-STM осуществлён переход от традиционных блокировок к программной транзакционной памяти, в качестве механизма для обеспечения параллелизма.

    Это круто. А как они проверяют отсутствие побочных эффектов внутри транзакций? Это более-менее годно смогли только в Haskell запилить.

     
     
  • 2.19, Антоним (?), 19:52, 07/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Аппаратные реализации тоже неплохо работают. Подробностей реализации, конечно же, нет, но Intel сообщали, что используют протоколы когерентности кэша для транзакций. Задачи схожи.
     

  • 1.11, Anonymus (?), 17:04, 07/07/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    То есть второй проц добавляет 90% производительности, а четвёртый всего-лишь 18. Апроксимируя получим 10% прирост на энный процессор. Вопрос: а накуя такое чудо?
     
     
  • 2.14, Аноним (-), 18:08, 07/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > То есть второй проц добавляет 90% производительности, а четвёртый всего-лишь 18.

    Вот такая вот хреновая многопроцессорность...

     
  • 2.17, bav (ok), 18:50, 07/07/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Вопрос: а накуя такое чудо?

    Это только прототип. Места для оптимизаций там еще много. А вообще это важная веха — наконец (!) реализация без GIL начинает масштабироваться.

     
     
  • 3.25, all_glory_to_the_hypnotoad (ok), 20:47, 07/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    лучше не будет, STM в случае топика в принципе не масштабируется.
     
     
  • 4.26, bav (ok), 20:54, 07/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > STM в случае топика в принципе не масштабируется

    В новости написано обратное. И прогресс с предыдущей попытки налицо.

     
     
  • 5.32, all_glory_to_the_hypnotoad (ok), 23:04, 07/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Мало ли что там написано и какими надеждами живут разработчики PyPy-STM, фундаментальные проблемы всё равно остаются и решить они их не смогут.
     
     
  • 6.36, chinarulezzz (ok), 02:06, 08/07/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    расскажи о фундаментальных проблемах а еще лучше на здоровенную книжку линк, или скажи что всем и так это всё известно, и на форумах не раз обсуждалось :D
     
  • 2.52, Аноним (-), 22:58, 08/07/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > То есть второй проц добавляет 90% производительности, а четвёртый всего-лишь 18. Апроксимируя
    > получим 10% прирост на энный процессор. Вопрос: а накуя такое чудо?

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


     

  • 1.24, all_glory_to_the_hypnotoad (ok), 20:46, 07/07/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    > При выполнении однопоточных программ наблюдается заметное отставание от PyPy на 20% - 300%, но уже при запуске многопоточной программы на двух ядрах CPU PyPy-STM начинает опережать PyPy, при увеличении числа вовлечённых в выполнение ядер CPU разрыв увеличивается.

    молодцы, заоптимизировали 20 % потенциальных юз-кейсов и угробили остальные 80 %. Кому оно такое нужно.

     
     
  • 2.53, Аноним рус (?), 11:18, 09/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Это может быть только ваши потребности такие, и ваши цифры, для других они другие.
     

  • 1.54, Аноним рус (?), 11:34, 09/07/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Есть данные по сравнению потребления оперативной памяти PyPy-STM и PyPy?
     

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



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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