Как оптимизировать свой процессор: изменить и включить L2 и L3 своих кэшей процессора. Делиться не всегда полезно: оптимизируем работу с кэш-памятью

Увеличение производительности кэш-памяти

Формула для среднего времени доступа к памяти в системах с кэш-памятью выглядит следующим образом:

Среднее время доступа = Время обращения при попадании + Доля промахов 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. Благо, материалов на эту тему предостаточно как в Web, так и на страницах компьютерных изданий. Но стоит ли вот так сразу набрасываться на систему и всегда ли можно получить положительный результат? Дабы сберечь нервные клетки, а в некоторых случаях и деньги рядовых пользователей ПК, я предлагаю разобраться в некоторых вопросах работы Windows более подробно. Итак, начнём.

Никогда, ни при каких обстоятельствах не производите изменений в реестре и системных файлах Windows, не имея резервной копии последних. Существует множество способов резервирования системы как стандартными средствами Windows, так и при помощи специальных программ. Этот вопрос неоднократно освещался на страницах компьютерной прессы и я надеюсь, что у каждого читателя уже имеется необходимый опыт в области резервирования реестра. А тем, кто пожелает создать свою программку backup, не изучая языки программирования, предлагаю прочитать статью, где подробно описано создание командных файлов для резервирования и восстановления системы. Будем считать, что резервная копия у Вас уже имеется, и мы можем продолжить наши исследования.

Оптимизация кэша жёсткого диска.

По мнению многих специалистов в области ОС Windows, размер кэша должен быть фиксированным и полностью зависит от объема оперативной памяти, установленной на компьютере. Мол, Windows не умеет работать с кэшем и тратит на это слишком много оперативки. Предлагаются даже стандартные схемы для определения размера кэша, исходя из размера памяти. Всё это прописывают в разделе файла system.ini в виде MinFileCache = размер в кб и MaxFileCache = размер в кб. Такой подход действительно позволит сэкономить некоторый объем памяти, но может привести к общему замедлению работы системы, особенно на домашних компьютерах, где в течение дня могут выполняться десятки самых разных программ, как мультимедийных, так и офисных и каждая из них требует разного размера кэша и оперативной памяти. Вряд ли Вам доставит удовольствие редактировать system.ini и перезагружать компьютер перед каждым запуском новой программы.

Универсальный же размер дискового кэша, на мой взгляд, возможность чисто теоритическая, так как в одних случаях всё равно будет наблюдаться избыток кэша и недостаток оперативки, в других — наоборот. А завтра сынишка притащит какую-нибудь игру с нестандартным использованием ресурсов памяти и system.ini снова придется редактировать? Современные версии Windows способны выполнять код программы прямо из кэша, т.е. кэш перестал быть промежуточным звеном между винчестером и памятью, а является ни чем иным, как частью оперативной памяти. Так что же мы, в таком случае, пытаемся ограничить? Вывод: Ограничение размера кэша жёсткого диска в большинстве случаев приводит к понижению производительности системы. Исключение составляют разве что компьютеры, выполняющие сходные задачи, в основном связанные с передачей больших объемов данных. Здесь оптимизация размера кэша действительно поможет добиться максимальной производительности системы.

Виртуальная память.

Большинство советов по этому поводу появилось на свет во времена победного шествия Windows 95, когда новый графический интерфейс потребовал дополнительной и достаточно дорогой оперативной памяти. Почему же эти древние советы перетаскиваются за седую бороду на новые платформы? Ведь современные версии Windows работают с виртуальной памятью абсолютно иначе. Итак, что же нам предлагают сотворить с файлом подкачки? Да всё то же, что и для древних окон, а именно: сделать его размер фиксированным и равным 3–4 размерам оперативной памяти. Необходимость этих действий объясняется обычно тем, что OS затрачивает чуть ли не целую вечность на изменение размера файла подкачки, данные излишне фрагментируются и тем самым тормозится работа системы.

Предвижу всеобщее негодование, но всё же берусь утверждать, что подобные объяснения если не полная чепуха, то, по крайней мере, давно потеряли свою актуальность. Лишив Windows возможности самостоятельно определять необходимый размер файла подкачки, Вы рискуете получить сообщение о невозможности запуска определённых программ. Риск увеличивается, если используется многозадачность Windows. К примеру, запросто может возникнуть ситуация, когда Вам будет необходима одновременная работа с Photoshop, текстовым процессором, HTML редактором и ещё каким-нибудь аниматором. Где гарантия, что в это время Вам не понадобится открыть графический файл размером в несколько десятков Мб для последующего редактирования? Представьте себе, что в этот момент произойдёт сбой системы из за того, что Windows не сможет увеличить размер виртуальной памяти, а результаты своих трудов Вы по какой-то причине не сохранили?! Это уже не смешно. Хочу обратить внимание уважаемых читателей на следующий факт. Windows изменяет размер файла подкачки динамически и в основном тогда, когда ресурсы системы относительно свободны и обращение к диску не вызывает никаких неудобств.

После завершения текущей задачи, размер файла подкачки остаётся неизменным в течение некоторого периода времени. Если в это время Вы пойдёте приготовить себе очередную чашечку кофе, то даже не заметите никаких действий со стороны OS, ну а если предпочтёте продолжить работу, то вряд ли будете сидеть сложа руки эти 2,5 минуты, а запустите очередную программу. Кроме того, потребность в виртуальной памяти для современных программ уменьшена в несколько раз благодаря использованию так называемого принципа прямого считывания (Linear Executable). Такие программы не загружаются в память полностью, а сопоставляют свой код страницам памяти и производят загрузку необходимых библиотек по мере необходимости. Таким образом обеспечивается наиболее полное и оптимальное использование как оперативной, так и виртуальной памяти. Сомнительными являются и предположения, что фиксация размера файла подкачки позволит избежать излишней фрагментации данных. Ведь внутри самого файла данные всё равно будут фрагментированы, возможно, даже в большей степени, чем при обычном использовании. Что касается переноса файла подкачки в начало диска или на отдельный физический диск, то такие методы действительно имеют право на жизнь. Но эффект от этого Вы едва ли сможете заметить.

Для осуществления подобных мероприятий понадобятся специальные дорогостоящие утилиты вроде знаменитого пакета господина Нортона, которые неизбежно пропишут в автозагрузку свои программы, тем самым компенсируя улучшенную виртуальную память уменьшением физической. Чтобы избежать этого, придётся оптимизировать уже сами утилиты. Кроме этого, работа с утилитами требует хотя бы элементарного понимания того, что происходит при их использовании. Особенно опасны автоматизированные функции. Мне не раз приходилось восстанавливать системы после использования Norton Utilities. Причина до смешного проста - неправильные региональные настройки. Дело в том, что программа Norton Disk Doctor, входящая в состав утилит считывает код страны. И если на Вашей машине установлена русская версия Windows, а региональные настройки, скажем, США, то программа посчитает все русскоязычные имена файлов и папок за ошибку. Результат, я думаю, понятен. И это всего лишь незначительная часть возможных проблем. Вывод: Современные версии Windows не нуждаются в оптимизации виртуальной памяти. А если Вы всё же решите переместить своп файл в начало диска или на отдельный диск, то не забудьте изучить цены на лицензионные утилиты + дополнительный жёсткий диск. На мой взгляд, линейка памяти обойдётся значительно дешевле.

Интернет и модем.

Продвинутые пользователи Windows советуют добавить в раздел реестра HKEY_LOCAL_MACHINE\ System\ CurrentControlSet\ Services\ Class\ NetTrans\ 0000 (может быть 0001 и т.д.) некоторые параметры, оказывающие прямое влияние на быстродействие модема. Главным параметром является MaxMTU. Напомню, что MTU (Maximum Transmition Unit) - это максимальный размер пакета данных, который может быть передан по сети за один физический фрейм. Наиболее оптимальным считается значение MaxMTU=576. Но простите, оптимальным - то для чего? Чтобы ответить на этот вопрос, я предлагаю провести маленький эксперимент. Давайте воспользуемся гостевым подключением к сети Интернет, предоставляемым одним из самых популярных столичных провайдеров — Svit Online. Для подключения к удалённому компьютеру будем использовать порядком подзабытую программу Hyper Terminal, номер дозвона 490-0-490, логин- svit, пароль - online. И что же мы увидим после ввода пароля?

Удалённый компьютер сообщает нам присвоенный IP адрес и… MTU=1500! Теперь Вам ясно, для чего значение MaxMTU=576 является оптимальным? Не иначе, как для замедления передачи данных. Для оптимальной передачи, оказывается, нужно исходить из значения 1500. Я не буду подробно останавливаться на расчётах других параметров, таких, как MSS, TTL, так как считаю все эти мероприятия далеко не безобидными, учитывая стоимость услуг провайдеров и поминутную оплату городского телефона. Windows прекрасно справляется с задачей автоматического определения MTU сама, без нашего вмешательства. Лучше сосредоточить своё внимание на повышении качества линии связи, хотя бы в пределах собственной квартиры. Чаще причиной ухудшения связи являются разного рода скрутки, плохие контакты и множество параллельных телефонных аппаратов, а не железо и soft. Но это-тема для отдельного разговора.

Участь быть оптимизированной постигла и Windows Me. Чего тут только не предлагают: и удалить PC Health, и отключить System Restore, и избавиться от Media Player 7 с Movie Maker’ом, и заменить IE 5,5 более старой версией, и даже ввести реальный режим DOS. И всё это только для того, чтобы установить новую операционку на ПК с Pentium 133 МГц и 32 Мб ОЗУ. Но тогда что от неё останется? О какой платформе Windows Me идёт речь? Ведь даже если Вам удастся поместить двигатель от «Mersedes» в «Запорожец», он от этого «Mesredes’ом» не станет. В результате — дополнительные сбои, неудобство в работе, а чаще — format C:. Вот тут то пользователь и поверит рассказам о легендарной глючности Windows. Точнее, не поверит, а проверит на собственном горьком опыте.

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

Мы все «немного читали» об оптимизации работы с памятью, и у нас отложилось, что полезно, когда «кэш остается горячим», то есть данные, к которым часто обращаются потоки, должны быть компактными и находиться в ближайшем к процессорному ядру кэше. Все так, но когда дело доходит до того, чтобы делиться доступом, потоки становятся злейшими врагами [производительности], а кэш не просто горячий, он аж «горит адским огнем » – такая во круг него разворачивается борьба.

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

Рассмотрим случай, который хорошо описан в 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. Попробуйте мой примерчик, и расскажите, на сколько процентов увеличилось быстродействие теста на вашей платформе.

Теги: Добавить метки

Одним из немаловажных факторов повышающих производительность процессора, является наличие кэш-памяти, а точнее её объём, скорость доступа и распределение по уровням.

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

Что такое кэш-память и её структура

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

Кэш-память построена на триггерах, которые, в свою очередь, состоят из транзисторов. Группа транзисторов занимает гораздо больше места, нежели те же самые конденсаторы, из которых состоит оперативная память . Это тянет за собой множество трудностей в производстве, а также ограничения в объёмах. Именно поэтому кэш память является очень дорогой памятью, при этом обладая ничтожными объёмами. Но из такой структуры, вытекает главное преимущество такой памяти – скорость. Так как триггеры не нуждаются в регенерации, а время задержки вентиля, на которых они собраны, невелико, то время переключения триггера из одного состояния в другое происходит очень быстро. Это и позволяет кэш-памяти работать на таких же частотах, что и современные процессоры.

Также, немаловажным фактором является размещение кэш-памяти. Размещена она, на самом кристалле процессора, что значительно уменьшает время доступа к ней. Ранее, кэш память некоторых уровней, размещалась за пределами кристалла процессора, на специальной микросхеме SRAM где-то на просторах материнской платы. Сейчас же, практически у всех процессоров, кэш-память размещена на кристалле процессора.

Для чего нужна кэш-память процессора?

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

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

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

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

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

Уровни кэш-памяти процессора

Современные процессоры, оснащены кэшем, который состоит, зачастую из 2–ух или 3-ёх уровней. Конечно же, бывают и исключения, но зачастую это именно так.

В общем, могут быть такие уровни: L1 (первый уровень), L2 (второй уровень), L3 (третий уровень). Теперь немного подробнее по каждому из них:

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

Мы будем рассматривать объёмы на процессоре высокого уровня производительности Intel Core i7-3770K. Данный процессор оснащен 4х32 Кб кэш-памяти первого уровня 4 x 32 КБ = 128 Кб. (на каждое ядро по 32 КБ)

Кэш второго уровня (L2) – второй уровень более масштабный, нежели первый, но в результате, обладает меньшими «скоростными характеристиками». Соответственно, служит буфером между уровнем L1 и L3. Если обратиться снова к нашему примеру Core i7-3770 K, то здесь объём кэш-памяти L2 составляет 4х256 Кб = 1 Мб.

Кэш третьего уровня (L3) – третий уровень, опять же, более медленный, нежели два предыдущих. Но всё равно он гораздо быстрее, нежели оперативная память. Объём кэша L3 в i7-3770K составляет 8 Мбайт. Если два предыдущих уровня разделяются на каждое ядро, то данный уровень является общим для всего процессора. Показатель довольно солидный, но не заоблачный. Так как, к примеру, у процессоров Extreme-серии по типу i7-3960X, он равен 15Мб, а у некоторых новых процессоров Xeon, более 20.

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

Тем не менее, если вы будете «правильно» записывать данные в память и удалять оттуда ненужную информацию, ничто не сможет помешать вам насладиться высокими скоростями работы оперативной памяти:

С помощью утилиты Dataram RAMDisk вы можете использовать часть вашей оперативной памяти в качестве жесткого диска.
В нашей пошаговой инструкции ниже «Настраиваем бесплатный RAMDisk » мы показываем, как вы можете создать и настроить небольшого размера флеш-диск в оперативной памяти. О том, как вы можете использовать такой диск, например, для хранения кэша браузера Firefox, мы расскажем в нижеприведенной инструкции «Размещаем в RAM-диске кэш браузера ».
С помощью бесплатной программы CleanMEM вы можете автоматизированно или вручную удалять более ненужные данные из вашей оперативной памяти.

Увеличиваем размеры оперативной памяти

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

О том, как идентифицировать тип используемой на вашем компьютере оперативной памяти и узнать о количестве свободных слотов, мы рассказываем в . Так вы можете узнать, какую оперативную память и в каком количестве можно установить в вашем случае.
Инструкцию на тему того, как вы можете установить новую оперативную память, мы тоже вам даем в .
В случае с ноутбуками замена отдельных компонент может оказаться несколько более сложной. Однако, именно к жестким дискам и модулям памяти, как правило, вы можете получить доступ через специальные «сервисные крышки», открывающиеся без необходимости в полной разборке корпуса. В этой статье мы даем вам .
Обратите внимание на условия гарантии на ваш компьютер - не потеряется ли она при вскрытии корпуса. В том случае, если у вас есть сомнения, для установки компонент или их замены лучше будет привлечь специалиста.

Размещаем в RAM-диске кэш браузера:

Настраиваем бесплатный RAMDisk

1 Бесплатная утилита

С помощью Starwind RAMDisk вы можете бесплатно настроить под Windows один или несколько RAM-дисков. Единственное ограничение: размеры каждого такого RAM-диска не могут превышать 1 Гбайт.

2 Может понадобиться драйвер

Windows должна думать, что в случае с RAM-диском речь идет как бы о жестком диске. Этого программное обеспечение добивается с помощью нового драйвера.

3 Обзор RAM-дисков

Windows может работать даже с несколькими RAM-дисками. Утилита представит вам обзор всех имеющихся в системе RAM-дисков.

4 Добавляем RAM-диск

Для добавления и настройки нового RAM-диска кликните на пункт «Add Device».

5 При настройке поможет ассистент

Сразу же вам на помощь приходит «ассистент», который поможет пройти самые важные шаги.

6 Ограничение в 1 Гбайт

В случае со свободно распространяемой версией программы размеры RAM-диска не могут превышать 1 Гбайт. Тем не менее, в большинстве случаев этого должно быть достаточно. Для разных действий вы можете использовать разные RAM-диски. Важно: обязательно поставьте галочку перед «Automount this Device», чтобы при каждой перезагрузке системы RAM-диск появлялся в «Проводнике» автоматически.