Программирование на Visual C++. Архив рассылки
Шрифт:
"Живые
Конечно же нельзя забывать о том, что "живые объекты" привносят в программу проблемы синхронизации доступа к свойствам объекта. Особенно это относится к сложным типам данных наподобие std::vector. Однако было бы ошибкой думать, что базовые типы данных не нуждаются в синхронизации доступа к ним. Хотя на массово распространенных сейчас однопроцессорных системах подобное пренебрежение синхронизацией может не вызывать проблем, но на многопроцессорных системах последствия могут быть самыми неожиданными. Так что лучше не уподобляться тем программистам, которые были уверены, что их программы к 2000-му году уже не будут использоваться.
Одновременное выполнение нескольких потоков только кажется параллельным. На самом деле количество потоков, работающих параллельно, прямо зависит от количества процессоров. Само собой, что на однопроцессорной системе в каждый момент времени работает только один поток. Процессорное время распределяется между потоками диспетчером потоков операционной системы. Конечно же переключение между потоками, так же называемое переключением контекста процессора, не бесплатно с точки зрения процессорного времени. Это связано с тем, что контекст процессора включает в себя некоторое количество информации, например состояние регистров процессора, а перемещение любого количества информации отнимает процессорное время.
Что же вызывает переключение контекста? Вариантов всего два – или поток отдает управление операционной системе добровольно, посредством вызова одной из соответствующих функций, или операционная система сама отбирает управление у потока по истечении минимального разумного времени, называемого time slice.
Теперь перечислю собственно вопросы, побудившие меня провести ряд экспериментов, и, в конечном итоге, написать эту заметку.
1. Каковы издержки на явное переключение контекста? Как они зависят от количества потоков в программе?
2. Как влияет на производительность многопоточной программы наличие в системе дополнительного процессора?
3. Как зависит производительность многопоточной программы от конкретной операционной системы?
4. Какие существуют ограничения на количество потоков в программе?
Сразу хочу оговориться, что тестовая программа имитирует систему, активно использующую "живые объекты", описанные в начале заметки. Это связано с тем, что меня интересовали вышеперечисленные вопросы применительно именно к "живым объектам". Для многопоточных программ с другой логикой организации работы потоков результаты испытаний могут быть другие. Так же прошу принять во внимание, что замеры не проводились с лабораторной тщательностью, и поэтому нужно сделать скидку на определенную погрешность в цифрах. Для компиляции использовался Visual C++ 6 SP5.
Тестовая программа создает заданное количество "живых объектов", которые все вместе выполняют фиксированный объем вычислений, и замеряет общее время выполнения. Вычисления выглядят следующим образом – в цикле вызывается библиотечная функция 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 потоками, после чего рост продолжается более-менее плавно.