Комментарии 21
Понятно, что это синтетика и «не сравнивайте данные разных версий, мы улучшаем наши тесты» — но какие-то опорные цифры можно получить?
PS у меня, судя по тестам, скорость чтения из памяти ~54Gb/s (3733@16-18-18-38)
Современные процессоры имеют много ядер. Иногда — десятки. Соответственно под это оптимизируется всё.
Один поток даже и близко не способен загрузить канал в память — и не потому, что программу такую не написать, а потому что контроллер памяти под это не оптимизировали.
утилизирует, по данным мониторинга, несколько Тб памяти и 15 Гб/с сети и дисков.
PS а ещё я видел чудо — среднюю загрузку процессоров кластера в 99,99% (много Xeon 8120) и 300Тб промежуточных данных в hdfs от неправильного MapReduce.
Реальность — она разная и зависит от точки зрения, но пиковые цифры, в любом случае, интересны.
Реальность — она разная и зависит от точки зрения, но пиковые цифры, в любом случае, интересны.Вот только старые однопоточные тесты вам и близко ничего похожего на пиковую производительность н покажут.
В этом, собственно, беда.
Или есть многоканальные высокочастотные контроллеры?
Да, это разгон, но не бог весть какой большой.
Плюс, чем больше планок — тем хуже разгон памяти.
PS хотя на реддите находил видео с частотами вплоть до 4200 MHz
2)больше планок-выше производительность(как и с 2-х ранковой памятью) при той-же частоте\таймингах.
Так что при увеличении количества планок производительность не ухудшится. Может улучшится, а может останется прежней.
Произвольное чтение из памяти осуществляется медленно. Катастрофически медленно
разумеется, доступ к памяти же идёт не побайтово, а блоками.
так что при последовательном чтении мы имеем одно обращение к памяти на блок, при случайном — одно на каждое обращение в худшем случае (промах мимо кэша).
В то же время произвольное чтение из кэша на удивление быстрое
а разве случайный/последовательный доступ к кэшу чем-то различаются? как минимум к L1 не должны
P.S. измерение именно пропускной способности памяти ИМХО не имеет большого смысла — ибо длинные последовательные обращения случаются не так уж часто.
P.P.S. "Хорошо бы создать небольшой, простой опенсорсный бенчмарк" — memtest86+ не подходит?
Кто-то открывает для себя устройство современного компьютера на паре архитектуры ЭВМ и ВС, а кто-то, как автор, на салфетке из пивбара.
В кэшах (даже L1) данные хранятся не байтами, а линиями размером примерно 64 байта, это вполне может влиять при произвольном доступе. В компьютере же есть ещё cache thrashing (он же ассоциативный и маленький), конечный TLB (чтобы понять, куда именно нужно в память идти при произвольном доступе), проблемы с внезапно включающимся Turbo Boost, учетом времени, оптимизирующими компиляторами и другими не менее захватывающими эффектами.
А последовательных обращений бывает в жизни, там, матрицы миллион на миллион перемножить, контрольную сумму проверить/блок расшифровать, выборку сделать по диапазону индекса в БД.
И лучший бенчмарк — это ваше приложение и есть. Плюс документация производителя ВС, эксперименты и мозг. Ибо одно дело перенести приложение 1:1 в видеокарту (или даже на многопроцессорную систему, чего далеко ходить) и потом всем рассказывать, как надо отключать NUMA, а другое — разобраться в причинах улучшения/ухудшения и адаптировать(ся).
Это нужно переварить. Произвольный доступ к кэшу сопоставим по скорости с последовательным доступом к RAM.Ага, осознание, что так и задумано, что это следствие того, что данные загружаются в кеш блоками.
Думаю, что это повлечёт глубокие последствия.
а какой поток данных может генерить процессор, каждым ядром?
Можно проверить реальную скорость PCIe 3.0 х1/х2/х4/х8/х16, совпадает она со спецификацией или медленнее, и насколько.
Поскольку скорость ядра вроде быстрее, то нагружать его несколькими PCIe 3.0 x16 слотами (до восьми штук x16 ??)
Кинуть в каждый слот по видеокарте(х16), БИОС раздаст им память.
И писать туда пямо с процесорного ядра, в видеопамять(без ОС).
Измеряем на коленке пропускную способность памяти