Медленная производительность рабочего потока с приоритетной очередью

Я пытался использовать рабочие потоки для ускорения более крупного алгоритма, когда я заметил, что использование независимой очереди приоритетов для большего количества потоков фактически замедляет производительность. Поэтому я написал небольшой тестовый пример.Медленная производительность рабочего потока с приоритетной очередью

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

Я положил тестовый пример here, потому что он длиннее фрагмента. (бит аффинности процессора относится к NCrunch)

Очередь приоритетов принадлежит моему собственному виду, поскольку .NET не имеет встроенной очереди. Он использует Pairing Heap, если это имеет значение.

Во всяком случае, если я запускаю программу с одним потоком и одним ядром, он получает около 100% использования. One core Использование капель с двумя резьбами/двумя сердечниками Two cores И в конечном итоге сжимает до 30% использования со всеми 8 сердечниками. eight cores

Это проблема, поскольку падение производительности сводит на нет любые выгоды от многопоточности. Что вызывает снижение производительности? Каждая очередь полностью независима от других потоков.

источник

2013-02-19 Tocs

Если вы работаете с процессором с несколькими физическими ядрами (и включенным гиперпотоком), все это может быть нормальным. См. Http://superuser.com/questions/133082/hyper-threading-and-dual-core-whats-the-difference и http://superuser.com/questions/420329/single-threaded-program-takes-too -low-cpu –

Хм, мне придется попробовать отключить гиперпоточность. Но если я сделаю что-то вроде http://stackoverflow.com/questions/39395/how-do-i-calculate-pi-in-c Calculate Pi, я получаю 100% по всем направлениям. – Tocs

@Tocs Пожалуйста, опубликуйте свои результаты. У меня была аналогичная проблема, и я не понимаю, что может быть виновата гиперпоточность. – AngryHacker

Некоторые проблемы, такие как решение pi, более подходят для распараллеливания и гиперпоточности, могут дать вам ускорение. Когда вы имеете дело с тяжелой проблемой памяти, такой как вы, Hyperthreading не может помочь и может на самом деле повредить. Проверьте «конвейерную обработку» в архитектуре процессора.

Существует не так много практических проблем, для которых вы можете получить 2x ускорение с помощью 2-cpus. Чем больше cpus, тем больше накладных расходов. В вашем тестовом алгоритме я подозреваю, что ядрам приходится ждать подсистемы памяти. Если вы настроите требования к памяти, вы увидите увеличение производительности (и использования) при перемещении требований к памяти ближе к размеру кеша ЦП.

источник

2013-02-19 17:38:51

Я видел, что это проблема, куча очереди не совсем локальна в памяти.Он часто выделяет небольшие фрагменты памяти, поэтому он будет разбросан. Я попытаюсь найти более реалистичную кэш-память и посмотрю, улучшит ли она ее. – Tocs

Для кого-то, у кого такая же проблема с приоритетной очередью, я написал грубую реализацию QuickHeap, которая является тайной кучей. Это означает, что он оптимально использует кеш, не зная его размера. http://pastie.org/6316709. Используя эту очередь приоритетов, я вижу почти 100% использования ЦП при нажатии и нажатии. Память действительно была проблемой. – Tocs

ОС назначает обработку в зависимости от того, какой процессор захочет в любой момент. Поэтому вы видите, что каждый процессор выполняет некоторую работу.

Кроме того, когда вы говорите «падение производительности», вы проверили, сколько утверждений создается системой? Вы, вероятно, тоже освобождаете себя от обсуждений среди нитей.

источник

2013-02-19 16:55:23

Медленная производительность рабочего потока с приоритетной очередью

ответ

Смежные вопросы