К. Касперски - Техника оптимизации программ, Эффективное использование памяти (1127752), страница 48
Текст из файла (страница 48)
1 ( =О( с < ОхВООООООО; бог(п=б( и < а(с)( и+т)гпг ц[к+т)=с( Заметим, что инициализация памяти выделена в отдельную функцию. Вопервых, не плохо было бы проверить, чем закончилось выделение 1б Гбайт памяти. Во-вторых, на забивание массива нулями тратится почти половина времени работы алгоритма. Я предполагаю, что, используя прямой доступ к памяти (РМА), это время можно сократить. - конец письма Глава 2 Проблемы тестирования оперативной памяти Разгон памяти — это весьма радикальное средство увеличения производительности, но и чрезвычайно требовательное к качеству модулей памяти. Впрочем, некачественные модули могут сбоить даже в штатном режиме безо всякого разгона. Последствия таких ошибок весьма разнообразны: от аварийного завершения приложения до потери и/или искажения обрабатываемых данных.
Судя по всему, приобретение "битой" памяти — отнюдь не редкость и со сбоями памяти народ сталкивается достаточно регулярно. Забавно, но подавляющее большинство разработчиков программного обеспечения начисто игнорируют эту проблему, заявляя, что всякое приложение вправе требовать для своей работы исправного "железа". Теоретически оно, может быть, и так, но на практике факт исправности "железа" предстоит еше подтвердить.
Причем, популярные диагностические утилиты (такие, например, как Сйескй) для этой цели абсолютно не пригодны. За исключением совсем уж клинических случаев, тест проходит без малейших помарок, но стоит запустить тот же %ого или С?паке, как система мгновенно "виснет". Меняем модуль память — все работает на ура. Выходит, виновата все же память? Тогда почему это не обнаружил Сйескй?! Причина в том, что далеко не всякая неисправность чипа памяти приводит к его немедленному отказу.
Чаше всего дефект проявляется лишь при определенном стечении ряда обстоятельств. Тяжеловесное приложение, "гоняюшее" память "и в хвост, и в гриву", имеет все шансы за короткое время "подобрать" нужную комбинацию, провоцирующую сбой. Популярные диагностические программы, напротив, тестируют весьма ограниченный спектр режимов в весьма щадящих условиях. Соответственно, и вероятность обнаружить ошибку в последнем случае значительно ниже. Выход? — Разрабатывать собственную тестирующую программу.
Во-первых, необходимо учитывать, что вероятность сбоя тесно связана с температурой кристалла. Чем выше температура — тем вероятнее сбой. А температура в свою очередь зависит от интенсивности работы памяти. При линейном чтении ячеек микросхема памяти за счет пакетного режима успевает несколько приостыть, поддерживая внутри себя умеренную температуру.
Действительно, при запросе одной ячейки вся РВАМ-страница читается целиком, сохраняясь во внутренних буферах, и до тех пор, пока не будет запрошена следующая страница этого же банка, никаких обращений к ядру памяти не происходит! Поэтому, прежде чем приступать к реальному тестированию, память необходимо как следует прогреть, читая ее с шагом, равным длине ПКАМ-банка. Оперативная память 241 Это заставит ядро данного банка работать максимально интенсивно, на каждом шаге выполняя процедуру чтения и восстанавливающей записи данных.
Не стоит тестировать несколько банков одновременно. Во-первых, это несколько снизит температуру "накала" каждого из них, а, во-вторых, перепад температур внутри кристалла увеличивает вероятность обнаружения сбоя. (Вообще-то, микросхеме при этом приходится по-настоящему туго, но она обязана выдержать такой режим работы, в противном случае, ее место — на свалке). Ага, модуль памяти нагрелся так, что не удержишься рукой. Самое время приступать к настоящим тестам.
Заполняем РВАМ-страницу контрольной последовательностью чисел (далее по тексту — шаблоном), переключаем страницу, чтобы гарантированно обновить ячейки памяти (в противном случае микросхема может возвратить содержимое своих буферов, не обращаясь к матрице памяти). Вновь переключаем страницу назад и проверяем, что мы записали. Это может выглядеть приблизительно так, как показано в листинге 2.45. тос )а=с) а < СРЛН вава 51ВВ) а += сваи Рязв 5155) исссетешр1асе)а)) // записмваем шаблон х = )ОВЛН ВАВК 5155-а)/ // переключаем СВЛМ-страницу // проверяем, что мм записали сошрасетешр1асе(а)) Причем, к шаблону предъявляются весьма жесткие требования. Во-первых, он должен тестировать каждый бит ячейки, причем, на оба значения — единицу и ноль, поскольку "битые" ячейки матрицы могут давать либо "всегда ноль", либо "всегда единица".
Во-вторых, крайне желательно, чтобы во всем увосьмеренном слове соседние биты имели противоположные значения. Такая комбинация создает наибольший уровень помех и тем самым провоцирует систему на ошибку. В-третьих, шаблон должен обеспечивать выявление ошибок адресации, т. е. ситуации, когда микросхема возвратила содержание ячейки не той строки и/или столбца. Поскольку все эти требования взаимоисключающие, для тестирования потребуется несколько шаблонов. Только не забывайте время от времени выполнять "холостое" чтение для поддержания температуры микросхемы на максимально достижимом уровне, иначе эффективность теста начнет падать. Глава 2 Остается обсудить лишь последовательность перебора станиц.
Первое, что приходит на ум, тривиальный последовательный перебор, затем — хаотичные обращения к страницам по случайному шаблону. Достаточно ли этого для выявления всех типов ошибок? К сожалению, нет. Многие (если не все) современные контроллеры памяти самостоятельно определяют предпочтительный порядок обработки запросов. Возьмем, например, листинг рассмотренный выше.
Контроллер, проанализировав очередь запросов, "видит", что двойного переключения страниц можно избежать, если не выполнять повторное чтение из матрицы памяти, а возвратить процессору содержимое буфера! Похоже, есть только один путь обхитрить контроллер — проверять ячейки не сразу после записи, а спустя некоторое время, когда внутренние буферы контроллера будут гарантированно перекрыты последующими запросами. Это же, кстати, позволяет выявить ошибки регенерации, когда из-за какихто дефектов заряд с ячейки матрицы стекает раньше, чем ее успевают регенерировать.
Глава 3 Кэш Когда караван поворачивает назад, самый медленный верблюд оказывается впереди. Арабское народное 0ЕГЗЯ ЕХ МАСНИЧА' Тогда мы поняли настоящую цену учебникам гила "Язык ХХХ за двадцать один день" или "у'г'у — зто просто!". Подобные тексты (сами по себе, быть может, и неплохо написанные) оставляют за своими рамками настолько обширные области языка, избегают касаться стольких его тонкостей и особенностей, что в голове у читателя-программиста формируется зачастую усеченный и выхолощенный образ инструмента, который он собирается использовать. Евгений Зуев.
"Редкая профессия" Прозрачность кэш-подсистемы современных процессоров сочетается с их капризным и весьма эгоцецтричным характером. Кэш похож на девушку, которая "хочет, но молчит", заставляя окружающих догадываться: что же у нее на уме, и как же ей угодить. И хотя робкие намеки на демократичность уже начали прорезаться (см. разд.
"Управление кэшированием в х86 процессорах старших поколений" этой главы), в целом кэш-подсистема представляет собой сплошное скопление чудес, сюрпризов и загадок. Это "дремучий лес", и официальная документация — плохой путеводитель, постоянно ставящий вас в тупик неполнотой, а то и откровенной недостоверностью информации. ' Бог из машины (лат.). — Ред. г44 Глава 3 Я искренне надеюсь, что вы сочтете настоящее описание кэш-подсистемы лучшим из имеющихся, но даже оно не освещает и доли всех тайн кэшпамяти! Перед вами — лишь небольшая часть того, что мне удалось "нарыть".
Увы! Сжатые временные сроки не позволили рассказать обо всем и пришлось ограничиться только самой необходимой информацией. Принципы функционирования 8ВАМ Автор долго колебался — включать этот раздел в книгу или нет. С одной стороны, для достижения грамотной работы с кэшем вдаваться в технические подробности устройства статической памяти совершенно не обязательно, поскольку статическая память абсолютно прозрачна для программиста и конструктивные особенности ее реализации полностью маскируются кэшконтроллером.
Но, в то же время, работать с "железкои", не имея никаких представлений о том, что находится у нее внутри, — это по меньшей мере невежественно, если не сказать "непрофессионально". В конечном счете, небольшой ликбез никогда не помешает. Этот, весьма скромный по объему, раздел книги, конечно же, не раскроет всех секретов статической памяти, но, по крайней мере, объяснит, что это такое и почему оно работает именно так, а не иначе. История История создания статической памяти уходит своими корнями "в глубину веков". Память первых релейных компьютеров по своей природе была статической и долгое время не претерпевала практически никаких изменений (во всяком случае — концептуальных), — менялась лишь элементарная база: на смену реле пришли электронные лампы, впоследствии вытесненные сначала транзисторами, а затем ТТ(.- и СМОК-микросхемами, но идея, лежащая в основе статической памяти, была и остается прежней.
Динамическая память, изобретенная, кстати, значительно позднее, в силу фундаментальных физических ограничений, так и не смогла сравняться со статической памятью в скорости. Ядро Ядро микросхемы статической оперативной памятп (ЯКАМ вЂ” В(апс Капг(от Ассезз Мегпогу) представляет собой совокупность гприггеров — логических устройств, имеющих два устойчивых состояния, одно из которых условно соответствует логическому нулю, а другое — логической единице. Другими словами, каждый триггер хранит один бит информации — ровно столько же, сколько и ячейка динамической памяти (см, разд, "Ядро" главы 4). Кэш 245 Между тем, триггер как минимум по двум позициям обыгрывает конденсатор: П состояния триггера устойчивы и при наличии питания могут сохраняться бесконечно долго, в то время как конденсатор требует периодической регенерации; 1З триггер, обладая мизерной инертностью, без проблем работает на частотах вплоть до нескольких ГГц, тогда как конденсаторы начинают "сваливаться" уже на 75 — 100 МГц.