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

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

И для Perl 5 тоже, перлобратец мой: http://search.cpan.org/~rkinyon/DBM-Deep-2.0009/lib/DBM/Deep.pod

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

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

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

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

И то, и другое.

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

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

В новости есть ссылка, в материале по ссылке есть еще одна: https://bitbucket.org/Raemi/stm-benchmarks/src

В новости есть ссылка, в материале по ссылке есть еще одна: https://bitbucket.org/Raemi/stm-benchmarks/src

спасибо!

кажется по немножку начинаю понимать... ``from __pypy__.thread import atomic`` ...

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

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

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

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

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

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

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

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

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

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

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

CPython 	81.1
PyPy-STM 	50.2

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

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

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

а с JIT:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Отсебятина.

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

А под CSP ты имеешь в виду

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

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

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

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

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

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

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

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

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тыщ блокировок в секунду.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Моё имхо.

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

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

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

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

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

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

не хотят

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

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

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

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

Я игрался с 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❯

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

Понятно спасибо

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

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

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

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