Главная Случайная страница


Полезное:

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


Категории:

АрхитектураАстрономияБиологияГеографияГеологияИнформатикаИскусствоИсторияКулинарияКультураМаркетингМатематикаМедицинаМенеджментОхрана трудаПравоПроизводствоПсихологияРелигияСоциологияСпортТехникаФизикаФилософияХимияЭкологияЭкономикаЭлектроника






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





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

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

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

  numThr
               
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 компьютера.

Date: 2015-12-12; view: 314; Нарушение авторских прав; Помощь в написании работы --> СЮДА...



mydocx.ru - 2015-2024 year. (0.006 sec.) Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав - Пожаловаться на публикацию