| проектирование многопоточных приложений | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Studentus | |
| Дата: | 27.12.07 10:29 |
| подскажите плизз что-бы почетать по сабжу? |
| Re: проектирование многопоточных приложений | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Sashaka | |
| Дата: | 27.12.07 11:21 | |
| Оценка: | 2 (1) | |
| Здравствуйте, Studentus, Вы писали: S>подскажите плизз что-бы почетать по сабжу? здесь ![]() |
| Re: проектирование многопоточных приложений | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Кодт модератор | |
| Дата: | 27.12.07 11:34 | |
| Оценка: | 3 (1) | |
| Re[2]: проектирование многопоточных приложений | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Studentus | |
| Дата: | 27.12.07 11:41 |
| Здравствуйте, Кодт, Вы писали: К>А если без размаха, то скажи, зачем тебе многопоточность — чтобы можно было более прицельно что-нибудь предложить. спасибо! многопоточное перекодирование аудио-видео контента грубо говоря сервер/конвертер из многих нестандартных кодеков в стандартные/поддерживаемые pstn железом |
| Re: проектирование многопоточных приложений | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Sergey | |
| Дата: | 27.12.07 12:45 | |
| Оценка: | +1 | |
| "Studentus" <57799@users.rsdn.ru> wrote in message news:2781607@news.rsdn.ru... > подскажите плизз что-бы почетать по сабжу? А кстати не знает ли кто каких-нибудь практически полезных формализмов для многопоточности? Posted via RSDN NNTP Server 2.1 beta Собака бывает кусачей только от жизни собачей | |
| Re[2]: проектирование многопоточных приложений | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Alex_Avr | |
| Дата: | 27.12.07 13:42 | |
| Оценка: | 9 (2) | |
| Здравствуйте, Sergey, Вы писали: S>"Studentus" <57799@users.rsdn.ru> wrote in message news:2781607@news.rsdn.ru... >> подскажите плизз что-бы почетать по сабжу? S>А кстати не знает ли кто каких-нибудь практически полезных формализмов для многопоточности? Patterns for Concurrent, Parallel, and Distributed Systems С уважением, Александр Авраменко. | |
| Re[2]: проектирование многопоточных приложений | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Didro | home~pages |
| Дата: | 27.12.07 14:02 | |
| Оценка: | 8 (1) | |
| Здравствуйте, Sergey, Вы писали: S>"Studentus" <57799@users.rsdn.ru> wrote in message news:2781607@news.rsdn.ru... >> подскажите плизз что-бы почетать по сабжу? S>А кстати не знает ли кто каких-нибудь практически полезных формализмов для многопоточности? Несильно формальная модель взаимодействия задач Р.Бара, была реализована в языке Ада, основана на концепции рандеву, но отличается от CSP Хоара тем, что не является исчислением процессов, отсюда и меньшая формальность. Сети Петри А вообще честно-говоря, практически полезный формализм — это, имхо, парадокс Советую также посмотреть среду и почитать доки проекта Ptolemy II (www.ptolemy.org), там множество формализмов параллельного взаимодействия, разного уровня абстракции. Но Ptolemy II — это прежде всего среда моделирования, есть некоторая возможность генерации кода, но в зачаточном состоянии. Возвращаясь к исходному вопросу — считать ли, например, блок-схемы практически полезным формализмом ? Если да — то, пожалуйста, есть ПБС — Параллельные блок схемы. Или тот же UML — полезный формализм или нет ? Вот у меня лично не было опыта применения формализмов с пользой для дела, может проекты мелковаты или "процессы не поставлены" С наступающим ! |
| Re[3]: проектирование многопоточных приложений | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Sergey | |
| Дата: | 27.12.07 14:04 |
| > S>А кстати не знает ли кто каких-нибудь практически полезных формализмов для многопоточности? > > Patterns for Concurrent, Parallel, and Distributed Systems Я вообще не паттерны и идиомы имел в виду, а алгебры или что-нибудь в этом роде. Т.е., средства, позволяющие, скажем, сочинив очередное решение задачки про обедающих философов, быстро и гарантированно узнать, что именно придумалось — программа с дедлоками, "голодание" или нормально работающее решение. Posted via RSDN NNTP Server 2.1 beta Собака бывает кусачей только от жизни собачей | |
| Re[4]: проектирование многопоточных приложений | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Didro | home~pages |
| Дата: | 27.12.07 14:07 |
| Здравствуйте, Sergey, Вы писали: >> S>А кстати не знает ли кто каких-нибудь практически полезных формализмов для многопоточности? >> >> Patterns for Concurrent, Parallel, and Distributed Systems S>Я вообще не паттерны и идиомы имел в виду, а алгебры или что-нибудь в этом роде. Т.е., средства, позволяющие, скажем, сочинив очередное решение задачки про обедающих философов, быстро и гарантированно узнать, что именно придумалось — программа с дедлоками, "голодание" или нормально работающее решение. Вот конкретно для этой задачи отлично подходит Ptolemy II (см. мой ответ выше) |
| Re[3]: проектирование многопоточных приложений | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Sergey | |
| Дата: | 27.12.07 14:51 |
| > Несильно формальная модель взаимодействия задач Р.Бара, была реализована в языке Ада, основана на концепции рандеву, но отличается от CSP Хоара тем, что не является исчислением процессов, отсюда и меньшая формальность. > > Сети Петри > > А вообще честно-говоря, практически полезный формализм — это, имхо, парадокс Например булева алгебра в целом и теорема де Моргана в частности — вполне себе практически полезные формализмы. Позволяют не морща мозг писать (a && b) вместо !(!a || !b) > Вы, наверное, имели ввиду все-таки реализации формализмов взаимодействия потоков в библиотеках и языках ? Не, я математический аппарат хочу. Чтобы, нарисовав табличку/диаграмку/формулу про некий код, построенный, например на мьютексах, кондишенах или других популярных примитивах, можно было бы тупо посчитать, чего у меня в программе случится плохого. > Тогда: Ада (Задачи Бара), MC# (Join-исчисление процессов), CCS(Join-исчисление), X10. Есть безусловно и другие реализации различных формализмов. На Join-исчисление я где-то натыкался (разглядывая boost::join, кажется), но, честно говоря, практического смысла в нем не увидел. Смотрел правда невнимательно, может оно и вправду полезное... А что за задачи Бара? Где про них почитать можно? А то гугл ничего отличного от таскбаров и просто баров кажись не выдает X10 — это вот это: http://domino.research.ibm.com/comm/research_projects.nsf/pages/x10.index.html ? > Советую также посмотреть среду и почитать доки проекта Ptolemy II (www.ptolemy.org), там множество формализмов параллельного взаимодействия, разного уровня абстракции. Но Ptolemy II — это прежде всего среда моделирования, есть некоторая возможность генерации кода, но в зачаточном состоянии. Спасибо, посмотрю. > Возвращаясь к исходному вопросу — считать ли, например, блок-схемы практически полезным формализмом ? Если да — то, пожалуйста, есть ПБС — Параллельные блок схемы. Или тот же UML — полезный формализм или нет ? Вот у меня лично не было опыта применения формализмов с пользой для дела, может проекты мелковаты или "процессы не поставлены" Насчет блок-схем не знаю... Если по ним можно сказать, есть ли в программе гонки или дедлоки — тогда подходят. Posted via RSDN NNTP Server 2.1 beta Собака бывает кусачей только от жизни собачей | |
| Re[4]: проектирование многопоточных приложений | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Didro | home~pages |
| Дата: | 27.12.07 15:29 | |
| Оценка: | 24 (3) | |
| Здравствуйте, Sergey, Вы писали: >> Несильно формальная модель взаимодействия задач Р.Бара, была реализована в языке Ада, основана на концепции рандеву, но отличается от CSP Хоара тем, что не является исчислением процессов, отсюда и меньшая формальность. >> >> А вообще честно-говоря, практически полезный формализм — это, имхо, парадокс S>Например булева алгебра в целом и теорема де Моргана в частности — вполне себе практически полезные формализмы. Позволяют не морща мозг писать (a && b) вместо !(!a || !b) Хорошо, есть алгебра процессов Хоара (в рамках его теории взаимодействующих процессов — CSP) — как пример, см. здесь. С помощью этой штуки можно сделать достаточно много, но в ней не учитывается время — только логические связи и следовательно будут проблемы в задачах, где это время есть (где время нужно учитывать и нельзя абстрагироваться от времени). Кроме того есть хороший, открытый архив с книгами мэтров программирования — здесь. В этом архиве есть как работы Дейкстры, Хоара по параллельному программированию, так и работы Глушкова (см. ниже), правда не все и его работ по параллельному программированию (по дискретным систмам) я там не видел. >> Вы, наверное, имели ввиду все-таки реализации формализмов взаимодействия потоков в библиотеках и языках ? S>Не, я математический аппарат хочу. Чтобы, нарисовав табличку/диаграмку/формулу про некий код, построенный, например на мьютексах, кондишенах или других популярных примитивах, можно было бы тупо посчитать, чего у меня в программе случится плохого. Есть ещё отечественная супер-пупер разработка Есть книжка: Капитонова Ю.В., Летичевский А.А. Математическая теория проектирования вычислительных систем — 1988. Из оглавления (приведу только избранные разделы): Глава 1. Дискретные системы — Алгебра языков — Конечные системы — Многокомпонентные системы — Автоматы — Дискретные преобразователи Глава 2 Алгоритмы — Параллельные алгоритмы Глава 3 Рекурсивные определения Глава 4 Структуры данных — Функциональные структуры данных — Многоосновные структуры данных Глава 5 Архитектура ЭВМ — Не-неймовские ЭВМ Глава 6 Проектирование последовательных программ Глава 7 Распределенные многопроцессорные системы — Принцип макроконвейра — Макроконвейерные сети — Проектирование распределенных программ — Динамическое распараллеливание посл.программ Из оглавления конечно не все видно, но там 80% сплошная дискретная математика приметительно к параллельному программированию. >> Тогда: Ада (Задачи Бара), MC# (Join-исчисление процессов), CCS(Join-исчисление), X10. Есть безусловно и другие реализации различных формализмов. S>На Join-исчисление я где-то натыкался (разглядывая boost::join, кажется), но, честно говоря, практического смысла в нем не увидел. Смотрел правда невнимательно, может оно и вправду полезное... Можете посмотреть тут — www.mcsharp.net или здесь. Повторюсь, что Join-исчисление прежде всего интересно как концепция для построения языков программирования. S>А что за задачи Бара? Где про них почитать можно? А то гугл ничего отличного от таскбаров и просто баров кажись не выдает Вот книжка здесь. (2.8mb) S>X10 — это вот это: http://domino.research.ibm.com/comm/research_projects.nsf/pages/x10.index.html ? Ага. S>Насчет блок-схем не знаю... Если по ним можно сказать, есть ли в программе гонки или дедлоки — тогда подходят. Дедлоки можно, с гонками будут проблемы. |
| Re[4]: проектирование многопоточных приложений | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | remark | http://groups.google.com/group/lock-free |
| Дата: | 27.12.07 16:01 | |
| Оценка: | 10 (2) | |
| Здравствуйте, Sergey, Вы писали: >> S>А кстати не знает ли кто каких-нибудь практически полезных формализмов для многопоточности? >> >> Patterns for Concurrent, Parallel, and Distributed Systems S>Я вообще не паттерны и идиомы имел в виду, а алгебры или что-нибудь в этом роде. Т.е., средства, позволяющие, скажем, сочинив очередное решение задачки про обедающих философов, быстро и гарантированно узнать, что именно придумалось — программа с дедлоками, "голодание" или нормально работающее решение. Таких средств нет и для последовательных программ. Т.е. ты не можешь скормить какому-то средству программу, ввести описание требуемого результата (как?), и получить ответ, является ли это корректной программой для данной задачи. И вобщем-то ничего такого и не предвидится. Что уж говорить о параллельных программах. А так, в принципе, все доказывают корректность параллельных алгоритмов так же как и математике. Утверждения. Леммы. Теоремы. Леммы. Теоремы. Двигаясь маленькими шажками к цели. Но быстрым этот метод точно нельзя назвать. Например смотри раздел Correctness Proof в следующих статьях: http://research.sun.com/scalable/pubs/DynamicWorkstealing.pdf http://delivery.acm.org/10.1145/880000/872049/p102-shalev.pdf?key1=872049&key2=5869078711&coll=&dl=ACM&CFID=15151515&CFTOKEN=6184618 http://www.cse.yorku.ca/~ruppert/papers/lfll.pdf Всё о параллелизме. На русском. |
| Re: проектирование многопоточных приложений | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | don ASKet | |
| Дата: | 27.12.07 16:07 | |
| Оценка: | 20 (1) | |
| Здравствуйте, Studentus, Вы писали: S>подскажите плизз что-бы почетать по сабжу? ну и мои 5 капель Меняю два проигрывателя, на один выигрватель! Возможна доплата... ;) | |
| Re[5]: проектирование многопоточных приложений | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Sergey | |
| Дата: | 27.12.07 20:28 |
| Здравствуйте, remark, Вы писали: S>>Я вообще не паттерны и идиомы имел в виду, а алгебры или что-нибудь в этом роде. Т.е., средства, позволяющие, скажем, сочинив очередное решение задачки про обедающих философов, быстро и гарантированно узнать, что именно придумалось — программа с дедлоками, "голодание" или нормально работающее решение. R>Таких средств нет и для последовательных программ. Т.е. ты не можешь скормить какому-то средству программу, ввести описание требуемого результата (как?), и получить ответ, является ли это корректной программой для данной задачи. R>И вобщем-то ничего такого и не предвидится. Что уж говорить о параллельных программах. Я не имею в виду автоматические средства. Была бы интересна некая система записи + набор формальных действий, которые с этой записью можно производить. Чтобы не решать задачку "без иксов" (http://offline.computerra.ru/2001/409/12218/), перенапрягая свой слаборазвитый мозг, когда можно просто составить пару уравнений. R>А так, в принципе, все доказывают корректность параллельных алгоритмов так же как и математике. Утверждения. Леммы. Теоремы. Леммы. Теоремы. Двигаясь маленькими шажками к цели. Но быстрым этот метод точно нельзя назвать. Доказывать очень по разному можно. Доказательства, подобные машинному доказательсву гипотезы 4-х красок, меня не интересуют — мне ведь не за доказательства деньги платят. R>Например смотри раздел Correctness Proof в следующих статьях: R>http://research.sun.com/scalable/pubs/DynamicWorkstealing.pdf Увы, я может чего не понимаю, но доказательство вызывает у меня нехорошую ассоциацию — как будто некто решил доказать тождество булевских функций, просто перебрав область определения и сравнив значения... 75 пунктов — это, конечно, не гипотеза 4-х красок, вполне обозримо, но все равно несколько напрягает. R>http://delivery.acm.org/10.1145/880000/872049/p102-shalev.pdf?key1=872049&key2=5869078711&coll=&dl=ACM&CFID=15151515&CFTOKEN=6184618 R>http://www.cse.yorku.ca/~ruppert/papers/lfll.pdf В этих двух доказательства поскипаны... А вот всякие там temporal algebra, π-calculus, CSP-algebra и прочие красивые слова, которых я не знаю — они как, к реальному коду применимы или чисто игрушка для теоретиков? Собака бывает кусачей только от жизни собачей | |
| Re[5]: проектирование многопоточных приложений | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Sergey | |
| Дата: | 27.12.07 21:09 |
| Здравствуйте, Didro, Вы писали: D>Хорошо, есть алгебра процессов Хоара (в рамках его теории взаимодействующих процессов — CSP) — как пример, см. здесь. С помощью этой штуки можно сделать достаточно много, но в ней не учитывается время — только логические связи и следовательно будут проблемы в задачах, где это время есть (где время нужно учитывать и нельзя абстрагироваться от времени). Значит CSP таки лучше прочитать. Кстати, не знаете, полного электронная версия русского перевода где-нибудь в свободном доступе есть? Мне только первая половина попадалась. S>>На Join-исчисление я где-то натыкался (разглядывая boost::join, кажется), но, честно говоря, практического смысла в нем не увидел. Смотрел правда невнимательно, может оно и вправду полезное... D>Можете посмотреть тут — www.mcsharp.net или здесь. Повторюсь, что Join-исчисление прежде всего интересно как концепция для построения языков программирования. Ну на плюсах насколько я понял Join-исчисление при желании реализуется как библиотека. Осталось понять, что оно дает... S>>А что за задачи Бара? Где про них почитать можно? А то гугл ничего отличного от таскбаров и просто баров кажись не выдает D>Вот книжка здесь. (2.8mb) Спасибо, будет что на "каникулах" почитать. Собака бывает кусачей только от жизни собачей | |
| Re[6]: КАР ХОАР | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | remark | http://groups.google.com/group/lock-free |
| Дата: | 28.12.07 07:31 |
| Здравствуйте, Sergey, Вы писали: S>Здравствуйте, remark, Вы писали: S>>>Я вообще не паттерны и идиомы имел в виду, а алгебры или что-нибудь в этом роде. Т.е., средства, позволяющие, скажем, сочинив очередное решение задачки про обедающих философов, быстро и гарантированно узнать, что именно придумалось — программа с дедлоками, "голодание" или нормально работающее решение. R>>Таких средств нет и для последовательных программ. Т.е. ты не можешь скормить какому-то средству программу, ввести описание требуемого результата (как?), и получить ответ, является ли это корректной программой для данной задачи. R>>И вобщем-то ничего такого и не предвидится. Что уж говорить о параллельных программах. S>Я не имею в виду автоматические средства. Была бы интересна некая система записи + набор формальных действий, которые с этой записью можно производить. Чтобы не решать задачку "без иксов" (http://offline.computerra.ru/2001/409/12218/), перенапрягая свой слаборазвитый мозг, когда можно просто составить пару уравнений. Просто это не будет в любом случае. Т.к. либо доказательство какой-то простой вещи будет состоять из нескольких тривиальных шагов, но тогда и смысла в доказательстве практического нет, т.к. и так всё понятно. Например, доказательства корректности программы, которая берет и складывает 2 числа. Либо доказательство будет типа того, что я приводил в первой ссылке. Я лично вижу очень мало практического смысла в таких доказательствах и не читаю их, и искренне жалею того, кто это писал В принципе можешь поглядеть эту книгу: http://www.williamspublishing.com/Books/5-8459-0388-2.html Она в любом случае является хорошем введением в параллельные алгоритмы. Плюс автор практически сразу вводит некую формальную нотацию записи параллельных алгоритмов. Поэтому в коде постоянно присутствуют некие "инварианты", и выкладки-доказательства. Скорее всего это то, что ты хочешь. Опять же повторюсь, я достаточно скептически отнёсся к этому (видимо потому что я — инженер, а не математик). Для тривиальных вещей и доказательство тривиальное и "смешное". А для каких-то сложных и больших алгоритмов, со сложным нетривиальным инвариантом, непонятно можно ли записать доказательство за конечное время, т.к. что бы в то же время было очевидно, что это доказательство именно того, что требуется, а не просто некая цепочка математически верных формул. Т.е. что верность этого доказательства является достаточным условием верности самого алгоритма. Плюс ко всему непонятно, как верифицировать само доказательство, т.к. оно обычно на порядок длинее алгоритма. Что собственно ставит под сомнение всю идею — проще уж неформально верифицировать алгоритм, чем формально верифицировать алгоритм, а потом неформально верифицировать на порядок более сложное доказательство R>>Например смотри раздел Correctness Proof в следующих статьях: R>>http://research.sun.com/scalable/pubs/DynamicWorkstealing.pdf S>Увы, я может чего не понимаю, но доказательство вызывает у меня нехорошую ассоциацию — как будто некто решил доказать тождество булевских функций, просто перебрав область определения и сравнив значения... 75 пунктов — это, конечно, не гипотеза 4-х красок, вполне обозримо, но все равно несколько напрягает. Там как раз не перебор, а формулы. А что ты хочешь? Доказательство всегда на порядок-два больше самого утверждения. Вспомни любую математическую теорему. Т.ч. если ты смотришь на формальное доказательства, как на средство снижения сложности задачи, то... S>А вот всякие там temporal algebra, π-calculus, CSP-algebra и прочие красивые слова, которых я не знаю — они как, к реальному коду применимы или чисто игрушка для теоретиков? А аналогичные средства для последовательных программ? Фактически тут принципиальной разницы нет. Ответь для себя про последовательные алгоритмы, получишь ответ и для параллельных алгоритмов. Возможно, если бы мне пришлось писать "софт для ядерной станции", то я прибегнул к формальным доказательствам, даже после внимательного кодирования, пеер-ревью и тонны тестов. А так это имхо для теоретиков. Кто-нибудь знает софт, который сделал этот КАР ХОАР? Всё о параллелизме. На русском. |
| Re[6]: Fork/Join | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | remark | http://groups.google.com/group/lock-free |
| Дата: | 28.12.07 09:15 | |
| Оценка: | 44 (3) | |
| Здравствуйте, Sergey, Вы писали: S>>>На Join-исчисление я где-то натыкался (разглядывая boost::join, кажется), но, честно говоря, практического смысла в нем не увидел. Смотрел правда невнимательно, может оно и вправду полезное... D>>Можете посмотреть тут — www.mcsharp.net или здесь. Повторюсь, что Join-исчисление прежде всего интересно как концепция для построения языков программирования. S>Ну на плюсах насколько я понял Join-исчисление при желании реализуется как библиотека. Осталось понять, что оно дает... Fork/Join сейчас является одной из самых распространённых методик для построения параллельных алгоритмов. Так же его называют параллельным Divide&Conquer (разделяй и властвуй). Идея следующая. Большая задача разделяется на несколько меньших. Потом эти ещё деляться на меньшие. И так до тех пор, пока задача не становится тривиальной, тогда она решается последовательным методом. Этот этап называется Fork. Далее [опционально] идёт процесс "свёртки", когда решения маленьких задач объединяются некоторым образом пока не получится решение самой верхней задачи. Этот этап называется Join. Решения всех подзадач (в т.ч. и разбиений на меньшие задачи) происходит параллельно. В принципе для решения некоторых задач этап Join не требуется. Например, для параллельного QuickSort — тут мы просто рекурсивно делим массив на всё меньшие и меньшие диапазоны, пока не дойдём до тривиального случая из 1 элемента. Хотя в некотором смысле Join нужен и тут, т.к. нам всё равно надо дождаться пока не закончится обработка всех подзадач. Что поглядеть. Не буду ходить очень далеко в прошлое или вдаваться в теорию. CilkРасширение для языка С. Реализовано в виде препроцессора и небольшого ран-тайм. Появилось в первой половине 90-х, активно развивалось до 2000, сейчас находится в стабильной версии. Одна из самых эффективных библиотек для параллельного программирования. Самый любимый алгоритм, который реализовывают и на котором меряются пиписьками, создатели параллельных систем — рассчёт N-ого числа Фибоначи методом грубой силы. Вот пример на Cilk:
Собственно Fork/Join схема — это единственная схема, возможная в Cilk. Т.е. авторы сделали ставку исключительно на эту модель. Подроднее здесь: The Cilk Project Cilk Papers Cilk 5.4.6 Reference Manual Качать здесь: http://supertech.csail.mit.edu/cilk/cilk-5.4.6.tar.gz Сейчас на основе Cilk разработан JCilk (соотв. для Java) и Cilk++ (для С++). JCilk Java Fork/Join FrameworkРазработана Doug Lea (который сделал dlmalloc). АФАИК Является пропоузалом для включения в спецификацию Ява (возможно уже включён — не слежу). Единственный вид параллелизма — тоже только Fork/Join. Подроднее здесь: Java Fork/Join Framework Качать здесь: http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/current/concurrent.tar.gz http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/current/concurrent.zip Пример Фибоначи:
Task Parallel Library (Parallel Extensions to .NET)Это соотв. параллельные расширения для .NET. Тут уже возможена не только Fork/Join схема, но параллельность по данным и общая параллельность по задачам. Подроднее здесь: Optimize Managed Code For Multi-Core Machines [ANN] Task Parallel Library (Parallel Extensions to .NET) Автор: remark Дата: 06.12.07 Качать здесь: http://www.microsoft.com/downloads/details.aspx?FamilyID=e848dc1d-5be3-4941-8705-024bc7f180ba&displaylang=en К сожалению примера Фибаначи не прилагается, но выглядел бы он примерно так же. Вот коротенький пример:
Intel Threading Building BlocksОпять библиотека для С++. Опен сорц. Так же как и Task Parallel Library помимо Fork/Join так же предоставляет параллельность по данным и общая параллельность по задачам. Подроднее здесь: TBB Home TBB Overview TBB Code Samples Качать здесь: http://threadingbuildingblocks.org/file.php?fid=77 Вот пример суммирования значений в дереве с помощью Fork/Join:
Несмотря на то, что Task Parallel Library и Intel Threading Building Blocks предоставляют так же возможность создания алгоритмов с параллелизмом по данным и с общим параллелизмом по задачам, фактически это просто надстройки над Fork/Join. Параллелизм по данным реализуется как одноразовый неявный Fork нескольких подзадач и потом неявный Join. Параллельность по задачам — это просто Fork без Join. Надеюсь вопросов, что такое Fork/Join больше не осталось Всё о параллелизме. На русском. |
| Re[7]: Fork/Join | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Sergey | |
| Дата: | 28.12.07 10:25 |
| > S>>>На Join-исчисление я где-то натыкался (разглядывая boost::join, кажется), но, честно говоря, практического смысла в нем не увидел. Смотрел правда невнимательно, может оно и вправду полезное... > > D>>Можете посмотреть тут — www.mcsharp.net или здесь. Повторюсь, что Join-исчисление прежде всего интересно как концепция для построения языков программирования. > Fork/Join сейчас является одной из самых распространённых методик для построения параллельных алгоритмов. Так же его называют параллельным Divide&Conquer (разделяй и властвуй). Что такое Divide&Conquer я в курсе и со схемой Fork/Join знаком. Сдается мне, речь просто идет о разных вещах. Посмотрите вот этот доклад: http://research.microsoft.com/~nick/polyphony/polyphonytoplasfinal.pdf Там используется совсем другой набор примитивов (вернее, я разглядел пока всего один примитив — аккорд), из которых при желании можно построить хоть те же read-write мьютексы. Штука интересная, но вот насчет ее практической полезности я что-то сомневаюсь. По меньшей мере, перед тем как ее применять, придется опять мозги набок выворачивать, как с метапрограммированием на шаблонах Posted via RSDN NNTP Server 2.1 beta Собака бывает кусачей только от жизни собачей | |
| Re[8]: Fork/Join | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | remark | http://groups.google.com/group/lock-free |
| Дата: | 28.12.07 11:26 |
| Здравствуйте, Sergey, Вы писали: >> S>>>На Join-исчисление я где-то натыкался (разглядывая boost::join, кажется), но, честно говоря, практического смысла в нем не увидел. Смотрел правда невнимательно, может оно и вправду полезное... >> >> D>>Можете посмотреть тут — www.mcsharp.net или здесь. Повторюсь, что Join-исчисление прежде всего интересно как концепция для построения языков программирования. >> Fork/Join сейчас является одной из самых распространённых методик для построения параллельных алгоритмов. Так же его называют параллельным Divide&Conquer (разделяй и властвуй). S>Что такое Divide&Conquer я в курсе и со схемой Fork/Join знаком. Сдается мне, речь просто идет о разных вещах. Посмотрите вот этот доклад: http://research.microsoft.com/~nick/polyphony/polyphonytoplasfinal.pdf Там используется совсем другой набор примитивов (вернее, я разглядел пока всего один примитив — аккорд), из которых при желании можно построить хоть те же read-write мьютексы. Штука интересная, но вот насчет ее практической полезности я что-то сомневаюсь. По меньшей мере, перед тем как ее применять, придется опять мозги набок выворачивать, как с метапрограммированием на шаблонах На беглый взгляд:
async == cilk (из Cilk) matching == continuation (из Cilk) Возможно тут и есть некоторые новые идеи, но видимо ничего принципиального... Всё о параллелизме. На русском. |