Удалёнка: опыт и лайфхаки
Реклама
Комментарии 21
0
Возможно, я не прав, но задержки и какие-то тесты скорости ( RAM read-write-copy/CPU/FPU) умеет показывать AIDA64?
Понятно, что это синтетика и «не сравнивайте данные разных версий, мы улучшаем наши тесты» — но какие-то опорные цифры можно получить?
PS у меня, судя по тестам, скорость чтения из памяти ~54Gb/s (3733@16-18-18-38)
0
Можно получить «опорные цифры», которые в несколько раз отличаются от реальности.

Современные процессоры имеют много ядер. Иногда — десятки. Соответственно под это оптимизируется всё.

Один поток даже и близко не способен загрузить канал в память — и не потому, что программу такую не написать, а потому что контроллер памяти под это не оптимизировали.
0
Всё оптимизируется в зависимости от требований, поэтому я не сильно удивляюсь играм, оптимизированным на 4 потока или кластеру hadoop, который на тяжёлых запросах
утилизирует, по данным мониторинга, несколько Тб памяти и 15 Гб/с сети и дисков.
PS а ещё я видел чудо — среднюю загрузку процессоров кластера в 99,99% (много Xeon 8120) и 300Тб промежуточных данных в hdfs от неправильного MapReduce.
Реальность — она разная и зависит от точки зрения, но пиковые цифры, в любом случае, интересны.
0
Реальность — она разная и зависит от точки зрения, но пиковые цифры, в любом случае, интересны.
Вот только старые однопоточные тесты вам и близко ничего похожего на пиковую производительность н покажут.

В этом, собственно, беда.
0
Когда Aida показывает 54Gb/s — это явно многопоток, который особого отношения к реальности не имеет, зато показывает потолок, нет?
0
А сколько каналов? Если 2 — то да, похоже на потолок. Если 3-4, то как-то изрядно от него далеко…
0
С такими частотами (3733) — естественно 2.
Или есть многоканальные высокочастотные контроллеры?
0
Threadripper штатно поддерживает 4 канала 3200. Разница между 3200 и 3733 — ⅙.

Да, это разгон, но не бог весть какой большой.
0
Не думаю, что в сегменте HEDT, куда целится TR, будут хоть сколько-то массово гонять память.
Плюс, чем больше планок — тем хуже разгон памяти.
PS хотя на реддите находил видео с частотами вплоть до 4200 MHz
0
1)Хуже частота. А у памяти важнее задержки(не в циклах а в нс) и как там влияет количество планок-хз. Я не нашёл тестов.
2)больше планок-выше производительность(как и с 2-х ранковой памятью) при той-же частоте\таймингах.
Так что при увеличении количества планок производительность не ухудшится. Может улучшится, а может останется прежней.
0
Производительность — не ухудшится, а вот нагрузка на КП процессора вырастет, соответственно может упасть потолок разгона оперативной памяти. Если мы об абстрактных плашках на JEDEC-овских 2400 — то да, станет лучше. Если с надеждой на разгон — может стать хуже.
0
Да, может. А может и не ухудшится(не факт ведь, что потолок определяет КП, а не сама память).
При этом если не ухудшится, то производительность возрастёт.
Мы с надеждой на разгон. Но цель разгона не циферка хххх МГц, а производительность.
0
Произвольное чтение из памяти осуществляется медленно. Катастрофически медленно

разумеется, доступ к памяти же идёт не побайтово, а блоками.
так что при последовательном чтении мы имеем одно обращение к памяти на блок, при случайном — одно на каждое обращение в худшем случае (промах мимо кэша).


В то же время произвольное чтение из кэша на удивление быстрое

а разве случайный/последовательный доступ к кэшу чем-то различаются? как минимум к L1 не должны


P.S. измерение именно пропускной способности памяти ИМХО не имеет большого смысла — ибо длинные последовательные обращения случаются не так уж часто.


P.P.S. "Хорошо бы создать небольшой, простой опенсорсный бенчмарк" — memtest86+ не подходит?

+2

Кто-то открывает для себя устройство современного компьютера на паре архитектуры ЭВМ и ВС, а кто-то, как автор, на салфетке из пивбара.


В кэшах (даже L1) данные хранятся не байтами, а линиями размером примерно 64 байта, это вполне может влиять при произвольном доступе. В компьютере же есть ещё cache thrashing (он же ассоциативный и маленький), конечный TLB (чтобы понять, куда именно нужно в память идти при произвольном доступе), проблемы с внезапно включающимся Turbo Boost, учетом времени, оптимизирующими компиляторами и другими не менее захватывающими эффектами.


А последовательных обращений бывает в жизни, там, матрицы миллион на миллион перемножить, контрольную сумму проверить/блок расшифровать, выборку сделать по диапазону индекса в БД.


И лучший бенчмарк — это ваше приложение и есть. Плюс документация производителя ВС, эксперименты и мозг. Ибо одно дело перенести приложение 1:1 в видеокарту (или даже на многопроцессорную систему, чего далеко ходить) и потом всем рассказывать, как надо отключать NUMA, а другое — разобраться в причинах улучшения/ухудшения и адаптировать(ся).

+2
разумеется, доступ к памяти же идёт не побайтово, а блоками.

Дело даже не в этом, а в том, что у памяти есть ненулевая латентность, а у процессора есть префетчер для нивелирования этой латентности. Поэтому если вы обращаетесь к памяти подряд, то данные уже запрошены и скоро будут в кеше (если уже не в кеше), а если вы обращаетесь в случайное место — ждите 60-100 нс на память (что сразу ограничивает скорость в 40-80 мегабайт/с, если читать по одному случайному инту), и это ещё не учитывая промахи TLB (про которые в статье ни слова). Я вообще удивлен, что у автора такая большая производительность случайных чтений, на самом деле.

0
Это нужно переварить. Произвольный доступ к кэшу сопоставим по скорости с последовательным доступом к RAM.
Думаю, что это повлечёт глубокие последствия.
Ага, осознание, что так и задумано, что это следствие того, что данные загружаются в кеш блоками.
+1
интересно сделать такие же изыскания для threadripper 2990WX там и NUMA и ядра не равноудалённые и кеши разные.
0
С замедлением в 25 раз Вам очень повезло. Скорее всего, доступ — всё-таки псевдослучайный. Я доводил до 100 кратного замедления в своих экспериментах (при теоретическом пределе в 250 раз ). А если поиграться с выравниванием, то можно получить ещё и пенальти дополнительную. Есть интрисинки для префетча, на порядки помогают для оптимизации подобного софта (можно загрузить всю память из одного потока, а остальные ядра использовать как-то).
0
Интересно, чем не устроил стандартный тест на полосу памяти и кеша stream от Дж. МакКалпина. Его даже в доках от интела по теме «Measuring memory bandwidth» используют.
0
>>Дальнейшие исследования
а какой поток данных может генерить процессор, каждым ядром?

Можно проверить реальную скорость PCIe 3.0 х1/х2/х4/х8/х16, совпадает она со спецификацией или медленнее, и насколько.

Поскольку скорость ядра вроде быстрее, то нагружать его несколькими PCIe 3.0 x16 слотами (до восьми штук x16 ??)
Кинуть в каждый слот по видеокарте(х16), БИОС раздаст им память.
И писать туда пямо с процесорного ядра, в видеопамять(без ОС).

Только полноправные пользователи могут оставлять комментарии.  , пожалуйста.