Comments 8
Ээ… Неинформативно как-то.
Обычно на графиках коэффициент ускорения в зависимости от числа потоков рисуют, и делают выводы.
Часто ещё полезно видеть коэффициент ускорения в зависимости от размера задачи (технологии параллелизма начинают быть эффективными только от некоторого размера).
Добрый день, согласен с Вашими замечаниями, но статья писалась в первую очередь для того, что бы показать, что сейчас все платформы практически одинаково справляются с многопоточными задачами решаемыми с применением OpenMP. На просторах часто ставился вопрос о применении OpenMP в разных ОС, а люди просили графики сравнения, отвечая на эти вопросы была написана данная статья.
Ну уж не «все платформы» конечно. а Win и Lin на Intel с неизвестным компилятором по вашей статье. Операционным системам, технологиям процессора, компиляторам и Open MP десятки лет. Как минимум, было бы странно, если бы этот стек не смог бы амортизировать на синтетической задаче всего лишь несколько потоков.
На реальной задаче может быть крайне трудным отжимать эффективность потоков по разным причинам, статья не должна вводить в заблуждение. И уж точно результаты не стоит масштабировать на реальные задачи или системы с сотнями потоков.
Удачи Вам в HPC исследованиях.
На реальной задаче может быть крайне трудным отжимать эффективность потоков по разным причинам, статья не должна вводить в заблуждение. И уж точно результаты не стоит масштабировать на реальные задачи или системы с сотнями потоков.
Удачи Вам в HPC исследованиях.
сейчас все платформы практически одинаково справляются с многопоточными задачами <...>
Но ведь из графиков следует, что WSL как раз справляется хуже, чем просто Windows.
Кода нет… Непонятно что сравнивается.
Настроек OpenMP нет — значит by default, статический шедулинг.
И что мы меряем? Время создания пула потоков?
Настроек OpenMP нет — значит by default, статический шедулинг.
И что мы меряем? Время создания пула потоков?
Спасибо автору за статью. Было бы интересно посмотреть на сам код и понять, что скрывается за секункдами в данном примере (GB/s, GFlops).
Буквально 2 месяца назад занимался сравнение скорости работы библиотек thrust (TBB, OpenMP, CUDA) и bohrium (OpenMP, OpenCL) с реализацией в CUDA. Тестировали базовые вещи: reduce, transpose и stencil. Reduce считает сумму элементов, transpose транспонирует матрицу, про stencil лучше почитать тут.
Буквально 2 месяца назад занимался сравнение скорости работы библиотек thrust (TBB, OpenMP, CUDA) и bohrium (OpenMP, OpenCL) с реализацией в CUDA. Тестировали базовые вещи: reduce, transpose и stencil. Reduce считает сумму элементов, transpose транспонирует матрицу, про stencil лучше почитать тут.
Результаты reduce: Х ось - количество элементов, Y ось - GB в секунду
Уважаемый автор статьи, приятно читать на Хабре, что люди интересуются параллельными вычислениями и OpenMP в частности. Однако, это все, что можно сказать положительного о вашей статье. Вы делаете очень резкие и громкие выводы без всяких на то оснований в виде фактических данных. Конкретнее (повторю некоторые из вещей, сказанных другими комментаторами выше):
1) Без конкретного кода, указанных настроек OpenMP разговора о каких-то выводах речи быть не может.
2) Без указания модели компилятора и параметров компиляции — то же самое. Кроме того, не стоит забывать, что даже один и тот же компилятор на одном и том же коде может вести себя по-разному на разных ОС на одной и той же машине.
3) Когда мы говорим об OpenMP — эта парадигма не ограничивается простым #pragma omp parallel for. В OpenMP разных спецификаций очень много инструкций, которые позволяют делать крутые вещи. В том числе, распараллеливать довольно трудный для параллельных вычислений код.
4) Процессор, на котором вы тестировали код имеет 4 ядра и 8 потоков. Для простого для распараллеливания кода (такого как вычисления числа пи) не имеет никакого смысла идти дальше 8 потоков. А, скорее всего, и четырех — ваши графики это собственно и показывают.
5) Такие графики необходимо строить в логарифмическом масштабе по оси времени (y) — будет гораздо понятнее. И очень сложно воспринимать графики, так как у вас WSL меняет цвет (красный и зеленый на первом и втором графике)
To sum it up: выводы должны основываться на фактах, а не на мнении. Ибо и мнение должно быть обосновано фактами. Особенно, если это мнение довольно противоречивое и ОБЩЕЕ.
1) Без конкретного кода, указанных настроек OpenMP разговора о каких-то выводах речи быть не может.
2) Без указания модели компилятора и параметров компиляции — то же самое. Кроме того, не стоит забывать, что даже один и тот же компилятор на одном и том же коде может вести себя по-разному на разных ОС на одной и той же машине.
3) Когда мы говорим об OpenMP — эта парадигма не ограничивается простым #pragma omp parallel for. В OpenMP разных спецификаций очень много инструкций, которые позволяют делать крутые вещи. В том числе, распараллеливать довольно трудный для параллельных вычислений код.
4) Процессор, на котором вы тестировали код имеет 4 ядра и 8 потоков. Для простого для распараллеливания кода (такого как вычисления числа пи) не имеет никакого смысла идти дальше 8 потоков. А, скорее всего, и четырех — ваши графики это собственно и показывают.
5) Такие графики необходимо строить в логарифмическом масштабе по оси времени (y) — будет гораздо понятнее. И очень сложно воспринимать графики, так как у вас WSL меняет цвет (красный и зеленый на первом и втором графике)
To sum it up: выводы должны основываться на фактах, а не на мнении. Ибо и мнение должно быть обосновано фактами. Особенно, если это мнение довольно противоречивое и ОБЩЕЕ.
Sign up to leave a comment.
Сравнение OpenMP на различных платформах