Gregory's Server
@rayslava А можно подробнее про торможение процессора? Из того, что я читал, я сделал вывод, что торможение будет в любом случае, просто мьютекс тормозит все ядра сразу, а барьеры памяти позволяют правильным образом разнести торможение ядер во времени, давая больше свободы для оптимизации компилятором. Это не так?
|
3 comments
 @standmit ну и само собой, всё это относится скорее к очень суровому хайлоаду, когда мы начинаем экономить такты, и когда экономия сотни микросекунд, умноженная на миллиарды серверов очень конкретной аппаратной конфигурации, даёт миллионы долларов экономии.  всем норм на похорониксе в последнее время пишут, что пошла движуха по переходу на x86_64v3 во многих дистрах |
@standmit Ну мьютекс вовсе необязательно тормозит хоть что-нибудь, это зависит от имплементации и кода (например, вот обзор бустового мьютекса есть, он тут вообще не лочится: https://www.appsloveworld.com/cplus/100/33/why-is-stdmutex-faster-than-stdatomic ), а про барьеры — на восстановления когерентности кэшей между ядрами всё равно будет уходить время, причём тут зависит именно от процессора и от реализации этого самого протокола когерентности, а не от того, как расставлены барьеры в коде. Тут скорость зависит не только от кода и компилятора, но и от того, как код разлёгся по ядрам, что попало в кэши, и как оно себя ведёт. При аккуратно расставленных барьерах торможение будет, конечно, меньше, чем если везде лупить sequential consistent требование, но какое-то всё равно будет, и это стоит учитывать
@standmit Ну мьютекс вовсе необязательно тормозит хоть что-нибудь, это зависит от имплементации и кода (например, вот обзор бустового мьютекса есть, он тут вообще не лочится: https://www.appsloveworld.com/cplus/100/33/why-is-stdmutex-faster-than-stdatomic ), а про барьеры — на восстановления когерентности кэшей между ядрами всё равно будет уходить время, причём тут зависит именно от процессора и от реализации этого самого протокола когерентности, а не от того, как расставлены барьеры в коде. Тут...