Кеш линии процессора

Очень часто со стороны программистов можно заметить утверждение
"Вот эти данные скорее всего попадут в кеш линию процессора" - на чем основываются программисты, когда делают подобные выводы?
Еще интересует то, что если данные которые претендуют на попадание в кеш превышают размер одной линейки кеша, могут ли они сохраниться сразу в двух линейках последовательно?

Например есть массив
L1 ---60% от последовательных данных---
L2 ---40% от последовательных данных(а остаток свободного места занят другими данными)---

0

Кэш лайн - это сплошной кусок памяти размером в 32 байта, выровненный на такой же размер. Этот размер может быть 64 или 128 байт (или ...) - зависит от конкретного устройства процессора. Для простоты буду называть его словами "32 байта".

При обработке запроса в память со стороны процессорв, реальное обращение в память происходит кусками по 32 байта. Т.е. если мы читаем из памяти 1 байт, то в реальности прочтётся кусок размером 32 байта с адреса, выровненного на 32. И весь этот кусок попадёт в кэш в виде кэш-лайна. Допустим, мы читаем байт по адресу 65, в реальности из памяти прочтётся 32 байта из диапазона адресов 64-95 и весь этот кусок памяти осядет в кэше, а до исполнительного устройства дойдёт только один нужный байт. Если после этого мы захотим прочесть один байт по адресу 66, то он уже прочтётся из кэша

Сообщение от sys_beginner "Вот эти данные скорее всего попадут в кеш линию процессора" - на чем основываются программисты, когда делают подобные выводы?

Например, у нас горячим является массив размером 1024 байта. Если мы его разместим в памяти по адресу, выровненному на 32, то мы будем уверены в том, что 32-й, 33-й, ... 63-й байты этого массива попадут в один кэшлайн

Сообщение от sys_beginner Еще интересует то, что если данные которые претендуют на попадание в кеш превышают размер одной линейки кеша, могут ли они сохраниться сразу в двух линейках последовательно?

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

4

Evg,
Большое спасибо!

Сообщение от Evg Если мы его разместим в памяти по адресу, выровненному на 32, то мы будем уверены в том, что 32-й, 33-й, ... 63-й байты этого массива попадут в один кэшлайн

1. А как это можно сделать? aligned_storage и ему подобные?
2. Что делать если используется большой пул памяти? достаточно что бы его начальный адрес был выровнен на 32? Или внутри пула относительно содержимых там типов так же нужно применять выравнивание?

Добавлено через 6 минут
И как понять какое выравнивание требует процессор для кеша(которое как я понял должно быть равно размеру линейки) что бы когда программа запускалась на разных процессорах всегда использовать эффективное выравнивание

0

Сообщение от sys_beginner 1. А как это можно сделать? aligned_storage и ему подобные?

В GNU C это выглядит как:

Сообщение от sys_beginner 2. Что делать если используется большой пул памяти? достаточно что бы его начальный адрес был выровнен на 32? Или внутри пула относительно содержимых там типов так же нужно применять выравнивание?

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

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

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

1

Сообщение от Evg int a[100] __attribute__((aligned(32)));

Не понял что означает эта запись

Сообщение от Evg На уровне языка программирования обычно работа идёт с переменными. Как только ты выровнял начало переменной на нужный размер, то обо всех внутренностях переменной уже можно делать какие-то предположения. Если память выделена динамически, то ты всегда можешь прибавить к указателю нужное значение, чтобы обеспечить его выравненность.

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

Добавлено через 1 час 11 минут

Сообщение от sys_beginner То есть не важно память динамическая или стековая главное что бы при обращении к переменной или ключу массива, адрес переменной/ключа был выровнен так как нам это нужно?

Скажем мы пишем пул для хранения объектов. Размер каждого объекта 57 байт. Нужно ли выделять место в пуле равное sizeof(object) * objects_count или нужно больше выделять для обеспечения выравнивания? И для каждого объекта добавлять свой padding? И как определить какое нужно выравнивание в конкретном случае?

0

Сообщение от sys_beginner Не понял что означает эта запись

Это означает, что переменная при распределении в память попадёт по адресу, выровненному на 32

Сообщение от sys_beginner То есть не важно память динамическая или стековая главное что бы при обращении к переменной или ключу массива, адрес переменной/ключа был выровнен так как нам это нужно?

Не совсем. Адрес НАЧАЛА нужного куска памяти должен быть выровнен. Т.е. если адрес начала переменной выровнен на 32, то, например, байты номер 32-65 внутри этой переменной гарантированно окажутся внутри одного кэшлайна. Т.е. программист может этим управлять и контролировать. Но если адрес начала выровнен только на 16, то такой гарантии уже не будет

Сообщение от sys_beginner Скажем мы пишем пул для хранения объектов. Размер каждого объекта 57 байт. Нужно ли выделять место в пуле равное sizeof(object) * objects_count или нужно больше выделять для обеспечения выравнивания? И для каждого объекта добавлять свой padding?

Во первый адрес начала пула должен быть выровнен на 32. Далее адрес любого объекта в этом пуле должен быть выровнен на 32. После этого первые 32 байта любого объекта гарантированно будут в одном кэшлайне. То же самое можно сказать и про остаточные 25 байт любого объекта

Сообщение от sys_beginner И как определить какое нужно выравнивание в конкретном случае?

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

1

Сообщение от Evg Во первый адрес начала пула должен быть выровнен на 32.

Насколько я понимаю, new и malloc для этого не годятся и нужно пользоваться инструментами, которые могут в качестве параметра принимать нужное нам выравнивание? А цифра 32 это условно, в зависимости от размера линеек?

0

Сообщение от sys_beginner Насколько я понимаю, new и malloc для этого не годятся и нужно пользоваться инструментами, которые могут в качестве параметра принимать нужное нам выравнивание?

Годятся, но с доработкой напильником. Допустим, тебе нужно выделить 1024 байта, но всегда выделаешь на 32 байта больше. Таким образом в первых 32 байтах всегда окажется точка, выровненная на 32. А первые несколько и последние несколько байт (в сумме 32) окажутся неиспользованными.

Здесь я говорю именно про кусок памяти, через new массив объектов напрямую, конечно же, так не выделишь. Т.е. через new нужно выделить кусок памяти (грубо говоря, массив char'ов), затем вычислить нужный адрес начала и через placement new натянуть массив объектов на эту память. Каждый объект можно искусственно добить нужным количеством неиспользуемых полей, чтобы размер каждого объекта был кратен 32 байтам

Сообщение от sys_beginner А цифра 32 это условно, в зависимости от размера линеек?

Да. Цифра 32 везде фигурирует в том контексте, о котором я оговаривался в первом абзаце в посте #2

1

Кажется понял

Сообщение от Evg Каждый объект можно искусственно добить нужным количеством неиспользуемых полей, чтобы размер каждого объекта был кратен 32 байтам

Это слегка муторно Если я все правильно понял, думаю самый нормальный вариант это как ты сказал для каждого объекта в пуле отдельно выделять память, например как массив char или с помощью operator new, размер которых будет равен sizeof объекта + столько байт, что бы размер объекта в пуле был кратен размеру кеш линии.

0

Сообщение от sys_beginner Это слегка муторно

Допустим, у тебя в объекте 57 полезных байт. Для простоты я их опишу в виде массива из 57 char'ов. Если ты искусственно добавишь ещё 7 байт (т.е. sizeof станет равным 64), то будет гораздо меньше возни с выравниванием отдельно взятого объекта или с реализацией массива объектов

1

Сообщение от Evg то будет гораздо меньше возни с выравниванием отдельно взятого объекта или с реализацией массива объектов

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

0

А... ты в этом смысле. Ну тогда по сути да, надо весь геморрой локализовать в менеджере памяти (или хз как его правильно назвать)

0

Evg,
Ага
Спасибо тебе, очень помог!

Добавлено через 18 минут
Evg,
Ещё один вопрос назрел
Предположим длина линейки кеша равна 128 а размер объекта хранимого в пуле равен 63. Так как это пул объекты железно следуют друг за дружком(плотно расположены). Если выравнивать до 128 то получится нам нужно будет добавить 65 байт мусора если выравнивать каждый объект по размеру линейки.
Можно анализировать размер кеш линии (если есть такая возможность) и таким образом уместить в одной линейке не один объект, а два, прибавив по одному байту к каждому объекту сделав их размер 64. Затем проц запишет эти 128 байт в кеш и уже два объекта будут закешированы вместо одного. Но тут палка двух концов, насколько я понимаю, если один из этих двух объектов будет изменен, то будет сброшен кеш всей линии

0

Сообщение от sys_beginner Предположим длина линейки кеша равна 128 а размер объекта хранимого в пуле равен 63

Если размер объекта меньше размера кэшлайна, то его надо помещать целиком вовнутрь одного кэшлайна. Т.е. внутри одного кэшлайна может оказаться несколько объектов

Сообщение от sys_beginner Но тут палка двух концов, насколько я понимаю, если один из этих двух объектов будет изменен, то будет сброшен кеш всей линии

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

1

Evg,
Понял, спасибо!

0