The OpenNET Project / Index page

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

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от opennews on 07-Июл-14, 11:45 
После трёх лет разработки представлен (http://morepypy.blogspot.ru/2014/07/pypy-stm-first-interesti...) первый официальный выпуск проекта PyPy-STM (http://pypy.readthedocs.org/en/latest/stm.html) (PyPy Software Transactional Memory), в рамках которого развивается реализация языка Python, способная распараллеливать выполнение разных потоков одного многопоточного приложения на нескольких ядрах CPU. Разработка PyPy-STM направлена на устранение одной из основных проблем СPython - наличие глобальной блокировки интерпретатора (GIL, global interpreter lock), не позволяющей обеспечить параллельное выполнение нескольких нитей кода на языке Python.


PyPy-STM основывается на кодовой базе PyPy, высокопроизводительной реализации языка Python, написанной на языке Python (используется статически типизированное подмножество RPython (http://doc.pypy.org/en/latest/coding-guide.html#id1), Restricted Python). Высокий уровень производительности достигается благодаря задействованию JIT-компилятора, на лету транслирующего некоторые элементы в машинный код. PyPy-STM  полностью совместим с содержащей глобальную блокировку версией PyPy, т.е. может быть использован для выполнения обычных многопоточных приложений на языке Python, выступая в качестве прозрачной замены PyPy. Дополнительно, в стандартный модуль thread добавлен низкоуровневый API "thread.atomic", позволяющий более тонко управлять выполнением многопоточных приложений на разных ядрах CPU.

Для решения проблемы с распараллеливанием на многоядержных системах в PyPy-STM осуществлён переход от традиционных блокировок к программной транзакционной памяти (http://ru.wikipedia.org/wiki/%D0%9F%D1%8...), в качестве механизма для обеспечения параллелизма. Данный механизм по своей сути напоминает методы изоляции изменений, используемые в СУБД для обеспечения целостности транзакций. По производительности выполнения программ 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, для сборки требуется модифицированная (https://bitbucket.org/pypy/stmgc/src/default/c7/llvmfix/) версия clang/llvm. Готовые для установки пакеты сформированы для выпусков Ubuntu  с 12.04 по 14.04.  В настоящее время стартовал сбор средств (http://pypy.org/tmdonate2.html) для второй фазы развития PyPy-STM, в рамках которой планируется решить остающиеся проблемы, провести оптимизации для различных внешних библиотек, обеспечить возможность распараллеливания различных фаз выполнения однопоточных программ, создать фреймворк для написания эффективных многопоточных приложений.

URL: http://morepypy.blogspot.ru/2014/07/pypy-stm-first-interesti...
Новость: http://www.opennet.me/opennews/art.shtml?num=40150

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от свин on 07-Июл-14, 11:45 
шёл 2014 год...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +9 +/
Сообщение от bav (ok) on 07-Июл-14, 11:52 
… а GIL до сих пор мешает кому угодно, только не питонистам.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от via (??) on 07-Июл-14, 13:17 
+ кто докажет, что это pypy-stm не глючит.
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

29. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от AlexAT (ok) on 07-Июл-14, 21:18 
юнит-тесты?
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

30. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  –1 +/
Сообщение от Аноним (??) on 07-Июл-14, 22:46 
Юнит-тесты доказывают лишь невменяемость некоторых программистов, ибо отнимают кучу времени и сил, препятствуют дальнейшей разработки и рефакторингу кодовой базы, при том что обеспечивают надёжность лишь в типовых ситуациях.
Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

40. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +2 +/
Сообщение от МММ (??) on 08-Июл-14, 07:38 
> Юнит-тесты доказывают лишь невменяемость некоторых программистов, ибо отнимают кучу времени
> и сил, препятствуют дальнейшей разработки и рефакторингу кодовой базы, при том
> что обеспечивают надёжность лишь в типовых ситуациях.

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

Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

8. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от Аноним (??) on 07-Июл-14, 14:54 
Например, для web-разработки GIL не является узким местом, так как проблема решается запуском нескольких экземпляров обработчиков запросов.
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

13. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +3 +/
Сообщение от Аноним (??) on 07-Июл-14, 18:07 
У веб разработчиков узким обычно вообще является другое место.
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

20. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от Филипп Филиппович (ok) on 07-Июл-14, 19:54 
Если под веб-разработкой понимать сайтописательство, то несомненно. Там всё решается специфичной средой выполнения. Если же говорить о сетевом коде вообще (Twisted, gevent и т.п.), то картина меняется. Там GIL и использование разных изобретений вместо простых потоков очень мешает.
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

23. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +1 +/
Сообщение от МММ (??) on 07-Июл-14, 20:42 
> Если под веб-разработкой понимать сайтописательство, то несомненно. Там всё решается специфичной
> средой выполнения. Если же говорить о сетевом коде вообще (Twisted, gevent
> и т.п.), то картина меняется. Там GIL и использование разных изобретений
> вместо простых потоков очень мешает.

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

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

33. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от Филипп Филиппович (ok) on 07-Июл-14, 23:42 
Вот именно тем и мешает, что вместо нормальных потоков городится чёрт знает что, работающее в итоге в одном. Что в Twisted, что гринлеты в gevent параллелятся очень специфическим образом. Иногда это нормально. Иногда это большая головная боль, и нужна возможность использовать нормальные потоки ОС, способные эффективно выполняться на разных ядрах и параллелиться без явного использования логики сопрограмм или патчей к половине стандартной библиотеки.

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

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

37. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от МММ (??) on 08-Июл-14, 07:12 
>Вот именно тем и мешает, что вместо нормальных потоков городится чёрт знает что, работающее в итоге в одном. Что в Twisted, что гринлеты в gevent параллелятся очень специфическим образом. Иногда это нормально. Иногда это большая головная боль, и нужна возможность использовать нормальные потоки ОС, способные эффективно выполняться на разных ядрах и параллелиться без явного использования логики сопрограмм или патчей к половине стандартной библиотеки.

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

Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

41. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от Филипп Филиппович (ok) on 08-Июл-14, 14:16 
Боже мой, идите и прочтите хоть что-нибудь. Хотя бы вот это для начала:

http://eu.wiley.com/WileyCDA/WileyTitle/productCd-0471606952...

Двадцать лет как всё описано, есть простой и понятный архитектурный паттерн "реактор" -- нет, опять какие-то особые пути и особое понимание парадигм, которые существуют невесть сколько. Асинхронность вовсе не должна быть связана с однопоточным реактором, а если вы полагаете, что должна, то вы слишком много программировали на Win32 или питоновских асинхронных фреймворках.

Ну хоть асинхронный фреймворк для C++ boost::asio возьмите для сравнения. Идеологически он очень похож на асинхронные фреймворки Питона. Но сравните потоковую модель и найдите, как говорится, N различий.

Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

43. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от rob pike on 08-Июл-14, 17:52 
> Асинхронность вовсе не должна быть связана с однопоточным реактором, а если вы полагаете, что должна, то вы слишком много программировали на Win32

Это что вы вот сейчас имели в виду?
Какие-то конкретные общеизвестные проблемы в overlapped IO или IOCP?

Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

47. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  –1 +/
Сообщение от МММ (??) on 08-Июл-14, 18:25 
>> Асинхронность вовсе не должна быть связана с однопоточным реактором, а если вы полагаете, что должна, то вы слишком много программировали на Win32
> Это что вы вот сейчас имели в виду?
> Какие-то конкретные общеизвестные проблемы в overlapped IO или IOCP?

Он просто бредит.

Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

46. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от МММ (??) on 08-Июл-14, 18:25 
> Боже мой, идите и прочтите хоть что-нибудь. Хотя бы вот это для
> начала:
> http://eu.wiley.com/WileyCDA/WileyTitle/productCd-0471606952...

Во-во прочти-ка сам.

> Двадцать лет как всё описано, есть простой и понятный архитектурный паттерн "реактор"
> -- нет, опять какие-то особые пути и особое понимание парадигм, которые
> существуют невесть сколько. Асинхронность вовсе не должна быть связана с однопоточным
> реактором, а если вы полагаете, что должна, то вы слишком много
> программировали на Win32 или питоновских асинхронных фреймворках.
> Ну хоть асинхронный фреймворк для C++ boost::asio возьмите для сравнения. Идеологически
> он очень похож на асинхронные фреймворки Питона. Но сравните потоковую модель
> и найдите, как говорится, N различий.

Какие блин отличия, внутри все те же, внезапно: libev /libevent. Да да обыкновенный Си. И при чём тут потоки.

Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

49. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от Мимо проходил on 08-Июл-14, 19:48 
Имеется в виду распределение асинхронных обработчиков не на 1 реактор, а сразу на несколько. Это просто следующий логичный шаг повышения производительности в рамках одного процесса.

http://www.boost.org/doc/libs/1_54_0/doc/html/boost_asio/ove...

Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

55. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от MM M on 13-Июл-14, 20:06 
>Имеется в виду распределение асинхронных обработчиков не на 1 реактор, а сразу на несколько. Это просто следующий логичный шаг повышения производительности в рамках одного процесса.

Gevent так и работает (from gevent.pool import Pool), в чём проблема с потоками? Тема  так и не раскрыта.

https://sdiehl.github.io/gevent-tutorial/

Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

27. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от bav (ok) on 07-Июл-14, 20:59 
> Там GIL и использование разных изобретений вместо простых потоков очень мешает.

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

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

34. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от Филипп Филиппович (ok) on 07-Июл-14, 23:45 
>> Там GIL и использование разных изобретений вместо простых потоков очень мешает.
> Внезапно, GIL сделан как раз с целью обеспечить работу простых потоков.

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


Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

38. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от МММ (??) on 08-Июл-14, 07:16 
>>> Там GIL и использование разных изобретений вместо простых потоков очень мешает.
>> Внезапно, GIL сделан как раз с целью обеспечить работу простых потоков.
> Бездну понимания прозреваю в словах ваших я. Это один из существующих способов.
> Очень простой. Довольно эффективный на одноядерных машинах. Но сейчас уже совершенно
> устаревший именно из-за направления развития современных процессоров в последние 10 лет.

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

Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

42. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от Филипп Филиппович (ok) on 08-Июл-14, 14:41 
> А других для интерпретируемых языков методов нет, точнее есть форк интерпретатора, но
> он менее эффективный. А для многопроцессорных систем логичнее использовать процессы.

Интересный штамп. "Интерпретируемый язык"... А что это такое? Непрерывный парсинг на лету при выполнении? Так этого в Python нет и вроде бы не было. Трансляция в байт-код и выполнение в ВМ? Но тогда и Java -- интерпретируемы язык.

И чем, скажите на милость, Python с трансляцией в байт-код и выполнением виртуальной машиной отличается от Java или C# с трансляцией в байт-код и выполнением виртуальной машиной же? Где принципиальная разница? Что транслировать принято на лету и поставлять программы в исходных текстах? Так это на архитектуру реализации параллелизма само по себе не влияет вообще никак. Проблема в неэффективной с точки зрения параллелизма (и потому устаревшей) реализации ВМ. И молодцы ребята, что в PyPy ищут решение проблемы. Глядишь, и до продакшена дойдёт.

Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

44. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от rob pike on 08-Июл-14, 17:57 
> И молодцы ребята, что в PyPy ищут решение проблемы. Глядишь, и
> до продакшена дойдёт.

Не только в PyPy его ищут.
https://speakerdeck.com/trent/pyparallel-how-we-removed-the-...

Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

45. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от МММ (??) on 08-Июл-14, 18:19 
>> А других для интерпретируемых языков методов нет, точнее есть форк интерпретатора, но
>> он менее эффективный. А для многопроцессорных систем логичнее использовать процессы.
> Интересный штамп. "Интерпретируемый язык"... А что это такое?

Программа написанная на интерпретируемом языке не может выполняться отдельно без программы-интерпретатора.

Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

48. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от МММ (??) on 08-Июл-14, 18:37 
> И чем, скажите на милость, Python с трансляцией в байт-код и выполнением
> виртуальной машиной отличается от Java или C# с трансляцией в байт-код
> и выполнением виртуальной машиной же? Где принципиальная разница?

Отличие в байт-коде, и методах его трансляции. Они совсем разные. Байт-код питона всего лишь незначительно ускоряет загрузку программы в память и больше ничего. А еще "внезапно" большое количество модулей python написано на Си С++ Fortran и бог еще знает на чём python в этом смысле всеядный, и эти модули выполняются без всякой трансляции в байт-код, и да у них(бинарных модулей) есть механизм отключения GIL. А еще в отличие от Java и С# python обладает динамической типизацией, и вы не сможете определить размер памяти необходимый для работы потока, потому что заранее вы не знаете тип данных.

Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

56. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от Филипп Филиппович (ok) on 27-Окт-14, 20:02 
А различие -- да, именно в неэффективной и устаревшей на сегодня ВМ и устаревшем же байт-коде. То есть именно об этом я и говорил.

> А еще в
> отличие от Java и С# python обладает динамической типизацией, и вы
> не сможете определить размер памяти необходимый для работы потока, потому что
> заранее вы не знаете тип данных.

Оппаньки. Такое даже комментировать сложно. То есть в Java так-таки всё известно? :-) Открою секрет: на момент создания объекта -- известно. Когда вы работаете с объектом через любой его интерфейс, точно так же ничего не известно. Да, это не настолько полная неизвестность, как в случае Python, но к выделению памяти проблема не имеет вообще никакого отношения.

Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

12. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  –2 +/
Сообщение от Аноним (??) on 07-Июл-14, 18:04 
>  шёл 2014 год...

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

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

28. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от МММ (??) on 07-Июл-14, 20:59 
> шёл 2014 год...

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

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

31. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от Аноним (??) on 07-Июл-14, 22:49 
Тем более что в современном мире параллельность означает наличие многих машин, а не четырёхядерного процика, упирающегося в частоту оперативы.
Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

35. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от rob pike on 08-Июл-14, 01:21 
Это вам в Cloud Haskell.
Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

39. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от МММ (??) on 08-Июл-14, 07:18 
> Это вам в Cloud Haskell.

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

Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

50. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от Аноним (??) on 08-Июл-14, 21:08 
В нормальных операционных системах время создания процесса такое же как и потока.
Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

5. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от anonim66666 on 07-Июл-14, 13:55 
если нужно что то быстро обсчитать(очень тяжелое), то проще и быстрее заиспользовать pyopencl. он в разы(на порядки, если на gpu) быстрее, чем на многопоточном python.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

15. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  –1 +/
Сообщение от Аноним (??) on 07-Июл-14, 18:09 
> pyopencl.

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

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

22. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от МММ (??) on 07-Июл-14, 20:39 
>> pyopencl.
> Учитывая что в opencl пишут на специфичном подвиде C, питон там вообще
> лишний элемент пейзажа.

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

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

18. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от Антоним on 07-Июл-14, 19:50 
Не каждую задачу можно ускорить, запустив на GPU. К тому же требует модификации кода.
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

6. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от anonim66666 on 07-Июл-14, 14:00 
считаем Mandelbrot Set на gpu за 41ms, а не за 9 сек и даже не за 23 ...
http://www.bealto.com/mp-mandelbrot_benchmarks.html
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

16. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  –3 +/
Сообщение от Аноним (??) on 07-Июл-14, 18:11 
> считаем Mandelbrot Set на gpu за 41ms, а не за 9 сек
> и даже не за 23 ...

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


Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

21. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от МММ (??) on 07-Июл-14, 20:37 
>Только GPU вообще питон выполнять не умеет

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

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

9. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  –1 +/
Сообщение от Аноним (??) on 07-Июл-14, 15:46 
> При выполнении однопоточных программ наблюдается заметное отставание от PyPy на 20% - 300%

не нужно.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

10. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от Аноним (??) on 07-Июл-14, 15:50 
>Для решения проблемы с распараллеливанием на многоядержных системах в PyPy-STM осуществлён переход от традиционных блокировок к программной транзакционной памяти, в качестве механизма для обеспечения параллелизма.

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

19. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от Антоним on 07-Июл-14, 19:52 
Аппаратные реализации тоже неплохо работают. Подробностей реализации, конечно же, нет, но Intel сообщали, что используют протоколы когерентности кэша для транзакций. Задачи схожи.
Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

11. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от Anonymus on 07-Июл-14, 17:04 
То есть второй проц добавляет 90% производительности, а четвёртый всего-лишь 18. Апроксимируя получим 10% прирост на энный процессор. Вопрос: а накуя такое чудо?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

14. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от Аноним (??) on 07-Июл-14, 18:08 
> То есть второй проц добавляет 90% производительности, а четвёртый всего-лишь 18.

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

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

17. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +2 +/
Сообщение от bav (ok) on 07-Июл-14, 18:50 
> Вопрос: а накуя такое чудо?

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

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

25. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от all_glory_to_the_hypnotoad (ok) on 07-Июл-14, 20:47 
лучше не будет, STM в случае топика в принципе не масштабируется.
Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

26. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от bav (ok) on 07-Июл-14, 20:54 
> STM в случае топика в принципе не масштабируется

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

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

32. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от all_glory_to_the_hypnotoad (ok) on 07-Июл-14, 23:04 
Мало ли что там написано и какими надеждами живут разработчики PyPy-STM, фундаментальные проблемы всё равно остаются и решить они их не смогут.
Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

36. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +1 +/
Сообщение от chinarulezzz (ok) on 08-Июл-14, 02:06 
расскажи о фундаментальных проблемах а еще лучше на здоровенную книжку линк, или скажи что всем и так это всё известно, и на форумах не раз обсуждалось :D
Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

52. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +1 +/
Сообщение от Аноним (??) on 08-Июл-14, 22:58 
> То есть второй проц добавляет 90% производительности, а четвёртый всего-лишь 18. Апроксимируя
> получим 10% прирост на энный процессор. Вопрос: а накуя такое чудо?

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


Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

24. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  –3 +/
Сообщение от all_glory_to_the_hypnotoad (ok) on 07-Июл-14, 20:46 
> При выполнении однопоточных программ наблюдается заметное отставание от PyPy на 20% - 300%, но уже при запуске многопоточной программы на двух ядрах CPU PyPy-STM начинает опережать PyPy, при увеличении числа вовлечённых в выполнение ядер CPU разрыв увеличивается.

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

53. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от Аноним рус on 09-Июл-14, 11:18 
Это может быть только ваши потребности такие, и ваши цифры, для других они другие.
Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

54. "Первый выпуск PyPy-STM, интерпретатора Python с поддержкой м..."  +/
Сообщение от Аноним рус on 09-Июл-14, 11:34 
Есть данные по сравнению потребления оперативной памяти PyPy-STM и PyPy?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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