Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет yigal_s ([info]yigal_s)
@ 2013-03-31 20:54:00


Previous Entry  Add to memories!  Tell a Friend!  Next Entry
В связи с появлением модели памяти С++ (и прочих, вроде java) открываются два интересных направления:

1. доведение НАБЛЮДАЕМОГО переупорядочивания процессорных операций и прочих операций на кеше и памяти до максимально возможной степени безумия - ибо подробный и внятный программистский стандарт даёт кое-какие гарантии производителям железа, что новые причуды их процессоров будут заведомо (в теории, конечно) совместимы с программистскими практиками. Во всяком случае, теперь более-менее ясно к чему программистское сообщество в принципе готово, или должно быть готово, а что может посчитать недопустимым превышением допустимого уровня переупорядочивания операций.

2. одновременный ввод максимально эффективных SC-атомарных операций для обеспечения эффективной и общеупотребимой SC-модели.

Удастся ли SC-атомарным операциям "вынести" полностью все другие, "relaxed" варианты атомарных операций на всех архитектурах (что предполагает их высокоэффектвную реализацию в контексте максимально-безумного переупорядочения операций - см пункт 1), станет ли "SC+no races" действительно общепринятым стандартом практики даже низкоуровнего программирования - вопрос открытый. Лично для меня это видится как довольно неожиданный подход, и перспективы его на действительно интенсивно переупорядочивающих архитекрурах мне не ясны совершенно. Но... направление заявлено.


(Добавить комментарий)


[info]mediant@lj
2013-04-01 03:17 (ссылка)
1. Itanuim точно, и наверное RISC тоже, давно уже имеют explicit контроль переупорядочивания, и недостатки с++ стандарта им в этом никак не мешали :) Другое дело, что их потенциал был наверное не полностью реализован, хотя в тонкости поведения компиляторов на этих платформах я не вникал.

(Ответить) (Ветвь дискуссии)


[info]yigal_s@lj
2013-04-01 09:24 (ссылка)
Разумеется, они все имеют подобный контроль. Иначе я вообще не знаю, как было бы возможно на них писать корректный мультитредный код. )

И, разумеется, производители процессоров в этой теме разбираются минимум не хуже, чем авторы стандарта.

С другой стороны, если учесть, что сам Intel засветил спек по переупорядочиванию на x86 лишь 5 лет назад, а также всякие рассказы Херба Саттера о том, как авторы С++ стандарта общались со специалистами IBM по поводу возможности хоть что-то куда-то сдвинуть относительно той точки, что задавал С++ стандарт, то кое-что в этой теме, наверное, далеко от идеала и несколько идёт вразнобой и определенных недопониманий всё же может хватать даже на уровне инженеров - дизайнеров железа.

Я, в общем, малокомпетентен, скорее излагаю тут то, что сам услышал и какие-то поверхностные впечатления, чем обоснованные предсказания )

(Ответить) (Уровень выше)


[info]yigal_s@lj
2013-04-01 09:34 (ссылка)
кстати, пункт 1 и производителей компиляторов касается. возможно, это даже важнее.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]mediant@lj
2013-04-01 11:05 (ссылка)
очевидно, что компиляторы смогут делать более агрессивную оптимизацию. думаю, что именно эта востребованность параллельного выполнения при наличии средств ее реализовать может дать новый толчок развитию процессоров.

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

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]yigal_s@lj
2013-04-01 22:50 (ссылка)
"закручивание гаек" - это вообще недопустимая вещь, т.к. в этом случае процессор попросту не работает в том моде, ради которого он проектировался.

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

(Ответить) (Уровень выше)