Здравствуйте, remark, Вы писали:

R>Но основная беда даже не в этом.

R>(опустим пока такие тривиальные вещи как сериализация на мьютексах)

R>Передача кэш-линии занимает порядка 150-350 тактов. Даже без всяких атомарных операций и пр.
R>Т.е. скорость работы снижается до 100 (!) раз. Т.о. тривиальный producer-consumer может стать ботлнеком, если данные просто переходят из одного кэша в другой (без всяких atomic, мьютексов, евентов, вызовов я ядро для пробуждения consumer).
R>Плюс шина межпроцессорного/межядерного взаимодействия может стать боттлнеком, так что приложение просто не будет масштабироваться вообще при добавлении ядер, даже если потоков/работы достаточно, и нет сериализации на мьютексах, ядра не загружены и шина памяти не загружена.

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

Это означает, что
— чем больше взаимодействие между потоками основано на пакетной обработке, тем лучше (впрочем, это и для одноядерных справедливо — в том плане, чтоб минимизировать переключения потоков)
— для очередей, не предполагающих пакетную обработку — нужно разбрасывать элементы по разным линейкам
Правильно?

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