Выравнивание памяти против выравнивания страницы

Question

Выравнивание памяти против выравнивания страницы

0

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

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

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

Xenoprimate 14 янв. 2015, в 20:51

Источник

0

«Ассоциативность кэша» является хорошим поисковым термином. Надеюсь, вы можете заменить свой второй абзац в своем мозгу лучшей моделью того, чего вы хотите избежать.
tmyklebu 14 янв. 2015, в 19:43
0

Это, безусловно, не имеет ничего общего с C #, C ++ или C. В частности, не C #.
abligh 14 янв. 2015, в 20:04
0

Я выбрал эти языки, потому что это языки, с которыми вам чаще всего приходится думать о подобных проблемах. И да, я думаю, что вы делаете в C # тоже.
Xenoprimate 14 янв. 2015, в 20:06
0

C # выравнивает поля своего объекта так же, как C ++, для повышения производительности. Компилятор сделает это за вас, вам не нужно об этом беспокоиться.
Lucas Trzesniewski 14 янв. 2015, в 20:07
0

Он выравнивает свои поля (если вы не переопределяете поведение), но я не знаю, что массивы структур выровнены по какой-либо конкретной границе (очень маловероятно, учитывая, что они перемещены GC), поэтому проблема выравнивания страниц остается. Кроме того, можно вручную выделить память с помощью AllocHGlobal и т. Д.
Xenoprimate 14 янв. 2015, в 20:09
1

Вы не контролируете, куда уходит выделенное пространство, даже с AllocHGlobal . А ваша программа видит только виртуальную память, что еще более усложняет ситуацию. Кроме того, .NET GC сильно оптимизирован. Если у вас действительно нет проблемы с производительностью, которая подтверждается профилированием вашего кода и прослеживает его (что на самом деле маловероятно), вам просто не стоит беспокоиться.
Lucas Trzesniewski 14 янв. 2015, в 20:21
0

Все еще можно выровнять распределения в .NET, см. Stackoverflow.com/questions/13413323/…
Xenoprimate 14 янв. 2015, в 23:15
0

Для процессоров X86 частичное предотвращение хеширования адресов с помощью буфера просмотра перевода (ссылка на вики), который часто реализуется с использованием адресуемой памяти содержимого (так называемой ассоциативной памяти), где все сравнения для сопоставления адресов выполняются параллельно.
rcgldr 15 янв. 2015, в 03:21

Показать ещё 6 комментариев

Теги:

c#

c++

performance

c

caching

2 ответа

2

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

4386427 14 янв. 2015, в 19:32

Ещё вопросы

«Ассоциативность кэша» является хорошим поисковым термином. Надеюсь, вы можете заменить свой второй абзац в своем мозгу лучшей моделью того, чего вы хотите избежать.
Это, безусловно, не имеет ничего общего с C #, C ++ или C. В частности, не C #.
Я выбрал эти языки, потому что это языки, с которыми вам чаще всего приходится думать о подобных проблемах. И да, я думаю, что вы делаете в C # тоже.
C # выравнивает поля своего объекта так же, как C ++, для повышения производительности. Компилятор сделает это за вас, вам не нужно об этом беспокоиться.
Он выравнивает свои поля (если вы не переопределяете поведение), но я не знаю, что массивы структур выровнены по какой-либо конкретной границе (очень маловероятно, учитывая, что они перемещены GC), поэтому проблема выравнивания страниц остается. Кроме того, можно вручную выделить память с помощью AllocHGlobal и т. Д.
Вы не контролируете, куда уходит выделенное пространство, даже с AllocHGlobal . А ваша программа видит только виртуальную память, что еще более усложняет ситуацию. Кроме того, .NET GC сильно оптимизирован. Если у вас действительно нет проблемы с производительностью, которая подтверждается профилированием вашего кода и прослеживает его (что на самом деле маловероятно), вам просто не стоит беспокоиться.
Все еще можно выровнять распределения в .NET, см. Stackoverflow.com/questions/13413323/…
Для процессоров X86 частичное предотвращение хеширования адресов с помощью буфера просмотра перевода (ссылка на вики), который часто реализуется с использованием адресуемой памяти содержимого (так называемой ассоциативной памяти), где все сравнения для сопоставления адресов выполняются параллельно.

jstine · Accepted Answer · 2015-01-16T15-35-00.000Z

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

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

Наконец, даже "эмпирическое правило" о "выравнивании наших переменных с границей N-байта" подчиняется базовому оборудованию. Большинство новых архитектур x86 для настольных компьютеров (большинство из которых составлено примерно после 2011 года) предпочитают упакованные данные, а не выровненные данные, потому что стоимость загрузки слов, упакованных по границе кешлин, стала дешевле, чем загружать больше общих линий для представления одного и того же набора данных. Но на мобильном устройстве работает ARM? Выравнивание по-прежнему очень важно.

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