Делиться с ближним своим для нас, божьих тварей, это очень характерно, считается добродетелью, и вообще, как утверждает , положительно отражается на карме. Однако в мире , созданном архитекторами микропроцессоров, такое поведение не всегда приводит к хорошим результатам, особенно если это касается разделения памяти между потоками.
Мы все «немного читали» об оптимизации работы с памятью, и у нас отложилось, что полезно, когда «кэш остается горячим», то есть данные, к которым часто обращаются потоки, должны быть компактными и находиться в ближайшем к процессорному ядру кэше. Все так, но когда дело доходит до того, чтобы делиться доступом, потоки становятся злейшими врагами [производительности], а кэш не просто горячий, он аж «горит адским огнем » – такая во круг него разворачивается борьба.
Ниже мы рассмотрим простой, но показательный случай возникновения проблем производительности многопоточных программ, а потом я дам несколько общих рекомендаций, как избежать проблемы потери эффективности вычислений из-за разделения кэша между потоками.
Рассмотрим случай, который хорошо описан в Intel64 and IA-32 Architectures Optimization Manual , однако про который программисты часто забывают, работая со массивами структур в могопоточном режиме. Они допускают обращение (с модификацией) потоков к данным структур, расположенных очень близко друг к другу, а именно в блоке, равном длине одной кэш-линии (64 байт). Мы это называем Сache line sharing
. Существует два типа разделения кэш-линий: true sharing
и false sharing
.
True sharing
(истинное разделение) – это когда потоки имеют доступ к одному и тому же объекту памяти, например, общей переменной или примитиву синхронизации. False sharing
(от лукавого) – это доступ к разным данным, но по каким-то причинам, оказавшимся в одной кэш-линии процессора. Сразу отметим, что и тот, и другой случай вредит производительности из-за необходимости аппаратной синхронизации кэш-памяти процессора, однако если первый случай часто неизбежен, то второй можно и нужно исключать.
Почему страдает производительность, поясним на примере. Допустим, мы обрабатываем последовательность структур данных, находящихся в очереди, в многопоточном режиме. Активные потоки один за одним вынимают следующую структуру из очереди и каким-либо образом обрабатывают ее, модифицируя данные. Что может произойти на аппаратном уровне, если, например, размер этой структуры небольшой и не превышает нескольких десятков байт?
Условия для возниконовения проблемы:
Два или более потока пишут в одну кэш-линию;
Один поток пишет, остальные читают из кэш-линии;
Один поток пишет, в остальных ядрах стработал HW prefetcher.
Может оказаться, что переменные в полях разных структур так расположились в памяти, что будучи считанными в L1 кэш процессора, находятся в одной кэш-линии, как на рисунке. При этом, если один из потоков модифицирует поле своей структуры, то вся кэш-линия в соответствии с cache coherency протоколом объявляется невалидной для остальных ядер процессора. Другой поток уже не сможет пользоваться своей структурой, несмотря на то, что она уже лежит в L1 кэше его ядра. В старых процессорах типа P4 в такой ситуации потребовалась бы долгая синхронизация с основной памятью, то есть модифицированные данные были бы отправлены в основную память и потом считаны в L1 кэш другого ядра. В текущем поколении процессоров (кодовое имя Sandy Bridge) синхронизационным механизмом используется общий кэш третьего уровня (или LLC – Last Level Cache), который является инклюзивным для подсистемы кэш-памяти и в котором располагаются все данные, находящиеся как в L2, так и в L1 всех ядер процессора. Таким образом, синхронизация происходит не с основной памятью, а с LLC, являющегося частью реализации протокола механизма когерентности кэшей, что намного быстрее. Но она все равно происходит, и на это требуется время, хотя и измеряемое всего несколькими десятками тактов процессора. А если данные в кэш-линии разделяются между потоками, которые выполняются в разных физических процессорах? Тогда уже придется синхнонизироваться между LLC разных чипов, а это намного дольше - уже сотни тактов. Теперь представим, что программа только и занимается тем, что в цикле обрабатывает поток данных, получаемых из какого-либо источника. Теряя сотни тактов на каждой итерации цикла, мы рискуем «уронить» свою производительность в разы.
Давайте посмотрим на следующий пример, специально упрощенный для того, чтобы было легче понять причины проблемы. Не сомневайтесь, в реальных приложениях такие же случаи встречаются очень часто, и в отличие от рафинированного примера, даже обнаружить существование проблемы не так просто. Ниже мы покажем, как с помощью профилировщика производительности быстро находить такие ситуации.
Потоковая функция в цикле пробегает по двум массивам float a[i] и b[i], перемножает их значения по индексу массива и складывает в локальные переменные потоков localSum. Для усиления эффекта эта операция делается несколько (ITERATIONS) раз.
< ITERATIONS; j++){ for (i = tid; i < MAXSIZE; i+= NUM_PROCS){ a[i] = i + a[i] * b[i]; localSum += a[i];}} }
Беда в том, что для разделения данных между потоками выбран способ перемежевания индексов цикла. То есть, если у нас работают два потока, первый будет обращаться к элементам массивов a и b, второй - к элементам a и b, первый - a и b, второй - a и b, и так далее. При этом элементы массива a[i] модифицируются потоками. Не трудно видеть, что в одну кэш-линию попадут 16 элементов массива, и потоки будут одновременно доступаться к соседним элементам, «сводя с ума» механизм синхрониции кэшей процессора.
Самое неприятное в том, что мы даже не заметим по работе программы существование этой проблемы. Она будет просто работать медленнее, чем может, вот и все. Как оценить эффективность программы с помощью профилировщика VTune Amplifier XE, я уже описывал в одном из постов на Хабре. Используя профиль General Exploration , о котором я там упоминал, можно увидеть описываемую проблему, которая будет «подсвечена» инструментом в результатах профилировки в колонке Contested Access . Эта метрика как раз и измеряет соотношение циклов, потраченых на синхронизацию кэшей процессора при их модификации потоками.
Если кому-то интересно, что стоит за этой метрикой, то во время комплексной профилировки инструмент среди других аппаратных счетчиков собирает и данные счетчика:
MEM_LOAD_UOPS_LLC_HIT_RETIRED.XSNP_HITM_PS
– Точный счетчик(PS) выполненной(RETIRED) операции(OUPS) загрузки(LOAD) данных(MEM), которые оказалиcь(HIT) в LLC и модифицированны(M). «Точный» счетчик означает, что данные, собранные таким счетчиком в семплировании, относятся к указателю инструкции (IP), следующему после инструкции, которая была той самой загрузкой, приведшей к синхронизации кэшей. Набрав статистику по этой метрике, мы можем с определенной точностью указать адрес инструкции, и, соответственно, строку исходного кода, где производилось чтение. VTune Amplifier XE может показать, какие потоки читали эти данные, а дальше мы уже должны сами сориентироваться, как реализован многопоточный доступ к данным и как исправить ситуацию.
Относительно нашего простого примера ситуацию исправить очень легко. Нужно просто разделить данные на блоки, при этом количество блоков будет равно количеству потоков. Кто-то может возразить: если массивы достаточно большие, то блоки могут просто не вместиться в кэш, и данные, загружаемые из памяти для каждого потока, будут вытеснять друг друга из кэша. Это будет верно в случае, если все данные блока используются постоянно, а не один раз. Например, при перемножении матриц мы пройдемся по элементам двумерного массива сначала по строкам, потом по столбцам. И если обе матрицы не помещаются в кэш (любого уровня), то они буду вытеснены, а повторный доступ к элементам потребует повторной загрузки из следующего уровня, что негативно влияет на производительность. В общем случае с матрицами применяется модифицированное перемножение матриц поблочно, при этом матрицы разбиваются на блоки, которые заведомо помещаются в заданную кэш-память, что значительно увеличивает производительность алгоритма.
Int work(void *pArg) { int j = 0, i = 0; int tid = (int) pArg; for (j = 0; j < ITERATIONS; j++){ chunks = MAXSIZE / NUM_PROCS; for (i = tid * chunks; i < (tid + 1) * chunks; i++){ a[i] = i + a[i] * b[i]; localSum += a[i];}} }
False sharing
No False sharing
Сравнение доступа потоков к элементам массива в случае False sharing и в исправленном коде
В нашем простом случае данные используются всего один раз, и даже если они будут вытеснены из кэш-памяти, они нам уже не понадобятся. А о том, чтобы данные обоих массивов a[i] и b[i], расположенные далеко друг от друга в адресном пространстве, вовремя оказались в кэше позаботится аппаратный prefetcher – механизм подкачки данных из основной памяти, реализованный в процессоре. Он отлично работает, если доступ к элементам массива последовательный.
В заключение, можно дать несколько общих рекомендаций, как избежать проблемы потери эффективности вычислений из-за разделения кэша между потоками. Из самого названия проблемы можно понять, что следует избегать кодирования, где потоки обращаются к общим данным очень часто. Если это true sharing мьютекса потоками, то возможно существует проблема излишней синхроницации, и следует пересмотреть подход к разделению ресурса, который защещен этим мьютексом. В общем случае старайтесь избегать глобальных и статических переменных, к которым требуется доступ из потоков. Используйте локальные переменные потоков.
Если вы работаете со структурами данных в многопоточном режиме, уделите внимание их размеру. Используйте «подкладки» (padding), чтобы нарастить размер структуры до 64 байт:
struct data_packet
{
int address;
int data;
int attribute;
int padding;
}
Выделяйте память под структуры по выровненному адресу:
__declspec(align(64)) struct data_packet sendpack
Используйте массивы структур вместо структур массивов:
data_packet sendpack;
вместо
struct data_packet
{
int address;
int data;
int attribute;
}
Как видно, в последнем случае потоки, модифицирующие одно из полей, приведут к запуску механизма синхронизации кэш-памяти.
Для объектов, аллоцируемых в динамической памяти с помощью malloc или new, cоздавайте локальные пулы памяти для потоков, либо используйте параллельные библиотеки, которые сами умеют это делать. Например, библиотека TBB содержит масштабируемые и выравнивающие аллокаторы , которые полезно использовать для масштабируемости многопоточных программ.
Ну и заключительный совет: не стоит бросаться решать проблему, если она не сильно влияет на общую производительность приложения. Всегда оценивайте потенциальный выигрыш, который вы получите в результате затрат на оптимизацию вашего кода. Используйте инструменты профилировки, чтобы оценить этот выигрыш.
P.S. Попробуйте мой примерчик, и расскажите, на сколько процентов увеличилось быстродействие теста на вашей платформе.
Теги: Добавить метки
Одна из самых раздражающих вещей в Windows - это то, что она может зависнуть на несколько секунд, судорожно делая что-то на диске. Одна из причин - работа Windows с дисковой виртуальной памятью, заложенная по умолчанию. Windows загружает драйверы и приложения в память, пока она не заполнится, а затем начинает использовать часть жесткого диска, чтобы «подкачать» информацию, освобождая оперативную память для задач более высокого приоритета. Файл, который использует Windows для этого типа «виртуальной памяти» файл подкачки pagefile.sys, - хранится в корневом каталоге диска.
Поскольку жесткий диск работает медленнее, чем физическая оперативная память, то чем больше Windows подкачивает, тем медленнее работает компьютер. Вот почему добавление оперативной памяти ускоряет работу - уменьшается необходимость в виртуальной памяти. Независимо от объема установленной физической памяти есть способ улучшить производительность виртуальной памяти. Настройки Windows по умолчанию довольно консервативны, но, к счастью, их можно изменить для улучшения производительности. Важно помнить, что эксперименты с такими настройками оправданны только для систем с объемными жесткими дисками, когда виртуальной памяти можно уделить больше дискового пространства.
Часть 1: Настройки виртуальной памяти
Одна из причин того, что настройки по умолчанию приводят к низкой производительности, - файл подкачки растет и уменьшается при использовании, быстро становясь фрагментированным. Первый шаг должен устранить эту проблему, установив фиксированный размер файла подкачки.
Заметьте, что создание фиксированного файла подкачки обеспечит более постоянный объем свободного дискового пространства. Если жесткий диск переполняется, запретите Windows использовать последний бит свободного пространства.
1. В Панели управления откройте страницу Система и нажмите ссылку Дополнительные параметры системы.
2. Под вкладкой Дополнительно в разделе Быстродействие нажмите кнопку Параметры.
3. На странице параметров быстродействия выберите вкладку Дополнительно и затем нажмите Изменить, чтобы открыть окно виртуальной памяти.
4. Выключите параметр Автоматически выбирать объем файла подкачки, чтобы получить доступ к настройкам в этом окне.
5. Настройки виртуальной памяти устанавливаются отдельно для каждого диска. Если у вас только один диск, виртуальная память уже включена для этого диска. Если вы используете больше одного диска или раздела, то виртуальная память по умолчанию будет включена только на диске с Windows. Начните с диска, который в настоящий момент содержит файл подкачки.
Другой способ запретить Windows интенсивно использовать жесткий диск - отключение виртуальной памяти. Еще лучше будет переместить файл подкачки на другой физический диск, в этом случае при работе Windows с виртуальной памятью процесс не будет высасывать все соки из основного диска компьютера,
6. Чтобы установить фиксированный размер виртуальной памяти, отметьте Указать размер, а затем введите одно и то же значение в Исходный размер и в Максимальный размер.
Объем определите сами. Если на диске есть место, то выделите место в 2-3 раза больше объема установленной оперативной памяти. Можно поэкспериментировать с различными размерами для того, чтобы определить наиболее подходящий.
7. Важно: после того как вы сделали изменения, нажмите Задать или ОК для фиксации изменений перед переходом к другому диску.
8. Нажмите ОК в каждом из трех открытых диалоговых окон.
Если вы просто изменили размеры файла подкачки, изменение сразу вступит в силу. Но если вы добавили файл подкачки на каком-либо диске, то необходимо перезапустить Windows, прежде чем вы сможете использовать новые настройки.
Часть 2: Дефрагментируйте файл подкачки
Шаги, описанные в предыдущем разделе, устраняют возможность фрагментации файла подкачки, но они не исправят его, если он уже фрагментирован. Для лучшей производительности виртуальная память должна быть дефрагментирована, но если файл подкачки имеет фиксированный размер, то это нужно сделать только один раз. Есть несколько способов дефрагментировать файл подкачки:
Используйте PerfectDisk
Используйте усовершенствованный дефрагментатор PerfectDisk. Дайте ему команду дефрагментировать системные файлы, и он запланирует дефрагментацию при следующем запуске Windows.
Формула для среднего времени доступа к памяти в системах с кэш-памятью выглядит следующим образом:
Среднее время доступа = Время обращения при попадании + Доля промахов x Потери при промахе
Эта формула наглядно показывает пути оптимизации работы кэш-памяти: сокращение доли промахов, сокращение потерь при промахе, а также сокращение времени обращения к кэш-памяти при попадании. На рисунке 5.38 кратко представлены различные методы, которые используются в настоящее время для увеличения производительности кэш-памяти. Использование тех или иных методов определяется прежде всего целью разработки, при этом конструкторы современных компьютеров заботятся о том, чтобы система оказалась сбалансированной по всем параметрам.
Первичная причина увеличения объема встроенного кэша может заключаться в том, что кэш-память в современных процессорах работает на той же скорости, что и сам процессор. Частота процессора в этом случае никак не меньше 3200 MГц. Больший объем кэша позволяет процессору держать большие части кода готовыми к выполнению. Такая архитектура процессоров сфокусирована на уменьшении задержек, связанных с простоем процессора в ожидании данных. Современные программы, в том числе игровые, используют большие части кода, который необходимо извлекать из системной памяти по первому требованию процессора. Уменьшение промежутков времени, уходящих на передачу данных от памяти к процессору, - это надежный метод увеличения производительности приложений, требующих интенсивного взаимодействия с памятью. Кэш L3 имеет немного более высокое время ожидания, чем L 1 и 2, это вполне естественно. Хоть он и медленнее, но все-таки он значительно более быстрый, чем обычная память. Не все приложения выигрывают от увеличения объема или скорости кэш-памяти. Это сильно зависит от природы приложения.
Если большой объем встроенного кэша - это хорошо, тогда что же удерживало Intel и AMD от этой стратегии ранее? Простым ответом является высокая себестоимость такого решения. Резервирование пространства для кэша очень дорого. Стандартный 3.2GHz Northwood содержит 55 миллионов транзисторов. Добавляя 2048 КБ кэша L3, Intel идет на увеличение количества транзисторов до 167 миллионов. Простой математический расчет покажет нам, что EE - один из самых дорогих процессоров.
Сайт AnandTech провел сравнительное тестирование двух систем, каждая из которых содержала два процессора - Intel Xeon 3,6 ГГц в одном случае и AMD Opteron 250 (2,4 ГГц) - в другом. Тестирование проводилось для приложений ColdFusion MX 6.1, PHP 4.3.9, и Microsoft .NET 1.1. Конфигурации выглядели следующим образом:
Dual Opteron 250;
2 ГБ DDR PC3200 (Kingston KRX3200AK2);
Системная плата Tyan K8W;
Dual Xeon 3.6 ГГц;
Материнская плата Intel SE7520AF2;
ОС Windows 2003 Server Web Edition (32 бит);
1 жесткий IDE 40 ГБ 7200 rpm, кэш 8 МБ
На приложениях ColdFusion и PHP, не оптимизированных под ту или иную архитектуру, чуть быстрее (2,5-3%) оказались Opteron"ы, зато тест с.NET продемонстрировал последовательную приверженность Microsoft платформе Intel, что позволило паре Xeon"ов вырваться вперед на 8%. Вывод вполне очевиден: используя ПО Microsoft для веб-приложений, есть смысл выбрать процессоры Intel, в других случаях несколько лучшим выбором будет AMD.
Частота промахов при обращении к кэш-памяти может быть значительно снижена за счет увеличения емкости кэша. Но большая кэш-память требует больше энергии, генерирует больше тепла и увеличивает число бракованных микросхем при производстве.
Один из способов обойти эти трудности -- передача логики управления кэш-памятью от аппаратного обеспечения к программному.
«Компилятор потенциально в состоянии анализировать поведение программы и генерировать команды по переносу данных между уровнями памяти», -- отметил Шен.
Управляемая программным образом кэш-память сейчас существует лишь в исследовательских лабораториях. Возможные трудности связаны с тем, что придется переписывать компиляторы и перекомпилировать унаследованный код для всех процессоров нового поколения.
На многих сайтах компьютерной тематики обязательно найдутся ссылки на программы, которые обещают в один клик улучшить работу нашего компьютера и превратить старенький медленный компьютер в скоростной «космолет». о том, что подобные «однокликовые» оптимизаторы как минимум бесполезны, и что к вопросу оптимизации необходимо подходить совершенно иначе — более продуманно и уж никак не с инструментом вида «в один клик». Также встречаются и оптимизаторы оперативной памяти, которые в линейке бесполезных утилит стоят особо высоко, потому что они не только не приносят никакой пользы, но и снижают скорость работы вашего компьютера. И сейчас я объясню почему.
Популярность оптимизаторов памяти основывается на нашем убеждении, что малый объем свободной памяти — это очень плохо. Хотя на самом деле никакой трагедии в этом нет, потому что это хорошо! Это может показаться странным, но это так.
Действительно, свободной памяти всегда мало… Однако понятия немного изменились за последние пять-семь лет. Теперь свободная память большого объема означает не большую эффективность работы системы, а наоборот меньшую. Дело в том, что современные операционные системы оставляют свободным лишь тот объем памяти, который может экстренно потребоваться какому-то вновь стартовавшему приложению или работающей программе в процессе ее деятельности. Всю остальную зарезервированную память система расходует на запущенные программы и службы.
Кэш — это данные, которые использовались системой или программами, и которые были зарезервированы в оперативной памяти на тот случай, если они еще понадобятся. Данные резервируются именно в памяти потому, что скорость чтения из оперативной памяти в разы выше, чем скорость чтения с жесткого диска. В случае необходимости система снова использует эти данные и без задержек выведет результат пользователю на экране. Если бы эти данные каждый раз резервировались на жестком диске, то скорость их загрузки была бы значительно ниже, что сильно бы замедляло скорость работы системы в целом и создавало повышенную нагрузку на жестких диск.
В качестве аналогии можно привести пример с кэшем браузера, который хранится на жестком диске компьютера (графика, стили, скрипты, флэш-анимация и прочее). Загружать все эти данные из интернета для каждой отделной страницы было бы слишком расточительно и занимало бы слишком много времени. Потому все современные браузеры резервируют эти «тяжелые» данные на жестком диске и подгружают только основной контент, что в разы ускоряет отображение страниц для пользователя. Подобный принцип используется и при работе системного кэша, который хранится в оперативной памяти для быстрого доступа к данным.
Поэтому стоит менять свои взгляды на память: в новых операционных системах понятие «свободная память» есть синоним бездарно пропадающих без дела ресурсов. Это всего лишь резерв, чтобы система могла выдать его очередному приложению на некоторое время, пока освобождается занятая память. Windows сама освободит нужный приложению объем оперативной памяти от данных кэша или перебросит данные редко используемых программ в файл подкачки.
Заметьте, делает все это операционная система самостоятельно, без помощи каких-либо оптимизаторов. Тогда зачем нужны такие «очистители памяти» и «бустеры»?
Основных принципов их работы всего два:
Ответ банален — просто не мешайте работать Windows и следуйте простым советам.
Все сторонние «оптимизаторы» и «бустеры» памяти как минимум бесполезны, а как максимум замедлят работу системы, показав кратковременное освобождение небольшого количества оперативной памяти.
Самыми сильными качествами оперативной памяти являются ее высокие скорости чтения и записи информации. К сожалению, это достигается только за счет физических свойств и незначительности размеров модулей памяти.
Тем не менее, если вы будете «правильно» записывать данные в память и удалять оттуда ненужную информацию, ничто не сможет помешать вам насладиться высокими скоростями работы оперативной памяти:
Если ваш компьютер, несмотря на все усилия по оптимизации, продолжает оставаться медлительным, вы можете предпринять еще кое-что, чтобы повысить производительность системы. Для этого вам потребуется заменить уже установленные модули памяти или добавить к ним новые. Хотя для этого и придется разобрать корпус вашего компьютера, но мы поможем вам подробной инструкцией и фотографиями.
С помощью Starwind RAMDisk вы можете бесплатно настроить под Windows один или несколько RAM-дисков. Единственное ограничение: размеры каждого такого RAM-диска не могут превышать 1 Гбайт.
Windows должна думать, что в случае с RAM-диском речь идет как бы о жестком диске. Этого программное обеспечение добивается с помощью нового драйвера.
Windows может работать даже с несколькими RAM-дисками. Утилита представит вам обзор всех имеющихся в системе RAM-дисков.
Для добавления и настройки нового RAM-диска кликните на пункт «Add Device».
Сразу же вам на помощь приходит «ассистент», который поможет пройти самые важные шаги.
В случае со свободно распространяемой версией программы размеры RAM-диска не могут превышать 1 Гбайт. Тем не менее, в большинстве случаев этого должно быть достаточно. Для разных действий вы можете использовать разные RAM-диски. Важно: обязательно поставьте галочку перед «Automount this Device», чтобы при каждой перезагрузке системы RAM-диск появлялся в «Проводнике» автоматически.
