Анонсирована аппаратная поддержка транзакционной памяти в Haswell

[mark_ablov]

Насчет префиксов, используется тот же опкод что для rep (0xF2/0xF3), конфликтов не возникает ибо обрласть применения префиксов различается — rep работает только с несколькими строковыми инструкциями, а в HLE — с другим набором.
Если процессор не поддерживает TSX, то эти префиксы перед не-строковыми инструкциями («округленно», там есть еще несколько вариантов) приводят к UB, хотя на самом деле, поведение стандартно — просто игнорирование.

[novoselov]

А Microsoft в курсе? У них тоже был проект STM.NET, возможно производительность повысят

[izard]

Я не работаю непосредственно с Microsoft, но уверен, что коллеги, которые работают в штате Вашингтон им сообщили по секрету где-то в прошлом году.

Надеюсь, STM.NET это поможет, и-или F# тоже.

[susl]

Так ведь этот проект закрыли давно, не?

[VenomBlood]

Судя по всему — да, общался более года назад с разработчиками из PnP группы, они сказали что планов по развитию нету. Уж слишком криво это интегрируется в язык.

[vlm]

В шестом выпуске fprog.ru, в интервью SPJ из Microsoft Research есть несколько мыслей по поводу STM.NET и STM вообще.

[vikky13]

Вопросы от полного дилетанта в этой теме:
-а какой прирост производительности от этого чуда ожидается на каких-нибудь известных задачах?
-"Производители процессоров давно облизывались на поддержку Transactional Memory в железе. Это потенциально решило бы проблемы с производительностью" -это ведь только в случае сильно многопоточных приложений, да?
и еще более глупый вопрос: а чем синтаксис транзакций может\должен отличаться от синтаксиса критической секции? она тоже определяет область кода, внутри которой,… хотя там внутри и совсем другой механизм, но для программиста в чем разница?

[izard]

1. У меня пока нет железки, так что не мерял. Плюс мы же вроде не имеем права публиковать бенчмарки до выхода железа. По идее если просто перекомпилять с HLE pthreads mutexes, и запустить что-то с большим количеством локов но низким контеншеном на EP или лучше EX будет очень хороший спидап.

2. Да, конечно, в случае сильно многопоточных приложений просто будет лучше скейлится. Но так как цена работы программиста давно уже больше цены процессорного времени, упрощение разработки многопоточного кода тоже хорошая мотивация.

3. Для программиста основная разница в том, что с критической секцией надо постоянно держать в голове, что при взаимодействии с другими локами возможен deadlock, в транзакции нет. Плюс если критическая секция возникла из-за того, что код внутри работает с разделяемой структурой (хэшом, массивом, списком) логично, что оптимистическое выполнение этого кода многими транзакциями одновременно будет часто быстрее, чем обычное сериализованное.

[vikky13]

По первым двум пунктам все ясно. Неясно, почему для stm предлагается отдельный синтаксис (расширение С++), а для обычной критической секции — нет. Мне кажется, что уж если делать, то целиком для всех. Тем более, что HLE все равно все скроет.

[izard]

да, я бы тоже добавил к обычной critical_section optimistic_critical_section с HLE, и чтобы программист или компилятор/рантайм решали, какую выбрать, в зависимости от контеншна, величины, кода внутри.

[stalkerg]

Эх… как всё хорошо начиналось. А теперь везде эту фичу выключили (баги) и опять нету ни одного живого процессора с TSX.

[SerCe]

В Broadwell наверняка поправят же.

[stalkerg]

Судя по слухам, то только в Skylake…

[SerCe]

По, например, этим слухам пофиксят в Broadwell, до выхода десктопных же еще довольно много времени.