Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Многопоточное програмирование.doc
Скачиваний:
4
Добавлен:
14.11.2019
Размер:
332.8 Кб
Скачать

3.1.2. Масштабируемость

Но одной лишь производительностью характеристики MT приложений не заканчиваются. Еще одним ключевым параметром является масштабируемость (scalability), т.е. способность приложения увеличивать производительность адекватно количеству задействованных ресурсов. Время исполнения не использующего параллелизм ST приложения будет увеличиваться пропорционально заданному объему работы, в то время как правильно спроектированное MT приложение будет способно выполнять работу на всех доступных процессорах параллельно и в идеальном случае увеличение количества процессоров, например, в два раза должно в два раза уменьшать затрачиваемое на тот же объем работы время.

В нашем случае каждый запущенный поток должен выполнить один и тот же объем работы, т.е. при отсутствии параллелизма (напр. когда приложению доступен только один процессор) общее время работы приложения будет увеличиваться (не менее чем) прямо пропорционально количеству рабочих потоков, задаваемых параметром numThr. С другой стороны, в случае идеального параллелизма, время работы приложения должно уменьшиться в количество раз, равное количеству задействованных процессоров.

Разобраться с масштабируемостью нам поможет следующая таблица. Значения в ячейках рассчитаны по формуле t(N)/t(1)/N. Т.е. время работы приложения с количеством рабочих потоков равным N делится на время, затраченное одним потоком, а затем на количество потоков. Тем самым мы измеряем относительное отклонение времени работы нашего MT приложения от обычного однопоточного варианта (факт. ST приложения).

numThr

1

2

3

4

5

6

7

8

1 CPU

std

1.000

1.007

1.036

1.132

1.232

1.284

1.322

1.393

ders

1.000

0.997

0.994

0.997

0.999

1.004

1.004

1.003

1 CPU, HT

std

1.000

1.129

1.172

1.158

1.168

1.153

1.164

1.162

ders

1.000

1.405

1.401

1.403

1.395

1.413

1.409

1.400

2 CPU, SMP

std

1.000

3.165

3.381

3.148

3.274

3.143

3.193

3.182

ders

1.000

0.513

0.513

0.513

0.512

0.513

0.525

0.509

2 CPU, HT

std

1.000

3.755

3.804

4.017

4.076

4.081

4.134

4.158

ders

1.000

0.502

0.844

0.634

0.655

0.649

0.647

0.636

Ну а выглядят данные следующим образом:

1 CPU

1 CPU, HT

2 CPU, SMP

2 CPU, HT

Как можно видеть,

  1. 1 CPU. Функция start_ders демонстрирует практически идеальное соответствие эталонному однопоточному варианту, т.е. присутствующие механизмы синхронизации не вызывают заметных накладных расходов. С другой стороны, накладные расходы функции start_std практически линейно увеличиваются с ростом количества задействованных потоков, достигая в итоге значения 1.4.

  2. 1 CPU, Hyper-Threading. Накладные расходы функции start_std увеличиваются до трех задействованных потоков, а затем стабилизируются возле значения 1.2. Накладные расходы функции start_ders стабилизируются уже на двух потоках, но на более высоком значении 1.4. Т.е. в этом случае несмотря на заметно более высокую скорость работы (42 раза, т.е. 4200%), масштабируемость start_ders примерно на 17% хуже start_std, т.е.

Использование нескольких потоков на Hyper-Threading архитектуре для такого рода задач является неоправданным, т.к. однопоточное приложение заведомо быстрее справится с объемом данных!

  1. 2 CPU, SMP. А это первый случай, в котором скорость работы приложения превышает скорость эталонного однопоточного варианта (отношение времени работы меньше единицы). Функция start_std демонстрирует более-менее стабильную масштабируемость около значения 3,2 раза. При этом значения нечетного количества потоков чуть больше, а четных -- чуть меньше данной величины (вероятно, худшая масштабируемость нечетного количества потоков связана с необходимостью планирования их работы на четном количестве процессоров). С другой стороны, функция start_ders показывает практически идеальные 0,5+дельта, т.е. удвоение количества процессоров в два раза уменьшило затрачиваемое на работу время.

  2. 2 CPU, Hyper-Threading. Еще один малоприятный случай: хоть масштабируемость функции start_ders и меньше единицы, но демонстрируемый в среднем результат 0,65 заметно хуже предыдущего варианта и уж точно никак не похож на 0,25, которого можно было бы ожидать от полноценного 4 CPU, SMP компьютера.