Производительность пропускной способности памяти для современных машин - PullRequest
4 голосов
/ 18 марта 2010

Я проектирую систему реального времени, которая иногда должна дублировать большой объем памяти. Память состоит из не крошечных областей, поэтому я ожидаю, что производительность копирования будет достаточно близка к максимальной пропускной способности, которую могут выполнять соответствующие компоненты (ЦП, ОЗУ, МБ). Это заставило меня задуматься о том, какую сырую пропускную способность памяти может использовать современная сырьевая машина?

Мой стареющий Core2Duo дает мне 1,5 ГБ / с, если я использую 1 поток до memcpy() (и, понятно, меньше, если я memcpy() с обоими ядрами одновременно). Хотя 1,5 ГБ - достаточный объем данных, в режиме реального времени Приложение, над которым я работаю, будет иметь примерно 1/50 секунды, что означает 30 МБ. В основном почти ничего. И, возможно, хуже всего, когда я добавляю несколько ядер, я могу обрабатывать намного больше данных без какой-либо повышенной производительности для необходимого шага дублирования.

Но в наши дни бюджетный Core2Due не совсем популярный. Существуют ли сайты с информацией, такой как фактические тесты, о необработанной пропускной способности памяти на текущем и ближайшем оборудовании?

Кроме того, для дублирования больших объемов данных в памяти, есть ли какие-либо ярлыки, или memcpy() настолько хорош, насколько это возможно?

Учитывая кучу ядер, которым нечего делать, кроме как дублировать как можно больше памяти за короткое время, что я могу сделать лучше всего?

РЕДАКТИРОВАТЬ: Я все еще ищу хорошую информацию о производительности копирования памяти. Я только что запустил мой старый memcpy() тест. Та же машина и настройки, теперь выдает 2,5 ГБ / с ...

Ответы [ 2 ]

2 голосов
/ 18 марта 2010

На более новых процессорах, таких как Nehalem, и на AMD, начиная с Opteron, память «локальна» для одного процессора, где один процессор может иметь несколько ядер. То есть ядру требуется определенное время для доступа к локальной памяти, подключенной к его ЦП, и больше времени для ядра, чтобы получить доступ к удаленной памяти, где удаленная память - это память, локальная для других ЦП. Это называется неравномерным доступом к памяти или NUMA. Для лучшей производительности memcpy вы хотите установить BIOS в режим NUMA, закрепить свои потоки на ядрах и всегда иметь доступ к локальной памяти. Узнайте больше о NUMA в Википедии .

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

Что касается производительности memcpy(), то она может варьироваться в зависимости от реализации. Библиотека Intel C (или, возможно, сам компилятор) имеет memcpy(), что намного быстрее, чем, например, в Visual Studio 2005. По крайней мере, на машинах Intel.

Лучшая копия памяти, которую вы сможете сделать, будет зависеть от выравнивания ваших данных, от того, сможете ли вы использовать векторные инструкции, от размера страницы и т. Д. Реализация хорошего memcpy() удивительно сложна, поэтому я рекомендую найти и протестировать как можно больше реализаций, прежде чем писать свою собственную. Если вы знаете больше деталей о вашей копии, таких как выравнивание и размер, вы можете реализовать что-то быстрее, чем Intel memcpy(). Если вы хотите вникнуть в подробности, вы можете начать с руководств по оптимизации Intel и AMD или страниц Agner Fog по оптимизации программного обеспечения .

1 голос
/ 19 марта 2010

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

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

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

Наконец, новый поток может перейти к скопированным данным и начать медленно передавать их удаленному источнику.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...