Время измерения для потоковой параллельной системы - PullRequest
0 голосов
/ 30 августа 2018

В стандартной настройке, когда один модуль работает с несколькими потоками, мы можем рассчитать время программы, используя реальное время (например, время настенных часов) и время потока (общее время, потраченное на все потоки, используемые модулем). Если в реальном времени мало, то у нас нет проблем. Программа быстро завершилась, и ее не нужно оптимизировать. Однако, если реальное время высокое, мы хотим уменьшить его, но мы не знаем, что замедляет программу: эффективность алгоритма или распараллеливание. Теперь мы можем использовать время потока, чтобы увидеть, какое время используется. Если время потока мало, распараллеливание необходимо оптимизировать. Если время потока велико, алгоритм должен быть оптимизирован.

Теперь это хорошо известно, и уже было сказано, что Что означают 'real', 'user' и 'sys' в выводе времени (1)?

Мы запускаем нашу программу в другом режиме. У нас огромное количество данных, поэтому нам нужно часто сохранять и загружать данные с диска, потому что мы не можем хранить их все в памяти одновременно. Чтобы максимально избежать ввода-вывода, мы транслируем одну точку данных одновременно через несколько модулей. Для пояснения на примере: у нас есть два модуля A и B и несколько данных D. Данные представляют собой набор точек данных d1, d2, .... Наш конвейер тогда определяется как:

disk -> d1 -> A -> d1' -> B -> d1'' -> disk
disk -> d2 -> A -> d2' -> B -> d2'' -> disk

и т. Д.

Теперь, чтобы добавить дополнительный слой, мы обнаружили, что модуль B работал медленно, поэтому распараллелил его, и он очень эффективен. ... если бы не тот факт, что мы больше не можем полагаться на наши измерения в реальном времени. Раньше у нас был таймер для каждого модуля, который запускался до вычисления заданной точки данных и затем приостанавливал ее. Теперь мы измеряем реальное время A и B, пока они работают одновременно.

ВОПРОС

Существует ли способ измерения времени для потоковой распараллеленной системы, позволяющий рассуждать о том, где оптимизировать и стоит ли сосредоточиться на эффективности алгоритма или распараллеливании?

1 Ответ

0 голосов
/ 30 августа 2018

Хотя конвейеры приносят большую пользу, проблема с ними связана с идентификацией и исправлением pipeline stalls. Из многих причин этого являются разные скорости отдельных этапов. Например, скажем, первая ступень работает быстрее и выдает данные каждую секунду, но если вторая ступень медленная и не может потреблять данные каждую секунду, то либо очередь будет накапливаться на стыке ступеней, либо первая ступень остановится / остановится до второй этап завершен обработкой предыдущих данных.

В зависимости от имплиментации, обнаружение может быть выполнено путем мониторинга очереди интерфейса или времени простоя / ожидания этапов. Средство почти всегда состоит из нескольких параллельных стадий медленного типа. Другое решение состоит в том, чтобы разделить медленную стадию на две последовательные, но более быстрые стадии.

...