caxapa.ru :: Параллельное программирование в виндах. Пытаюсь разобраться.

Evgeny_CD, Архитектор (01.12.2011 20:38, просмотров: 9336)

Параллельное программирование в виндах. Пытаюсь разобраться. Есть API операционки для работы с потоками. Есть OpenMP http://ru.wikipedia.org/wiki/OpenMP Intel Threading Building Blocks http://ru.wikipedi …eading_Building_Blocks Есть Pthreads-w32, правда непонятно, нахрена. В 2006 заглохло. http://sources.red …at.com/pthreads-win32/ Есить великий и ужасный boost http://ru.wikipedi …1%82%D0%B5%D0%BA%D0%B0) И еще много чего есть. У меня вопрос - а накуя они есть? Если какое-то приложение написано под ОСь, и в эту ОСь встроен механизм управления потоками (покажите мне ОСь, где его нет...), то зачем нужные еще какие-то либы? Какой от них толк? Или они работают быстрее? Или они как-то пытаются автоматизировать управление потоками? Чем из перечисленного (или чем другим) стоит пользоваться на Win x64? А что-то похожее в C# есть?

Ответить

- "для программирования многопоточных приложений на многопроцессорных системах с общей памятью", что несколько отличается от многопоточности на одном ядре - Vit(02.12.2011 11:14)
  - Многопоточность на одном ядре вообще не имеет смысла с точки зрения ускорения вычислений. - =AlexD=(02.12.2011 11:17)
    - Как мы знаем, при одном ядре многопоточность приводит только к увеличению расхода памяти и увеличению числа процессорных тактов на единицу полезной работы. Но тонкость состоит в том, что она приводит к уменьшению затрат на разработку, вот все ее и Evgeny_CD(7 знак., 02.12.2011 13:08)
      - Тут просто нужно отделять мух от котлет. Модульность, вытесняемость и надёжность - отдельно, ускорение числомолотилки за счёт распараллеливания вычислений - отдельно. - =AlexD=(02.12.2011 13:32)
    - согласен. 640 ядер должно хватить каждому(С):) - Vit(02.12.2011 11:20)
- Я те абисню, зачем опен-мп. Берёшь интеловский компилёр, берёшь свою прогу, подсовываешь компилёну ключ -Qopenmp и ... всё. Он в меру своего разумения сам раскидает крупные циклы по потокам. Ну а если ты на столько крут, что выучил десяток #pragma =AlexD=(387 знак., 02.12.2011 07:11 - 07:14, ссылка)
  - Я это понимаю так. OS-многопоточность ничего не требует от компилятора - что программер написал, что он и сгенерил. И сводится такая многопоточность к достаточно общим правилам программирования и наличию некоторого количества функций. Evgeny_CD(546 знак., 02.12.2011 08:58)
    - Ну да, в том и кайф, что это фактически расширение общераспространённого языка. Но вообще, компилятор там не сильно много делает - просто разбивает цикл на куски и вызывает функции опен-мпишной либы. Работы не больше чем для обычной оптимизации. - =AlexD=(02.12.2011 10:40)
      - Теже самые функции можно и руками вызвать, если "чувствуешь в себе силы" :-) - =AlexD=(02.12.2011 10:42)
        
        Так вот вопрос - в чем отличие этих функций от функций Pthreads, к примеру. - Evgeny_CD(02.12.2011 10:47)
        
        Ну одно - стандартизируется гигантами индустрии и поддержано компиляторами, другое пилится непонятно кем непонятно зачем. - =AlexD=(02.12.2011 10:53)
        
        Спрошу по другому. Предположим, я включил моск, и им распараллелил свою прогу. Потом закодил это распараллеливание на Pthreads и на OpenMP, вызывая функции этих "либ" и максимально используя идеологию обоих стандартов. Какой код будет работать Evgeny_CD(449 знак., 02.12.2011 11:02)
        
        Если ты включил моск, то пофигу :-), а компилятору нужна либа с тем пространством имён, которое он знает :-) Жень, ну глянь ты доку, там же в инструментарии не только либа, но и разные тулзы для кодоанализа, конечно всё это заточено исключительно =AlexD=(30 знак., 02.12.2011 11:13)
        
        Снова спрошу по другому. Разработал я стандарт EvgenyOpenMP. В него входят: Evgeny_CD(743 знак., 02.12.2011 13:15)
        
        GCC тоже умеет опен-мп'ить, поэтому смысл затеи от меня ускользает. - =AlexD=(02.12.2011 13:28)
        
        Я ничего разрабатывать не буду. Это модель была. Я просто в OpenMP пытаюсь отделить средства разметки кода, средства его анализа, средства комиляции и библиотеку. Т.е. я в упор не могу понять, почему после разбора и компиляции нужно обращаться к Evgeny_CD(324 знак., 02.12.2011 14:03)
        
        Думаю, просто синдром "фатального недостатка". - Скрипач(02.12.2011 14:20, ссылка)
        
        По той же причине, по которой вместе с С/С++ компилятором поставляются стандартные библиотеки, а не скажем boost. Заметь, это при том, что надёжность, производительность, продуманность и полнота стандартной либы вызывает много вопросов. =AlexD=(36 знак., 03.12.2011 09:50)
        
        Разве что... - Evgeny_CD(02.12.2011 15:01)
- мож OpenCL ?? - Adept(01.12.2011 23:41)
  - Оно пока вроде как токо для видюх существует, насколько я понимаю -> - Evgeny_CD(02.12.2011 08:49, ссылка)
    - А так? Д.ARMоед(03.12.2011 00:19)
      - Я сильно впечатлился! Это отличается от изначальной темы топика, но респект большущий! Блин, народ движется к единой среде исполнения. И получается масштабирумо: многоядерный проц -> GPU -> FPGA. Evgeny_CD(111 знак., 03.12.2011 09:48)
        
        Смотрим кадр 18, а потом кадр 8(HPS) от альтеры из цитатника.. Д.ARMоед(1417 знак., 03.12.2011 11:08 - 04.12.2011 19:50)
        
        По Event-B едем туда. -> - Evgeny_CD(03.12.2011 14:53, ссылка)
      - Собственно, цитатник тут -> Д.ARMоед(60 знак., 03.12.2011 00:27 - 01:31, ссылка, ссылка)
    - Интель обещался (а может и есть уже) её поддержку для многопроцессорности х86 в т.ч. с поддержкой SSE/AVX. - =AlexD=(02.12.2011 10:46)
      - Тама токо C99 - старье :) - Evgeny_CD(02.12.2011 10:48)

Средства и методы разработки