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