Две методики измерения латентности памяти на платформе Intel Pentium 4 при помощи тестового пакета RightMark Memory Analyzer — как выбрать пригодную? Крайняя «официальная» методика, изложенная в статье « Тема измерения латентности оперативной памяти на платформах с процессорами семейства Intel Pentium 4 затрагивалась нами не один раз. Ничего необычного в этом нет — неувязка имеет место быть, объективно измерить латентность памяти с этими процессорами очень проблемно ввиду значимых ухищрений, реализованных производителем, в особенности в крайних ядрах процессоров Prescott/Nocona с целью сокрытия данной для нас самой «латентности» — т.
е. задержек при доступе к оперативной памяти. Под этими ухищрениями мы сначала имеем в виду метод аппаратной предвыборки (Hardware Prefetch) данных из памяти как такой (детали реализации которого неопознаны), также его самую важную изюминка — предвыборку сходу 2-ух строк кэша из памяти в L2-кэш процессора. », насчитывает приблизительно полгода и удачно применялась нами в протяжении всего сих пор. Ничего не мешает ей существовать и далее — в качестве одной из вероятных методик оценки латентности оперативной памяти в настоящих критериях. Потому изложим основную сущность данной методики. Итак, основная трудность измерения латентности памяти на рассматриваемой платформе обоснована 2-мя отмеченными выше обстоятельствами: наличием у процессора механизма Hardware Prefetch и предвыборкой сходу 2-ух примыкающих 64-байтных строк из памяти в кэш процессора. Довольно верно и прогнозируемо картина смотрится только при вполне случайном обходе, таковым образом, более корректные значения латентности следовало бы ждать конкретно в данном случае, если б не очередное «но». На сей раз — достаточно малый размер буфера трансляции виртуальных адресов памяти в физические адреса (D-TLB). Дело в том, что истинно случайный обход памяти исчерпывает его чрезвычайно быстро. Ведь загрузка страничек памяти в данном случае также на сто процентов случайна, таковым образом, D-TLB может отлично «кэшировать» количество страничек, не превышающее его свой размер. Получаем всего 128 (размер буфера) x 4 (размер странички) = 512 КБ памяти. А в тесте употребляется сравнимо большой 16-МБ блок... Несложно посчитать, что процент промахов D-TLB в данном случае будет составлять (16384 — 512) / 16384 = 96.88%, что обходится данному семейству процессоров очень и очень «недешево». Заметим, что данное ограничение не относится к линейным режимам обхода, где замещение записей в D-TLB идет поочередно и плавненько. Отсутствует оно и при псевдослучайном обходе — с той целью он и разрабатывался. В этом способе загрузка страничек из памяти идет прямо и поочередно, а обход частей странички вполне случаен. Приведенный выше набросок объясняет сущность трудности. На нем представлена зависимость латентности чтения 2-ух 32-битных частей из оперативной памяти от расстояния меж этими элементами (в б). Конкретно таковой тест употребляется программным пакетом RMMA в качестве внутреннего способа определения действенной длины строчки L2-кэша, которая в нашем случае составляет 128 б. Предвыборка 2-ух 64-байтных строк видна во всех вариантах — величины латентности прямого и обратного линейного, псевдослучайного и случайного обхода только некординально растут при превышении расстояния меж элементами в 64 б. Предстоящее возрастание латентностей — от 128 б и выше — протекает совсем неочевидным образом. И тут виновато другое событие (1-ое по списку): наличие метода аппаратной предвыборки. Беря во внимание изложенную выше теоретическую базу, в нашей первой «официальной» методике было решено употреблять последующие характеристики для теста латентности оперативной памяти. Заглавие пресета: Minimal RAM Latency, 16MB Block, L2 Cache Line Кривые псевдослучайного и случайного обхода сохраняются на практически неизменном уровне, т.е. эффективность метода Hardware Prefetch не меняется при увеличении разгрузки Bus Interface Unit (BIU) процессора. В отличие от кривых прямого и обратного линейного обхода памяти, где разгрузка шины очевидно наращивает эффективность Hardware Prefetch. На основании анализа этих данных в свое время был изготовлен вывод о том, что измерение латентности памяти данным образом (используя данные псевдослучайного обхода) можно считать полностью адекватным. Размер блока: 16 МБ Размер шага: действенная длина строчки L2-кэша Режим обхода: псевдослучайный Внедрение данного режима дозволяет получить приблизительно последующий итог. Итак, как бы все отлично — что все-таки еще можно придумать, чтоб одурачить очень хитрецкий метод предвыборки, и что ». Одурачить метод Hardware Prefetch, пожалуй, уже никак нельзя, но можно ведь... для чего ? Начнем с вопросца « совершенно отключить аппаратную предвыборку! Таковая возможность заложена во всех процессорах Pentium 4 и Xeon, но надлежащие опции в BIOS доступны, обычно, лишь для крайних. С них-то все и началось, мы решили провести маленькое исследование — влияют ли они на результаты тестов, и ежели да, то как — оказалось, что чрезвычайно даже влияют! В связи с чем, в новейшей версии RMMA 3.45 было решено добавить их в виде отдельной закладки (в ближайшее время мы чрезвычайно любим «играть» со специфичными опциями процессоров Pentium 4). Ах так смотрится эта закладка. Сходу отметим: данные опции рассчитаны только для тестовых целей, о чем говорится в самой програмке. Для обычного режима работы процессора а именно, и всей системы в целом трогать их не рекомендуется. Опишем кратко каждую из их. Adjacent Cache Line Prefetch (Enabled/Disabled) — включение/выключение режима предвыборки смежной строчки. В случае Disabled осуществляется предвыборка лишь одной (содержащей запрашиваемые данные) 64-байтной строчки 128-байтного сектора, в случае Enabled — обе строчки вне зависимости от наличия/отсутствия нужных данных. Hardware Prefetch Queue (Enabled/Disabled) — включение/выключение очереди аппаратного префетчера, проще говоря — механизма аппаратной предвыборки данных из памяти. L1 Data Cache Context Mode (Adaptive/Shared) — изменение режима работы L1-кэша данных процессора. Эта настройка фактически на результаты теста латентности памяти влиять не обязана, тем более, она очевидно относится к тому, с чем имеет дело тестовый пакет RMMA. Данная настройка доступна лишь для процессоров с технологией Hyper-Threading и задает метод использования L1-кэша данных процессора логическими процессорами. В случае Shared L1-кэш представляется логическим процессором в полном объеме, но содержит данные, принадлежащие обоим процессорам. В режиме Adaptive каждый логический процессор получает свою часть L1-кэша, содержащую данные лишь этого логического процессора, размер которой варьируется при необходимости. Заметим, что опции используются только к данному системному процессору, номер которого задается выбором Итак, отметим основное: отныне у нас есть метод CPU Index . В случае «настоящих» многопроцессорных систем (SMP) рекомендуется использовать однообразные опции для всех физических процессоров. Для систем с технологией Hyper-Threading, напротив, довольно поменять опции 1-го из логических процессоров (хоть какого), составляющих физический процессор. отключить обе индивидуальности механизма аппаратной предвыборки данных: как сам метод, так и предвыборку смежной строчки (которая, заметим, может осуществляться независимо от использования Hardware Prefetch). Последовательность действий для измерения латентности памяти вторым способом будет смотреться последующим образом. Platform Info -> Tweaks , выставив 1. Отключить аппаратную предвыборку в Hardware Prefetch Queue в положение Disabled . 2. Выбрать тест Minimal RAM Latency, 16MB Block, L2 Cache Line Microarchitecture -> D-Cache Arrival , пресет , либо выставить последующие опции вручную: Размер блока: 16 МБ Размер шага: действенная длина строчки L2-кэша Режим обхода: псевдослучайный 3. Включить аппаратную предвыборку в Hardware Prefetch Queue в положение Enabled . Platform Info -> Tweaks , выставив Что ж, самое время проверить опции в действии — для начала, запускаем тест Microarchitecture -> D-Cache Arrival , пресет Результатом является «практически безупречная» картина для варианта предвыборки смежной строчки (его-то, напомним, мы L2 D-Cache Line Size Determination . не отключили — для наших целей это не требуется). Смотрим дальше: тест Microarchitecture -> D-Cache Latency , пресет . Minimal RAM Latency, 16MB Block, L2 Cache Line Итог очень увлекательный. Кривая случайного обхода осталась практически без конфигураций — как высококачественных, так и количественных. Следовательно, в случае истинно случайного доступа к памяти Hardware Prefetch вправду фактически не работает, даже ежели он включен. Но... как быть с псевдослучайным обходом? Отменно соответственная кривая смотрится так же, как и ранее, но количественно... «поднялась» приблизительно на 30 нс ввысь! Вывод? Hardware Prefetch, когда он включен, работает с некой эффективностью и при псевдослучайном обходе! По-видимому, имеет место предвыборка на уровне целых страничек памяти. Избежать которую можно лишь 2-мя методами: или употреблять истинно случайный обход (но тут вспоминаем накладываемые ограничения размера D-TLB), или отключить предвыборку вообщем. Другое дело, а есть ли в этом необходимость? включая многофункциональные блоки процессора, ответственные за обмен данными с оперативной памятью. Вот мы и подходим к другому данному выше вопросцу — « для чего ». Какие результаты следует считать наиболее «правильными» — с аппаратной предвыборкой, либо без такой? Другими словами, необходимо ли отключать Hardware Prefetch на время измерения? Ответ на этот вопросец будет максимально прост: все зависит от того, что мы желаем измерить. Ежели нам требуется оценить настоящие задержки при чтении процессором данных из памяти в одной из моделируемых тестом ситуаций — прямого, обратного, случайного либо псевдослучайного обхода блока памяти (1-ые две из которых соответствуют кодированию видео либо какой-нибудь иной потоковой обработке данных, а две крайних — к примеру, поиску в базе данных) — то следует тормознуть на первом варианте. Конкретно этот вариант будет отражать реальность, т.е. обычный режим работы процессора: Hardware Prefetch включен, а считывание данных из памяти осуществляется по 128-байтным секторам, составляющим две строчки кэша процессора. Резюмируя, 1-ый способ дозволяет нам оценить настоящую латентность подсистемы памяти в целом, т.е. Ежели же нам требуется оценить некоторую характеристику, поближе подобающую настоящим задержкам при доступе к массиву ячеек памяти, нам больше подойдет 2-ая методика. Ибо она обхватывает наиболее неширокую часть подсистемы памяти — конкретно носитель (микросхемы модулей), также чипсет, таковым образом, она дозволяет оценить задержки при доступе в память безотносительно способностей процессорного интерфейса, осуществляющего обмен с памятью (BIU). В конце концов, можно употреблять комбинированную методику, сочетающую оба способа: измерение латентности псевдослучайного доступа к 16-МБ блоку со 128-байтовым шагом поначалу с Hardware Prefetch, потом без него. И применять приобретенный интервал значений в качестве оценки вероятных настоящих задержек при доступе к подсистеме памяти в разных ситуациях.
е. задержек при доступе к оперативной памяти. Под этими ухищрениями мы сначала имеем в виду метод аппаратной предвыборки (Hardware Prefetch) данных из памяти как такой (детали реализации которого неопознаны), также его самую важную изюминка — предвыборку сходу 2-ух строк кэша из памяти в L2-кэш процессора. », насчитывает приблизительно полгода и удачно применялась нами в протяжении всего сих пор. Ничего не мешает ей существовать и далее — в качестве одной из вероятных методик оценки латентности оперативной памяти в настоящих критериях. Потому изложим основную сущность данной методики. Итак, основная трудность измерения латентности памяти на рассматриваемой платформе обоснована 2-мя отмеченными выше обстоятельствами: наличием у процессора механизма Hardware Prefetch и предвыборкой сходу 2-ух примыкающих 64-байтных строк из памяти в кэш процессора. Довольно верно и прогнозируемо картина смотрится только при вполне случайном обходе, таковым образом, более корректные значения латентности следовало бы ждать конкретно в данном случае, если б не очередное «но». На сей раз — достаточно малый размер буфера трансляции виртуальных адресов памяти в физические адреса (D-TLB). Дело в том, что истинно случайный обход памяти исчерпывает его чрезвычайно быстро. Ведь загрузка страничек памяти в данном случае также на сто процентов случайна, таковым образом, D-TLB может отлично «кэшировать» количество страничек, не превышающее его свой размер. Получаем всего 128 (размер буфера) x 4 (размер странички) = 512 КБ памяти. А в тесте употребляется сравнимо большой 16-МБ блок... Несложно посчитать, что процент промахов D-TLB в данном случае будет составлять (16384 — 512) / 16384 = 96.88%, что обходится данному семейству процессоров очень и очень «недешево». Заметим, что данное ограничение не относится к линейным режимам обхода, где замещение записей в D-TLB идет поочередно и плавненько. Отсутствует оно и при псевдослучайном обходе — с той целью он и разрабатывался. В этом способе загрузка страничек из памяти идет прямо и поочередно, а обход частей странички вполне случаен. Приведенный выше набросок объясняет сущность трудности. На нем представлена зависимость латентности чтения 2-ух 32-битных частей из оперативной памяти от расстояния меж этими элементами (в б). Конкретно таковой тест употребляется программным пакетом RMMA в качестве внутреннего способа определения действенной длины строчки L2-кэша, которая в нашем случае составляет 128 б. Предвыборка 2-ух 64-байтных строк видна во всех вариантах — величины латентности прямого и обратного линейного, псевдослучайного и случайного обхода только некординально растут при превышении расстояния меж элементами в 64 б. Предстоящее возрастание латентностей — от 128 б и выше — протекает совсем неочевидным образом. И тут виновато другое событие (1-ое по списку): наличие метода аппаратной предвыборки. Беря во внимание изложенную выше теоретическую базу, в нашей первой «официальной» методике было решено употреблять последующие характеристики для теста латентности оперативной памяти. Заглавие пресета: Minimal RAM Latency, 16MB Block, L2 Cache Line Кривые псевдослучайного и случайного обхода сохраняются на практически неизменном уровне, т.е. эффективность метода Hardware Prefetch не меняется при увеличении разгрузки Bus Interface Unit (BIU) процессора. В отличие от кривых прямого и обратного линейного обхода памяти, где разгрузка шины очевидно наращивает эффективность Hardware Prefetch. На основании анализа этих данных в свое время был изготовлен вывод о том, что измерение латентности памяти данным образом (используя данные псевдослучайного обхода) можно считать полностью адекватным. Размер блока: 16 МБ Размер шага: действенная длина строчки L2-кэша Режим обхода: псевдослучайный Внедрение данного режима дозволяет получить приблизительно последующий итог. Итак, как бы все отлично — что все-таки еще можно придумать, чтоб одурачить очень хитрецкий метод предвыборки, и что ». Одурачить метод Hardware Prefetch, пожалуй, уже никак нельзя, но можно ведь... для чего ? Начнем с вопросца « совершенно отключить аппаратную предвыборку! Таковая возможность заложена во всех процессорах Pentium 4 и Xeon, но надлежащие опции в BIOS доступны, обычно, лишь для крайних. С них-то все и началось, мы решили провести маленькое исследование — влияют ли они на результаты тестов, и ежели да, то как — оказалось, что чрезвычайно даже влияют! В связи с чем, в новейшей версии RMMA 3.45 было решено добавить их в виде отдельной закладки (в ближайшее время мы чрезвычайно любим «играть» со специфичными опциями процессоров Pentium 4). Ах так смотрится эта закладка. Сходу отметим: данные опции рассчитаны только для тестовых целей, о чем говорится в самой програмке. Для обычного режима работы процессора а именно, и всей системы в целом трогать их не рекомендуется. Опишем кратко каждую из их. Adjacent Cache Line Prefetch (Enabled/Disabled) — включение/выключение режима предвыборки смежной строчки. В случае Disabled осуществляется предвыборка лишь одной (содержащей запрашиваемые данные) 64-байтной строчки 128-байтного сектора, в случае Enabled — обе строчки вне зависимости от наличия/отсутствия нужных данных. Hardware Prefetch Queue (Enabled/Disabled) — включение/выключение очереди аппаратного префетчера, проще говоря — механизма аппаратной предвыборки данных из памяти. L1 Data Cache Context Mode (Adaptive/Shared) — изменение режима работы L1-кэша данных процессора. Эта настройка фактически на результаты теста латентности памяти влиять не обязана, тем более, она очевидно относится к тому, с чем имеет дело тестовый пакет RMMA. Данная настройка доступна лишь для процессоров с технологией Hyper-Threading и задает метод использования L1-кэша данных процессора логическими процессорами. В случае Shared L1-кэш представляется логическим процессором в полном объеме, но содержит данные, принадлежащие обоим процессорам. В режиме Adaptive каждый логический процессор получает свою часть L1-кэша, содержащую данные лишь этого логического процессора, размер которой варьируется при необходимости. Заметим, что опции используются только к данному системному процессору, номер которого задается выбором Итак, отметим основное: отныне у нас есть метод CPU Index . В случае «настоящих» многопроцессорных систем (SMP) рекомендуется использовать однообразные опции для всех физических процессоров. Для систем с технологией Hyper-Threading, напротив, довольно поменять опции 1-го из логических процессоров (хоть какого), составляющих физический процессор. отключить обе индивидуальности механизма аппаратной предвыборки данных: как сам метод, так и предвыборку смежной строчки (которая, заметим, может осуществляться независимо от использования Hardware Prefetch). Последовательность действий для измерения латентности памяти вторым способом будет смотреться последующим образом. Platform Info -> Tweaks , выставив 1. Отключить аппаратную предвыборку в Hardware Prefetch Queue в положение Disabled . 2. Выбрать тест Minimal RAM Latency, 16MB Block, L2 Cache Line Microarchitecture -> D-Cache Arrival , пресет , либо выставить последующие опции вручную: Размер блока: 16 МБ Размер шага: действенная длина строчки L2-кэша Режим обхода: псевдослучайный 3. Включить аппаратную предвыборку в Hardware Prefetch Queue в положение Enabled . Platform Info -> Tweaks , выставив Что ж, самое время проверить опции в действии — для начала, запускаем тест Microarchitecture -> D-Cache Arrival , пресет Результатом является «практически безупречная» картина для варианта предвыборки смежной строчки (его-то, напомним, мы L2 D-Cache Line Size Determination . не отключили — для наших целей это не требуется). Смотрим дальше: тест Microarchitecture -> D-Cache Latency , пресет . Minimal RAM Latency, 16MB Block, L2 Cache Line Итог очень увлекательный. Кривая случайного обхода осталась практически без конфигураций — как высококачественных, так и количественных. Следовательно, в случае истинно случайного доступа к памяти Hardware Prefetch вправду фактически не работает, даже ежели он включен. Но... как быть с псевдослучайным обходом? Отменно соответственная кривая смотрится так же, как и ранее, но количественно... «поднялась» приблизительно на 30 нс ввысь! Вывод? Hardware Prefetch, когда он включен, работает с некой эффективностью и при псевдослучайном обходе! По-видимому, имеет место предвыборка на уровне целых страничек памяти. Избежать которую можно лишь 2-мя методами: или употреблять истинно случайный обход (но тут вспоминаем накладываемые ограничения размера D-TLB), или отключить предвыборку вообщем. Другое дело, а есть ли в этом необходимость? включая многофункциональные блоки процессора, ответственные за обмен данными с оперативной памятью. Вот мы и подходим к другому данному выше вопросцу — « для чего ». Какие результаты следует считать наиболее «правильными» — с аппаратной предвыборкой, либо без такой? Другими словами, необходимо ли отключать Hardware Prefetch на время измерения? Ответ на этот вопросец будет максимально прост: все зависит от того, что мы желаем измерить. Ежели нам требуется оценить настоящие задержки при чтении процессором данных из памяти в одной из моделируемых тестом ситуаций — прямого, обратного, случайного либо псевдослучайного обхода блока памяти (1-ые две из которых соответствуют кодированию видео либо какой-нибудь иной потоковой обработке данных, а две крайних — к примеру, поиску в базе данных) — то следует тормознуть на первом варианте. Конкретно этот вариант будет отражать реальность, т.е. обычный режим работы процессора: Hardware Prefetch включен, а считывание данных из памяти осуществляется по 128-байтным секторам, составляющим две строчки кэша процессора. Резюмируя, 1-ый способ дозволяет нам оценить настоящую латентность подсистемы памяти в целом, т.е. Ежели же нам требуется оценить некоторую характеристику, поближе подобающую настоящим задержкам при доступе к массиву ячеек памяти, нам больше подойдет 2-ая методика. Ибо она обхватывает наиболее неширокую часть подсистемы памяти — конкретно носитель (микросхемы модулей), также чипсет, таковым образом, она дозволяет оценить задержки при доступе в память безотносительно способностей процессорного интерфейса, осуществляющего обмен с памятью (BIU). В конце концов, можно употреблять комбинированную методику, сочетающую оба способа: измерение латентности псевдослучайного доступа к 16-МБ блоку со 128-байтовым шагом поначалу с Hardware Prefetch, потом без него. И применять приобретенный интервал значений в качестве оценки вероятных настоящих задержек при доступе к подсистеме памяти в разных ситуациях.