std :: _ производительность Lockit

Question

std :: _ производительность Lockit

0

У меня есть небольшой парсер, который я пытаюсь оптимизировать.

Он читает кучу файлов (тысяча в типичном использовании) заполняет vector<code_file> code_file - это структура, которая, среди прочего, содержит содержимое файла.

второй шаг (более длинный и тот, который я пытаюсь оптимизировать) проходит через вектор и для каждого файла parse( it ), который заполняет структуру code_file. никакая модификация задействованного вектора.

for( auto it = code_files.begin(); it != code_files.end(); ++it )
{
    parseCodeFile( *it );
}

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

Я пробовал с профилировщиком, и я заметил, что он тратит почти 50% времени в std::_Lockit::_Lockit (25%) и std::_Lockit::~_Lockit (25%)

Есть ли способ избежать этого?

Я видел это сообщение: Что делает std :: _ lockit? но я запускаю его в выпуске, и определения выглядят нормально:

_SECURE_SCL=0
_HAS_ITERATOR_DEBUGGING=0
_ITERATOR_DEBUG_LEVEL=0

Некоторая дополнительная информация: функция синтаксического анализа, очевидно, выполняет много строковых манипуляций, она использует некоторые дополнительные утилиты, такие как boost :: trim и boost :: starts_with, скомпилированные с помощью Visual Studio 2010.

foke 11 июнь 2014, в 22:06

Источник

0

Я предполагаю, что в iostream он усеян замками, чтобы сделать его потокобезопасным. Это просто никогда не было задумано с учетом того, что когда-то. Использование потоков для чтения файлов само по себе очень плохая идея, вы отправляете головку считывателя дисков туда-сюда. Очень дорогой.
Hans Passant 11 июнь 2014, в 21:17

Теги:

c++

performance

visual-studio-2010

stl

1 ответ

Ещё вопросы

Я предполагаю, что в iostream он усеян замками, чтобы сделать его потокобезопасным. Это просто никогда не было задумано с учетом того, что когда-то. Использование потоков для чтения файлов само по себе очень плохая идея, вы отправляете головку считывателя дисков туда-сюда. Очень дорогой.

MSalters · Answer 1 · 2014-06-11T18-24-00.000Z

Просто угадайте, так как я не вижу весь ваш код, но заметьте, что code_files может меняться по длине внутри parseCodeFile. Если он перераспределит, то UB, но сжатие может быть безопасным. MSVC++ просто не знает и должен перепроверить .end().

Конечно, это немного не важно для parallel_for. Вы не показываете этот код, но он задокументирован как работающий только с интегральными типами. Microsoft может описать ее как STL-подобную, но это явно не означает, что STL-like будет поддерживать итераторы.

хм нет code_files не может измениться по длине ... не беспокойтесь о корректности, он работает и дает тот же результат. Мне просто интересно, почему он не работает лучше с несколькими потоками. Что касается parallel_for, то это не реализация Microsoft, а моя собственная. Реализация Microsoft по какой-то причине работает намного хуже. 10% дополнительного времени с моим параллелизом, 55% с Microsoft
@foke: Как вы говорите компилятору, чтобы он не беспокоился? Будет. И производительность вашего parallel_for - это то, что мы не можем судить без кода, конечно. Вы используете разделяй и властвуй? (Хотя диапазон достаточно велик, разделите диапазон на две части и создайте поток для обработки второй половины) Или простое разбиение (Разбейте диапазон на N частей, создайте N потоков)? Мотивация для первого - то, что вы можете иметь N / 2 потоков, создающих N / 2 потоков параллельно.