Одной из наиболее важных вещей, на которую следует обратить внимание при написании многопоточных приложений, является его производительность. Существует ряд общих проблем с производительностью, с которыми будут сталкиваться большинство разработчиков многопоточных приложений. Они включают в себя, такие шаблонные как oversubscription, сериализация, блокировка, а также неравномерное распределение рабочей нагрузки. У нас есть сведения о некоторых из этих шаблонных проблем параллельного программирования. Мы называем эти шаблоны "
Rogues Gallery". Мы планируем расширить этот список шаблонных ошибок на основе материалов сообщества разработчиков и публиковать новые ошибки, возможные при параллельном программировании.
В этой заметке я расскажу oversubscription. В случае oversubscription, количество потоков пытающихся встать на выполнение превышает число доступных логических ядер. Это излишнее дробление нагрузки приводит к дополнительным ненужным переключениям контекста. Переключение контекста имеют ненулевой стоимости и особенно ресурсо-емких, когда поток переходит на выполнение, на другое ядро.
Чтобы было более понятно, объясню на простом примере. В данном примере, я буду решать одну и туже задачу, используя четыре потока, а затем туже задачу десятью потоками. Моя машина имеет четыре ядра и я знаю, что создание десяти потоков бессмысленно. Первые два изображения демонстрируют деятельность четырех потоков со статистикой в видимой профилировке по времени. Вторые два изображения показывают поведение системы, когда для решения той же проблемы используются десять потоков, а также связанная с ними профилировка по времени.
Использую 4 потока (3.41 sec)
Использую 10 потоков (4.84 sec)
После запусков сценариев с различным количеством потоков, я сравнил оба сценариях, и обнаружили, что в среднем, при использовании четырех потоков задача решена примерно за 3,41 секунды, а при использовании десяти потоков примерно за 4,84 секунды. В этом примере мы столкнулись с тем, что существует значительно больший объем дополнительных переключений контекста, вызванные выполнением более нити на ядре. Большая части времени тратится потоком на ожидание ресурсов, которые будут ему предоставлены.
Легенда показывает, что на переключение контекста используется 4% времени для 4 потоков и 49% при использовании десяти потоков. Существует небольшие прерывания даже для четырех потоков и в связи с обработкой процессором других процессов, запущенные в системе. В связи с увеличением переключение контекста вызваны дополнительными потоками, десять — потоков выполняются медленнее. Если ваш алгоритм поддается распараллеливания и он не требует создания большего числа потоков, чем есть ядер, то лучше избегать oversubscription.
Это лишь один из многих возможных ошибок, приводящих к снижению производительности, которую надо иметь в виду при написании многопоточных приложений. Очень важно быть в курсе, какие проблемы параллелизма влияют на производительность вашего приложения. Concurrency Visualizer- это отличный способ быстро определить, существует ли такая ошибка в вашем приложении.
<от переводчика>Если кто знает как красиво и коротко перевести oversubscription, напишите вашу версию в комментариях. Не нашел как одним словом это перевести красиво. Хотя смысл то понятен, что оно значит, но красиво ведь надо перевести.</от переводчика>
комментарии (9)
и да, preemption — это не прерывания, а переключение контекста
2-Финансовые тексты -это одно. А тут не финансы ведь. Я думаю есть специализированный термин. Да и переподписка звучит если честно отвратительно и совершенно не понятно.
Надеюсь, кто нибудь предложит лучший вариант перевода.
Ну что это такое:
?
«Дефицит процессоров» или «нехватка процессоров».
VS -инструмент для разработки как для нативных приложений так и для .net. Оригинальная статья находится в блоге, где основной материал про .net 4.0 с примерами кода на C#. Отладка, профилирование, параллельное программирование на C# и прочее я думаю можно было бы перенести только в блог VS. Но не вижу причины, чем блог .Net хуже.
Назовите почему Вам этот блог не нравится, пожалуйста.