Здравствуйте
Если не трудно посоветуйте, на какие книги/статьи ориентироваться, чтобы начать программировать параллельно.
Интересует теория и практическая часть (не managed языки). И желательно что-нибудь актуальное (то есть не чистая теория, а как в реальных проектах принято 'задействовать все ядра').
На данный момент умею создать поток в линукс/windows, и знаю что модифицируемые данные, к которым имеют доступ более двух потоков, нужно защищать объектами синхронизации (максимум что я делал — переменная-флаг bool in_use). Собственно, все . Слышал и читал про OpenMP, усиленно продвигаемый Intel. Насколько он широко используется в современных C++ программах?. И насколько он поддерживается gcc?
Может, стоит на boost обратить внимание? Там, вроде, и кроссплатформенность сразу. Или другие библиотеки какие?
Может, есть какие-то хорошие книги где на пальцах объясняется для чего в ОС столько разнообразных примитивов синхронизации потоков? Где объясняется как правильно параллелить код.
Извините за наивный вопрос, но как вы пришли к параллельному программированию? Для меня это как переход от процедурного программирования к объектно ориентированному, без хорошего вступления не разберусь
Здравствуйте, Аноним, Вы писали: А>Если не трудно посоветуйте, на какие книги/статьи ориентироваться, чтобы начать программировать параллельно.
1. К.Ю. Богачев. Основы параллельного программирования — прекрасно написанная книга для студентов.
2. Грегори Р. Эндрюс. Основы многопоточного, параллельного, распределенного программирования — ИМХО лучшее введение в предмет.
3. QNX/UNIX. Анатомия параллелизма — блестящая книга.
Ну и Рихтер, конечно.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Аноним, Вы писали: А>Здравствуйте А>Если не трудно посоветуйте, на какие книги/статьи ориентироваться, чтобы начать программировать параллельно. А>Интересует теория и практическая часть (не managed языки). И желательно что-нибудь актуальное (то есть не чистая теория, а как в реальных проектах принято 'задействовать все ядра').
самый тру мультитрединг в GPGPU. литературы мало, зато искать долго не придется, почти все есть на сайте производителей
Здравствуйте, __kot2, Вы писали:
__>самый тру мультитрединг в GPGPU.
Это назвать multithreading-ом можно только с натяжкой.
На самом деле это подобие SIMD.
Много потоков выполняет одну и ту же программу, только каждый поток над своим набором данных.
Сделать так, чтоб разные потоки выполняли разные программы нельзя в принципе.
Здравствуйте, Аноним, Вы писали:
А>Интересует теория и практическая часть (не managed языки). И желательно что-нибудь актуальное (то есть не чистая теория, а как в реальных проектах принято 'задействовать все ядра').
очень рекомнедую начать с "взаимодействие последовательных процессов". в проитвном солучае выправлять мозги после чтения "практических введений" будет уже поздно — это всё равно что учить человека программированию начав с ассемблера вместо ml
Здравствуйте, <Аноним>, Вы писали:
А>Здравствуйте А>Если не трудно посоветуйте, на какие книги/статьи ориентироваться, чтобы начать программировать параллельно. А>Интересует теория и практическая часть (не managed языки). И желательно что-нибудь актуальное (то есть не чистая теория, а как в реальных проектах принято 'задействовать все ядра').
В основно теория, но по-существу. Детально описываются подходы к параллельному программированию, возникающие трудности и как с ними борются. Разбирается большое количество примеров. После книги легче будет работать с реальным библиотеками/комиляторами — становится понятно для чего сделан тот или иной примитив/метод.
А>Слышал и читал про OpenMP, усиленно продвигаемый Intel. Насколько он широко используется в современных C++ программах?. И насколько он поддерживается gcc? А>Может, стоит на boost обратить внимание? Там, вроде, и кроссплатформенность сразу. Или другие библиотеки какие?
ИМХО, OpenMP широко применяется. Поддерживается основными компиляторами (в т.ч. и gcc). Основной подход — распараллеливание с помощью директив, обычно распараллеливание циклов.
Есть еще библиотека MPI, тоже часто используется. Работает на основе приема/передачи сообщений. Часто используется для распределенного программирования. Можно использовать вместо или вместе с OpenMP.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, __kot2, Вы писали:
__>>самый тру мультитрединг в GPGPU. CC>Это назвать multithreading-ом можно только с натяжкой. CC>На самом деле это подобие SIMD. CC>Много потоков выполняет одну и ту же программу, только каждый поток над своим набором данных. CC>Сделать так, чтоб разные потоки выполняли разные программы нельзя в принципе.
можно двумя способами.
Здравствуйте, __kot2, Вы писали:
__>>>самый тру мультитрединг в GPGPU. CC>>Это назвать multithreading-ом можно только с натяжкой. CC>>На самом деле это подобие SIMD. CC>>Много потоков выполняет одну и ту же программу, только каждый поток над своим набором данных. CC>>Сделать так, чтоб разные потоки выполняли разные программы нельзя в принципе. __>можно двумя способами.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, __kot2, Вы писали:
__>>>>самый тру мультитрединг в GPGPU. CC>>>Это назвать multithreading-ом можно только с натяжкой. CC>>>На самом деле это подобие SIMD. CC>>>Много потоков выполняет одну и ту же программу, только каждый поток над своим набором данных. CC>>>Сделать так, чтоб разные потоки выполняли разные программы нельзя в принципе. __>>можно двумя способами.
CC>С какой версии?
с любой
когда у вас код выполняется в десятки тысяч потоков у вас писалка отвалится писать код для каждого потока. но никто вам не мешает писать специфичный код для конкретного потока или разбить потоки на группы, где в каждой группе будет выполняться свой код
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, __kot2, Вы писали:
__>>>>можно двумя способами. CC>>>С какой версии? __>>с любой
CC>Ок. Дано: Tesla C2050 CC>Как на нёй одновременно запустить 2 разных кода. Скажем один на 80 ядрах и второй на оставшихся 368ми.
в реальных приложениях так в общем-то не делают, так как оно обычно и не нужно, но принципиальной тут никакой особой сложности нет
правда, мыслить стоит не "рекламными" ядрами, а мультипроцессорами, коих в 5870 20 штук, а в тесле не знаю сколько, тоже примерно так же. каждый мультипроц какбэ может работать независимо от других, храня контекст и свитчась в мультитрединге между морем тредов, но есть некоторые ограничения
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, Аноним, Вы писали: А>>Если не трудно посоветуйте, на какие книги/статьи ориентироваться, чтобы начать программировать параллельно. LVV>1. К.Ю. Богачев. Основы параллельного программирования — прекрасно написанная книга для студентов. LVV>2. Грегори Р. Эндрюс. Основы многопоточного, параллельного, распределенного программирования — ИМХО лучшее введение в предмет. LVV>3. QNX/UNIX. Анатомия параллелизма — блестящая книга. LVV>Ну и Рихтер, конечно.
Добавлю:
Новая книжка по многоядерному программированию — неплохая: http://www.ozon.ru/context/detail/id/5137578/
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте А>Если не трудно посоветуйте, на какие книги/статьи ориентироваться, чтобы начать программировать параллельно. А>Интересует теория и практическая часть (не managed языки). И желательно что-нибудь актуальное (то есть не чистая теория, а как в реальных проектах принято 'задействовать все ядра').
А>На данный момент умею создать поток в линукс/windows, и знаю что модифицируемые данные, к которым имеют доступ более двух потоков, нужно защищать объектами синхронизации (максимум что я делал — переменная-флаг bool in_use). Собственно, все . Слышал и читал про OpenMP, усиленно продвигаемый Intel. Насколько он широко используется в современных C++ программах?. И насколько он поддерживается gcc?
А>Может, стоит на boost обратить внимание? Там, вроде, и кроссплатформенность сразу. Или другие библиотеки какие?
А>Может, есть какие-то хорошие книги где на пальцах объясняется для чего в ОС столько разнообразных примитивов синхронизации потоков? Где объясняется как правильно параллелить код.
А>Извините за наивный вопрос, но как вы пришли к параллельному программированию? Для меня это как переход от процедурного программирования к объектно ориентированному, без хорошего вступления не разберусь
А>Спасибо!
Как уже говорилось, "QNX/UNIX. Анатомия параллелизма" — очень хорошая книга.