Ожидаете ли вы, что будущие поколения процессоров не связаны с кэшем?

Question

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

Это не проблема для современных процессоров Intel. Но я хочу, чтобы эта программа приносила доход как минимум в течение следующих десяти лет (непродолжительное время для программного обеспечения), поэтому мне интересно, думаете ли вы, что это может стать проблемой для будущих архитектур ЦП.

Answer 1

Мы уже там. Компьютеры требуют когерентности кеша, но в то же время у них есть временный буфер хранения для записи, чтение может быть завершено через этот буфер вместо кеша (т. Е. Буфер хранения только что превратился в некогерентный кеш), а недействительные запросы также ставятся в очередь, позволяя процессору временно использовать строки кэша, которые, как он знает, устарели.

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

Что касается избежания блокировок и т. Д.: Всегда сложно контролировать уровень знаний людей через Интернет, поэтому либо вы ошибаетесь в том, что, по вашему мнению, может работать, либо находитесь на переднем крае программирования без блокировок. Трудно сказать.

Вы понимаете протокол MESI, барьеры памяти и видимость? Вы читали материал от Пола МакКенни и т. Д.?

Answer 2

Я подозреваю, что будущие поколения процессоров все равно будут обрабатывать для вас согласованность кэша. Без этого большинство основных методологий программирования потерпит неудачу. Я сомневаюсь, что любая архитектура процессора, которая будет широко использоваться в течение следующих десяти лет, лишит законной силы текущую модель программирования - она ​​может расширить ее, но трудно отбросить что-то столь широко распространенное.

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

Answer 3

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

http://acg.cis.upenn.edu/papers/cacm12_why_coherence.pdf

«Почему согласованность кэша на чипе остается здесь» - Мартин, Хилл и Сорин

Answer 4

Я не знаю, по сути. Но я бы хотел увидеть тенденцию к некогерентным когерентным режимам.

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

Однако, как отмечает Рид Копси, весь мир вычислительной техники x86 построен на предположении когерентности кэша (что даже больше, чем доля Microsoft на рынке!). Так что это не исчезнет в ближайшее время!

Answer 5

Вопрос кажется мне вводящим в заблуждение. Архитектура процессора не так важна, важна модель памяти платформы, на которой вы работаете.

Вы разрабатываете приложение для некоторой среды с определенной моделью памяти. Например. если вы в настоящее время ориентируетесь на x86, вы можете быть уверены, что любая будущая платформа будет реализовывать ту же модель памяти, когда она будет выполнять код x86. То же самое верно для виртуальных машин Java или .NET и других платформ выполнения.

Если вы планируете портировать ваше текущее приложение на некоторые другие платформы, если модель памяти платформы будет отличаться, вам придется подстраиваться под нее, но в этом случае вы тот, кто делает порт, и у вас есть полный контроль за то, как ты это делаешь. Это, однако, верно даже для современных платформ, например, Модель памяти PowerPC позволяет производить гораздо больше переупорядочений, чем модель x86.

Answer 6

Вы делаете странный запрос. Вы запрашиваете наше (сообщество SO) предположения о будущих архитектурах ЦП - очень опасное предложение. Готовы ли вы положить свои деньги туда, где находится наш рот? Потому что, если мы ошибаемся, и ваше заявление не получится, именно вы не будете зарабатывать деньги ...

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