В MIT разработана схема эффективного распараллеливания общих алгоритмов

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

С алгоритмами, которые используют распространенную структуру сведений, называемую очередью по приоритетам (priority queue), такая прямая пропорциональность сберегается примерно до восьми ядер, но с дальнейшим добавлением ядер рост быстродействия замедляется. Причина заключается в том, что к началу очереди, сформированной по приоритетности, одновременно пытаются обратиться многие ядра. Возникающие конфликты тормозят вычисления — иногда на многие порядки величины.

На февральском симпозиуме ACM по принципам и практике параллельного программирования, ученые из лаборатории CSAIL (Computer Science and Artificial Intelligence Laboratory) Массачусетского технологического института (MIT) расскажут о новом способе применения приоритетных очередей. В симуляциях алгоритмы с такой структурой сведений продолжали демонстрировать рост быстродействия с увеличением числа ядер до 80.

Для достижения этого аспиранты MIT Джастин Копински (Justin Kopinsky) и Джерри Ли (Jerry Li) ослабили требование, обязующее ядра выбирать элемент, стоящий в начале очереди. Если все первые элементы обязаны обрабатываться параллельно, распределение по ядрам способен выполняться случайным образом.

В этом случае каждое ядро должно знать, где находится назначенная ему информация. Осуществить это не так просто как кажется, поскольку для удобства манипулирования очереди организованы в виде связанного списка (linked list), включающего значение каждого элемента и указатель на адрес следующего. Для того, чтобы вставить новейший элемент между 2-мя другими требуется поменять только 2 указателя, в противном случае пришлось бы обновлять адреса для всей оставшейся очереди.

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

Для ликвидации подобных заторов, сотрудники MIT применили так называемый список пропусков (skip list), строящий иерархию связанных списков поверх основного. На каждом следующем уровне количество элементов списка снижается вдвое. Чтобы найти элемент в корневом списке, довольно следовать указателям верхнего списка пока не обнаружится промежуток, в котором находится нужный элемент, затем спуститься на уровень ниже и повторить процедуру, и так далее, пока не будет достигнут корневой список.

В такой схеме конфликты также смогут возникать, к примеру, если ядро модифицирует элемент, присутствующий на нескольких уровнях иерархии, но их вероятность существенно уменьшается.
Новости науки >>
Добавил KonstantinVC KonstantinVC 4 Февраля 2015
проблема (1)
Комментарии участников:
vmizh
+1
vmizh, 4 Февраля 2015 , url
Довольно прямолинейное решение. Получилось, потому что памяти становится все больше и больше. Но реально работающее — это уже не плохо :)
dinga
0
dinga, 4 Февраля 2015 , url
Всегда trade off, выйгрыш по времени за счет увеличения памяти.
Закон сохранения почти ;))
vmizh
+1
vmizh, 4 Февраля 2015 , url
В общем — да. Но бывают прорывы. :) Здесь пошли напрямую.
dinga
+1
dinga, 4 Февраля 2015 , url
Опять же, теоретически можно прикрутить и более сложную data structure и получить чудеса, но вопрос в реализации, пусть предъявят работающий «ящик» с прогонкой каких-нибудь вызывающих доверие бенчмарков из «общих алгоритмов» с 80% экономией по времени, и… станут миллиардерами ;)
vmizh
+1
vmizh, 4 Февраля 2015 , url
като так — да :)
Flinky
0
Flinky, 4 Февраля 2015 , url
В порядке бреда — почему бы не воспользоваться системой блокировок, как это сделано в СУБД?
Ядро, захватившее элемент очереди вычислений, накладывает на него блокировку. Следующее ядро ищет ближайший к нему свободный элемент. Адреса обновляются по факту снятия одной или нескольких ближайших к началу очереди блокировок — это можно подобрать экспериментально. Само-то по себе место в очереди особого значения не имеет, когда с ней работают сразу несколько ядер.
nikcpp
0
nikcpp, 4 Февраля 2015 , url
так втом то и проблемма что к одной очереди обращаюся несколько ядер
С алгоритмами, которые используют распространенную структуру сведений, называемую очередью по приоритетам (priority queue), такая прямая пропорциональность сберегается примерно до восьми ядер, но с дальнейшим добавлением ядер рост быстродействия замедляется. Причина заключается в том, что к началу очереди, сформированной по приоритетности, одновременно пытаются обратиться многие ядра. Возникающие конфликты тормозят вычисления — иногда на многие порядки величины.
Flinky
0
Flinky, 4 Февраля 2015 , url
Тут мысля отказаться от приоритетов вообще. Выделяем список блокировок, и заставляем ядро обращаться сначала к нему, чтобы узнать, к какому элементу нужно обратиться — это будет ближайший к первому заблокированному. Ядро тут же блочит этот элемент и работает с ним. И так со всеми ядрами. Когда блокировка/несколько блокировок сняты — адреса пересчитываются. Короче, мне думается, что надо не разрешать коллизии, а избегать их возникновения.
Serge51
+1
Serge51, 4 Февраля 2015 , url
Видимо, с поиском ближайшего и есть проблемы.


Войдите или станьте участником, чтобы комментировать