Где баланс между количеством потоков и временем блоков потоков?

Question

Удлиненный вопрос:
При наличии большего количества блокирующих потоков, чем ядер ЦП, где находится баланс между количеством потоков и временем блоков потоков, чтобы максимизировать эффективность ЦП за счет сокращения издержек переключения контекста?

У меня есть множество устройств ввода-вывода, которые мне нужно контролировать в Windows 7, с многоядерным процессором x64: PCI-устройства, сетевые устройства, вещи, сохраняемые на жесткие диски, большие куски копируемых данных, .. Наиболее распространенной политикой является: «Положите поток на это!». Спустя несколько десятков тем это начинает казаться плохой идеей.

Ни одно из моих ядер не используется на 100%, и есть несколько ядер, которые все еще не работают, но есть задержки, отображающиеся в диапазоне от 10 до 100 мс, которые не могут быть объяснены блокировкой ввода-вывода или интенсивным использованием ЦП. Другие процессы тоже не требуют ресурсов. Я подозреваю, что переключение контекста связано с издержками.

У меня есть куча возможных решений:

• Сокращение потоков за счет объединения одних и тех же устройств ввода-вывода: в основном это касается жесткого диска, но, возможно, и сети. Если я сохраняю 20 МБ на жестком диске в одном потоке, а 10 МБ - в другом, не лучше ли разместить все это в одном файле? Как это будет работать в случае нескольких жестких дисков?
• Сократите потоки, связав аналогичные устройства ввода-вывода, и увеличьте его приоритет: десятки потоков с повышенным приоритетом, вероятно, вызовут заикание потоков в моем пользовательском интерфейсе. Но я могу объединить всю эту функциональность в один или несколько потоков и увеличить ее приоритет.

Любые тематические исследования, посвященные аналогичным проблемам, высоко ценятся.

Answer 1

Во-первых, похоже, что эти задачи должны выполняться с использованием асинхронного ввода-вывода (предпочтительно портов завершения ввода-вывода), а не с отдельными потоками. Блокировка потоков, как правило, является неправильным способом ввода / вывода.

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

Answer 2

10-100 мс с простоями некоторых ядер: это не накладные расходы на переключение контекста, поскольку коммутатор на несколько порядков быстрее, чем эти задержки, даже при перестановке ядра и очистке кэша.

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

Вам не хватает процессора, так что же это? Много ли побоев - нехватка оперативной памяти? Чрезмерный пейджинг может привести к большим задержкам. Где ваш файл подкачки? Я перенес свой диск с диска C на другой быстрый диск SATA.

пропускная способность PCI? У вас там есть пара телевизионных карт?

Операция очистки контроллера диска - есть ли у вас SSD, который приближается к емкости? Это всегда хорошо для необъяснимых пауз. Я получаю странную паузу, хотя мой 128G SSD заполнен только на 2/3.

У меня никогда не было проблем, конкретно связанных со временем смены контекста, и я десятилетиями писал многопоточные приложения. Операционная система Windows довольно быстро планирует и отправляет готовые потоки на ядра. Само по себе «несколько десятков потоков» (т.е. не все запущены!) Не является проблемой удаленно - теперь, глядя на мой TaskManger / производительность, у меня загружено 1213 потоков и вообще нет проблем с производительностью ~ 6% загрузки ЦП, (приложение в тестовом режиме работает в фоновом режиме, BitTorrent и т.д.). Firefox имеет 30 потоков, VLC media player 27, мое тестовое приложение 23. Нет проблем при написании этого поста.

Учитывая вашу проблему с задержками в 10-100 мс, я был бы удивлен, если работа с приоритетами потоков и / или изменение способа загрузки вашей работы в потоки дает какое-то улучшение - что-то еще наполняет вашу систему (у вас нет какие-нибудь драйверы, которые я написал, не так ли? :).

Дает ли perfmon какие-либо подсказки?

Rgds, Martin

Answer 3

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

Answer 4

Я не думаю, что есть окончательный ответ, и это, вероятно, зависит также от вашей ОС;некоторые обрабатывают темы лучше, чем другие.Тем не менее, задержки в диапазоне от 10 до 100 мс не связаны с самим переключением контекста (хотя они могут быть связаны с характеристиками алгоритма планирования).Мой опыт работы с Windows заключается в том, что ввод-вывод очень неэффективен, и если вы делаете ввод-вывод любого типа, вы будете блокировать.И этот ввод / вывод одним процессом или потоком в конечном итоге блокирует другие процессы или потоки.(Например, в Windows, вероятно, нет смысла иметь более одного потока для обработки жесткого диска. Вы не можете читать или записывать несколько секторов одновременно, и у меня сложилось впечатление, что Windows не оптимизирует доступ, как некоторые другиесистемы делают.)

Что касается ваших точных вопросов:

"Если я сохраню 20 МБ на жестком диске в одном потоке, а 10 МБ в другом, не будет ли лучшеотправить все это в одно и то же? »: зависит от ОС.Как правило, при использовании отдельных потоков не должно быть никакого сокращения времени или задержки, и в зависимости от других действий и ОС может быть улучшение.(Если в наличии несколько запросов к диску, большинство ОС оптимизируют доступ, переупорядочивая запросы для уменьшения движения головы.) Самое простое решение - попробовать оба варианта и посмотреть, какой из них лучше работает в вашей системе.

«Как это будет работать в случае нескольких жестких дисков?»: ОС должна иметь возможность выполнять ввод / вывод параллельно, если запросы поступают на разные диски.

Что касается увеличения приоритета одного илибольше тэдов, это очень зависит от ОС, но, вероятно, стоит попробоватьЕсли в потоках с более высоким приоритетом не используется значительное время ЦП, это не должно влиять на пользовательский интерфейс - эти потоки в основном блокируются для ввода-вывода, помните.