Состояние функциональности "memset" в C ++ с современными компиляторами - PullRequest
19 голосов
/ 05 октября 2008

Контекст:

Некоторое время назад я наткнулся на эту статью DDJ 2001 года Александреску: http://www.ddj.com/cpp/184403799

Речь идет о сравнении различных способов инициализации буфера для некоторого значения. Как то, что "memset" делает для однобайтовых значений. Он сравнил различные реализации (memcpy, явный цикл for, устройство Даффа) и не нашел лучшего кандидата для всех размеров наборов данных и всех компиляторов.

Цитата:

В основе всего этого лежит очень глубокая и печальная реализация. Мы в 2001 году, году Пространственной Одиссеи. (...) Просто выйдите из коробки и посмотрите на нас - через 50 лет мы все еще не очень хорошо заполняем и копируем память.

Вопрос:

  1. Кто-нибудь имеет более свежую информацию об этой проблеме? Действительно ли последние реализации GCC и Visual C ++ работают значительно лучше, чем 7 лет назад?
  2. Я пишу код со сроком жизни 5+ (возможно, более 10) лет, который будет обрабатывать размеры массивов от нескольких байтов до сотен мегабайт. Я не могу предположить, что мой выбор сейчас будет оптимальным через 5 лет. Что я должен делать:
    • а) использовать системный набор настроек (или эквивалентный) и забыть об оптимальной производительности или предположить, что среда выполнения и компилятор справятся с этим для меня.
    • b) раз и навсегда выполнить сравнительный анализ для различных размеров массивов и компиляторов и переключаться во время выполнения между несколькими подпрограммами.
    • в) запустить эталонный тест при инициализации программы и переключаться во время выполнения на основе точных (?) Данных.

Редактировать: я работаю над программным обеспечением для обработки изображений. Мои элементы массива - это PODы, и каждая миллисекунда считается!

Редактировать 2: Спасибо за первые ответы, вот некоторые дополнительные сведения:

  • Инициализация буфера может составлять 20% -40% от общего времени выполнения некоторых алгоритмов.
  • Платформа может измениться в ближайшие 5+ лет, хотя она останется в категории «самые быстрые ЦП, которые можно купить у DELL». Компиляторы будут некой формой GCC и Visual C ++. Никаких встроенных вещей или экзотических архитектур на радаре
  • Я хотел бы услышать от людей, которые должны были обновить свое программное обеспечение, когда появились MMX и SSE, так как я должен буду делать то же самое, когда появится «SSE2015» ... :)

Ответы [ 12 ]

1 голос
/ 05 октября 2008

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

Тогда вам также следует помнить, что memset так или иначе будет зависеть от аппаратного обеспечения, на котором он работает, в течение этих пяти лет будет ли программное обеспечение работать на той же платформе? На той же архитектуре? Когда вы придете к такому выводу, вы можете попытаться «свернуть» свой собственный набор записей, обычно играя с выравниванием буферов, убедившись, что вы обнуляете 32-битные значения одновременно, в зависимости от того, что наиболее эффективно в вашей архитектуре.

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

0 голосов
/ 06 октября 2008

Год уже не 2001. С тех пор появились новые версии Visual Studio. Я нашел время, чтобы изучить memset в тех. Они будут использовать SSE для memset (если доступно, конечно). Если ваш старый код был верным, статистически если теперь будет быстрее. Но вы можете попасть в неудачный уголок. Я ожидаю того же от GCC, хотя я не изучал код. Это довольно очевидное улучшение и компилятор с открытым исходным кодом. Кто-то создал патч.

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