2013-10-15 3 views
0

Я написал программу, которая читает WAV-файл и собирает различные данные, затем выполняет определенные вычисления и выводит любую полезную информацию, которая мне нужна (конечная точка - это дискриминатор голоса). Все это происходит по отдельности для каждого файла в отдельном объекте класса, но для каждой из них требуется только отдельная строка ввода, поэтому я решил, что могу довольно легко наполнить приложение, и я мог бы запустить его в четыре раза быстрее или около того.Использование ядра в C#

Это я сделал, и, похоже, он работает хорошо. Тем не менее, когда я пришел ко времени приложения (с потоком и без потоковой передачи), я получил около 3 секунд в течение минуты, чтобы работать через ~ 3600 файлов. Мое лучшее предположение для этого - входы/выходы файлов, и я увижу большие улучшения во всех проверенных тестах, но это не то, что меня особенно интересует.

С Диспетчером задач, открытым на Win7, обе версии приложения демонстрировали аналогичную активность на всех четырех (виртуальных) ядрах на моей i3-машине, которые затем все сбрасывались до минимума по завершении.

Итак, мой вопрос: компилятор C# и Visual Studio, в частности, уже оптимизированы для нескольких ядер? а если нет, я пропустил что-то фундаментальное?

ответ

0

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

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

Если вы видите такое же использование процессора для обоих однопоточных и многопоточных кода, там может быть несколько причин для этого (только угадывание, так как я не знаю код):

  • Вы используете слишком мало/слишком много потоков
  • Disk I/O Су много, что все выгоды от потоков вымываются
  • у вас есть так много других процессов/потоков, выполняющихся в системе, что они мешают с вашим измерением

Возможно, существует ряд других причин, но, как упоминает ответ Аллан Элдер, вы можете попробовать попробовать библиотеку Parallels - он попытается выбрать оптимальное количество потоков для вашего кода на основе различных факторов. Это делает использование потоков намного проще, так как код шаблона для подключения потоков выполняется для вас.

Когда я делал подобную обработку файлов изображений, используя несколько потоков, я сократил время обработки на 40% (хотя я загрузил большинство изображений в память - они не были потоковыми, поэтому I/O не был таким же фактором). В моем случае использование ядра было намного лучше с многопоточным подходом - это было 8 ядер против 1 ядра.

+0

Я только что включил все свои тесты и выключил файлы журнала и снова запустил: 20 секунд против 35. Так что, моя производительность тонула в дисковых вводах-выводах, как ожидалось. Я уже установил большую часть этого, но спасибо, что поставил его так ясно. Я в основном хотел проверить, что я ничего не пропустил. – FlyingWeagle

1

Вы ищете TPL; Параллельная библиотека задач.

В частности, вы можете использовать оператор Parallel.ForEach для обработки ваших файлов.

Смотрите здесь: http://msdn.microsoft.com/en-us/library/dd460720.aspx

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