Тестовая программа создает заданное количество "живых объектов", которые все вместе выполняют фиксированный объем вычислений, и замеряет общее время выполнения. Вычисления выглядят следующим образом – в цикле вызывается библиотечная функция rand(), результат которой делится по модулю на некоторое число. Каждый "живой объект" выполняет количество итераций цикла равное общему количеству итераций, заданному для всей программы, поделенному на количество "живых объектов".
Каждые сто итераций цикла "живой объект" вызывает функцию Sleep(0), которая фактически форсирует переключение контекста и передачу управления другому потоку.
ПРЕДУПРЕЖДЕНИЕ
Без вызова функции Sleep тестовая программа не отражала бы изменение реальных затрат времени на переключение контекста в зависимости от количества "живых объектов". В этом случае количество переключений контекста примерно равнялось бы продолжительности выполнения программы деленному на размер time slice независимо от количества потоков. И, следовательно, из-за того, что количество переключений контекстов фиксировано, увеличение времени исполнения очень слабо зависит от количества потоков (разница продолжительности выполнения между 2 и 4096 потоками составляет менее 300мс на 2xPIII-1000 под Windows 2000 Professional при общей продолжительности работы программы около 3200мс).
Тестовая программа была запущена на нескольких конфигурациях, оказавшихся под рукой. Для удобства сравнения результатов выбирались конфигурации с одинаковыми процессорами. Результаты сведены в следующую таблицу:
Кол-во потоков 2xPIII-1000 Windows NT4 Server (мс|издержки) 2xPIII-1000 Windows 2000 Professional (мс|издержки) PIII-1000 Windows 2000 Professional (мс|издержки) PIII-1000 Windows XP Professional (мс|издержки) PIII-1000 Windows 98 SE (мс|издержки) 8192 8343 53% 8391 57% 16323 58% 15913 50% 4096 8500 56% 8328 56% 15172 47% 14961 41% 2048 8203 50% 7937 49% 14942 45% 14792 40% 1024 7843 44% 7796 46% 14731 43% 14611 38% 36776 208% 512 7562 39% 7593 42% 14431 40% 14411 36% 30632 156% 256 7547 38% 7281 36% 13620 32% 14081 33% 25273 112% 128 7328 34% 7281 36% 13619 32% 13940 32% 22971 92% 64 6671 22% 6609 24% 11917 16% 12348 17% 21254 78% 32 6547 20% 6016 13% 10616 3% 10926 3% 19911 67% 16 6000 10% 5922 11% 10515 2% 10825 2% 19323 62% 8 5984 10% 5875 10% 10515 2% 10805 2% 19184 61% 4 5968 9% 5906 11% 10515 2% 10775 2% 19124 60% 2 5453 0% 5344 0% 10415 1% 10746 1% 19087 60% 1 10703 10563 10315 0% 10595 0% 11943 0% Анализ результатов
Проанализируем таблицу, чтобы получить ответы на наши вопросы.
Каковы издержки на явное переключение контекста? Как они зависят от количества потоков в программе?Для двухпроцессорной системы два потока в программе дают оптимальную и максимально возможную производительность программы. Однако увеличение количества потоков приводит к постоянному увеличению времени выполнения программы на десять и более процентов. С другой стороны, на однопроцессорной системе увеличение количества потоков до 32 практически не сказывается на времени выполнения программы, после чего происходит резкий скачок на промежутке между 32 и 128 потоками, после чего рост продолжается более-менее плавно.
Сильно упрощая и обобщая результаты, можно сказать, что общие потери на переключение контекста процессора не будут превышать шестидесяти процентов на разумном количестве потоков (до 8192). Но даже такой упрощенный вывод необходимо уточнить:
1. Тестовая программа создает стрессовую ситуацию – каждый "живой объект" стремится подмять под себя все свободное процессорное время, но мы заставляем его быть менее прожорливым, вызывая принудительное переключение контекста вызовом Sleep(0). Реальные "живые объекты" требуют меньше процессорного времени, что выражается в вызове функции Sleep с параметром, отличным от нуля. Таким образом в реальной программе переключения контекста будут происходить реже, чем в нашем тесте, и, следовательно, потери времени будут меньше.
2. Наши рассуждения не относятся к линейке Windows 9x/ME. У операционных систем этого семейства отношения с многопоточностью крайне прохладные. Отсюда уточнение – если ваша программа будет активно использоваться под Windows 9x/ME, основательно работайте над эффективностью кода, так как потери во времени выполнения начинают превышать пятьдесят процентов уже после создания второго потока.
Как влияет на производительность многопоточной программы наличие в системе дополнительного процессора?Для более наглядного представления данных упростим вышеприведенную таблицу, объединив данные для двух- и однопроцессорных систем и отбросив результаты, полученные под Windows 98SE:
Кол-во потоков Двухпроцессорная система (мс) Однопроцессорная система Прирост производительности 8192 8367 16118 93% 4096 8414 15067 79% 2048 8070 14867 84% 1024 7820 14671 88% 512 7578 14421 90% 256 7414 13851 87% 128 7305 13780 89% 64 6640 12133 83% 32 6282 10771 71% 16 5961 10670 79% 8 5930 10660 80% 4 5937 10645 79% 2 5399 10581 96% 1 10633 10455 -2%
То есть прирост производительности всегда меньше, чем в два раза, независимо от количества потоков. В среднем прирост производительности составляет порядка 85 процентов. Возможно (и даже наверняка) эта цифра будет отличаться для других процессоров, в особенности для линейки Intel Xeon, которая славится улучшенной поддержкой многопоточности, а так же для систем с количеством процессоров больше двух.
Как зависит производительность многопоточной программы от конкретной операционной системы?Так как мы говорим о Win32, выбор операционных систем не очень велик – линейки Windows 9x/ME и Windows NT/2000/XP. Исходя из имеющихся данных, для Windows NT/2000/XP принципиальной разницы в производительности между всеми комбинациями NT/2000/XP и Workstation/Server нет, хотя, возможно, это будет опровергнуто дальнейшими испытаниями на других конфигурациях.
Результаты для Windows 98 SE говорят сами за себя. Ввиду того, что принципиальных изменений в ядро Windows 95 до сих пор внесено не было, можно смело утверждать, что эти результаты показательны для любой версии Windows 9x/ME.
Какие существуют ограничения на количество потоков в программе?Разумно предположить, что количество потоков в процессе ограничено ресурсами самого процесса, а так же ресурсами ядра операционной системы.
ПРИМЕЧАНИЕ
Все сказанное ниже справедливо для линейки Windows NT/2000/XP.
Один из основных ресурсов ядра операционной системы, потребляемый при создании потока, это невыгружаемая памяти (non-paged memory) ядра. Создание одного потока требует около 12 килобайт невыгружаемой памяти. Ограничения на размер пула невыгружаемой памяти устанавливается в следующем ключе системного реестра:
HKLMSystemCurrentControlSetControlSession ManagerMemory Management
параметрами NonPagedPoolQuota и NonPagedPoolSize. Их значение по умолчанию равно нулю, что отдает управление этими значениями в руки операционной системы.
