Задержка памяти aida64 что это
Задержка памяти у тебя адская. 88 нс. В нормальных условиях должно быть в районе 60.
Что касается частот памяти - всё нормально. Так и должно быть.
Eyef Оракул (98290) задержка памяти зависит от таймингов и частот памяти. Чем выше задержка - тем медленнее памяти "отвечает" на запросы процессора, фактически задержка больше 70нс - должна проявляться например в играх - как постоянные просадки fps и ощущения фризов. Т. е. показывает, например 60 fps, а по ощущениям где-то 30.
Означает пропускную способность памяти и задержки, которые у тебя 88 наносекунд .
Короче ОВОЩ у тебя, огород на нем пахать можешь ))))
не понял, так из-за чего это? системник только недавно собрал, оперативка, вроде как, неплохая, так в чем причина? что делать то?
Марик Гуру (4675) Алексей Галкин, оперативка, вроде как, неплохая - это ты где услыхал ? Твои модули памяти, это считай низ рынка памяти DDR4 . Хрень короче.
Вот нормальная задержка .
Это означает, что ты сидишь на 3600 АМД в одноканале. это жесть. от этого и все показатели отстой и проц будет явно тупить, сходи и купи вторую планку.
проще вообще поменять? можно ли как-то сдать её по гарантии?
Андрей Мыслитель (9158) Алексей Галкин, Если тебе проще поменять поменяй, но на ДВЕ! на амд вообще только в двухканале можно сидеть. Что хочешь изобретай, но планки должно быть 2 или можно 4. но не одна
Тест оперативной памяти в AIDA64 позволяет узнать об ее параметрах и возможностях. Это помогает выявить проблемы, а также узнать, какой модуль подойдет для определенной материнской платы при замене. Рассмотрим, какие эксплуатационные характеристики у оперативной памяти есть и как их протестировать.
Параметры оперативной памяти
Перед тем, как проверить оперативную память через AIDA64, следует знать следующее о ней:
- Тип. На компьютерах используется память DDR3 или DDR4. На ноутбуках и нетбуках – преимущественно модули с маркировкой SO-DIMM. Тип ОЗУ определяет скорость передачи данных. Чем выше поколение, тем она быстрее.
- Объем. На сегодняшний день выпускаются планки с памятью от 2 Гб. Чем показатель выше, тем лучше работоспособность системы в целом. Для офисных ПК достаточно 4-6 Гб, для игровых – от 16 Гб.
- Частота. От нее зависит пропускная способность модуля. При большем показателе больше данных способно передаваться в течение секунды.
- Тайминг. Показатель указывает на время задержки, в течение которого происходит переход по элементам ОЗУ. Чем он меньше, тем лучше.
- Напряжение. Устанавливаемые плашки ОЗУ в нетбуки или ноутбуки с маркировкой SO-DIMM потребляет меньше энергии.
Зная все эксплуатационные характеристики оперативной памяти, можно без труда заменить модуль . Не придется платить за ремонт или диагностику в сервисном центре. Достаточно сходить в специализированный магазин и купить ОЗУ. Также об этом полезно знать, чтобы понимать особенности и производительность системы для определенной работы. Например, для запуска требовательной программы или игры. Протестировать оперативную память можно с помощью утилиты – AIDA64.
Как узнать параметры оперативной памяти через средства AIDA64
С помощью AIDA64 возможно узнать о характеристиках оперативной памяти. Чтобы их проверить, следуйте инструкции:
После этого проще подобрать новую плашку так, чтобы она была совместима с материнской платой и другими компонентами ПК или ноутбука.
Чтобы узнать максимальный размер объема оперативной памяти, который будет поддерживаться материнской платой, в списке «Системная плата» выберите пункт «Чипсет». В свойствах северного моста отображается это значение.
Увидеть объем установленного ОЗУ также можно в свойствах операционной системы. Для этого достаточно щелкнуть правой кнопкой мыши по иконке «Мой компьютер» на рабочем столе и перейти в пункт «Свойства».
Но здесь слишком мало информации об оперативной памяти, поэтому лучше воспользоваться AIDA64.
Тестирование оперативной памяти
Тестирование оперативной памяти необходимо, если возникают сбои в ее работе или есть подозрение, что существуют неполадки с кешем.
Чтобы проверить это, действуйте следующим образом:
Проверка может занять продолжительное время, в зависимости от ее объема и типа. Она осуществляется по нескольким параметрам: скорость записи, чтения, копирования и задержки. Если результат проверки не сообщат о наличии ошибок, то оперативная память работает нормально.
Стресс-тест в AIDA64
Чтобы проверить стабильность работы ПК, необходимо протестировать все его комплектующие на работоспособность. Встроенные средства AIDA64 также позволяют сделать это. Обычно функцию применяют после разгона процессора или видеокарты, поэтому обычным пользователям она не требуется. Но в некоторых случаях, нужно протестировать оборудование. Например, чтобы выявить проблему в работе материнской платы и ее компонентов.
Чтобы запустить стресс-тест в АИДА64, сделайте следующее:
После этого запустится стресс-тест производительности. Если во время проверки, приложение выдаст ошибку о том, что есть перегрев устройства, необходимо отключить ПК или ноутбук до выяснения обстоятельств и причин перегрева.
| Рекомендуем! InstallPack | Стандартный установщик |
|---|---|
| Официальный дистрибутив Aida64 | |
| Тихая установка без диалоговых окон | |
| Рекомендации по установке необходимых программ | |
| Пакетная установка нескольких программ |
рекомендует InstallPack, с его помощью вы сможете быстро установить программы на компьютер, подробнее на сайте.
Функционал AIDA64 позволяет узнать необходимую информацию об устройствах и компонентах ПК или ноутбука, что нельзя сделать через саму систему. С ее помощью можно посмотреть, какая оперативная память установлена, ее тип, тайминг, объем и другие характеристики. При сбое в работе памяти или кеша пользователь может запустить проверку ОЗУ или производительности всей системы, чтобы выявить проблему и в дальнейшем решить ее с минимальными затратами.
Я не спец по разгону оперативной памяти, но знаю, что для Ryzen это полезно.
XMP профиль 3000 CL15. Разгон до 3200 делается спокойно, прирост пропускной ощутимый.
Но после 3200 прирост идет просто никакущий, на частоте 3600 пропускная ОЗУ ниже 50 тысяч на чтение и копирование + очень высокая задержка(см. скрин). При этом смотрю обзоры и разгоны других людей даже с такой же ОЗУ и у них на более низких частотах пропускная в разы выше, до 56-60 тысяч и задержка около 62ns.
Может я что-то не так делаю? Или чипы настолько убогие, что их макс производительность на 3000-3200 :\
ОЗУ - Corsair CMK16GX4M2B3000C15 Hyniz AFR A-Die 1 Rank
Мать - ASUS B450M Pro Gaming
Проц - Ryzen 3600
- Вопрос задан более двух лет назад
- 5044 просмотра
Если хотите 3600 МГц и больше, с низкими таймингами и высокой производительностью - готовьте кошелёк) На такой же матери как у вас, но с другой памятью, а именно из линейки crucial ballistix sport LT на 3000 МГц, смог получить 3533 МГц. Выше 3600 гнать большого смысла уже нет. Поставьте XMP на 3200, попробуйте вручную снизить тайминги до 15-16-16-35. Должно быть лучше.
Мне не очень нравится скорость чтения, как правило, скорость чтения и копирования довольно близки, а у вас большой разрыв.
Ну и не нужно ставить самоцелью поднятие частоты. Нужно стремиться к оптимальному сочетанию частоты, таймингов и латентности. Но если на этой памяти вы сможете сделать ниже 70нс - уже будет неплохо. Опирайтесь на скорости чтения, записи и копирования.
P. S. На интел латентность будет ниже, но что поделать. Лично я не страдаю при работе с компом вообще ни разу.
Пример с сайта Overclockers, память у пользователя была такая же, другая мать и проц.
Но различия достаточно существенные. У меня частоты более высокие берутся проще, но прирост никакущий, у него танцы с бубном, но прирост есть. (
Несколько недель назад в разговоре за обедом коллега пожаловался на какой-то медленный процесс. Он подсчитал количество сгенерированных байт, количество циклов обработки, и в конечном счёте, объём оперативной памяти. Коллега заявил, что современный GPU с пропускной способностью памяти более 500 ГБ/с съел бы его задачу и не подавился.
Мне показалось, что это интересный подход. Лично я раньше не оценивал задачи производительности с такой стороны. Да, я знаю о разнице в производительности процессора и памяти.
Я знаю, как писать код, который активно использует кэш. Знаю примерые цифры задержки. Но этого недостаточно, чтобы сходу оценить пропускную способность памяти.
Вот мысленный эксперимент. Представьте, что в памяти непрерывный массив из миллиарда 32-разрядных целых чисел. Это 4 гигабайта. Сколько времени займёт перебор этого массива и суммирование значений? Сколько байт в секунду может CPU считать из оперативной памяти? Непрерывных данных? Произвольного доступа? Насколько хорошо можно распараллелить этот процесс?
Вы скажете, что это бесполезные вопросы. Реальные программы слишком сложны, чтобы имел смысл такой наивный ориентир. Так и есть! Реальный ответ — «зависит от ситуации».
Тем не менее, я думаю, что этот вопрос стоит изучить. Я не пытаюсь найти ответ. Но думаю, что мы можем определить некоторые верхние и нижние границы, некоторые интересные точки в середине и что-то узнать в процессе.
Если вы читаете блоги по программированию, то наверняка сталкивались с «цифрами, которые должен знать каждый программист». Они выглядят примерно так:
Отличный список. Он всплывает на HackerNews как минимум раз в год. Каждый программист должен знать эти цифры.
Но эти цифры о другом. Задержка и пропускная способность не одно и то же.
Тот список составлен в 2012 году, а эта статья 2020 года, времена изменились. Вот цифры для Intel i7 со StackOverflow.
Интересно! Что изменилось?
- L1 стал медленнее; 0,5 → 1,5 нс
- L2 быстрее; 7 → 4,2 нс
- Соотношение L1 и L2 намного уменьшилось; 2,5x против 14х (ого!)
- Кэш L3 теперь стал стандартом; от 12 до 40 нс
- Оперативная память стала быстрее; 100 → 60 нс
Вот некоторые цифры из wikichip по пропускной способности и размеру кэша моего процессора.
Что хочется знать:
- Верхний предел производительности RAM
- Нижний предел
- Лимиты кэшей L1/L2/L3
Проведём несколько тестов. Для замера пропускной способности я написал простенькую программу на C++. Очень приблизительно она выглядит так.
Некоторые детали опущены. Но вы поняли идею. Создать большой, непрерывный массив элементов. Разделить массив на отдельные фрагменты. Обработать каждый фрагмент в отдельном потоке. Накопить результаты.
Также нужно измерить случайный доступ. Это очень сложно. Я попробовал несколько способов, в итоге решил смешивать предварительно вычисленные индексы. Каждый индекс существует ровно один раз. Затем внутренний цикл перебирает индексы и вычисляет sum += nums[index] .
В расчёте пропускной способности я не рассматриваю память массива индексов. Считаются только байты, которые вносят свой вклад в общую сумму sum . Я не делаю бенчмарки своего железа, а оцениваю способность работать с наборами данных разных размеров и с разными схемами доступа.
Проведём тесты с тремя типами данных:
int — основное 32-разрядное целое число
matri4x4 — содержит int[16] ; помещается в 64-байтовую строку кэша
matrix4x4_simd — использует встроенные средства __m256i
Мой первый тест работает с большим блоком памяти. Блок размером 1 ГБ из N элементов выделяется и заполняется небольшими случайными значениями. Простой цикл перебирает массив N раз, поэтому он обращается к памяти объёмом N ГБ для вычисления суммы int64_t . Несколько потоков разбивают массив, а каждый получает доступ к одинаковому количеству элементов.
Тада! На этом графике мы берём среднее время выполнения операции суммирования и преобразуем его из runtime_in_nanoseconds в gigabytes_per_second .
Довольно неплохой результат. int32 может последовательно считывать в одном потоке 11 ГБ/с. Он масштабируется линейно, пока не достигнет 38 ГБ/с. Тесты matrix4x4 и matrix4x4_simd быстрее, но упираются в тот же потолок.
Существует чёткий и очевидный потолок, сколько данных мы можем считывать из оперативной памяти в секунду. На моей системе это примерно 40 ГБ/с. Это соответствует современным спецификациям, перечисленным выше.
Судя по трём нижним графикам, случайный доступ медленный. Очень, очень медленный. Производительность однопоточного int32 составляет ничтожные 0,46 ГБ/с. Это в 24 раза медленнее, чем последовательное суммирование на скорости 11,03 ГБ/с! Тест matrix4x4 показывает лучший результат, потому что выполняется на полных кэш-линиях. Но он по-прежнему в четыре-семь раз медленнее, чем последовательный доступ, и достигает пика на уровне всего 8 ГБ/с.
В моей системе размер кэша L1/L2/L3 для каждого потока составляет 32 КБ, 256 КБ и 2 МБ. Что произойдёт, если взять 32-килобайтный блок элементов и перебрать его 125 000 раз? Это 4 ГБ памяти, но мы всегда будем попадать в кэш.
Потрясающе! Однопоточная производительность аналогична чтению большого блока, около 12 ГБ/с. За исключением того, что на этот раз многопоточность пробивает потолок 40 ГБ/с. В этом есть смысл. Данные остаются в кэше, так что узкое место оперативной памяти не проявляется. Для данных, которые не поместились в кэш L3, действует тот же потолок около 38 ГБ/с.
Тест matrix4x4 показывает аналогичные результаты схеме, но ещё быстрее; 31 ГБ/с в однопоточном режиме, 171 ГБ/с в многопоточном.
Теперь давайте посмотрим на matrix4x4_simd . Обратите внимание на ось y.
matrix4x4_simd выполняется исключительно быстро. Он в 10 раз быстрее, чем int32 . На блоке 16 КБ он даже пробивает 1000 ГБ/с!
Очевидно, что это поверхностный синтетический тест. Большинство приложений не выполняют одну и ту же операцию с одними и теми же данными миллион раз подряд. Тест не показывает производительность в реальном мире.
Но урок понятен. Внутри кэша данные обрабатываются быстро. С очень высоким потолком при использовании SIMD: более 100 ГБ/с в однопоточном режиме, более 1000 ГБ/с в многопоточном. Запись данных в кэш происходит медленно и с жёстким лимитом около 40 ГБ/с.
Давайте сделаем то же самое, но теперь с произвольным доступом. Это моя любимая часть статьи.
Чтение случайных значений из RAM происходит медленно, всего 0,46 ГБ/с. Чтение случайных значений из кэша L1 очень быстрое: 13 ГБ/с. Это быстрее, чем скорость чтения последовательных данных int32 из RAM (11 ГБ/с).
Тест matrix4x4 показывает аналогичный результат по тому же шаблону, но примерно вдвое быстрее, чем int .
Произвольный доступ matrix4x4_simd безумно быстр.
Произвольное чтение из памяти осуществляется медленно. Катастрофически медленно. Менее 1 ГБ/с для обоих вариантов теста int32 . В то же время произвольное чтение из кэша на удивление быстрое. Оно сравнимо с последовательным чтением из оперативной памяти.
Это нужно переварить. Произвольный доступ к кэшу сопоставим по скорости с последовательным доступом к RAM. Падение от L1 16 КБ до L2 256 КБ всего в два раза или меньше.
Думаю, что это повлечёт глубокие последствия.
Погоня за указателем (прыжки по указателям) — это плохо. Очень, очень плохо. Насколько снижается производительность? Смотрите сами. Я сделал дополнительный тест, который обёртывает matrix4x4 в std::unique_ptr . Каждый доступ проходит через указатель. Вот ужасный, просто катастрофический результат.
Последовательное суммирование значений за указателем выполняется со скоростью менее 1 ГБ/с. Скорость произвольного доступа с двойным пропуском кэша составляет всего 0,1 ГБ/с.
Погоня за указателем замедляет выполнение кода в 10-20 раз. Не позволяйте своим друзьям использовать связанные списки. Пожалуйста, подумайте о кэше.
Для разработчиков игр привычно устанавливать предел (бюджет) нагрузки на CPU и объём памяти. Но я никогда не видел бюджет пропускной способности.
У современных игр FPS продолжает расти. Сейчас он на уровне 60 FPS. VR работает на частоте 90 Гц. У меня игровой монитор на 144 Гц. Это потрясающе, так что 60 FPS кажется дерьмом. Я ни за что не вернусь к старому монитору. У киберспортсменов и стримеров Twitch мониторы 240 Гц. В этом году Asus представила на выставке CES монстра на 360 Гц.
У моего процессора верхний предел около 40 ГБ/с. Это кажется большой цифрой! Однако при частоте 240 Гц получается всего лишь 167 МБ на кадр. Реалистичное приложение может генерировать трафик 5 ГБ/с на частоте 144 Гц, а это всего 69 МБ на кадр.
Вот таблица с несколькими цифрами.
Мне кажется, полезно оценить проблемы с такой стороны. Это позволяет понять, что некоторые идеи неосуществимы. Достигнуть 240 Гц непросто. Это не случится само собой.
Прошлый список устарел. Сейчас его необходимо обновить и привести в соответствие к 2020 году.
Вот несколько цифр для моего домашнего компьютера. Это смесь AIDA64, Sandra и моих бенчмарков. Цифры не дают полной картины и являются лишь отправной точкой.
Хорошо бы создать небольшой, простой опенсорсный бенчмарк. Какой-нибудь файл C, который можно запустить на настольных компьютерах, серверах, мобильных устройствах, консолях и т. д. Но я не тот человек, который напишет такой инструмент.
Измерить пропускную способность памяти сложно. Очень сложно. В моём коде наверняка есть ошибки. Много неучтённых факторов. Если у вас есть некое критическое замечание для моей методики, вероятно, вы правы.
В конечном счёте, я думаю, что это нормально. Это статья не о точной производительности моего десктопа. Речь о постановке проблем с определённой точки зрения. И о том, как научиться выполнять некоторые приблизительные математические расчёты.
Коллега поделился со мной интересным мнением о пропускной способности памяти GPU и производительности приложений. Это подтолкнуло меня к исследованию производительности памяти на современных компьютерах.
Для примерных расчётов вот некоторые цифры для современного десктопа:
- Производительность RAM
- Максимум: 45 ГБ/с
- В среднем, примерно: 5 ГБ/с
- Минимум: 1 ГБ/с
- Максимум (c simd): 210 ГБ/с / 80 ГБ/с / 60 ГБ/с
- В среднем, примерно: 25 ГБ/с / 15 ГБ/с / 9 ГБ/с
- Минимум: 13 ГБ/с / 8 ГБ/с / 3,5 ГБ/с
Тем не менее, самое важное — это новый способ думать о проблемах. Представление проблемы в виде байтов в секунду или байтов на кадр — ещё одна линза, через которую нужно смотреть. Это полезный инструмент на всякий случай.
Спасибо за чтение.
Эта статья только слегка затронула тему. Вероятно, я не буду углубляться в неё. Но если это сделал, то мог бы охватить некоторые из следующих аспектов:
- Производительность записи
- Ложное совместное использование (false sharing)
- Производительность std::atomic (или её отсутствие)
- Счётчики производительности
Тесты проводились на моём домашнем ПК. Только стоковые настройки, никакого разгона.
Читайте также: