LINUX.ORG.RU

теоритический вопрос по параллельному программированию


0

2

просто теоретическое рассуждение

скажем программа - и мультипроцессорная машина

в программе - есть определенный уровень параллельности
весьма много частей кода - обрабатывают разные независимые данные

вопрос - как сделать наиболее оптимальную параллельность ?
имеется ввиду весьма низко уровненная параллельность

скажем - по алгоритму - можно выделить 10-20 возможно параллельных участков - которые также динамически прибавляются-убавляются

так что - на каждый этот участок делать нить? которая тока и будет что сидеть и ждать свой семафор?


а что если сделать число нитей - равное число процессоров - и в каждой ните сделать внутренний шедуллер кусков кода и кусков данных - которые были бы описаны - описано их взаимовлияние
и по этом правилам - внутренний шедуллер и распределял бы задачи на реальные процессоры

что в данной ситуации являеться более оптимальным ?

★★

ну и еще вопрос - если ли в этом - какой та принципиальная и оч большая проблема в реализации
может кто сталкивался

ae1234 ★★ ()

какое программирование имеется ввиду? если вы говорите о параллельном программировании, то это скорее всего вам необходима использовать кластер и что-нибудь типа openMP / MPI. Если вы говорите о многопоточном приложении, то здесь совсем другой разговор.

Есть схемы по распараллеливанию вычислений. Я думаю в интернете вы без труда сможете это найти.

guilder ()

Если нить ждет своего семафора - про неё можно не вспоминать, а оптимальная схема, IMHO: количество активных процессов(нитей) = кол-во процессоров.

umbr ()
Ответ на: комментарий от umbr

ну да - но чтоб начать работать - семафор должны включить - а это должна сделать система - то есть свитчиться ей придется в ядро
а если идеть речь о очень низкоуровневом параллелизме - то это весь бонус съесть

ae1234 ★★ ()

весьма много частей кода - обрабатывают разные независимые данные

Это как так?

dizza ★★★★★ ()
Ответ на: комментарий от umbr

ну - просто (имхо) такая логика работы приложения вытекает из мультипроцессорности

обычьно в программах очень много паралельных участков кода - но их запаралелить - это уткнеться в оверхед что привносят мутексы и так далее

а что если изначально делать программу - блоками - и описывать взаимодействие блоков
типа - результат работы каких блоков пораждает условия на начала работы других блоков
посуществу этакая блок схема

ae1234 ★★ ()
Ответ на: комментарий от dizza

ну как как - вот пример

tcp сервер - принимает соединения - принимает данные - обрабатывает - и отсылает ответ - и ведет базу свою

сам select/poll/epoll - это четко выделенный блок - результаты которого (полученные события) - являются условием для работы след блока - который обрабатывает события

обработанные события - новые соединения или поступившие данные - иль запрос на выдачу данных - являются условием для работы блоков обработки данных иль выдачи данных иль обработка новых подключения

эти же блоки - являются источником работы для блока который ведет базу

и так далее

вот такая простая схема - уже пораждает 6-8 блоков - которые способны работать в параллель
причем часть блоков (ресурсоемкие и нетолько) - должны мочь работать в нескольких экземпляров

ae1234 ★★ ()
Ответ на: комментарий от ae1234

а какой плюс от этого ?
плюс в том - что такая система способна принять соединение - тутже отдать обработку этого соединения на другой процессор - и сразу опять слушать соединения

а проблема в том - что нехочеться на каждый блок делать отдельную нить - слишком много нитей - обрабатывать эти нити - куда как чаще ядро дергать (имхо)

ae1234 ★★ ()
Ответ на: комментарий от ae1234

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

dizza ★★★★★ ()
Ответ на: комментарий от dizza

> Ну для веба вообще все просто.

Итого идеальная модель параллельности это треды или процессы по количеству ядер

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

Или подразумевается, что тред, «занявший» ядро, сам занимается диспетчеризацией запросов?

oami ★★ ()
Ответ на: комментарий от oami

подразумеваеться что предварительно несколько нитей занимают места - и уже распределяют всю работу чисто между собой - минимально дергая систему

суть то вопроса - это лучше или хуже - чем обычьное решение для мультипроцессорности

ae1234 ★★ ()
Ответ на: комментарий от ae1234

> а что если изначально делать программу - блоками - и описывать взаимодействие блоков...
Идея неплохая, но писать такого диспетчера - задача нетривиальная :)

umbr ()
Ответ на: комментарий от ae1234

man OpenMP

Именно оно там и делается, только границы блоков определяют барьеры — точки кода, которые должны быть достигнуты всеми потоками прежде, чем программа будет исполняться дальше. Внутри блока — полный параллелизм.

annoynimous ★★★★★ ()
Ответ на: комментарий от ae1234

>а что если изначально делать программу - блоками - и описывать взаимодействие блоков типа - результат работы каких блоков пораждает условия на начала работы других блоков посуществу этакая блок схема

зачем вы заново придумали erlang?

s0ul ()
Ответ на: комментарий от annoynimous

> man OpenMP

Наверное, все-таки лучше конкретизировать задачу, не съест ли оверхед от OpenMP выигрыш от распараллеливания?

Хотя... раз вопрос ТС «чисто теоретический», то OpenMP тоже сгодится.

oami ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.