LINUX.ORG.RU

В PyPy появилась поддержка STM

 ,


0

3

Спустя два года после начала работы в PyPy была добавлена начальная поддержка Software Transactional Memory (STM). STM позволяет избавить многопоточные приложения от блокировок.

Первые результаты показали очень хорошее масштабирование: выполнение кода в 8 потоков на неназванном четырёхъядерном процессоре увеличило скорость в 4.6 раза (процессор был с hyper-threading).

К сожалению, пока поддержка STM далека от оптимальной. Она создаёт значительные накладные расходы и на однопоточных приложениях скорость PyPy-STM не сильно отличается от CPython. Разработчики обещают в будущем исправить эту досадную проблему.

>>> Подробности

★★★★★

Проверено: Shaman007 ()

В Perl 6 уже давно, если что.

anonymous ()

Уже быстрее CPython и при этом масштабируется.

Интересно, а можно поверх STM изобразить CSP?

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

а можно поверх STM изобразить CSP?

Применительно к PyPy или вообще?

true_admin ★★★★★ ()

есть небольшой пример, как можно использовать этот волшебный STM?

(или оно автоматом, во время чего-то %) %) ?)

user_id_68054 ★★★★★ ()

Тру-админ, Шаман, вы вообще не тру, ничего не поняли в новости, которую переводили.

Это достигается путём «оборачивания» доступа к общим данным внутрь транзакций которые выполнятся атомарно на уровне процессора и памяти. Пока эту технологию поддерживают лишь процессоры Intel и IBM.

Чепуха, там STM на то и S-TM, а не H-TM, что не требует поддержки со стороны процессора. Где вы нашли эту чушь в оригинальной новости?

Она создаёт значительные накладные расходы и на однопоточных приложениях скорость PyPy-STM не сильно отличается от CPython.

Вы хоть на цифры-то посмотрели? На однопоточных приложениях, однопоточный PyPy-STM *сливает* CPython как никто... Только на 8-ми потоках она ухитряется его перегнать.

Разработчики обещают в будущем исправить эту досадную проблему.

Досадная проблема заключается в том, что STM плохо взаимодействует с JIT, за счет которого PyPy и выигрывает в общем случае у CPython. А сейчас получается так, что из-за барьеров, в ветке STM он (JIT) вообще почти не работает, отсюда и результаты выше, т.е. в текущем виде от него может хоть какая-то польза быть только на 6 и больше ядрах (не HT).

Но, так или иначе, работа ведется, и специалистов текущие результаты действительно впечатляют. Возможно, что через пару лет STM-таки подружится с JIT.

А новость свою позорную лучше перепишите...

anonymous ()
Ответ на: комментарий от anonymous

На однопоточных приложениях, однопоточный PyPy-STM *сливает* CPython как никто...

Без JIT - да (как и PyPy без STM), а с JIT:

CPython 	81.1
PyPy-STM 	50.2

Но про аппаратную поддержку, конечно, надо убрать.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Без JIT - да (как и PyPy без STM)

Ты имел в виду «как и PyPy без STM и без JIT»? В целом да, но с STM стабильно хуже, что не удивительно.

а с JIT:

А как насчет Richards? Так что не надо, в лучшем случае на уровне CPython... Я не говорю, что это плохо, но это факт.

anonymous ()
Ответ на: комментарий от anonymous

А как насчет Richards? Так что не надо, в лучшем случае на уровне CPython...

В лучшем случае оно быстрее, цифры я уже привел.

tailgunner ★★★★★ ()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от tailgunner

Эти цифры весьма сомнительны; смысл этого микробенчмарка в другом: CPython не масштабируется из за GIL, а вот STM масштабируется хорошо, на этом бенчмарке на 8 потоках быстрее аж в 4 раза и учитывая какие возможности это потенциально открывает, результат очень впечатляющий.

anonymous ()
Ответ на: комментарий от anonymous

Я понимаю смысл бенчмарка.

на 8 потоках быстрее аж в 4 раза

Причем 8 потоков - это с HT, а задача по существу вычислительная. Так что да, это круто. Если оно еще будет нормально жить с адаптированным numpy, то будет совсем круто.

tailgunner ★★★★★ ()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от tailgunner

Причем 8 потоков - это с HT, а задача по существу вычислительная. Так что да, это круто. Если оно еще будет нормально жить с адаптированным numpy, то будет совсем круто.

Да, на коленке все делалось (прямо на живом билд сервере запускали); по уму надо было бы HT отключить и собрать побольше точек, но пока как есть...

С самим ядром (т.е. NumPyPy) оно должно жить нормально, а вот со всем остальным (т.е. то, что вызывается через FFI) будут проблемы, если его дергать на тех переменных, которые должны быть атомарными (логично), но, с другой стороны, мне кажется, что это не так страшно, потому, что на самом деле можно обойти.

anonymous ()

Пока эту технологию поддерживают лишь процессоры Intel и IBM.
выполнение кода в 8 потоков на неназванном четырёхъядерном процессоре увеличило скорость в 4.6 раза (процессор был с hyper-threading).

Никогда еще Штирлиц не был так близок к провалу.

DNA_Seq ★★☆☆☆ ()
Ответ на: комментарий от DNA_Seq

Да, кстати, а я и не заметил, этот секретный процессор называется Xeon W3580; true_admin, ау, спрятался, да?!

anonymous ()
Ответ на: комментарий от tailgunner

А под CSP ты имеешь в виду акторов которые между собой через очереди сообщений общаются?

true_admin ★★★★★ ()
Ответ на: комментарий от anonymous

спрятался, да?!

Нету прав чтобы править новость.

Где вы нашли эту чушь в оригинальной новости?

Отсебятина.

Хм, если это софтварная реализация то с какой бы скоростью оно бы работало с хардварной? Особенно интересно что там в IBM-вских процах. Жаль что оно не для простых смертных.

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

Нету прав чтобы править новость.

Стой, а ты разве не один из модераторов? Хммм...

Хм, если это софтварная реализация то с какой бы скоростью оно бы работало с хардварной?

Да, это программная реализация «простой» идеи заворачивать потоки в транзакции, вместо того, чтобы не давать потокам выполняться параллельно вообще, или расставлять вручную много маленьких локов, чтобы защищать те структуры данных, которые они могут использовать одновременно.

Поддержка на уровне процессора, это, безусловно, дело хорошее, но там всё происходит несколько на другом уровне. По моему дилетантскому мнению, эти задачи несколько ортогональны, и, видимо, над поддержкой на уровне процессора надо скорее работать на уровне JIT оптимизатора и JIT бэкенда.

anonymous ()
Ответ на: комментарий от true_admin

если это софтварная реализация то с какой бы скоростью оно бы работало с хардварной?

Вряд ли намного быстрее (да и вообще я не уверен, что оно работало бы - Армин проводил анализ, там всё не радужно было).

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

http://en.wikipedia.org/wiki/Communicating_sequential_processes

Я это каждый раз перечитываю когда ты заводишь речь про CSP. Каждый раз долго въезжаю. Я поэтому думаю в терминах http://en.wikipedia.org/wiki/Actor_model_and_process_calculi , мне это ближе. В любом случае, всё сводится к передачи сообщений между различными частями системы, верно? В CSP эти части системы вообще анонимны, в акторах они называются акторами, ну а в конкретной реализации это могут быть потоки, гринлеты, ко-роутины... На сколько я далёк от истины?

Вот, если так рассуждать, то, получается, слабое место тут это работа с очередями т.к. это общий ресурс (наверно, единственный интерфейс взаимодействия в CSP). И надо как-то разруливать общий доступ к очередям. Значит STM тут можно применить чтобы атомарно добавлять сообщение в очередь и убирать сообщение из очереди. Других применений STM в CSP я пока не вижу. И у меня сразу вопрос стоит ли оно того. Я может на выходных заморочюсь замерить скорость работы очередей со спин-локом и мютексом. А вот как реализовать STM я пока не знаю. Впрочем, судя по инетам, мютексы имеют низкий практический потолок на линуксе. В районе 4-6тыщ блокировок в секунду.

Ну а теперь я с удовольствием твоё экспертное мнение :)

true_admin ★★★★★ ()
Ответ на: комментарий от tailgunner

Вряд ли намного быстрее

Есть ещё второй нюанс - а какой подход легче заимплементить. Лично я даже готов ноутбук заменить на haswell если это облегчит программирование (S|H)TM :).

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

Я это каждый раз перечитываю когда ты заводишь речь про CSP. Каждый раз долго въезжаю. Я поэтому думаю в терминах http://en.wikipedia.org/wiki/Actor_model_and_process_calculi , мне это ближе.

Ну, нам в универе рассказывали о CSP, а не об акторах, так что мне ближе CSP.

любом случае, всё сводится к передачи сообщений между различными частями системы, верно? [...] Вот, если так рассуждать, то, получается, слабое место тут это работа с очередями т.к. это общий ресурс

CSP - это модель параллельных вычислений без общей памяти (в этом ее принципиальное отличие от STM). Данные (я специально не говорю «сообщения») передаются по небуферизованным каналам, т.е. концептуально общий ресурс (очередь сообщений) отсуствует; данные между процессами копируются, так что, опять же концептуально, конфликтов вообще нет. Понятно, что в реализациях «под капотом» какие-то общие данные есть, но, может быть, есть какой-то хитрый трюк, выражающий CSP через STM.

STM тут можно применить чтобы атомарно добавлять сообщение в очередь и убирать сообщение из очереди

Тоже интересный вопрос. При достаточно богатой семантике вложенных atomic-блоков, наверное, можно избежать конфликтов. Но, блин, наверняка не мы первые задаем такие вопросы, так что ответы должны уже быть.

Ну а теперь я с удовольствием твоё экспертное мнение :)

Был бы я экcпертом - не задавал бы таких вопросов.

tailgunner ★★★★★ ()

А разве STM имеет смысл без превалирующей иммутабельности как в хаскеле или кложуре?

Вон, в .NET с иммутабельностью плохо и даже очень плохо, и по мнению некоторых это явилось одной из главных причин провала, когда пытались приручить STM c .NET на официальном уровне. Был у них такой проект внутри мелкософта. Впрочем, на уровне F# технология STM работает, но то F#.

dave ★★★★★ ()
Ответ на: комментарий от dave

А разве STM имеет смысл без превалирующей иммутабельности как в хаскеле или кложуре?

Как допилят — узнаем :). Вообще, всё зависит от сценария. И на питоне можно писать в иммутабельном стиле.

true_admin ★★★★★ ()
Ответ на: комментарий от dave

Зачем вообще иметь STM с иммутабельностью?

zz ★★★★ ()
Ответ на: комментарий от zz

Мир иммутабелен только с т.з. программиста. А внутри оно... по-разному.

Моё имхо.

true_admin ★★★★★ ()
Ответ на: комментарий от zz

Оптимизация благодаря иммутабельности. Иначе у команды .NET получались большие накладные расходы для предоставления некоторых гарантий. Что-то такое писал один из известных хаскелистов. Я сильно не вдавался в подробности.

dave ★★★★★ ()

Это достигается путём «оборачивания» доступа к общим данным внутрь транзакций которые выполнятся атомарно на уровне процессора и памяти

Точно атомарно а не оптимистик локингом, сейчас набежит куча людей и будут пользоваться этим делом на 100 потоках

vertexua ★★★☆☆ ()
Ответ на: комментарий от dave

А разве STM имеет смысл без превалирующей иммутабельности как в хаскеле или кложуре?

Имеет смысл, просто превалируй иммутабельность в том коде, в котором STM

vertexua ★★★☆☆ ()
Ответ на: комментарий от vertexua

Да это вообще хрень, и её надо убрать из новости, но не хотят.

anonymous ()
Ответ на: комментарий от anonymous

не хотят

Да тупо некому. Впрочем, щас поговорю с riki....

true_admin ★★★★★ ()

Я очень рад что PyPy развивается. А что там по поводу Cython? Проект вроде отличный. Что вы думаете по поводу Cython-а?

shamkir ()
Ответ на: комментарий от shamkir

Задумка хорошая, но плохая интеграция с C всё портит. Так же понятны некоторые их закидоны. Например, не поддерживался оператор возведения в степень. А функция pow была. Странно это.

А так оно вполне годно, люди используют.

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

Я игрался с cython-ом. Очень большой прирост производительности, если использовать сишные типы(int, cdef, и т.д.) то скорость исполнения кода такая же, как и у Си. Если компилировать чисто питоновский код, то опять же прирост производительности по сравнению с PyPy (в том числе, если сравнивать с Nuitka) намного выше. Почему то многие просто переходят на какой нибудь другой язык (более быстрый), вместо того, что бы использовать Cython. Вы не знаете почему так происходит?

P.S. операция возведения в степень вроде есть ~/cython_executabe_file❯ cat embedded.pyx print 2 ** 2 ~/cython_executabe_file❯ ./embedded 4 ~/cython_executabe_file❯ time ./embedded 4 ./embedded 0,03s user 0,01s system 94% cpu 0,043 total ~/cython_executabe_file❯

shamkir ()
Ответ на: комментарий от shamkir

Проблема в том что cython это не питон. И не си. Поэтому на замену питона он не тянет. Это, скорее, дополнение. Причём, ни с чем не совместимое. Причём, рождающее свои грабли. Например, за integer overflow придётся следить самому.

true_admin ★★★★★ ()
Ответ на: комментарий от shamkir

Если компилировать чисто питоновский код, то опять же прирост производительности по сравнению с PyPy

Что, прям-таки любой код? Когда я смотрел Cython, он компилировал Python в вызовы Python API, и это работало немногим быстрее CPython.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Речь, скорее всего, идёт о том чтобы переписывать код с указанием типов аля «cdef int x».

PS на счёт integer overflow я может и загнал. Там это, похоже, настраивается.

true_admin ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.